迁移后测试表单和支付，别从点页面开始，要按「提交 → 落库 → 回调 → 对账」四段拆开验证：用 curl 打接口、拿数据库比对结果、最后用 SQL 全量对账迁移前后的订单表。页面能不能点通说明不了任何问题，接口通、数据对、回调幂等才算过。
迁移后表单测试第一步测什么？
结论：先测边界值、落库结果和通知链路，样式和排版放到最后。
表单最容易在迁移后出问题的地方，通常是配置而不是代码。字段长度上限、必填校验、首尾空格 trim、emoji 和特殊字符入库，这些都要逐条提交一次并回查数据库，确认写入的是 utf8mb4 而不是被截断成问号。
验证码是重灾区。以本站为例，注册、登录、发帖、回帖页面都启用了 4 位数字/字符图形验证码，有效期 10 分钟，管理员和版主免验证码。迁移后如果缓存层换了实例或被清空，常见现象是验证码永远校验失败，或者 10 分钟有效期被重置成默认值。测法是：取一次验证码 → 等 11 分钟再提交，必须失败；再取一次 → 立刻提交，必须成功。
文件上传同样要复测限制值。本站图片单张上限 5MB，支持 jpg、jpeg、png、gif、webp；普通附件单个上限 10MB，支持 zip、rar、7z、pdf；危险可执行后缀由系统直接拦截。迁移后重点看 php.ini 的 upload_max_filesize 和 post_max_size 有没有被还原成默认的 2M——超限时应当返回明确报错，而不是白屏或 500。
防灌水规则也要点一遍：发帖冷却 30 秒、回帖冷却 15 秒，冷却周期内禁止重复提交。这类计数通常存在 Redis 里，迁移后如果键前缀变了，规则会静默失效，表现就是用户能连发。
支付功能迁移后怎么测？
结论：支付不能靠「下单成功」判断，必须让三方回调、本地落库、对账文件三方对平。
第一项是金额一致性。系统内部金额统一用「分」做整数存储，禁止浮点。测试用例至少覆盖 0.01 元、整数元、单笔上限三个点，比对下单请求金额、支付平台返回金额、订单表 amount 字段三者完全相等。
第二项是回调验签和幂等。用 curl 直接模拟三方异步通知：
curl -i -X POST https://你的域名/pay/notify/alipay \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "out_trade_no=TEST20250601001&trade_status=TRADE_SUCCESS&total_amount=0.01&sign=伪造签名"
三条断言必须全部成立：伪造签名返回 fail 且订单状态不变；正确签名返回 success 且订单变为已支付；同一条通知连续推送 3 次，只发货 1 次。第三条是迁移后最常挂的，因为幂等锁往往依赖缓存或唯一索引。
第三项是网络可达性。迁移换机房后，支付平台的回调 IP 可能被新的 WAF 或安全组拦截，去 access log 里搜有没有来自三方 IP 的 403。同时检查支付私钥路径与文件权限（建议 600）、证书到期时间，这类问题平时不报错，一到真实支付就全线失败。
迁移后哪些限额规则最容易漏？
结论：凡是「每天 N 次」「单笔 X 元」这类硬规则，必须逐条手工触发一次，因为限额失效不会报错。
以本站为例，充值的硬约束是单笔区间 1 元～1000 元、单个账号每日最多 3 笔，这类配置存在数据库表或配置文件里，迁移脚本漏一个字段就会静默放开。限额一旦失效，用户不会投诉，只会默默刷。
配置项状态也要单独确认。本站充值总开关已开启，但金币与人民币兑换比例尚未配置，因此当前充值通道关闭。这种「开关开、比例空」的组合必须测出友好提示，而不是抛异常或白屏；后续比例配置上线时，同一套回归用例还要再跑一次。
上线前最后一小时做什么？
结论：跑一次 SQL 全量对账，比任何手工点击都可靠。
在旧库和新库分别执行：
SELECT COUNT(*), SUM(amount), MIN(created_at), MAX(created_at)
FROM orders WHERE created_at >= '2025-05-01';
条数和金额必须完全一致，不一致就按订单号导出差异清单逐单核对。同时对账时顺手查三个隐性坑：自增 ID 起始值是否连续、时区是否统一（订单时间整体差 8 小时说明 UTC 与 +08:00 混用）、新库字符集是否仍为 utf8mb4。
把上面四段串起来看，迁移后的验收顺序是：表单边界与配置 → 支付下单与验签 → 回调幂等与网络可达 → 限额规则 → SQL 对账。前四步靠测试用例，最后一步靠数据，两者都过才算迁移完成。
