苟新节

主题

 

为什么刷脸过闸机后，钉钉会自动完成上下班打卡？ ​

更新: 10/16/2026字数: 0 字 时长: 0 分钟

很多公司现在都使用人脸闸机作为办公楼门禁。比较神奇的是，早上刷脸进入公司后，手机里的钉钉几乎同时就显示了“上班打卡成功”。

很多人可能会以为：

闸机是不是通过蓝牙、Wi-Fi 或其他方式控制了我的手机？

其实通常不是。

这背后本质上是一个门禁系统与考勤系统的数据联动。一次刷脸，不仅可以完成开门，还可以同时产生一条考勤记录。

一、刷脸为什么能够同时完成开门和打卡？ ​

整个过程可以简单理解为：

text
员工刷脸
   ↓
人脸识别
   ↓
确认员工身份
   ↓
门禁权限验证
   ↓
闸机开门
   ↓
产生通行记录
   ↓
同步到考勤系统
   ↓
根据考勤规则生成打卡
   ↓
钉钉显示打卡结果

例如，公司系统中可能已经建立了这样的关联：

text
张三
├── 员工ID：10086
├── 人脸信息：xxxx
├── 门禁权限：1号楼
└── 钉钉账号：xxxx

早上张三来到闸机前，摄像头识别人脸后，系统确认：

text
这是员工 10086

随后门禁系统检查他有没有进入办公区域的权限。

如果有权限：

text
身份确认成功
      ↓
允许通行
      ↓
闸机打开

与此同时，门禁系统还会产生一条类似这样的事件：

json
{
  "employeeId": "10086",
  "deviceId": "gate-001",
  "time": "08:38:12",
  "event": "face_pass",
  "result": "success"
}

这条数据对门禁系统来说是通行记录，但对考勤系统来说，它也可以被当成一次考勤事件。

于是考勤系统根据公司的规则判断：

text
08:38
↓
工作日
↓
属于上班时间
↓
员工进入办公区域
↓
生成上班打卡

最终钉钉显示：

text
08:38
上班
正常

所以这里最关键的一点是：

不是闸机操作了你的手机，而是门禁产生的数据被后台考勤系统利用了。

二、钉钉为什么不用打开，也能完成打卡？ ​

这是因为真正产生考勤记录的地方，通常不是手机 App，而是服务器端。

可以把它理解成：

text
                 刷脸
                   ↓
              人脸闸机
                   ↓
               门禁系统
                   ↓
             通行事件记录
                   ↓
              考勤系统
                   ↓
             钉钉后台服务
                   ↓
              钉钉 App

因此，即使你当时根本没有打开钉钉，后台也完全可以先生成考勤记录。

你打开钉钉以后看到的，只是服务器已经保存好的结果。

这和你打开银行 App 查看余额很类似：

余额并不是打开 App 后才产生的，而是银行服务器早就保存好了，App 只是把数据展示出来。

门禁考勤也是类似的逻辑。

三、那手机定位和“极速打卡”又是怎么回事？ ​

这里需要区分两种情况。

门禁刷脸打卡 ​

如果你发现：

text
刷脸 → 闸机打开 → 钉钉打卡

而且每次都和刷脸动作紧密对应，那么很可能是：

门禁系统与钉钉考勤系统进行了集成。

核心链路是：

text
人脸 → 门禁 → 考勤 → 钉钉

这种情况下，手机定位并不是核心。

钉钉自动/极速打卡 ​

另外一种情况是，你甚至不用刷脸，只要进入公司附近的考勤范围，钉钉就自动完成打卡。

这种情况下，可能涉及手机的：

text
GPS
Wi-Fi
蓝牙
网络状态

以及钉钉自身的考勤能力。

所以：

“刷脸后自动打卡”和“手机进入考勤范围自动打卡”是两种不同的实现方式。

如果你是刷脸之后才触发打卡，那么门禁与考勤联动的可能性更大。

四、从程序员角度看，这其实是一个“事件驱动系统” ​

这个案例非常适合用来理解后端系统中的事件驱动（Event Driven）。

刷脸成功以后，系统产生一个事件：

text
FacePassEvent

例如：

json
{
  "employeeId": "10086",
  "time": "08:38:12",
  "device": "1号楼东门",
  "result": "success"
}

不同的系统可以消费这个事件：

