去年做一个产业园区的项目，客户提了一个需求："我们门禁系统、考勤系统、认证计费系统，能不能打通？员工在公司门口刷门禁进来了，考勤自动打卡，连WiFi也自动认证上网，不用再输账号密码。"这个需求听起来很合理，但真做起来，发现三个系统各自的数据模型、接口规范、运维团队都不一样，打通的复杂度远超预期。

先搞清楚"打通"到底要什么效果

客户说"打通"，可能指三种不同的效果。第一种是"身份打通"：三个系统用同一套账号体系，员工换部门了，只要在HR系统里改一下，门禁、考勤、上网的权限都同步更新。第二种是"体验打通"：员工刷门禁进来，后面上网认证自动完成，不用再操作。第三种是"数据打通"：三个系统的数据能互相查询，比如HR想看某个员工今天有没有来上班、有没有在公司上网，能在一个界面里看到。

这三种打通，技术实现难度递增。身份打通相对简单，一般做法是选一个系统作为"身份源"，其他系统定时同步身份信息。体验打通需要系统之间有实时交互接口，比如门禁系统刷门成功时，发一个消息给认证计费系统，触发自动认证。数据打通最复杂，需要建一个统一的数据平台，三个系统的数据都往里面送。

所以对接之前，我会先跟客户确认：你们最想要的是哪种打通效果？如果预算有限，先做哪一种？有些客户一开始想要"全部打通"，但聊完预算和实现周期，会选择"先做身份打通，后面再考虑体验打通"。

门禁系统和认证计费系统的"时空差异"

门禁系统和认证计费系统，看起来都是"认证"场景，但实际使用的时间、空间差异很大。门禁认证发生在入口处，时间点是"到达公司"的那一刻；上网认证发生在办公区域内，时间点是"打开电脑连WiFi"的那一刻。这两个时间点，可能只差几分钟，也可能差几个小时（比如员工先去食堂吃早饭，再进办公室）。

如果要实现"刷门禁后自动上网认证"，就要处理这种时间差。一种方案是：门禁系统刷门成功后，把员工身份信息和"预计上网时间"发给认证计费系统，认证系统提前把这个账号设为"已认证"状态。但这样有个问题：如果员工刷了门禁但临时又出去了（比如忘带东西），那提前认证的账号就浪费了，还可能被别人冒用。

更稳妥的方案是：门禁系统和认证计费系统之间做一个"短时效令牌"机制。刷门禁的时候，生成一个有时效的令牌（比如10分钟内有效），员工连WiFi的时候，认证系统校验这个令牌，如果有效就自动认证通过。这个方案更安全，但要求两个系统之间能实时通信。

考勤系统的"离线优先"设计和上网认证的"实时优先"冲突

考勤系统一般设计为"离线也能打卡"：员工在考勤机上打卡，记录先存在本地，等有网络的时候再同步到服务器。这是为了防止网络故障导致没法打卡。但认证计费系统一般是"实时认证"：用户上网的时候，必须实时向认证服务器确认身份，不能先上网再补认证。

这两个系统的设计哲学不一样，导致对接的时候有冲突。比如，员工刷门禁（触发考勤打卡）的时候，如果网络不好，考勤记录可能没及时同步到服务器，这时候如果员工马上连WiFi，认证系统可能查不到他的考勤状态，就不给自动认证。

解决这个冲突，一般有两种思路。一种是"以认证系统为准"：不管考勤记录有没有同步，只要员工在门禁系统里有有效身份（比如当天刷过门），认证系统就给通过。这种方案简单，但可能出现"代刷门禁"的安全漏洞。另一种是"以数据同步为准"：门禁系统和认证系统之间建一个高可靠的实时同步通道，确保刷门禁的记录秒级同步到认证系统。这种方案安全，但对网络稳定性要求高。

三个系统的接口对接，谁来开发

对接项目里最容易出现推诿的环节就是"接口开发责任划分"。门禁系统厂商说："我们有标准接口文档，认证计费系统那边按文档开发就行。"认证计费系统厂商说："我们系统支持标准协议，门禁系统那边按协议推送数据就行。"两边都有道理，但真要动手的时候，发现谁都不太想主动改自己的代码。

我经历过的对接项目，接口开发责任划分一般有几种模式。第一种是"总包模式"：客户找一家集成商，由集成商负责跟所有系统厂商协调，接口开发工作量算在总包合同里。第二种是"指定主导方模式"：客户指定其中一个系统厂商作为主导方，负责写接口对接方案，其他厂商配合。第三种是"各自开发模式"：每个系统厂商都开发自己的对外接口，然后由客户自己的IT团队或者外包团队写集成脚本，把接口串起来。

这三种模式各有优劣。总包模式省心但贵；指定主导方模式省钱但容易扯皮（主导方可能偏向自己的系统）；各自开发模式最灵活但要求客户有自己的技术力量。

对接后的运维责任划分

系统对接完，上线运行，这时候如果出现问题，比如"员工刷了门禁但上网认证没自动通过"，应该找谁排查？是门禁系统没推送成功，还是认证系统没接收到，还是中间网络传输丢了数据？

这个问题，对接项目上线前就要说清楚。我一般会建议客户：建一个统一的日志平台，门禁系统、考勤系统、认证计费系统都把关键操作日志往这个平台送。出了问题，先查日志平台，看整个流程在哪个环节断了。这样责任划分清楚，排查效率也高。

但如果客户没有条件建统一日志平台，那至少要约定：每个系统要提供什么样的自检工具，让运维人员能快速判断问题出在哪个系统。比如，认证计费系统要能提供"查询某用户自动认证触发记录"的功能；门禁系统要能提供"查询某员工刷卡记录是否成功推送"的功能。

真实案例：一家工厂的对接项目踩过的坑

去年做的一家工厂项目，对接需求是：员工刷门禁进厂（同时考勤打卡），然后连工厂内网WiFi的时候自动认证，不用再输账号。我们选的方案是：门禁系统刷卡时，通过MQTT消息推送给认证计费系统，触发自动认证。

项目上线后，一开始运行正常。但过了两个月，有员工投诉："我刷了门禁，但连WiFi的时候还是要输账号。"我们排查发现，问题出在MQTT消息的QoS等级配置错了。我们配的是QoS 0（最多发送一次，不保证送达），在网络不稳定的时候，会有消息丢失。改成QoS 1（至少送达一次）后，问题解决了。

但这个改动引发了一个新的问题：有些情况下，同一条刷卡记录会被推送多次（网络闪断重传），导致认证系统重复触发自动认证，系统日志里出现重复记录。虽然不影响功能，但日志污染看起来不专业。最后我们加了一个"消息去重"的逻辑：每条MQTT消息带一个唯一ID，认证系统收到消息后先检查这个ID是否已经处理过，如果处理过就忽略。

这个小插曲让我意识到：系统对接不是把接口调通就结束了，还要考虑各种边界情况和异常处理。这些地方，厂商的标准接口文档一般不会写，只能靠项目经验去补。

对接项目，技术难度是一方面，项目管理难度是另一方面。三个系统，可能涉及三家厂商，每家的项目排期、接口规范、测试环境都不一样。作为集成商或者项目牵头方，要花很多精力在协调沟通上。有些客户觉得"对接就是写代码"，但实际上，写代码的时间可能只占整个项目周期的三分之一，剩下三分之二都在协调、测试、整改。