专业网站开发的交付清单，源码之外还有四样

深圳有位做自动化设备的老板，网站上线一年后想换一家做改版，回头找原来的服务商要源码，对方只给了一个压缩包，解压之后是编译过的文件，数据库拿不到，后台账号也只剩一个管理员。新接手的团队只能照着线上页面重新写一遍，等于重做。

这种事在专业网站开发里不算少见。合同上写的是"交付源码"，交付那天给一个压缩包，法律意义上确实履行了，但拿到手的东西没法用。网站源码交付这一步出问题，后面全是麻烦。这篇讲清交付日那天该收的四样东西，以及每样具体包含什么。

深圳交付日那天，到底该从对方手里收什么

合同里"交付源码"这四个字，实际能覆盖的范围差异很大。写清单的好处是双方都不用猜，交付那天照着项目交付清单打勾，缺一样就当场补，最后再核对网站验收标准。深圳这边做软件外包的团队，把这份清单提前给到甲方的情况不多，多数是甲方自己没想到要问。深圳这边的网站开发公司，交付清单的粗细能差出好几倍。合同里该写清哪些内容，另有一篇 target="_blank"。

源码包里该有的目录和一份说明

源码包**要紧的是能跑起来。压缩包里只有业务代码，缺少依赖清单，接手的人得一个个猜版本，光搭环境就能耗掉两天。规范的交付里，包管理器的依赖文件是必须有的，比如 PHP 项目的 composer.json，前端项目的 package.json，并且版本号要锁死。

第二要紧的是一份说明文件。不用写长，说清三件事就够，本地怎么跑起来，需要哪些环境变量，**次部署要执行哪些命令。很多团队交付时口头交代一遍，接手的人三个月后早忘了，说明文件放在源码根目录里，谁拿到都能看懂。

第三是配置文件样例。正式环境里的数据库密码、接口密钥不能进源码包，但配置项的名称和数量要有一个样例文件，通常是 .env.example 这样的命名。少了这个文件，接手的人连要配几个参数都不知道。

数据库结构和初始化脚本

网站的数据比代码更值钱，也更难重建。交付时应该拿到一份完整的建表语句，每个字段有注释，说清这个字段存什么。字段注释这件事在开发赶进度时最容易被跳过，等到交接时，接手的人面对几十张表和几百个字段，只能靠猜。

初始化脚本是第二样。网站上线时后台要有一批基础数据，栏目分类、配置项和权限角色这些，靠后台手动点一遍既慢又容易漏。一份能直接执行的初始化脚本，能让接手的人在半小时内还原出一个可用的后台。

演示数据备份也要一份，前提是里面不能带真实用户的隐私信息。深圳做电商和医疗类站点的客户，这一条尤其要注意，生产库直接打包给出去，是数据合规上的风险。

第三方账号和密钥清单

网站跑起来要依赖一堆外部服务。从域名注册商、DNS 解析到服务器和对象存储，从 CDN、短信通道到支付接口和统计代码，少一样网站就缺一块功能。这些账号注册在谁名下，是交接时最容易起争议的地方。

建议的做法是账号统一注册在甲方公司名下，服务商只拿操作权限。域名和服务器尤其要这么做，这两样是所有资产的根。深圳早期一批企业网站，域名挂在建站公司的注册商账号里，公司换了服务商之后，域名续费都要看人脸色，这种情况现在还有。

密钥清单单独一份文档。数据库密码、接口密钥和证书私钥，这些不能进源码包，也不能只放在某一个工程师的电脑上。用加密文档或者密码管理工具存一份，双方各留一把钥匙。

部署文档要细到环境参数

一份能用的部署文档，细度要到版本号。操作系统是 CentOS 7 还是 Ubuntu 22.04，Web 服务是 Nginx 1.20 还是更高，语言运行时是 PHP 7.4 还是 8.1，装了哪些扩展，这些都要写。差一个版本号，接手的人在新环境上部署就可能遇到兼容性问题。

伪静态规则也是必写项。网站做了 URL 重写，规则只存在服务器的配置文件里，不写进文档，换服务器时页面全是 404。定时任务清单同理，每天凌晨跑的数据统计、每周清理的日志，这些任务不写下来，换环境之后没人知道要配。

深圳这边用虚拟主机和轻量服务器的客户不少，部署文档里还要写清目录结构和权限设置。上传目录要不要可执行权限，日志文件放在哪，这些细节在新环境上配置错了，不是报错就是留安全隐患。

后台账号和权限分级

后台账号的交接要做两件事。一是把所有默认账号改掉，二是按岗位分权限。很多项目交付时只给一个超级管理员账号，公司里五六个人共用，谁改了什么查不出来。内容编辑、产品维护和订单查看这三类角色分开设置，操作日志才有用。

密码强度也要当场确认一遍。开发期间为了省事，账号密码经常设成 admin123 这类，上线前不改，就是给扫描器留的后门。深圳这边中小企业的官网后台被撞库登录的情况并不少见，源头多半是弱密码。

交付物清单与验收标准

最容易漏掉的四样

• 配置文件的样例，接手的人不知道要配几个参数
• 伪静态规则和定时任务，换服务器后直接失效
• 图片和附件目录的备份，只交了代码没交素材
• 后台操作日志的开启状态，出问题后查不到是谁改的

不建议接受的三种交付方式

• 只给一个压缩包，里面是编译后的文件，没有原始代码
• 源码托管在服务商自己的私有仓库，甲方只能拿到一个只读链接
• 第三方账号全部注册在服务商名下，甲方只有后台登录权限

这三种方式在合同层面都不算违约，但甲方拿到手之后没法自主处置。网站是长期使用的资产，交付时图省事，后面花的代价往往是几倍，挑服务商时可以先看它自己的官网，见 target="_blank"。

深圳这边的验收时间节点怎么排

验收期建议留七个工作日。前两天核对清单上的东西是否齐全，中间三天在测试环境上重新部署一遍，最后两天处理发现的问题。只留两三天的验收，通常只够点开页面看看，部署环节的问题根本来不及暴露。

质保期是另一个要写进合同的节点。深圳这边的行业惯例是上线后三个月到一年不等，期间出现的功能性问题免费修，新增需求另外计价。质保期的长短，比价格本身更能反映服务商对自己代码的信心。

拿到东西以后先做这三件事

**件是当场在测试环境上部署一遍。清单打勾不能替代实际跑一遍，很多问题只有部署时才会暴露。深圳有位客户就是在这一环发现，交付的源码包里少了一个图片处理扩展，本地环境装了，新环境没装。

第二件是把源码存进公司自己的代码仓库。不管用哪家平台，先有一份属于公司的托管副本，再谈后续维护。这一步做完，换服务商这件事就从被动变成了主动。

第三件是改掉所有默认密码，核对一遍域名和服务器的账号归属。这两件事各花半小时，能避免后面绝大多数麻烦。做完这三件，这次交付才算真正结束。

如需进一步沟通，可直接致电 13928418795。