text
                    FacePassEvent
                         │
             ┌───────────┼───────────┐
             ↓           ↓           ↓
           门禁        考勤        日志
             ↓           ↓           ↓
           开门       生成打卡      保存记录

这就是现代企业系统中非常常见的一种设计：

一个事件产生，多套业务系统进行消费。

因此，看起来只是“刷了一下脸”，背后实际上可能涉及：

人脸识别 → 身份认证 → 权限控制 → 设备通信 → 事件处理 → API/SDK 数据同步 → 考勤规则 → 钉钉服务

五、门禁数据是怎么“同步”到考勤系统的？推送还是轮询？ ​

前面反复出现“同步”这个词，但具体怎么同步，其实有几种主流做法。

① 主动推送（Push / Webhook / 事件订阅） ​

门禁系统每产生一条通行事件，就立刻把数据 POST 给考勤系统的回调地址：

text
闸机刷脸成功
     ↓
门禁平台产生事件
     ↓
立即 HTTP POST 到考勤系统的回调地址
     ↓
考勤系统收到后写库 / 生成打卡

特点：

  • 延迟极低，通常毫秒到秒级
  • 需要在门禁平台侧配置回调地址
  • 一般会带签名验签 + 失败重试
  • 和你在钉钉里看到的“几乎同时”最吻合

门禁平台内部也常把事件丢进消息队列（Kafka / RocketMQ 等），由考勤服务订阅消费。这本质上也是推送，只是中间多了一跳。

② 定时轮询（Pull） ​

考勤系统按固定周期去“拉”门禁平台的通行记录接口：

text
每 1 分钟 / 5 分钟
       ↓
调用门禁平台接口：查询 lastSyncTime 之后的增量记录
       ↓
返回一批通行记录
       ↓
考勤系统逐条生成打卡
       ↓
更新游标 lastSyncTime

特点：

  • 实现简单，不需要对方开放公网回调地址
  • 一定有延迟，最短延迟就等于轮询间隔
  • 容易出现“有时立刻打卡、有时要等几十秒”的现象
  • 必须做增量游标和去重，否则会重复或漏数据

③ 中间库 / 共享表（最土但很常见） ​

门禁系统往一张数据库表里写通行记录，考勤系统直接读这张表（或者用数据库触发器、定时 Job）。

特点：

  • 开发最快，耦合最重
  • 一方改表结构，另一方就可能挂掉
  • 内网小系统、老项目里非常普遍

几种方式对比 ​

方式延迟实现成本耦合度可靠性
主动推送（Webhook）毫秒~秒级中低高（需验签 + 重试）
消息队列（MQ）毫秒~秒级中高低高（天然削峰）
定时轮询等于轮询间隔低中中（需游标 + 去重）
中间库 / 共享表取决于 Job 周期最低最高低

那到底怎么判断公司用的是哪种？ ​

看两件事就够了：

  1. 延迟特征：如果“刷脸和打卡几乎同时”，偏向推送；如果“差不多每次都要等一会儿，而且等待时间挺规律”，偏向轮询。
  2. 钉钉里的打卡明细：钉钉原生考勤会记录“打卡方式 / 打卡地点”。如果显示“考勤机打卡”“智能考勤机”，说明是考勤机接入钉钉考勤；如果打卡方式和地点都是空的，那可能只是公司自建系统发来的一条工作通知消息 —— 你看到的“打卡成功”是条通知，真正的考勤记录并不在钉钉里。

补充一句：钉钉开放平台提供了考勤类 OpenAPI 和事件订阅（回调）能力。第三方考勤机 / ISV 应用接入时，常见做法是“设备或厂商侧把打卡数据推给钉钉考勤服务”，而不是钉钉反过来去轮询设备。具体支持哪些接口和事件类型，以钉钉开放平台官方文档为准。

六、钉钉手机端为什么“立刻”就弹出提示？—— 另一段推送 ​

上面讲的是“门禁 → 考勤系统”这一段。还有另一段链路：考勤系统 → 你的手机。

如果靠 App 自己去问服务器（轮询），会是这样：

text
每 30 秒问一次服务器：有新打卡吗？

后果是耗电、耗流量，延迟还被拉长到几十秒 —— 显然不现实。

所以移动端普遍用的是长连接 + 服务端推送：

text
钉钉 App 启动
     ↓
与钉钉服务器建立长连接
     ↓
