所以，网络WiFi认证计费系统上线前，真正重要的不是先看页面，而是先把现场条件摸透。这里面最不能含糊的，一般就是三类：现有设备条件、认证链路条件、收费规则条件。
先看现有设备。网络WiFi认证计费系统几乎不会在完全空白的环境里部署，现场通常已经有AP、交换机、无线AC、路由器、出口设备，甚至还可能已经跑着一套基础认证。这个时候，系统能不能顺利落进去，第一步就得看现有设备条件够不够。最常见的问题就是现有AC是否支持外部Portal，是否支持Radius，固件版本是否有兼容限制，终端接入以后流量到底经过哪些节点。如果这些问题前期不搞清楚，后面就很容易出现一种情况：页面能弹、认证也能提交，但放行状态不稳、计费状态不同步，或者根本没法把收费链路接完整。
很多客户前期会直接问一句：我们现场已经有无线设备了，你们系统能不能直接接？这个问题如果回答得太快，后期往往最容易出事。因为“能接”不是看能不能弹出个页面，而是看认证和计费的整条链路能不能真正跑通。现有设备品牌、型号、版本、网络结构、出口位置，这些都必须提前确认。只有这些条件明确了，才能判断是直接对接就行，还是需要增加认证网关，或者需要做局部调整。
第二个重点，就是认证链路。很多人做网络WiFi认证计费系统，只盯着前端页面，觉得用户输入账号、手机号、验证码，能认证成功就差不多了。实际上，项目真正稳不稳，看的不是页面，而是后面那条认证链路是不是闭环。用户接入无线后，页面怎么弹出来，认证请求发给谁，认证成功结果怎么回传，设备放行由谁来执行，收费状态怎么同步，终端在线状态怎么维护，这些都属于认证链路的一部分。只要其中某一段前面没确认好，后面就会不停出小问题。
比如现场到底准备采用什么认证方式，这个就必须提前定。员工走账号密码还是企业微信，访客走短信还是微信，住客和学生用房号、学号还是手机号认证，临时来宾是不是要走前台开通或者审批放行。这些不是上线后边试边改的东西，而是前期就要收口的规则。因为不同认证方式，对接条件不同，后台策略也不同。如果前面没有把人群和认证方式拆开，后面很容易所有人走一个入口，看起来简单，实际管理全乱了。
再往下，就是收费规则。这个部分很多客户前期只会说一句“要能计费”，但这句话其实等于没说。因为计费系统最怕的不是没收费功能，而是收费规则定义不清楚。比如到底按时收费、按天收费、按月收费，还是多种套餐并存；一个账号允许几台设备在线；套餐什么时候生效；到期后是直接断网还是先提醒；续费后从购买时开始算，还是顺延到原套餐后面；用户能不能自己续费，能不能提前买下一期套餐。这些问题前期如果没有明确，后面就一定会反复改。
尤其是终端数规则，很多项目都会在这里出问题。因为一个账号到底能几台设备上网，不只是体验问题，也是收费问题。如果前期不定清楚，后面用户会不断问：为什么我手机能用，电脑不能用？为什么我换了一台设备就登录不上？为什么我买了套餐还要被踢下线？这些问题表面看是系统问题，实际上往往是收费规则和终端规则没有提前确认好。所以网络WiFi认证计费系统上线前，终端数限制、终端绑定、终端解绑、超限处理方式，最好都一次性说透。
还有一个很关键的点，是网络出口和日志。很多客户上系统时只想着认证和收费，却没把出口控制和日志留存一起考虑。实际上，只要现场对日志、留痕、行为回查有要求，就不能只盯着登录页面。认证成功后是谁放行，出口日志从哪里留，认证记录和上网行为能不能对应上，异常时能不能追到具体账号和时间段，这些都要提前确认。特别是公共场所、酒店、公寓、园区这类场景，日志留存能力很容易变成后期的硬要求，前面不看，后面会非常被动。
部署方式也不能含糊。是单点本地部署，还是多站点统一管理，是每个楼栋独立，还是集中后台统一配置，这些都会直接影响系统设计。很多项目前期规模不大，客户觉得先让一栋楼跑起来就行，结果过几个月又要扩楼、扩区域、扩用户量，这时如果前面没有考虑扩展性，后面改起来就会特别麻烦。网络WiFi认证计费系统不是只看眼前一周怎么上线，还要看半年后、一年后会不会扩场景、改规则、加用户。如果这些趋势前期就大概率存在，那部署方式最好一开始就往稍微长远一点的方向规划。
再说管理和运维。很多客户以为系统上线后，后面只要用户自己买套餐就完了。实际并不是这样。上线之后，管理员还会经常碰到很多问题：账号开通、套餐调整、设备解绑、访客开通、欠费处理、报表导出、日志查询、异常排查。如果前期没有把管理员角色、操作流程、权限分配理清楚，系统虽然装上了，后面却没人敢动，或者出了问题谁都不知道从哪查。一个真正顺的项目，不只是系统功能够用，而是上线前就把“谁来管、怎么管、常见情况怎么处理”这些事情想清楚。
说到底，网络WiFi认证计费系统上线前要确认什么，核心就是一句话：不要带着模糊需求直接开干。 现有设备条件要看清楚，认证链路要跑通逻辑，收费规则要一次性收口，终端限制要提前说明，日志和出口要一并考虑，部署方式和后期运维也要有预案。很多项目后期反复返工，不是技术做不了，而是前面把事情想简单了。真正做得稳的项目，通常不是上线时冲得最快的，而是前期把关键条件问得最透的。条件确认清楚了，后面上线才会顺，系统跑起来也会稳得多。
English