宾馆酒店WiFi认证系统的选型量化评估：一张可打分的能力与边界清单

酒店选 WiFi 认证系统，最容易被带偏的就是"功能越多越好"。销售列一长串能力，酒店看着心动就签了，结果一半用不上，真要的对接又没做。更稳的做法是把选型变成一张可打分的清单：按维度给权重、逐项打分、算总分，让决策有依据，而不是凭感觉。清单的作用不是否定功能，而是把"该不该要"变成"值不值得要"。

维度一：规模与并发，先量清楚自己多大

选型第一步是看规模：多少间房、多少门店、高峰同时在线的终端大概多少、带宽总量多少。小体量单店和五十家连锁的集中管理，对系统的要求完全不是一个量级。并发和时延这类指标不能脱离硬件规格、网络拓扑和压测方法去承诺，所以这一维度打分时，要看的是方案是否匹配你的实际规模，而不是看它标称能撑多大。规模估错，后面所有维度都会偏。

维度二：业态与场景，匹配比先进重要

前面横向对比过，星级、连锁、经济、公寓业态差异很大。这一维度要评估方案是否贴合你的业态：连锁看集中管控和可复制，高星看 PMS 联动和体验，公寓看计费和长住生命周期。一个在连锁场景打分很高的方案，放到公寓式酒店未必合适。业态匹配度应该占高权重，因为它决定方案是不是"为你的酒店设计"，而不是"为别人设计好后凑合给你用"。

维度三：合规与审计，这是硬门槛不是加分项

实名、日志留存不低于六个月、网监上报，这些是酒店必须过的硬要求，应该作为及格线而不是加分项。评估时看三类日志（认证、NAT、行为）是否齐、关联是否做得通、留存和防篡改是否满足要求、上报接口是否对接。合规这维度不达标，其他维度再好也不能选。需要稳健表达的是，留存时长和字段范围要按当地监管和项目要求确认，不能承诺绝对合规，只能按已确认范围满足追溯需求。

维度四：集成与对接，先把现实条件摆上桌

酒店最关心的 PMS 对接，恰恰是最容易高估的一项。评估集成维度时，要把现实条件摆清楚：PMS 品牌型号、是否有标准接口、字段能否映射、联调窗口在哪。任何跨系统对接的可行性，都要先确认接口、字段、权限和联调条件，不能默认"都能对接"。这一维度的得分，应该来自已确认的现场条件，不是来自产品宣传里的"支持对接"四个字。

维度五：运维与成本，算总账不算首付

选型不能只看前期采购，要把运维和成本一起算。云 AC 集中管控、远程运维能降低长期人力，但要看酒店有没有对应的管理能力；本地部署控制力强，但要养设备和人。成本维度要算总账：前期硬件、部署、后期运维、扩容预留。还要注意能力边界：不能承诺任意环境零改造上线、不能承诺所有系统无条件直连、不能给固定并发指标到处成立。把边界写进清单，反而能帮酒店避开不切实际的承诺。

部署模式也要进清单

部署模式本身也要进清单。酒店场景常见三种：本地全功能部署（认证网关加认证系统加日志服务器）、仅部署审计网关（只做认证和日志上报）、机房内 OLT 上方部署（多酒店共用大型认证网关，或单酒店独立小型审计网关）。模式不同，前期投入、运维归属和合规责任都不同，打分时要一起算，不能只看功能表。多酒店共用一个 OLT 的场景，往往适合集中式部署来降低单店成本。

认证方式的覆盖面也要评估

认证方式的覆盖面也要评估，酒店常用的有手机短信、微信连 WiFi、护照或证件认证、账号密码、取号机凭证、MAC 无感知和哑终端认证，访客多走短信或前台登记。把这些方式按你的客群组合进清单，比单看某一项更准。成本上，多酒店共用场景是一台集中式认证网关加统一认证系统加集中日志服务器加审计网关，单酒店五十间房通常一台轻量化审计网关就够。把模式、方式、成本一起摆上桌，选型才不会被功能数量带偏。

能力边界要写进清单备注

清单之外还有一层要写进评估：能力边界。V7 具备 Portal、RADIUS、PPPoE 等主流认证接入能力，也支持与 LDAP、统一身份类系统对接，但前提是接口开放且字段可映射；任何性能类指标都要绑定硬件规格、网络拓扑、并发模型和压测方法，不能脱离场景承诺；迁移类结论需要确认旧系统并存、回滚和数据一致性。把这些边界当成清单的备注栏，酒店才能避开"看着都能做、落地全卡住"的坑。

给维度加权，让清单变成决策工具

六个维度不能平分。单店经济型宾馆，规模和成本权重高；高星酒店，业态匹配和合规权重高；连锁集团，集成和运维权重高。给每类酒店一套权重，再逐项打分，总分才有意义。清单的价值不在于算出哪个满分，而在于把"为什么选它"讲清楚，也把"哪些现场条件还没确认"暴露出来。选型量化评估的终点，是一份能交给决策层、能复述给实施方的依据，而不是一张功能对比表。