作者结合自身真实上线经验，整理了一份 Solana 程序从 devnet 到 mainnet-beta 的部署检查表，覆盖部署前、部署中、部署后权限管理、前端对接等四个阶段，并标注了亲自踩过的坑。作者认为，最危险的不是 deploy 命令本身，而是集群确认、升级权限决策、缓冲区 SOL 回收这些“外围步骤”——每项都不复杂，但一旦忙起来容易忘，而任何遗漏都可能造成不可逆损失。
预计起飞前有检查单，外科医生下刀前也有。不是因为他们忘了怎么飞或做手术——而是因为在压力下跳过一个步骤的代价太高，不能仅靠记忆。把 Solana 程序发到主网也属于同一类：不可逆操作、真实资产在线，以及十几件每件在忘记之前看起来都显而易见的小事。作者最近刚完整走了一遍上线流程，趁记忆还新鲜把步骤写成了过手单。
Phase 1: Pre-flight（在 devnet 上做） 确保测试全部通过，且测试针对最终编译的字节码（不是之前版本）。在 devnet 上完整体验一遍主网流程，不跳过任何计划“这次先跳过”的步骤。用
anchor build --verifiable 生成可验证构建——跳过它的话程序就永远是个黑箱。确认部署钱包有足够 SOL 覆盖 rent-exempt minimum（可用 solana rent 预览），注意：有了可验证构建后不要再跑普通 anchor build 或 cargo build-sbf，否则会生成不同哈希。Phase 2: 部署（不可逆阶段） 切换 CLI 到 mainnet-beta 并用
solana config get 确认。通过专用 RPC 端点部署（不用公共端点，限流会导致写入超时）。网络忙时加 priority fee（--with-compute-unit-price）。了解恢复路径：部署不是原子操作，若中断可用 solana program show --buffers 查看滞留的 buffer 并恢复或关闭它，避免每次失败都泄漏 SOL。Phase 3: 部署后权限与验证 用
solana program show <PROGRAM_ID> 确认程序已上线并检查升级权限。主动决定谁持有升级权限（单密钥对、Squads 多签或 --final 不可变），不要默认。发布 IDL 让程序接口随程序本身可检索，并通过 IDL 重新生成类型化 client。注意：跳过 IDL 发布会导致构建验证失败。Phase 4: 前端与上线 将 React 前端指向主网 program ID。确认 Wallet Standard 连接展示的是主网钱包（不是 devnet 残留）。重新验证所有失败模式（拒绝授权、余额不足、blockhash 过期）现在都能给出清晰提示。公布上线，并提前写好用户反馈渠道。
真正让作者惊讶的是：部署命令本身并不吓人——跟 devnet 上跑的一样。真正需要谨慎的是围绕部署的那些环节：确认集群、把升级权限当作决策而非默认、记住停止的部署不是从头再来而是 SOL 在 buffer 里等着回收。最好的工程团队不把上线当作记忆或英雄主义表演，而是当作程序来执行。
#开发者 #工具 #Solana #Web3 #Checklist #Deployment #Anchor #React
@DevToolboxHub