服务端产生新的打卡结果
     ↓
通过长连接主动下发
     ↓
App 立刻弹出提示

也就是说，你看到“叮”的一下弹出打卡成功，是因为服务器主动推给了手机，而不是手机一直在那儿问。

所以整条链路上其实有两段不同的数据流：

text
闸机 → 门禁平台 →（推送 / 轮询）→ 考勤系统 →（长连接推送）→ 钉钉 App

七、只有一条“通行记录”，系统怎么区分上班和下班？ ​

这是很多人容易忽略的地方：门禁记录里只有“有人通过了闸机”，它本身并不带“上班”或“下班”的标签。

常见的判定方式有三种。

① 靠闸机方向 ​

进出分离的通道（进门闸机 / 出门闸机，或带方向标识的双向闸机）：

text
从外往里刷 → 上班
从里往外刷 → 下班

这也是为什么双向闸机、进出分通道很重要 —— 方向本身就是业务信息。

② 靠时间段规则 ​

如果只有进门闸机，就只能靠规则硬判：

text
09:00 之前通过 → 算上班
09:00 之后通过 → 算下班

讲究一点的做法会按时间段分档（早班 / 午休 / 晚班），避免“中午出去吃饭”被算成下班。

③ 一天多次通行，取最早和最晚 ​

现实中你一天可能刷十几次脸。考勤系统通常不会每条都生成打卡，而是按规则聚合：

text
当天所有通行记录
     ↓
取最早一条 → 上班
取最晚一条 → 下班

所以你中午出去吃饭、下午下楼取快递，一般都不会影响打卡 —— 因为规则会把中间那些记录过滤掉。

八、工程落地时容易被忽略的几个坑 ​

1. 设备时钟必须同步（NTP）

闸机是独立设备，本地时间可能走偏。如果闸机比标准时间快 20 分钟，你 08:40 刷脸，系统里记录的却是 09:00，直接变成迟到。所以设备必须接入 NTP 校时，服务端也不要无条件信任设备上报的时间。

2. 断网要能离线放行 + 事后补传

办公网断了，闸机不能把人锁在门外。通常做法是：人脸模板和权限下发到设备本地，断网时本地比对、离线放行，记录缓存在设备里，联网后补传。补传记录的时间戳取自设备本地时钟 —— 这也是第 1 点更重要的原因。

3. 上报必须幂等去重

网络抖动、失败重试都可能让同一条通行记录被上报两次，不去重就会出现“同一次刷脸记了两条打卡”。一般用设备 ID + 记录序号（或事件 ID）作为唯一键。

4. 要处理乱序和延迟到达

补传的记录可能比实时上报的记录晚到。考勤系统不能简单按“到达顺序”处理，而应该按事件发生时间排序后再聚合上班 / 下班。

5. 人脸属于敏感个人信息

人脸是生物识别信息，属于《个人信息保护法》里的敏感个人信息，需要单独同意并说明必要性。相对合规且常见的做法是：人脸模板在闸机或边缘侧本地比对，不上传人脸原图到云端，云端只流转员工 ID。这一点必须在设计阶段就考虑，事后补救代价很大。

6. 日志要能一路追溯

员工申诉“我明明打卡了”时，要能顺着 通行记录 → 同步日志 → 考勤记录 一路查下去，否则运维和 HR 都会很痛苦。

九、总结 ​

所以，为什么你刷脸通过闸机后，钉钉自动完成上下班打卡？

答案其实很简单：

因为你们公司的门禁系统和考勤系统进行了数据联动。

一次刷脸首先完成了：

text
确认“你是谁”
      ↓
确认“你有没有权限进入”
      ↓
允许闸机开门
      ↓
记录“你什么时候进入了公司”
      ↓
把这个事件交给考勤系统
      ↓
考勤系统判断是否应该打卡
      ↓
同步到钉钉

所以真正有意思的地方并不是“闸机控制了钉钉”，而是：

现实世界中的一个物理事件——“刷脸进入公司”，被转换成了数字事件，然后被多个软件系统共同使用。

至于它是推送过来的还是轮询拉过来的，决定了你刷卡之后是“秒出结果”还是“要等一会儿”；而手机上的即时提示，则来自移动端的长连接推送。

这其实就是很多智能门禁、智能办公、IoT、SaaS 和企业数字化系统背后的基本技术思路。