WiFi实名认证系统装上之后，运营最该盯的其实不是认证顺不顺，而是日志留得对不对、审计对不接得上。很多单位认证跑得欢，一被监管抽查日志，发现留存时长不够、字段对不上、查询接口卡死，照样判不合规。日志留存和公安审计对接是实名认证系统的"后半篇文章"，做不好，前面认证再稳也白搭。

要留哪些日志，先把字段清单列全

实名认证产生的日志至少包括：用户身份标识、认证时间、下线时间、使用的IP和MAC、上网站点或目标（按监管要求粒度）、认证方式、失败原因。每一类都要按监管模板的字段名和格式存，不能自己起名。我们做项目第一步就是拿监管的数据规范，把字段逐条映射到系统里，缺哪个补哪个。常见的坑是只存了认证成功记录，没存失败记录，结果监管问"某时段有多少认证失败、什么原因"，答不上来。字段清单要对齐规范，不是系统有什么就存什么。

留存时长要卡在法定区间内

日志不是存越久越好。法定有最低留存期，一般是六十天，具体看场所和属地。低于最低期，监管查不到算违规；远高于，又违反个人信息存储期限最小化。WiFi实名认证系统要把留存期做成可配置，按法定最低期设默认值，到期自动清理，清理动作留痕。我们建议客户把留存策略写进制度文件，变更要走审批，不能运维随手改。曾经有单位为了"留着以后分析"，把日志存了一年，被指出超期留存个人信息，反而惹麻烦。

存储容量要按峰值提前算

日志量比很多人想的大。一个日均五千认证的场所，每条记录算几百字节，六十天就是上亿条，加上上网明细更大。存储不够，系统跑几个月就满，满了之后要么写不进新日志、要么开始丢旧日志，两种都致命。上线前要按用户规模和留存期算总存储，留出一倍余量，并且规划扩容方式。我们见过一个项目，存储满了没人告警，日志悄悄停止写入，监管来查发现近一个月空白，直接出问题。存储容量和告警，是留存能落地的物理基础。

上报接口要联调，不能只发不验

日志上报到公安指定平台，不是把文件丢过去就完事。上报的格式、加密、频率、接收确认，都要和对方平台联调通过。我们强调上线前必须做一次完整的联调：发一批测试数据，确认对方能正确解析、入库、可按条件查询。很多单位只在自己这边看"发送成功"，但对方平台字段对不上解析失败，等于没报。联调要覆盖正常数据、边界数据、异常数据，确认对方在各种情况下都能正确处理。这一步省了，上线后就是定时炸弹。

查询响应要够快，演练不能少

监管调证往往有时限，要求多长时间内提供指定时段的认证和上网记录。系统查询接口如果慢，或者数据量一大就超时，到时候拿不出就是问题。我们建议把"监管调证"当成一项常规演练，每季度模拟一次，从发请求到出完整数据，测响应时间和准确性。曾经有单位平时不练，真来查了，查询语句跑了二十分钟没出结果，场面很难看。查询性能要在设计阶段就考虑索引、分区、缓存，不能等数据堆成山再优化。

数据一致性和时间对齐是硬伤高发区

审计最怕身份和上网行为对不上、时间对不齐。比如认证记录记的是A时间，上网明细是B时间，中间差几分钟，串起来就有缝隙；或者身份标识在两段日志里格式不一致，关联不上。我们要求系统内部所有时间用统一时钟（NTP同步），身份标识全程用同一个主键。多设备、多区域部署时尤其要注意时钟一致，差一秒都可能在追溯时造成断点。数据一致性不是锦上添花，是审计能不能成立的前提。

本地留存和对外上报要职责分离

日志既要本地留存供自查，又要对外上报供监管，两套职责要分离。本地留存按运维和审计需要设计，对外上报只取监管要求的字段、只连指定地址。不能把完整的本地日志库直接对外开放，也不能为了上报方便把内部数据粒度放松。WiFi实名认证系统要把"本地库"和"上报模块"做成两个独立环节，上报模块只读必要字段。我们见过单位为了方便，把整个日志库权限给了第三方运维，结果数据泄露。职责分离守不住，留存和对接两头都危险。

把审计对接当成持续性工作

监管规范会变，对接平台会升级，日志留存和审计对接不是上线一次就完事。我们建议单位把这块纳入日常运维：监控上报成功率、定期演练调证、关注规范更新、留存策略随法规调整。WiFi实名认证系统厂商一般也会跟进项升级，但单位自己要有主动权，不能全押在供应商身上。后半篇文章写好了，实名认证系统才是真正合规闭环，否则前面认证再漂亮，监管一查还是露怯。