小程序源码

源码到底给不给、给了是不是完整的、拿到手能不能自己接着改？这三个问题不弄清，签合同时谈得再顺，后面也可能卡住。围绕小程序源码，下面把交付前、交付时、交付后各环节该怎么做拆开讲清楚，照着核对，至少能少走一遍返工路。

交付前先把归属和范围写进合同

源码归属不是口头承诺能解决的事。合同里要明确写：项目验收结清后，前端代码、后端程序、数据库结构脚本、接口文档一并移交，著作权归甲方。缺一项，后面就可能变成加钱项。有的服务商把后台管理端单独算一套，交付时才发现只能改页面不能改逻辑，这种扯皮在行业里并不少见。

交付范围还要落到功能清单上。把每个页面、每个接口、每个后台模块列成表格附在合同后面，验收时逐项打勾。功能清单越细，交付争议越少——写得含糊的「会员系统」和写清楚的「注册登录、积分、等级、消息通知四个子模块」，执行起来完全是两回事。

另外要约定源码的完整度标准。行业里常见的做法是交付可编译、可部署的完整工程，包含依赖配置文件，能在干净的开发环境里跑起来。只给打包后的产物、不给工程文件的，算不上源码交付。遇到过的实际情况是，客户拿到一堆压缩包，解压后连启动命令都找不到，最后还是得回头找原团队。

交付时按清单逐项核对，别急着签字

交付当天最忌讳看一眼文件夹就确认收货。稳妥的做法是当场做三件事：在一台干净的电脑上按文档部署一遍，用测试账号跑通核心业务流程，再检查代码里有没有写死的第三方密钥或指向原服务商服务器的地址。部署跑不通，后面的核对都是空谈。

数据库这块要单独看。要求提供建表语句和初始数据脚本，而不是只给一个导出的数据文件。前者能重建结构，后者只能恢复数据，迁移到新环境时差别很大。接口文档同样要核对，字段说明、请求方式、返回格式是否齐全，直接决定后续二次开发的成本。

域名和服务器账号也要在这一步交接。域名注册商账号、云服务器登录权限、小程序技术团队后台的管理员身份，这些掌握在谁手里，项目的实际控制权就在谁手里。你会放心把公司的数字资产一直挂在别人名下吗？交接时把管理员账号改成公司自己的邮箱和手机号，这一步花不了多少时间，却能省掉后面很多麻烦。

交付后自己接手要做的几件事

拿到代码不等于能维护。先在一台测试服务器上把项目完整跑起来，记录部署步骤和环境版本，形成一份内部文档。开发语言版本、数据库版本、依赖包的安装方式，这些细节不写下来，换个人接手就要重新摸索一遍。

代码托管要迁到公司自己的仓库。把工程推送到自建或自购的代码托管服务上，开启提交记录，后续每次修改都有迹可循。原来的开发方如果需要继续参与维护，用协作者权限加入，而不是继续持有主账号。

维护责任也要提前说清楚。验收后一般留 3-6 个月的问题修复期，期间因程序本身缺陷导致的故障由开发方处理；超出这个范围的调整，按工作量另行计费。响应时效建议写进约定，比如工作日 24 小时内响应、紧急故障 4 小时内介入，写清楚比事后争论有用。

费用和周期心里也要有个数。一个功能中等的小程序，定制开发一般在 1.5 万到 5 万元之间，周期 20-45 个工作日；模板类产品按年付费，通常每年 3000-8000 元，但不含源码。报价明显低于这个区间的，多半在交付内容上做了减法，签约前把清单对一遍就能看出来。

源码这件事，核心就一句话：归属写进合同、交付按清单核对、接手后自己管住账号和仓库。三步都做到，项目才算真正落在你手里。小程序源码的交付质量，往往在签约那一刻就定下了大半，剩下的靠执行细节补上。签合同前把功能清单和交付物列表逐条过一遍，比事后追着要文件省心得多。