账号开通、地址到手的那一刻，是最容易冲动的时候——很多人直接把业务切过去，结果上线第一天就发现问题，白白背上一次事故。其实验收只要花一天，换来的是长期省心。这篇把验收分成五步，照着走一遍再上生产环境。
第一步：对订单
先做最笨但最重要的事：核对到账的地址数量、类型、地区和有效期，跟订单逐项比对。数量少一个、地区错一批，都是高频的交付问题，这一步五分钟就能揪出来。
第二步：测连通
抽样测成功率，别只测一两个。随机抽出一批地址，逐个发起连接，统计失败比例。如果失败率明显高于参数页宣称的存活率，要么是交付的问题，要么是统计口径的问题，都值得当场问清楚。
第三步：测速度
速度要分时段测，也要分目标测。早高峰、晚高峰各跑一轮，测延迟和吞吐；再拿平时要访问的目标服务单独测，因为有些线路对特定目标的稳定性和对一般网站完全不同。
第四步：跑样例
拿真实的业务场景跑一轮小规模样例，而不是用测试脚本自嗨。真实请求长什么样、会触发什么行为，只有真实场景能暴露。这一轮跑出来的结果，才是”能不能上线”的依据。
第五步：试售后
发一个工单，问一个不痛不痒但需要处理的问题，看响应速度和态度。平时看不出售后好坏，最需要服务的时候才看出来就晚了。现在测一次，成本极低。
验收过程中发现问题的处理顺序也有讲究：先判断是交付问题还是配置问题，交付问题找平台，配置问题自查；都排查过还解决不了，再考虑换平台。
- 数量、类型、地区、有效期，逐项对订单
- 抽样测连通，失败率过高当场问口径
- 分时段、分目标测速度
- 跑一轮真实业务样例
- 发工单试售后响应
验收的过程值得留一份记录。每步的结果、发现的问题、平台的处理答复，随手记下来，攒成一份简单的验收报告。别小看这一步：几个月后遇到问题时，翻出这份记录，能立刻分辨是刚交付就这样、还是后来才劣化，排查方向会清晰很多。记录也不用复杂，几行字加一个日期就够，真正值钱的是那份可对比的时间线。
验收还有个容易被忽略的细节：尽量安排在业务真实运行的时段做，而不是挑空闲的深夜。深夜测出来的结果漂亮，但高峰期才是真正要扛压力的场景，只有在自己实际使用的时间段里测过，数据才有参考意义。
验收不是不信任平台，而是把”发现问题的时机”提前。上线后再发现问题，代价是业务中断和加班排查；验收期发现问题，代价只是发几条消息。同样的信息，早一天知道，价值完全不同。
一天验收，换来的是上线后的安稳。这笔时间账，怎么算都划算。