发布链上应用时，测试网能跑通不代表主网可以直接上线。网络参数、账户权限、外部服务和实际费用都可能不同。把链上应用测试网部署与主网发布清单拆成可核验的步骤，才能让验证范围跟着成本和风险走，而不是只看一次成功部署。
测试网验证：确认流程，不只确认“能部署”
测试网适合检查交易路径、权限配置和前端交互。比如使用 Solana Devnet 或 Polygon Amoy 时，应先确认应用、钱包和所用 RPC 服务指向同一网络；测试代币不等于主网资产，测试网的可用性和参数也不能代替主网核对。
按真实用户路径逐项测试
- 列出关键操作：从连接钱包、读取数据到提交交易，按用户实际顺序走一遍，并覆盖成功、拒绝签名、余额不足和网络切换等情况。
- 检查权限边界：确认管理员、运营账户和普通用户各自能做什么。对暂停、参数修改等高权限操作，核对执行账户是否正确，并记录权限交接方式。
- 核对外部依赖：检查 RPC、索引服务、预言机或其他接口的网络配置、超时处理与异常提示；依赖不可用时，应用不应把错误数据当作正常结果。
- 保存部署证据：记录网络名称、部署账户、合约地址、版本标识和关键配置。链上交易可供核查，但前端配置与服务端设置也需要留档。
测试网发现的问题要回到代码或配置中修复，再重新走关键路径。链上应用测试网部署与主网发布清单应注明每项检查的结果、负责人和未解决风险，避免把“已部署”误当成“已验证”。
主网上线前：把可变配置和权限单独复核
主网发布前，先从干净环境构建将要发布的版本，避免测试配置混入正式配置。核对目标网络、合约地址、部署账户、签名流程和前端读取地址；若项目使用外部服务，还要确认其正式环境凭据与访问权限。
- 部署交易：核对交易目标、构造参数和发送账户；多人协作时，采用明确的审批与签名流程。
- 合约验证：如目标网络支持公开验证，检查提交的源代码、编译配置与已部署字节码是否对应。验证有助于审阅，不等同于安全审计。
- 上线观察：准备查看交易失败、异常事件和服务不可用的渠道，并安排发布后的值守时间。
- 回滚预案：链上已确认的部署交易通常不能像普通服务器发布那样直接撤销。预案应说明如何切换前端或服务配置、暂停相关功能，以及在何种条件下发布修正版。
把每项标成“通过、阻塞或接受风险”，并由责任人确认。这样，链上应用测试网部署与主网发布清单才是发布决策依据，而不是形式化勾选表。
部署成本决定验证范围，但不能取消底线
链上部署费用通常受网络拥堵、交易复杂度和目标网络计费规则影响，无法用固定金额代表所有项目。先在目标网络估算部署交易费用，再为初始化、必要配置和后续维护预留预算；同时区分链上费用与 RPC、监控、审计等链下支出。测试网领取的代币一般不能支付主网交易费。
预算有限时，可减少低风险功能的重复人工检查，却不应跳过核心资金路径、权限控制、正式网络配置和发布审批。若预算无法覆盖必要审查，应缩小首发功能范围，或延后上线，而不是把未验证部分默认视为安全。链上应用测试网部署与主网发布清单可按影响排序：资金与权限相关项优先，其次是关键业务流程，最后是非关键体验细节。
常见问题
测试网通过后，为什么还要重新核对主网？
因为网络地址、账户、外部服务和交易费用可能不同。测试结果证明的是特定环境下的行为，不自动覆盖主网配置。
主网发布前一定要做安全审计吗？
取决于应用风险、代码复杂度和管理权限。涉及用户资产或高权限操作时，应安排适当的独立审查；测试通过不能替代审计。
部署后发现地址或配置错误怎么办？
先停止引导用户使用错误入口，再评估合约是否可升级、是否存在暂停机制，并按预案修正前端或服务配置。已确认的链上交易通常不能直接删除。
用风险排序安排验证、用预算决定覆盖深度，并保留未解决事项记录，才是可执行的链上应用测试网部署与主网发布清单。