把WiFi上网认证方式搭在一起选，看起来是道多选题，实际上是道场景匹配题。短信、微信、MAC无感知三种方式各有各的适用前提，把一种方式用在错误的场景里，不会直接“用不了”，但会让你和你的客服团队多接很多不该接的电话。

　　WiFi短信认证最大的优势是门槛低到几乎没有。住客不需要装任何APP，不需要关注公众号，不需要记住任何密码，有手机号就能上网。这个特性在酒店场景里是核心竞争力，因为酒店住客的共性就一个：懒。最好是打开WiFi页面就自动弹出，输入手机号，收码填进去，点确认，完事。整个过程住客不用离开浏览器页面，不用打开微信扫二维码，不用输入身份证号。但WiFi短信认证也有它绕不开的成本和风险。短信通道每条验证码都有费用，按条计费，入住率高的酒店一个月的短信费不是小数目。而且短信收不到这种情况永远没法百分之百消除，国际住客尤其明显，一部分国外运营商会拦截来自中国短信通道的国际短信，这个问题目前没有根治方案。

　　微信认证是很多人眼里的“高级选项”。打开微信扫一下二维码就能上网，连手机号都不用输，看起来比短信认证利落得多。但微信认证有一个硬前提和一个软代价。硬前提是住客的手机必须装了微信，并且已经连上了WiFi热点（虽然是未认证状态）。如果你的Portal页没做好流程设计，用户连上WiFi但微信打不开的情况并不少见。软代价是多了至少两跳中间路径：Portal页唤起微信、微信打开认证页、认证页回跳Portal页完成授权。每多一跳就多一个可能出问题的环节。而且微信公众平台自己的接口变更和审核规则变更不受你控制，你今天跑得好好的认证流程，微信后台一个接口升级就可能让Portal页跳转失败。

　　MAC无感知认证走的是另一条路。住客第一次手动认证成功后，系统记住设备MAC地址，下次这台设备再连同一酒店WiFi时自动放行，不需要再手动认证。听起来很理想，但这个“下次”和“同一酒店”两个前提，在酒店这种住客流动性极高的场景里能命中的比例比你想象的低。回头客的比例撑不起一种主认证方式。而且苹果设备从iOS某个版本开始启用了私有MAC地址功能，每次连新WiFi随机生成一个假MAC，在WiFi短信认证系统眼里每次都是新设备。这个限制不是你的系统能解决的，是终端厂商的策略决定的。安卓设备也有类似趋势，部分品牌已经开始跟进随机化MAC地址。

　　三种方式按场景对号入座就很清楚了。酒店场景：以WiFi短信认证为主力，覆盖所有类型住客；微信认证作为备选，给愿意用微信的用户一个更快的入口；MAC无感知作为常客的锦上添花。企业办公场景：MAC无感知加AD域或账号认证为主力，员工不需要每次进办公室都收条短信。临时展会场景：短信认证优先，参展人员没有你的公众号，也没有历史MAC记录，短信是唯一不需要任何前置条件的通道。

　　这里有个细节需要补充：微信认证和短信认证不是二选一的关系，很多系统可以同时开启两种认证方式，让住客自己选。但开启双认证模式会带来两个额外的管理点。第一是Portal页面的设计，要同时放两个入口，并且确保两个入口的跳转逻辑不互相干扰。第二是认证成功后的跳转目标要统一，不能短信认证成功跳回首页、微信认证成功跳回另一个页面，那样用户会困惑。双认证模式在酒店这种住客群体复杂的场景里很有用，但前提是你的Portal页开发团队有足够的前端经验，能把两个认证流程的交互细节处理到位。

　　另一个容易被忽略的点是MAC无感知的“白名单管理”。MAC无感知认证本质上是把设备MAC地址加入一个免认证白名单。这个白名单的容量是有限的，一般几千条到几万条不等。如果你的酒店住客流动性极高，白名单很快会满，满了之后要么自动清理最早加入的设备，要么停止添加新设备。自动清理可能导致常客被误踢，停止添加则让MAC无感知功能形同虚设。所以MAC无感知在酒店场景里只能做锦上添花，不能做主力，原因不光是回头客比例低，还因为白名单的容量管理本身就是一个运维负担。

　　把三种方式的适用边界搞清楚，比花时间纠结哪种技术更先进有用得多。选认证方式这件事，本质上不是选技术，是选你的住客群体最可能接受的那条路径。技术参数可以对比，但住客行为习惯只能靠实际运营数据来验证。上线后看认证方式的使用分布，哪个方式占比最高，哪个方式放弃率最高，这些数据比任何技术白皮书都更有说服力。