去年做了一个产业园区的WiFi网络实名认证系统改造项目，改造对象是一个运营了八年的园区，里面有几十家入驻企业、物业团队和临时施工人员。项目做完之后回顾，踩的坑大多数是改造特有的，新建项目不太会遇到。

老网络里的"暗通道"需要彻底排查

园区原来的网络是逐步扩容建起来的，当年没有统一规划，各楼栋分别布线，后来加了一层汇聚，但底层的一些直通出口没有清理干净。开始施工后我们发现有三个交换机端口是直接通外网的，完全绕过了认证网关，这些端口是早年某个企业单独拉的宽带，企业撤走之后端口没有回收，一直在那里。

这种"暗通道"对WiFi网络实名认证系统的部署影响很大：如果认证网关覆盖不完整，认证系统的日志就是有缺口的。监管审查时，日志里没有记录的那段时间不是"没有上网行为"，而是记录不到。这种情况暴露出来的后果比没装认证系统还麻烦。

改造项目必须在动工前做一次完整的网络拓扑排查，把所有上行出口都标清楚，确认哪些会经过认证网关，哪些不经过，不经过的要么关掉，要么接入认证链路，确认全覆盖后再推进认证系统的部署。这件事不能靠设备台账，要靠物理核查。

入驻企业的独立网络和园区统一认证的矛盾

园区里的企业有自己的IT需求。有些企业自己拉了专线，有自己的网络出口，用园区WiFi只是补充。这类企业的员工连园区WiFi，不希望走跟其他人一样的门户认证流程——他们在企业系统里有账号，有的还有802.1X的无线认证配置，再走一遍园区的手机号认证，体验很差。

解决这个矛盾的方式是在WiFi网络实名认证系统里为入驻企业单独建账号体系：企业管理员在系统里管理本企业员工账号，员工用企业账号认证，走单独的认证策略（可以更宽松，或者对接企业自己的LDAP）。园区管理员只做汇总监管，看到认证记录，但不需要管理企业内部账号的细节。

这个方案的前提是系统支持多租户模式，要在选型时验证清楚：能不能给不同入驻单位建独立的账号域，域管理员能不能独立管理本域账号，日志是全局可查还是各域隔离。这些功能在不同产品里实现差异很大，不能只看功能列表，要在演示时实际操作一遍。

施工队和临时人员的认证管理容易被忽略

产业园区里除了入驻企业，还有一类人经常被忽略：临时施工队、外包服务人员、访客。这些人不在任何企业的员工名单里，也不可能给他们建固定账号，但他们在园区里也要用网。

临时认证的合理做法是由园区管理员或入驻企业管理员生成临时账号（有效期24小时或指定时段），凭此账号认证上网，过期自动失效。这个流程在WiFi网络实名认证系统里不难实现，但需要有人负责发放和回收，制度上要明确谁来发、发给谁、有效期多长。

我们做的这个园区项目，最初计划是让物业统一发放临时账号，结果物业人员轮班，没有统一操作规程，发账号的方式五花八门，有人打印出来贴墙上（等于公开可用），有人用微信转发，有人根本没有发而是让来访者扫公共二维码——这条二维码对应的是个无限制的账号，等于没有认证。运营流程的管理，和技术系统的功能同等重要。

旧系统的日志和新系统的日志如何衔接

改造而不是新建，意味着有一段历史日志在旧系统里。新系统上线后，旧系统的日志要么导出归档、要么继续保留旧系统只读运行一段时间。这件事如果不处理，监管审查时跨越新旧系统的时间段，可能出现记录断档。

旧日志的迁移有两个难点：格式不同（旧系统可能是私有格式，不能直接导入新系统）；时间精度可能不一致。我们的做法是把旧日志导出为CSV，写了一个转换脚本转成新系统能读取的格式，然后在新系统里以"历史归档"方式导入，保证时间线完整。这个工作量在项目报价里经常没有列出来，临时加工期紧的时候很麻烦。

做园区WiFi网络实名认证系统改造，建议在立项阶段就把旧日志的处理方式定进合同。要么乙方负责迁移，要么甲方自行处理，责任边界要说清楚，不要留到验收时才发现是烫手山芋。