一个WiFi短信认证系统的上线，最顺利的情况是厂商远程部署、调试、验收，半天收工。但这种顺利是很多前置确认做对了的副产品。实际翻车的案例里面，大多数问题不在产品本身，在上线前几个关键环节没和现场条件对齐。

DNS和Portal重定向的兼容测试，是部署前必须先对齐的第一个环节。这个环节容易出问题的根源在于，厂商的测试环境没有你现场那么复杂的网络结构。你的酒店网络可能跑了不止一套出口网关：电信一条专线、移动一条专线、再绑了个4G备份链路。每个出口的DNS解析路径都不同。WiFi短信认证系统第一步要做的事，是住客设备刚连上WiFi还没认证的时候把HTTP请求强制重定向到Portal认证页面。这个动作依赖DNS劫持或者其他重定向机制。多出口场景下，如果DNS劫持策略只在主出口上生效，备出口上的设备就可能跳过Portal直接上网。这个问题在验收测试时不一定能暴露，验收通常只测主链路。但入住高峰期备出口一启用，投诉马上就来。上线前把网络拓扑图和实际出口策略先发给厂商，让他们按多出口场景做一遍重定向覆盖测试。花半天时间做这个前置动作，比上线当天返工强一百倍。

PMS接口的回归验证是第二个容易被忽略的环节。WiFi短信认证系统要和酒店PMS打通，才能办入住时自动匹配房间号和手机号，退房时自动注销上网权限。这个对接存在一个隐蔽的时间炸弹：PMS升级。酒店PMS是独立系统，有它自己的版本更新节奏。哪怕只是从v2.3升到v2.4，接口返回的字段顺序或者数据结构有一处微小改动，短信认证系统那边的数据解析就有可能直接挂掉。不发生你完全想不到，一发生就是大面积住客无法认证。部署阶段就要和双方明确一件事：PMS接口变更的事前通知机制。不是要求PMS不升级，是不能升级前不通报。同时要求认证系统侧提供PMS接口状态监控，对接状态异常时自动告警。这两条都写进合同里。

AP漫游时的会话保持是第三个现场必须确认的环节。住客拿着手机从大堂走到房间、从一楼坐电梯到五楼，中间要跨越多个无线AP，发生WiFi漫游切换。这个动作在住客侧是无感的，在认证系统侧是有感的。设备漫游到新AP后IP地址是否变化？网关对已认证设备的会话状态是否正确同步到了新AP下？两个问题只要有一个没处理好，住客走到新位置后发现又要重新收短信认证，第一反应是“这网是不是断了”。这不是功能Bug，是AP漫游策略和认证系统会话管理的联动没做到位。部署阶段让厂商找一层楼的几个相邻AP做漫游切换的认证保持测试，确保设备在AP切换后不会被要求重新认证。

这三个环节，DNS多出口重定向、PMS接口变更通知、AP漫游会话保持，没有一个是产品本身的功能，但随便一个没对齐，WiFi短信认证系统上线第一周你的运维团队就要加班了。

除了这三个技术环节，部署阶段还有一个容易被低估的非技术环节：现场人员的配合度。厂商远程部署的时候需要酒店IT人员配合做几件事——在AC上确认VLAN配置、在防火墙上放行认证服务器的IP和端口、在PMS后台导出测试用的住客数据。这些操作本身不复杂，但需要酒店IT人员有对应的操作权限。如果酒店IT是外包的，或者权限分散在不同部门手里，光协调权限可能就要花掉半天到一天。部署前把需要酒店侧配合的操作清单提前发给IT负责人，确认每一项都有对应的人能执行，这个动作不花技术时间，但能避免工程师远程连上来之后干等。

还有一个容易被忽略的验收项：Portal页面的多终端兼容。WiFi短信认证系统的Portal页面是住客看到的第一屏，这个页面在不同设备上的显示效果直接影响认证成功率。iPhone Safari、安卓Chrome、iPad、甚至一些老款安卓机自带的浏览器，对Portal页面的渲染差异很大。验收的时候不能只拿一台手机测，至少覆盖iOS和安卓各两个主流系统版本，确保页面元素不重叠、输入框不偏移、验证码按钮不被遮挡。这个测试花不了多少时间，但上线后如果某个系统版本的住客因为页面显示问题无法完成认证，你收到的投诉会非常分散且难以定位。

而且这个加班不是修Bug的那种加班，是跟厂商来回对接、前后端抓包、跟PMS供应商拉协调会的那种加班，比修Bug折磨得多。部署这件事，技术问题有技术解法，但协调问题只能靠前置沟通来解决。把该确认的环节在部署前全部拉齐，上线当天的风险就降了一大半。上线不是终点，上线之后第一周的稳定运行才是真正的验收。