公共场所提供WiFi，实名认证不是单位自己想不想做的问题，是法规要求。但真正落地的时候，很多人对"实名"的理解停留在"让用户输入手机号收个验证码"，没有意识到这背后连着一套和运营商、和公安对接的链路。WiFi实名认证系统和运营商实名要求之间的对接，细节非常多，任何一环没接好，要么是认证不通过，要么是数据传不上去，要么是被监管抽查时拿不出合规凭证。

手机号实名只是第一层，不是全部

用户填手机号、收验证码，这一步只能证明"这个号码能收短信"，并不能证明"用WiFi的人就是号码主人"。监管要求的是把上网行为和真实身份对应起来，所以很多场景下还需要进一步核验，比如上传身份证、做人脸比对，或者对接运营商的实名库做二次校验。我们在做商场项目时发现，只走短信验证，监管那边不认可，要求补身份核验环节。单位在规划WiFi实名认证系统时，不能只按"能连上"来设计，要先把当地公安对实名等级的要求问清楚，再决定认证流程要做到哪一层。

短信通道要接运营商合规网关

验证码短信不是随便接个短信平台就行。监管对短信通道有要求，必须是经过运营商实名备案的通道，发送内容、频率、用途都要在备案范围内。有些单位图便宜接了来路不明的短信接口，验证码经常延迟或者收不到，更麻烦的是被运营商判定为垃圾短信通道直接封掉，整个认证链路就断了。对接时要确认短信服务商有正规运营商授权，能提供通道资质证明，并且验证码发送要有限频和防刷机制，避免被恶意刷量导致通道被封。这些在采购阶段就要写进合同，不能上线后出了问题再换。

和运营商实名库的对接方式要定清楚

部分场景要求WiFi实名认证系统把用户身份信息和运营商实名库做比对，确认号码和机主一致。对接方式一般是通过运营商开放的认证API，或者由公安侧的统一平台转发。这里的问题是接口标准不统一，不同运营商的字段、鉴权方式、返回码都不一样，对接前要拿到完整的接口文档和测试环境。我们踩过坑：某项目对接时只按一家运营商的返回码写了解析逻辑，换到另一家运营商，返回结构变了，比对结果全错，认证大面积失败。所以对接文档要覆盖所有会用到的运营商，测试也要逐家跑通，不能只测一家。

数据上报的格式和频率要符合监管口径

实名认证产生的上网日志、身份对应关系，要按监管要求上报到指定平台。上报不是随便发个文件，格式、字段、加密方式、上报频率都有明确规定。我们见过一个项目，上报数据用的是明文HTTP，被监管指出不符合传输安全要求，要求改成加密通道并补传输日志。还有字段命名和监管模板对不上的，对方平台收了但解析不出来，等于没报。对接前要把监管的数据规范拿全，按字段逐项映射，最好做一次联调，确认对方平台能正确解析和入库，再正式上线。

留存期限和查询接口是容易被漏掉的硬指标

实名信息不是存了就行，还要能按监管要求留存足够长时间，并且提供查询接口供核查。留存多长时间、哪些字段必须留、查询响应要在多久内返回，这些都要在系统设计阶段明确。有的单位系统只存了认证时间，没存对应身份和上网明细，监管来查的时候拿不出完整链路，就被判不合规。还有留存周期设太短的，到期自动清理，正好把监管要查的时间段清掉了。这些细节比"认证顺不顺畅"更关键，因为它直接关系到单位会不会被处罚。

访客和内部员工的实名口径要区分

单位自己员工的WiFi，通常可以走内部账号体系，通过统一身份认证对接，不一定每次都走运营商短信验证。但访客WiFi必须走对外实名。WiFi实名认证系统要能区分这两类场景，分别走不同的认证和上报路径。如果混在一起，要么内部员工每次连WiFi都要收验证码，体验极差；要么访客走了内部通道，实名要求没满足。对接设计时要把员工实名和访客实名当成两套流程，分别对接对应的身份源和上报口径，不能图省事合二为一。

接口变更和故障要有兜底机制

运营商接口、监管上报平台都不是单位能控制的，它们升级、维护、临时故障都可能发生。WiFi实名认证系统要设计兜底：比如短信通道故障时有备用通道，上报失败时有本地重试和补报队列，实名比对超时时有明确的失败处理而不是卡死用户。我们建议把外部依赖的可用性当成系统的一部分来管理，做监控、做告警、做切换演练。否则外部一抖，单位自己的网络就瘫一片，这种事在重大活动期间尤其致命。

对接工作要留下完整的合规证据链

从短信通道资质、运营商接口授权、监管上报联调结果，到留存策略配置截图，整个对接过程要保留可查的证据。监管抽查时看的就是这些。很多单位系统跑得好好的，一被问"你的实名链路合规证明呢"，拿不出东西。证据链不全，系统再稳也经不起查。建议对接阶段就让供应商配合出一份合规对接说明，把每一步对接的资质、接口、测试结果都附上，归档备查。这件事麻烦，但关键时刻能替单位挡掉不少风险。