源码是软件项目里最容易被忽略、又最要命的一项交付物。没有源码，你只能永远依赖原开发方：改一个功能、换一次服务器、接一个新系统，都要排队、报价、等档期。本文讲清三件事：源码要不要拿、以什么形式交付、拿不到时的兜底方案。
为什么源码必须拿
源码在手，你才能：
- 自行或委托第三方继续开发、修复与迁移；
- 在开发方失联、涨价、档期排不开时，业务不中断；
- 做技术尽调、安全审计与合规检查。
反过来，源码不在手，风险是隐性的：平时看不出来，一旦发生变动就变成"停摆级"问题。源码的意义不在于你自己会不会读，而在于你保留了对代码的控制权。
交付形式：不是"给个压缩包"就算
建议在合同里写清交付形式，至少包含：
- 完整可编译的源码仓库，含提交历史（便于追溯改动）
- 依赖清单与版本说明
- 构建脚本与部署文档
- 环境配置说明（开发、测试、生产三套环境的差异）
只给一份不含历史的最终快照，等于把维护的上下文全部丢掉：接手的人要从零理解代码，成本会大幅上升。
托管方式：三种常见安排
| 方式 | 做法 | 适用 |
|---|---|---|
| 直接交付 | 项目结束交付至甲方指定仓库 | 多数定制项目，最推荐 |
| 阶段性同步 | 按里程碑同步至甲方仓库 | 周期长、金额大的项目 |
| 第三方托管 | 代码托管于中立的托管平台，约定触发交付条件 | 开发方坚持不直接交付时 |
无论哪种，都要写明"触发条件"和"时限"，例如"甲方付清对应节点款项后 5 个工作日内完成同步"。
拿不到源码时的兜底
如果开发方坚持不交付源码，至少争取三件事：
- 代码托管：约定第三方托管，并写明触发交付的条件；
- 文档齐全：数据库设计、接口文档、部署手册必须交付；
- 禁止复用：明确本项目定制部分不得用于其他客户项目。
同时约定一条退出机制：若开发方无法继续维护，须在约定期限内配合完成交接。
交付验收时，这样验证源码是"真的能用"
- 在干净环境按文档完成一次构建，能成功
- 按部署文档在测试环境跑起来，功能正常
- 依赖清单与仓库实际一致，无缺失
- 提交历史完整，不是一次性导入
- 数据库结构与文档一致
源码交接时最常见的三个争议
争议一：给了代码，但跑不起来。常见原因是依赖没有锁定版本、环境配置没有文档化。解决办法是在验收时要求"在干净环境按文档完成一次构建"，跑通才算交付。
争议二：给了代码，但缺提交历史。一次性导入的快照看不出改动过程，接手的人无法追溯"某个功能为什么这样写"。要求交付含提交历史的仓库，是对维护友好度最低限度的保障。
争议三：定制部分与通用框架混在一起。开发方说"框架是我们的，不能给"，你说"定制的是我的，必须给"。避免这类争议的方法，是在合同里就把通用组件逐项列明，其余一律随源码交付。
这三个争议有一个共同点：都能在签约阶段预防，却几乎无法在交付阶段解决。把交付形式写具体、把边界划清楚，是唯一省事的做法。
为什么很多企业最后拿不到源码
复盘常见的失败案例，原因集中在三处：
- 合同没写：只写了"交付系统"，没写"交付源码"，事后要起来理不直气不壮；
- 尾款已付清：钱付完了，主动权就没了，对方"排期忙"可以拖很久；
- 约定模糊：写了"提供源码"，但没说形式和时限，最后收到一个跑不起来的压缩包。
三个原因指向同一个动作：把源码交付与付款节点、验收标准绑定。 例如约定"源码在干净环境构建成功并通过验收，才支付对应节点款项"。有了这条，交付就不再依赖对方的善意。
源码不是可选项，而是项目资产的一部分。签合同前把"归属、形式、托管、触发条件"四件事写清楚，比事后追着要代码容易得多。