是否支持源码交付？

结论：支持。滚水科技默认交付项目专属源码和可复现构建所需资料，但范围必须写进合同；开源库、商业 SDK 与既有通用组件仍受各自许可证或授权约束，源码交付不等于所有内容都可无限转授权。

真正可接管的源码交付，不是项目结束时发一个压缩包。客户至少应拿到自己可管理的 Git 仓库、约定分支与版本标签，前后端及小程序代码，依赖锁定文件，数据库迁移脚本，接口定义、部署手册、设计源文件和第三方服务清单。环境变量可以提供字段样例和取值说明，但生产密钥不应写进仓库；密钥应通过客户自己的云密钥服务或受控渠道移交。

在约定交付物、接管方式与责任边界时，还可以对照 数据所有权和知识产权属于谁？；这些内容补充了需要放在同一项决策中考虑的上下文。

三种常见交付方式，实际控制力差别很大：

交付方式	客户实际拿到什么	可追溯性	接管风险	结论
只交 ZIP 源码	某一时点的文件快照	看不到提交与版本演进	缺配置、缺脚本时难以复现	不适合作为正式验收
完整仓库加文档	源码、历史、标签、文档与制品清单	能定位版本和变更	仍需验证客户环境能否跑通	可作为最低合格线
客户仓库持续交付	研发过程就在客户控制的仓库和流水线中进行	里程碑持续可见	需提前配置账号和权限	企业项目优先采用

交付边界要逐项写清。为客户专门创作的代码、页面、接口和文档，其著作权归属或使用许可按合同约定；MIT、Apache 等开源依赖按许可证使用，不能因为它被打包进项目就改变原作者许可；地图、支付、推送等商业 SDK 还可能限制账号主体、调用量和分发方式。滚水科技自项目开始就建议建立软件物料清单，记录组件名称、版本、来源、许可证及商业授权到期日，可用 SPDX 许可证清单 统一标识，避免交付后才发现依赖无法继续商用。

接口文档也要能被机器和人共同验证。采用 OpenAPI 规范 时，应交付与上线版本一致的接口定义，而不是一份过期截图。数据库交付应包含结构迁移、必要的初始化数据说明、备份恢复步骤；设计交付应明确字体、图片和素材是否拥有可转让或可商用授权。涉及客户真实数据时，交测试数据或脱敏样本即可，不能为了证明“完整”而复制不必要的个人信息。

验收最有效的方法是让客户团队在一套干净环境中独立完成一次构建、部署、数据恢复、版本回滚和密钥替换。合格证据应包括构建日志、版本号、制品校验值、恢复结果和问题关闭记录。仅以“代码文件数量”“压缩包能打开”验收，没有证明系统可维护。依赖私有包的，还要验证客户拥有包仓库读取权；依赖供应商服务的，要说明停服后的替代路线。

合同附件可把交付物、文件格式、存放位置、完成时间、验收方法和未通过后的整改期限列成清单。若客户要求完整提交历史、安全扫描报告或软件著作权材料，应在报价前确认，因为历史清理、许可证核验和登记材料都会占用工时。滚水科技的实践是按里程碑持续同步，而不是尾款前一次性交钥匙；具体交付原则可继续查看 透明交付标准。