连WiFi这件事，看起来人人都会，但真要把十几类终端都照顾好，一点儿不简单。苹果手机、安卓各品牌、笔记本电脑、智能手表、车载设备、物联网终端，每一类在无线协议、加密支持、浏览器行为上都有差异。WiFi无线认证系统如果只按"手机能连"来设计，上线后就会被各种奇葩终端教做人。多终端适配不是锦上添花，是基本盘。

苹果和安卓的底层差异要先认

iOS和Android在WiFi行为上很不一样。苹果对后台网络请求管得严，连上未认证WiFi后，系统可能会主动探测网络连通性，这个探测行为本身会影响认证页的触发逻辑；安卓各厂商又各自改过系统，有的会在锁屏后掐断后台。这些差异导致同样的认证流程，在苹果上顺利、在安卓上卡顿的情况非常常见。我们做适配测试时，至少拿苹果最新两代加安卓主流三四款真机实测，不能只看模拟器。认差异，是适配的第一步。

Portal认证页的终端兼容性

认证页本身要在各种终端的浏览器里正常显示和交互。老款安卓自带的浏览器对现代CSS支持差，某些国产手机默认浏览器会拦截跳转，车载屏幕的浏览器更是千奇百怪。对策是认证页尽量用最朴素的标准HTML，不依赖新特性，按钮和输入框尺寸够大，跳转用最稳的方式。我们曾经被一个车载设备坑过，它的浏览器不执行某段JS，导致认证永远停在空白页，最后给这类终端单独做了极简版页面才解决。兼容性差的终端，值得单独开小灶。

物联网和哑终端的处理

很多场所除了手机电脑，还有摄像头、POS机、打印机、智能家电这类"哑终端"，它们没有浏览器，弹不出认证页，也没法输验证码。如果一股脑放进认证WiFi，这些设备全废了。做法是给哑终端单独划VLAN或者用MAC白名单直连，不走Portal认证。我们见过一个商场，把所有的自助收银机都接在认证WiFi下，结果机器天天弹认证页失败、断网，收银排长队。哑终端必须绕过认证，这是适配里最容易忘、后果最严重的一块。

双频和频段切换的体验

现在很多WiFi同时开2.4G和5G，认证流程要能扛住频段切换。问题是用户可能先在2.4G下认证，走到5G覆盖区时被分到另一个VLAN，认证状态没跟着走，又得重连。对策是认证状态绑定到用户身份而不是连接本身，切换频段后系统识别到还是同一个人，直接放行。我们做场馆项目时，会专门测"边走边连"的场景，因为用户不会站着不动上网。频段切换不断认证，是体验的隐形分水岭。

笔记本和访客设备的浏览器行为

笔记本用户习惯打开浏览器才触发认证，但有些系统设置成"连上即弹"，对笔记本来说弹窗可能被浏览器拦截。另一方面，访客带的设备系统语言、时区各异，认证页的编码和字符集要稳，否则会出现乱码导致用户以为坏了。我们建议认证页严格用UTF-8，并且不依赖任何浏览器插件或特殊协议。笔记本和手机是两大主力终端，两者的触发逻辑最好分别验证，不能假定"手机能过电脑就能过"。

适配的取舍：覆盖主流，记录长尾

再强的团队也不可能适配世界上每一款终端，所以要有取舍。原则是覆盖占比九成以上的主流终端，把测试资源砸在这里；剩下的长尾设备，做成"连不上时有明确提示+人工兜底通道"，而不是无休止地一个个适配。我们一般建议客户先拉一份自己场所的用户终端分布，按占比排优先级，别凭想象去适配。取舍不是偷懒，是把有限精力放在最能减少投诉的地方。

用真实终端做上线前验收

适配工作最后一定要落到"真机验收"这一步。拿计划支持的设备清单，一台台连、一台台认证、一台台上网，把结果记下来。我们发现太多项目在模拟环境测得好好的，真机一上就露馅，原因就是模拟器还原不了真实终端的怪异行为。验收报告里要写明哪些通过、哪些有问题、问题怎么兜。这份报告既是上线依据，也是将来扯皮时"我们确实测过"的证据。多终端适配，测过和没测过，上线后完全是两回事。