去年旺季，一个做酒店的朋友半夜给我发消息，说他们刚花了近十万上的一套无线网络实名认证系统，满房第一天直接崩了。两百间客房，住客同时连WiFi，认证页面死活加载不出来，前台电话被打到占线。事后排查才发现，系统在厂商的测试环境里跑得顺风顺水，但那个测试环境模拟的并发量连实际场景三分之一都不到。

　　第一个大坑：只看功能演示，不看压力实测。任何一套酒店无线网络实名认证系统，只要你的房间数超过五十间，选型评估的时候就得拿到一个量化答案——满房状态下所有住客同时触发认证请求，并发处理峰值是多少？认证时延的中位数和P99各是多少？厂商给的实验室数据不能当真，你得要他们拿出跟你体量、场景接近的真实客户环境的实测报告。而且得是服务端的压力测试，不是简单测一下Portal页面打开速度。如果厂商在这个问题上含含糊糊，或者一直绕回“我们服务过多少家酒店”这类话术，那基本可以判断他们的产品没有经过严格的并发验证。

　　第二个坑是Portal认证页面的终端兼容性。听起来是个小问题，到了真实住客场景里就是大麻烦。住客手里拿的手机型号跨度极大——有人用最新款旗舰跑着刚发布的系统版本，也有人拿着一台四年前的中端机、系统从来没升过级。如果认证页面在某个特定系统版本或特定浏览器内核上弹不出来、排版错乱、验证码加载失败，住客不会觉得是系统的问题，他只会觉得“这家酒店WiFi怎么这么烂”。更要命的是，现在很多酒店的Portal推送机制依赖浏览器自动弹窗，而部分手机品牌出于安全考虑会主动拦截弹窗行为。上线前没有做过覆盖主流品牌和主流系统版本的兼容性遍历测试，等住客入住之后你面对的就不是一个技术故障，而是一批接一批的投诉电话。

　　第三个坑是很多人完全没意识到的：公安数据上传链路的容错能力。网络安全合规检查的逻辑是，实名认证数据没上传或延迟上传，跟没做认证性质一样。但酒店的网络环境不可能永远稳定——光缆被施工挖断、运营商骨干网故障、机房意外断电，这些事一年之中发生的概率远比你想象的高。如果你的认证系统在断网的几十分钟或几个小时里，直接把没来得及上传的数据扔了，网络恢复之后也没有自动补传，那这些“丢了”的数据就是你合规记录上的黑洞。断网本地缓存、恢复后自动补传、补传失败后的重试和告警——这些不是“附加功能”，是底线。选型时厂商的技术方案里没对这块做详细说明，就当它没有。

　　第四个坑是PMS对接比表面深得多。很多酒店上认证系统的时候会提一个听起来合理的需求：跟前台PMS打通，住客办入住的时候自动完成网络实名认证，省掉二次输入手机号的步骤。需求本身没毛病，毛病出在对接方式上。每个PMS厂商的数据结构、接口规范、认证流程都不一样。你的认证系统如果只对外提供一套标准API，让PMS厂商来主动适配，等于把技术难度和沟通成本全部甩给了酒店和PMS厂商。真正成熟的酒店无线网络实名认证系统，应该能主动适配主流PMS，而不是反过来让酒店当两套系统之间的翻译。评估供应商的时候直接问一句：你们系统已经对接过哪些品牌的PMS？对接周期一般多久？有没有可以演示的实例？回答不上来，后面方案写得再好看也要打个问号。

　　第五个坑最隐蔽，影响也最持久：运维的真空地带。太多酒店把系统上线当成终点，上线那天发个朋友圈庆祝一下，就没了。但运维才是长期痛苦的开始。日志文件有没有自动清理机制，会不会三个月就把服务器硬盘撑满？认证失败率到多少的时候系统能自动告警？告警推送到哪个渠道——邮件、短信还是钉钉？是不是只通知了厂商售后，酒店网管反而收不到？有没有一个可视化面板，让非技术背景的值班经理也能一眼看出当前网络认证状态？这些问题你在上线前一个都没问过，那你买的可能不是一个系统，而是一个装完就没人管的黑盒子，出了故障连从哪个方向开始排查都摸不着。花半小时让厂商演示一遍运维后台和告警配置界面，比你逐字读合同条款更能保护你未来三年的安稳觉。