开发者进阶中级125 次阅读
DApp 上线检查清单：从合约到前端的 12 项
合约、前端、监控、应急四条线同时就绪才算上线；本文给出 12 项可逐条勾选的检查清单与对应的责任划分。
#上线#检查清单#运维#应急#发布
一句话结论
上线不是「合约部署成功了」，而是合约、前端、监控、应急四条线同时就绪。缺任何一条，一次小故障都会被放大成一次事故。
12 项清单
合约侧
- 审计完成，遗留问题有明确结论与处理方式，测试覆盖到关键分支。
- 权限收敛：管理权限交给多签，敏感操作加时间锁，不在个人钱包上留后门。
- 源码验证完成，编译参数与部署参数可追溯。
- 升级路径确认：是代理还是不可升级，升级的触发条件与执行人写清楚。
前端侧
- 配置了多个 RPC 端点，并有网络异常与数据延迟的明确界面状态。
- 完整手动回归：连接、签名、授权、链切换、拒绝签名各走一遍。
- 移动端与未安装钱包的用户有明确引导路径。
- 签名请求内容可读，不使用盲签（必要时用 EIP-712 结构化签名）。
运行侧
- 关键事件监控上线，告警按优先级分级并指定渠道。
- 值班安排与处理手册（runbook）确定，每条告警都有人对应。
- 应急开关可用：暂停、限额、权限转移的执行方式与执行人已确认。
沟通侧
- 公告渠道与状态页确定，出问题时第一时间向用户说明的模板准备好了。
为什么是 12 项而不是 5 项
因为真实事故的成因往往不在合约代码里，而在「没监控到」「没人值班」「用户不知道该做什么」。合约写得再好，一次没被及时发现的异常，或者一次没人回应的公告，都会让损失成倍放大。
给你的教训
- 清单要有人负责、有完成时间，否则它只是一份文档。
- 先在测试网完整跑一遍清单，不要拿主网当第一次演练。
- 优先灰度而不是一次全量：先限额、先开放部分用户，再逐步放大。
- 提前演练监控与应急，在没出事的时候确认流程走得通，比事后补救便宜得多。
- 上线后第一周集中盯盘，确认平稳后再逐步放松。