验收与上线检查：上线前 40 项（含功能验收），验收单怎么签
给要上线或验收项目的人：开发方用它做上线前自检，客户方用它组织验收。产出三样东西：一张 40 项的上线检查清单（含功能验收）、一份七字段的验收单、一套遗留项管理办法。
上线前 40 项检查清单
按八组检查，全部通过再约验收。每项只有「通过 / 不通过」两种状态，不通过的项不进入验收会。
一、功能验收（6 项，对照需求清单）
| # | 检查项 | 通过标准 |
|---|---|---|
| 1 | 功能清单逐项演示 | 按冻结版需求清单编号逐项演示，清单外功能不算在本次验收内 |
| 2 | 主流程端到端走通 | 用贴近真实的业务数据（不是测试摆拍数据）走完整业务链，如建单→审核→履约→结算→对账 |
| 3 | 多角色分别验证 | 每个角色用自己的账号登录，各自的核心操作与数据边界正确 |
| 4 | 异常路径可恢复 | 断网重连不丢单、错误输入有明确提示、重复提交被拦截 |
| 5 | 报表与导出核对 | 报表/导出数字与手工台账核对一致，导出能打开、字段齐全 |
| 6 | 已知问题分级清零 | 遗留问题按 P0/P1/P2 分级列表，P0（阻塞核心流程/资损/数据错误）必须为零 |
二、环境与部署（5 项）
| # | 检查项 | 通过标准 |
|---|---|---|
| 7 | 生产环境部署完成 | 域名可访问，HTTPS 证书有效，无浏览器安全警告 |
| 8 | 环境隔离 | 生产与测试的数据库、文件存储、账号完全独立 |
| 9 | 配置项收口 | 数据库连接、密钥、第三方参数在配置文件或环境变量中，未硬编码在代码里 |
| 10 | 版本可追溯 | 页面或接口可查版本号，与交付记录一致 |
| 11 | 初检体验 | 首页与核心页 3 秒内可交互，目标用户常用机型上核心流程可用 |
三、数据（5 项）
| # | 检查项 | 通过标准 |
|---|---|---|
| 12 | 初始化数据导入完成 | 基础数据与客户确认的清单一致 |
| 13 | 历史数据迁移核对签字 | 迁移核对四步（总数/抽样/金额/关联）完成并双方签字 |
| 14 | 上线前备份已执行且可恢复 | 全量备份成功，并实际恢复演练过一次 |
| 15 | 测试数据清理 | 开发期的假数据、测试账号已清除或隔离 |
| 16 | 数据可导出 | 客户能自行导出核心业务数据（数据归属的兜底保障） |
四、权限、账号与安全（6 项）
| # | 检查项 | 通过标准 |
|---|---|---|
| 17 | 角色权限与需求一致 | 每个角色能做什么、不能做什么，与需求清单对照通过 |
| 18 | 默认权限最小化 | 新建账号默认无敏感数据可见权，无「未授权先可见」 |
| 19 | 越权抽查通过 | 用低权限账号遍历列表、详情、导出接口，取不到越权数据 |
| 20 | 管理后台安全 | 后台默认密码已改、默认路径不对外暴露、不被搜索引擎收录 |
| 21 | 管理员账号移交 | 管理员账号密码移交客户，开发方不再持有生产密码 |
| 22 | 登录闭环 | 登录、退出、密码重置、（如需要）验证码全部可用 |
五、支付与交易（5 项，无交易功能整组跳过）
| # | 检查项 | 通过标准 |
|---|---|---|
| 23 | 真实小额收款 | 用最小金额（如 0.01 元）完成一笔真实支付，钱到客户商户号 |
| 24 | 退款走通 | 全额退款一次，状态与到账正确 |
| 25 | 回调与状态机 | 支付回调正确驱动订单状态，重复通知不产生重复入账 |
| 26 | 对账可用 | 渠道账单能下载并与系统订单核对 |
| 27 | 交易可追溯 | 订单号、支付流水号、退款单号可按单查询 |
六、培训与交付物（5 项）
| # | 检查项 | 通过标准 |
|---|---|---|
| 28 | 操作培训完成 | 按角色培训到位（场次、参加人记录在案），培训录屏交付客户 |
| 29 | 操作手册交付 | 覆盖核心流程的操作手册（截图版）交付，客户新员工照着能上手 |
| 30 | 源码与仓库交接（买断类） | 仓库权限移交、构建脚本可用、依赖版本锁定；非买断类此项标「不适用」 |
| 31 | 部署与运维文档 | 部署步骤、端口目录、备份恢复步骤有书面文档 |
| 32 | 第三方账号归属确认 | 短信/支付/地图/存储等账号确认在客户名下，或过户/重建方案与期限已书面确认 |
七、备份与监控（4 项）
| # | 检查项 | 通过标准 |
|---|---|---|
| 33 | 数据库定时备份 | 自动任务配置完成，保留策略明确（如每日一份、保留 30 天） |
| 34 | 备份实际恢复过 | 从最近备份恢复成功一次，不只见备份文件存在 |
| 35 | 基础监控告警 | 服务存活、磁盘、数据库连接有告警且能通知到人 |
| 36 | 日志可定位 | 关键操作与报错有日志，能按时间查到问题现场 |
八、回滚与应急（4 项）
| # | 检查项 | 通过标准 |
|---|---|---|
| 37 | 版本可回滚 | 上一版本可回退，步骤有书面记录 |
| 38 | 数据库变更可回退 | 本次上线的 DDL 有对应回退脚本 |
| 39 | 应急联系人与时限 | 双方联系人、响应时限书面确认 |
| 40 | 上线窗口确认 | 选业务低峰时段，客户方书面知悉 |
验收单模板（七字段 + 三档结论）
| 字段 | 填写内容（示例） |
|---|---|
| ① 验收范围 | 某母婴连锁小程序，按合同附件功能清单 v1.3 第 1–18 项（标准来源=合同附件，写版本号） |
| ② 验收标准 | 功能项逐项演示通过；主流程用真实数据端到端走通；性能口径：50 并发下单响应 ≤ 2 秒；数据口径：迁移核对四步签字通过 |
| ③ 验收数据 | 演示账号与测试数据随验收单附上；生产数据以第 13 项核对签字为准 |
| ④ 验收期限 | 验收期 7 个自然日，自交付日起算；逾期未提书面异议视为通过（书面异议以合同载明邮箱送达为准） |
| ⑤ 签字人 | 甲方验收人：姓名/职务/联系方式——应为合同载明的验收签字人 |
| ⑥ 遗留项 | 编号 L1：批量导入超 5 万行时分页偏慢 / 整改期限 7 天 / 责任人：开发方 / 复验方式：整改后演示。每条遗留项四要素缺一不可 |
| ⑦ 培训与交付物确认 | 培训 2 场已完成（录屏已交）；操作手册、部署文档、源码仓库按交付清单编号移交（清单附后） |
结论三选一，写在验收单标题下方：通过 / 有条件通过（遗留项四要素齐全且不阻塞核心业务，限期整改后复验）/ 不通过（写明卡在哪些项，整改后重新验收）。
使用注意三条
- 功能验收的主流程必须用真实业务数据走。测试账号摆拍出来的「通过」骗得过演示骗不过上线——第一周真实开单，字段对不上、流程拐弯的问题全会冒出来。
- 遗留项没有整改期限和责任人就等于永远挂着。每条四要素（编号、期限、责任人、复验方式）缺一不可，缺了就不算「有条件通过」，算「不通过」。
- 培训与交付物是验收的一部分，不是验收之后的善意。培训没做、手册没交，客户上线后每个操作问题都会变成开发方的售后工单——第 28–32 项就是用来堵这个的。
什么时候不适用
纯展示型官网（无交易、无用户数据）：功能验收简化为主流程 1 条，数据、支付两组共 10 项跳过，用剩余约 25 项。内部单人使用的小工具：备份监控组可简化为「代码有 git 记录」一项。几十人以上使用的交易系统：本清单是下限，支付组之外要加对账巡检与资损告警项。
相关阅读
- 博客：国内项目验收为什么总卡住——验收标准为什么签约时就要写死、验收五步流程；
- 博客：一个人做行业软件，先接单再做产品——每单强制归档的五样交付物；
- 案例：相关案例整理中（美容连锁 2 周上线的验收实例）。
| 版本 | 适用日期 | 变更记录 |
|---|---|---|
| v1.1 | 2026-10 | 按产品/技术复审补：功能验收组（6 项）、培训与交付物组（5 项）、安全项；验收单增加第⑦字段与标准来源 |
| v1.0 | 2026-10 | 首版：30 项六组 + 验收单六字段三档结论 |