代码托管换起来比想象中贵：不只是 git 历史，还有议题、评论、CI 配置、权限与集成。先算迁移成本，再比功能。
代码托管的选型看起来简单：能推能拉就行。但真正决定长期体验的，是协作功能和迁移成本。
按规模看
**个人项目**：要求最低。稳定、免费额度够用、能私有仓库即可。国内访问速度是实际考量，克隆慢会天天难受。
**三到十人**：开始需要议题、合并请求、代码评审、以及基本的 CI。这个规模最在意的是「能不能少配」，因为没人专职维护。
**十人以上**：需要权限分层、审计日志、分支保护、以及和公司账号体系（如企业目录）的对接。这一层开始出现合规要求。
迁移到底会丢什么
git 仓库本身好迁：`git clone --mirror` 再推过去，提交历史、分支、标签都在。
真正麻烦的是仓库之外的东西：
- **议题与评论**：多数平台能导出，但附件链接常常失效 - **合并请求的讨论**：部分平台只导出标题与状态，讨论内容丢失 - **CI 配置**：`.github/workflows` 这类文件跟着仓库走，但 runner 的密钥、环境变量不跟着走 - **Webhook 与集成**：机器人、通知、第三方挂钩要重新配 - **权限与团队**：成员、角色、团队分组要重建 - **包与制品**：如果用它托管私有包，迁移是单独一件事
一个务实的判断顺序
1. 团队在哪个平台已经有用例？优先复用，减少两套账号 2. 私有仓库的免费额度够不够？人数是主要变量 3. CI 免费额度够不够？分钟数常常先耗尽 4. 迁移成本有多大？把上面六项数一遍
自建值不值
自建（比如自托管方案）能解决合规与数据归属，但成本容易被低估：服务器、备份、升级、以及出问题时要有人修。三五个人的团队自建，通常是把时间花在了不产生价值的地方。
例外是两种情况：有强合规要求必须内网，或者团队里有人愿意长期维护。
一个容易被忽略的点
别把「代码托管」和「项目管理」混在一起用。有些平台两者都做，于是团队把所有议题、文档、排期都放进去。这时候迁移成本就不只是代码，而是整个工作流。
如果预见到可能要换平台，从一开始就把「决策记录」和「需求文档」放在可导出的地方（Markdown 文件、独立文档工具），代码平台只承担代码与评审。