做过弱电集成的应该都有这个经历：甲方扔过来一个需求，说"我们要上无线认证系统，你给我报个方案"。一听觉得简单，Portal服务器、RADIUS、AP，再加一台网关，好像搭起来就行了。等真正动手才发现，甲方说的"无线认证"和他真正需要的根本不是一回事。

学校有学校的需求，酒店有酒店的麻烦，政务窗口和工厂车间完全是两码事。同一个词，背后要解决的问题差着十万八千里。项目能不能做下来，往往不是技术行不行，而是问题有没有问对。

第一步，先搞清楚甲方的场景是什么

无线认证系统不是一套标准产品打天下。不同场景的核心诉求根本不一样，拿错方案去谈，要么功能过剩，要么关键功能根本不支持。

学校场景最怕的是什么？学生多、设备杂、日志要留存。绝大多数省市的中小学现在都有公安审计要求，上网日志留存180天是基本门槛，如果认证系统没有完整的日志记录功能，验收的时候会被直接打回来。另外学校的账号体系通常比较特殊，有的用学号，有的用手机号，有的要和一卡通系统对接，Portal页面怎么配合、账号怎么统一管，这些都要在方案阶段问清楚再做选型。

酒店场景稍微复杂一点，客房无线和公共区域无线其实是两套逻辑。客房主要是住客用，认证方式通常要求简单，短信或者房号密码都行，关键是退房后自动断网、不能延续到下一个客人。公共区域——大堂、会议室、餐厅——则有可能是营销场景，微信吸粉、Portal广告推送这些运营需求也经常出现。拿着一个方案同时去套两个不同的需求，配置的时候会很别扭。

政务窗口和公共服务场所，核心矛盾是实名审计。办业务的群众流动性强，不一定配合主动注册，实名制落地往往要靠短信认证或者运营商标记。日志追溯能力是刚需，项目验收基本都绕不开这一项，不是可选项。

企业总部场景如果需要对接AD域或者LDAP，那Portal方案就不够用了，通常要上802.1X，和现有的网络设备、交换机做联动。配置链路长，终端兼容性要提前测试，一旦出问题排查起来比Portal麻烦得多。但好处是安全等级高，而且员工不需要每次连WiFi都输密码，支持MAC无感知认证，体验也不差。

所以接到项目的时候，先别急着列设备清单，问清楚三个问题就够了：这个项目是哪种场景，核心要管的是员工、访客还是外部群众，日志追溯是验收必须项还是可选项。把这三个问题回答了，选型方向基本就定了。

Portal方案，AC兼容性是个大坑

选Portal认证的集成商很多，因为这种方式对终端几乎没有要求，智能手机、传统电脑、各种智能设备都能用。但Portal最大的隐患不在认证本身，而在和现有AC的配合上。

华为有华为的Portal协议版本，中兴有中兴的标准，华三和锐捷又各自有一套。不是说Portal不通用，而是各家在实现细节上有差异，有的AC能精准推送自定义Portal页面，有的只能弹出一个简陋的通用框。认证网关和AC之间的配合顺不顺利，不是看协议名字对不对得上，而是要看实测效果。

项目上常见的问题是：前期方案沟通时厂商说支持，等进场对接了才发现华为AC的Portal推送只能跳到厂商自己的认证页面，自定义页面根本塞不进去。AP点位数量少的时候还能绕过去，AP数量一多，整个网络验收就被卡在这里。

稳妥的做法是在签合同之前，要求做一次小规模对接测试。用项目实际的AC型号、实际的网关设备，跑通Portal推送、账号认证、上网策略这三条基本路径，能跑通再往下走。这一个测试做下来，可能比改三版方案的时间成本都低，但能避免进场之后才发现对不上的尴尬。

日志留存和实名审计，这两项不过验收很难过

连锁酒店、商场、政务大厅这些场景，现在都有明确的合规要求。上网日志要能追溯到具体的人在具体的终端上做了什么事，留存时间通常要求不少于180天。这不是行业惯例，是很多省市公安网的检查清单里的必查项。

很多集成商在这一步踩过坑：方案里写了认证网关的功能参数，性能指标漂亮，但偏偏没有提日志系统，项目做完了甲方验收时被要求提供三个月前的某台终端的上网记录，系统里根本查不到。问题不在设备，在于方案里没有把日志留存和追溯能力当回事。

确认日志需求的时候要问几个具体数字：留存多长时间，日志里包含哪些字段，能不能按账号、按终端MAC、按IP地址查询，能不能导出成检查部门要求的格式。这几项说不清楚的方案，一律不能签字。

认证方式多不等于方案就稳

有些厂商会拿"支持十几种认证方式"当卖点。短信、微信、802.1X、LDAP、一键登录、无感知认证，说出来阵容豪华。

但真实项目里用到两三种认证方式就算多了。短信认证要接短信服务商，每条有成本；802.1X对终端有要求，兼容性测试工作量不小；多因素认证听着安全，但配置复杂，用户体验差，上了反而会被投诉。企业内部员工用场景，Portal加无感知认证基本够用；访客为主的场景，短信或者微信就够。认证方式越多，运维和故障排查的复杂度也越高。

选型的时候把"项目真正用得上几种"和"每种方式后续的维护成本是多少"这两条先算清楚，再去看总数字。

部署方式要提前谈清楚

云端部署还是本地部署，看起来是技术选择，实际上影响的是整个项目后期的运维模式和责任边界。

云端方案好处是开局快、管理集中，多点位统一管控很方便，但数据要上到云端，网络延迟和专线成本要先确认。本地部署数据更安全，响应实时性好，但本地设备要有人管，出现故障要能第一时间到场或者远程处理。多分支机构的情况下，还要谈清楚总部的云端系统和各分支的本地设备之间怎么联动、故障升级谁负责。

还有一个常见的分歧点是双机热备。核心机房做了双机热备，但分支机构的AP掉线了没人管，这种不对称的保障体系在验收和售后阶段会产生大量扯皮。方案里把各级别的保障要求写清楚，比出了问题再吵有效得多。

设备性能别只看书面的，要看并发

认证网关的性能参数里有两个数字要重点看：每秒认证次数和最大在线用户数。Portal每秒认证4000次以上、RADIUS每秒认证4000次以上这些指标拿出来很漂亮，但实际场景要看并发峰值。

学校搞集体活动，几千台设备同时接入；商场高峰期，认证请求集中爆发；工厂车间换班，几百人同时认证。这些场景下如果设备标称的并发数不够，用户端的表现就是Portal弹不出来或者认证超时，投诉会直接堆到甲方那里。提前和甲方确认最大并发规模，用真实数字去匹配设备参数，比看PPT里的理论上限靠谱得多。

多厂商设备混用，责任边界要提前理清

实际项目里，大多数场景不是从零搭建，而是在现有网络上做叠加。AP可能是好几个品牌的，AC是甲方的，网关和认证系统是这次新上的。一旦出问题，集成商说网关没问题，网关厂商说AC不对接，AC厂商说配置没问题，最后集成商夹在中间两头受气。

项目合同里把各厂商的分工写清楚：AP掉线谁管，AC对接认证网关的参数谁来配，出现认证失败的问题怎么逐级排查。出了问题能快速定位责任，比事后吵架省心得多。

无线认证系统本身的技术难度不算高，项目能不能做好，往往取决于前期的需求确认做得够不够细、方案里的坑填得够不够多。场景搞对了，AC兼容性测过了，日志功能确认了，并发规模对齐了，后面的施工和验收不会出大幺蛾子。