做WiFi认证项目久了会有一个感受：认证方式本身的技术门槛不高，高的是这些外部通道的可靠性保障。短信验证码看起来就是一个API调用的事情，但短信网关偶尔抽风、运营商通道拥堵、用户手机信号差收不到验证码——任何一个环节出问题，整条认证链路就断了。微信扫码认证也是同理，公众平台的接口偶尔超时、OAuth回调被浏览器兼容性问题卡住，都会导致认证失败。这些问题从技术文档上看不到，只有实际跑过大量真实的认证流量，才能摸清楚哪里会出问题、怎么兜底。

短信网关的可靠性，靠的是双通道和超时重试。

首先关于通道数量。大部分WiFi认证系统在对接短信网关时只接了一家的通道，图省事。但这个做法在关键时刻非常危险——如果这个通道因为欠费、被运营商限制、或者服务商自己出故障而不可用，所有依赖短信认证的场景同时瘫痪。更好的做法是接入至少两家短信服务商的通道，做故障自动切换。平时两个通道都活跃使用，按一定的分流比例分配流量，其中一个通道不可用时自动把流量全部切到另一个通道。

双通道不是简单地把两个服务商的API都接上就行，有几个细节需要处理。一是两个通道的模板需要提前审核，确保在同一场景下发送的短信内容一致，用户不会因为通道切换而收到内容不同的验证码短信。二是通道切换的检测机制不能只看API调用是否报错——有时候API调用是成功的，但短信实际上没有送达，这种情况需要靠送达回执来判断通道的健康状态。如果某个通道的送达率在最近5分钟内下降到低于80%，就应该自动降低这个通道的流量权重。

还有一类问题是运营商对短信内容的敏感词过滤。验证码短信的内容模板理论上应该是最安全的——就是一个数字验证码加上一条简短提示。但在实际运营中，确实遇到过因为某个汉字触发了运营商的关键词过滤规则导致短信发送失败的情况。这些情况非常难以排查，因为不同运营商、不同省份的过滤规则不一样，而且不会告诉你具体是什么词触发了。应对方式是：短信模板尽量精简，不要带任何非必要文字，并且准备两个不同措辞的备用模板，在主模板被拦截时可以快速切换。

短信验证码的有效期和重发机制也需要精心设计。有效期太短，用户来不及输入；有效期太长，安全性有隐患。通常的做法是设定5分钟的有效期，同一手机号在60秒内不允许重复发送。如果用户点击了"重新获取"但没有收到，只允许在120秒后再次请求。这些参数不是拍脑袋定的，需要在运营中根据实际数据做微调——如果一个区域的短信平均送达时间是45秒，那60秒的重发限制就偏紧了。

微信认证的对接，技术链路比看起来长。

微信扫码认证的标准流程是：客人在Portal页上点"微信认证"，页面显示一个二维码，客人用微信扫描这个二维码，微信客户端向公众平台发起请求，公众平台回调WiFi认证系统的服务器，服务器完成认证并通知Portal页跳转到成功页面。这条链路里每一步都可能因为各种原因失败。

一是二维码的生成和展示。二维码是一张图片，如果Portal页的网络环境导致图片加载失败，用户看到的可能是一个裂图或者空白区域，完全不知道该怎么操作。这个问题的应对方式是：在二维码加载失败时，显示一个清晰的文字提示"二维码加载失败，请尝试短信认证"，并提供短信认证的快捷入口，避免用户卡在空白页面上。

二是微信公众平台回调的可靠性。公众平台的回调是有超时限制的——如果回调超过5秒没有响应，微信会放弃这次回调。这意味着WiFi认证系统的回调接口必须在短时间内完成用户识别和认证处理，不能在回调处理里做太多耗时操作。正确的做法是：回调接口只做最基本的用户身份校验，确认后就返回成功响应给微信，实际的账户创建、日志记录等操作通过异步队列在后台完成。

三是Portal页如何知道微信侧认证成功了。微信扫码完成后，Portal页需要感知到认证结果以便跳转。常用的做法有两种：一种是Portal页定期轮询后台接口查询认证状态；另一种是用WebSocket做实时通知。轮询方式实现简单但实时性差，在高峰期大量终端同时轮询会给后台带来不必要的压力。WebSocket方式实时性更好，但在某些网络环境下连接稳定性有问题。实际方案通常是用轮询作为基础机制，轮询间隔设为2秒，同时WebSocket作为加速通道，WebSocket可用时优先走实时通知。

两种认证方式的统一管理。

从运维角度看，短信认证和微信认证虽然技术实现完全不同，但在认证系统里应该是统一管理的。同一个用户的认证记录不管来自哪种方式，应该汇总到同一条用户画像下；认证失败的原因不管是短信通道问题还是微信回调超时，应该统一记录到告警平台里；认证方式的可用性监控应该对两种通道都做覆盖。

实际项目中常见的做法是：在WiFi认证系统的架构设计里引入一个"认证通道适配层"，把短信、微信、账号密码、一键认证等不同认证方式抽象为统一的认证接口，上层业务逻辑只和这个适配层交互，不需要关心具体用了哪种认证方式。通道适配层内部负责各自的连接管理、超时重试、健康检测，上层只需要拿到统一的认证成功或失败结果。这种设计让新增一种认证方式的成本大幅降低，不需要修改上层业务代码。

通道适配层还有一个重要作用：当一个认证通道不可用时，可以自动将用户的认证请求路由到其他可用通道。比如短信网关全部宕了，已有的Portal页上可以自动隐藏短信认证选项，引导用户使用微信扫码认证。这种降级能力在认证通道出现大规模故障时能显著降低用户投诉量。

说到底，认证通道的可靠性不是一个技术问题，是一个持续运营的工程问题。技术方案可以把双通道、自动切换、健康检测这些机制都做了，但如果没有人去监控通道的运行状态、没有人定期检查通道余额、没有人关注通道服务商的合同到期时间，各种机制在关键时刻还是可能失效。把通道可靠性作为日常运维的一个固定检查项，是比单纯依赖技术兜底更靠谱的做法。