联系表单测试：上线前检查清单

损坏的联系表单是最糟糕的一类 bug：它不触发任何警报，不破坏任何布局，唯一的表现就是沉默--而这看起来和“没人来咨询”一模一样。有些网站带着失效的表单运行了数周，所有人都以为只是生意清淡。上线前花十五分钟就能避免这一切。

1. 正常流程--从真实网站出发

从已部署的生产环境 URL提交一次真实测试，而不是在 localhost 上。只有这一项测试才能检验本地测试无法检验的东西：DNS、TLS，尤其是 CORS--如果你的表单后端使用来源白名单（应该如此），生产环境是唯一能让你发现该域名不在名单里的地方。如果你同时提供 www 和顶级域名，两者都要测试。

确认三端都正常：浏览器中显示成功状态，提交出现在仪表盘中，通知（推送或邮件）确实送达了你实际会随身携带的设备。

2. 验证--试着把它弄坏

• 空提交。每个 required 字段都应在正确的位置提示，且语言要与网站一致（一个塞尔维亚语网站配上浏览器默认的英文提示信息是个经典的失误--如果这点很重要，就设置自定义提示信息）。
• 在邮箱字段中提交 not-an-email。
• 粘贴一段真正很长的消息--5000 个字符--并确认它要么被接受，要么以明确的限制优雅失败，而不是被静默截断。
• 如果有文件字段：正确类型、错误类型和超大文件都要测试。超大文件应带提示失败，最好是在慢速上传完成之前就失败。

3. 失败路径--大家都会跳过的测试

暂时把表单指向一个无意义的端点（或在开发者工具中拦截该请求），然后提交。访客会看到什么？不可接受的答案是“什么都没有”--一个毫无反应的按钮，或者永远转圈的加载图标。这里应该有一个带回退方案的错误状态（例如“或发邮件至 …”）。这正是你的真实用户在服务中断或部署出错时会遇到的状态，也是丢失一个 lead 和挽回一个 lead 之间的差别。查看你后端的错误响应参考，确保你的处理方式与它实际返回的内容相匹配。

4. 垃圾信息防护--确认已开启，但别开过头

• Honeypot：通过开发者工具填写隐藏字段并提交--它应该被静默吞掉，绝不出现在仪表盘中。
• 速率限制：快速多次提交；确认限流会生效，并且该限制要足够宽松，能容纳一次合理的更正重发。
• Turnstile（如已启用）：分别在普通窗口和隐私窗口中测试；确认令牌失败路径会显示人类可读的提示信息。

（每一层是如何工作的：联系表单反垃圾保护。）

5. 移动端、键盘，以及那些不起眼的部分

• 在真实手机上完整提交一次：正确的键盘类型（type="email" 会调出带 @ 的键盘）、可轻松点按的按钮、无需滚动查找即可看到的成功状态。
• 纯键盘操作检查：Tab 顺序合理，Enter 键可提交，焦点状态清晰可见--并且 Tab 应该跳过 honeypot（如果会停在那里，添加 tabindex="-1"）。
• 自动填充：让浏览器自动填写表单；确认字段映射是合理的。
• 感谢页跳转（如果有的话）能正常解析，且不会被后端的跳转验证拦截。

6. 留一只金丝雀

上线后，每月给自己发一条真实提交--日历提醒，三十秒就够。部署、DNS 变更和过期密钥这些事都会发生；这只金丝雀能在两周的“生意清淡”假象出现之前，先发现那次静默失败。

总耗时：上线时约十五分钟，之后每月三十秒。这是网页开发中最便宜的保险。