Karte

可以戴耳塞. 耳塞很管用

合理, 主要有以下几点:

1. 一个功能一个分支：确保功能完整，便于问题回退，控制影响范围。合并到主线通过 MR ，git log 清晰记录提交范围。
2. 小提交原则：避免一次性提交完整功能。若功能开发中（已提交 5 次）遇 issue ，主线开发需选择回退（ revert ）或继续提交。前者需重新提交，后者可能因未完成功能导致主线无法运行。而一功能一分支、一 issue 一分支可快速切换修复 issue ，不受未完成功能影响。修复后，切回功能分支，rebase 解决冲突，继续开发。

假设你已经 commit (还未 push) 了 5 个 change, 功能还未开发完成. 这时突然出现一个 issue, 如果这个 feature 在主线而非分支. 那你是打算 revert 之前的提交, 还是直接修改继续提交 (6 个提交).
如果 revert, 那你得先 revert 之前的所有提交, 然后提交 issue, 之后还得重新 commit.
如果直接提交, 那你还未完成的 feature 也同步 push 到主线. 那很有可能会出现无法跑通的情况 (必尽你还未开发完成).

@recying5566 哈哈哈哈哈哈, 只要 6 万起, 能拉能运还便宜 [doge].

五菱宏光, 混动续航 1000KM +

https://www.bilibili.com/video/BV1SRo6Y2Eaf/

@heiya 首先大文件会占用过大的磁盘 IO, 如果云磁盘容量过低则 IOPS 也会很低.

在没有性能要求的情况下, 且数据库和 MINIO 不属于同台机器是可以使用 minio 的. 如果有性能要求, 那磁盘 IOPS 则会是瓶颈. 既然如此可以试试内网 OSS, 或者内网 S3. 内网的费用相对便宜实惠.


对于大文件是否需要 CDN 这个问题, 你得先明白 `CDN (Content Delivery Network)` 是什么. CDN 是一个内容分发网络, 将你提供的资源尽可能的靠近用户侧 (实际请求的用户, 例如 B 站的视频资源), 同时提供海量带宽.
如果你的文件不会频繁下载, 或者根本不会下载, 那 CDN 就不需要了. CDN 引入只会徒增成本 (资源成本 + 流量成本).

说实在的, 有 OSS 不用非得自己搭. 图啥啊?

自建存在以下问题:
- 安全措施 (即使 MINIO 有账户校验和链接校验, 但只要有漏洞数据就全丢了)
- 磁盘限制 (云厂商提供的硬盘是按照容量分配 IOPS 的, 你容量越小, IO 越小. 存个大文件直接把 IO 吃满了)
- 带宽限制 (你也说了带宽瓶颈了, 既然你是对外提供服务, 为什么不选择 CDN ?)
- 高可用 (自建没有现成的好)


PS: 如果只是出于学习的目的, 那尽管折腾.