WiFi网络计费系统里有两套逻辑一直在拉扯：认证方式和计费策略。认证方式决定用户怎么连上网，计费策略决定用户怎么被计量和扣费。这两件事听起来各自独立，但在实际系统里它们紧密耦合，配置不当就会出各种说不清的问题。有些项目把认证和计费分给不同的人配置，结果上线后发现认证能过但计费数据对不上，或者计费策略生效了但用户体验极差。认证和计费怎么配合，是部署阶段必须想清楚的问题，不能两边各做各的。

Portal认证和按时长计费是天然搭配

Portal认证是WiFi网络计费系统里最常见的认证方式，用户连接WiFi后弹出认证页面，输入账号密码后上网。这种认证方式天然适合按时长计费——认证成功的那一刻开始计时，用户主动断开或超时自动断开时停止计时，时长统计相对准确。但要注意的是，Portal认证有一个容易出问题的点：用户关掉浏览器不代表下线，如果系统没有检测到终端离线，计时会一直持续。配置按时长计费时，必须同时配置终端在线检测策略，比如连续3次心跳无响应就判定下线，否则用户下次登录时会发现上次的时长还在跑。

802.1X认证和按流量计费的配合更精细

802.1X认证比Portal认证更底层，认证发生在链路层，用户感知不到认证页面的存在，体验更好。802.1X和按流量计费配合时，流量统计的精度更高，因为认证状态下所有流量都经过计费系统管控，不像Portal认证可能存在认证前流量漏计的问题。但802.1X的部署门槛更高——终端要配置证书或客户端，AP和交换机都要支持，运维复杂度上去了。如果学校对计费精度要求高，用户终端相对固定（比如教学楼的有线网络），802.1X是更好的选择。如果是访客WiFi或者公共区域，Portal认证就够了。

MAC认证不适合做计费但可以做免认证

MAC认证在WiFi网络计费系统里经常被误用。有些学校把MAC认证当成正式认证方式，给每个终端的MAC地址绑定账号，按MAC地址计费。这有两个问题：第一，MAC地址可以伪造，学生改个MAC地址就能用别人的额度；第二，终端MAC地址会变化，比如iOS的私有地址功能会让同一个手机每天换MAC地址，计费数据全乱。MAC认证真正适合的场景是免认证——比如打印机、IoT设备这些不需要计费的终端，通过MAC白名单直接放行。把MAC认证用在该用的地方，别拿它做计费依据。

混合认证策略要按区域分场景设计

学校里不同区域的WiFi使用场景差异很大，用一套认证+计费策略去管所有区域往往行不通。教学楼适合802.1X认证+不限流量按时长统计（主要为了审计）；宿舍区适合Portal认证+套餐制流量计费（学生有明确的消费预期）；公共区域适合Portal认证+免费限时策略（保障基本网络使用）。WiFi网络计费系统要支持分区域策略，认证方式和计费策略按区域独立配置。混合策略的配置关键是策略之间的切换逻辑要清晰——用户从宿舍区走到教学楼，认证方式怎么切换、计费策略怎么切换、切换过程中是否有断网感知，这些细节配置好了用户体验才好。

认证失败时的计费处理逻辑不能忽略

WiFi网络计费系统里有一个容易被忽略的边界情况：认证失败时已经产生的流量怎么处理。用户输入了错误密码，认证没通过，但终端已经尝试连接网络，可能产生少量流量。这些流量要不要计入用户账户？大多数系统默认不计入，但如果没有明确配置，可能出现认证失败用户仍然产生流量、而计费系统没有记录的情况。这类边界情况虽然流量不大，但在审计追责时可能成为漏洞。认证失败时的流量处理策略要明确：要么完全阻断（认证前不分配IP），要么记录但不计费（日志留存用于审计）。

套餐切换时的认证状态衔接

用户在WiFi网络计费系统里切换套餐时，认证状态的衔接是一个技术细节。比如学生从"10元5G套餐"切换到"20元10G套餐"，切换过程中用户是在线的，是要求用户重新认证，还是系统自动刷新策略不用断线？前者用户体验差，后者技术实现复杂。不同系统的处理方式不同，配置时要根据实际场景选——如果切换频率低，要求重新认证也没大问题；如果切换频率高（比如按天切换套餐），必须支持无感切换，否则用户每次切换都要重连WiFi，投诉量会很高。

认证和计费的数据一致性要定期校验

认证系统和计费系统是两套数据，即使在一个平台里也分属不同模块。上线运行一段时间后，两边的数据可能出现不一致——认证记录显示用户在线，但计费系统显示用户已下线；或者计费系统记录了流量，但认证系统没有对应的会话。这类不一致如果不定期校验，积累起来就是计费纠纷的根源。WiFi网络计费系统要配置每日数据一致性校验，把认证日志和计费日志做交叉比对，不一致的记录单独列出处理。这个工作不复杂但必须有人做，不能等到用户投诉了才发现数据对不上。