源码交付不能等同于“把一个压缩包发给甲方”。真正合格的交付，应让甲方能够独立编译、部署、维护和二次开发，并在服务商退出后仍掌握系统的技术控制权。因此，验收标准必须写进合同和功能附件，而不能只依赖口头承诺。
先验收“交付物是否完整”
合同应明确交付完整、可编译的前后端源代码，而不是仅提供前端文件、加密混淆代码或已经打包的后端镜像。至少应逐项核对：
- 前端工程源码、后端工程源码；
- 数据库脚本及必要的数据结构说明；
- 接口文档、部署文档和二次开发指南；
- 设计源文件、操作手册；
- 服务器、相关平台及系统运行所需的账号权限；
- 订单、会员、商品等业务数据的完整导出能力。
“代码能打开”不等于“代码可接管”。验收时应在甲方可控的环境中完成编译、部署和启动测试，并由非原开发人员尝试修改一个明确功能，检查工程是否缺少关键依赖、隐藏授权或无法替换的服务端组件。
再验收“功能是否可运行”
源码交付必须与功能验收同步进行。甲方应依据合同附件中的功能清单逐项核对，不能只看演示视频或几个页面。对于涉及注册、下单、支付、库存、后台管理等流程的系统，应进行完整业务链路测试；移动端还应安排真机测试，检查不同设备上的界面、权限和核心操作。
发现问题后，应区分缺陷、未交付和需求变更：合同已有功能但无法正常运行，属于缺陷；合同约定的代码、文档或账号缺失，属于交付不完整；新增合同外功能，才进入需求变更流程。三者混为一谈，最容易造成验收争议。
最终验收看“能否脱离服务商运行”
验收不应止于“项目上线”。甲方还应确认源码、数据库、文档和账号均已归档，数据可以导出，部署步骤能够复现，维护范围和期限已经书面明确。付款节点也应与原型确认、测试验收、上线交付源码等阶段绑定，避免在核心交付物尚未确认前支付全部款项。
源码的价值，不在文件数量，而在自主控制能力。只有做到可编译、可部署、可维护、可迁移，并且交付边界和验收方法清晰，源码才是真正可使用的软件资产，而不是形式上的附件。
