设备巡检系统开发实战：扫码打卡、离线缓存与防作弊的完整方案

引言：先承认一个事实——巡检数据大多是"编"的

做设备巡检系统之前，我们在客户现场蹲过三天点，看了保安和设备员怎么"巡检"：拿着一沓纸质的巡检表，在办公室里花十分钟把一整天的勾全部打完，字迹工整，地点全对——因为表是提前印好的。

这就是巡检数字化的真正起点：系统要解决的不是"记录巡检"，而是"让巡检真实发生"。防不住造假，后面所有基于巡检数据的统计、考核、健康分析都是垃圾进垃圾出。本文把这个模块从作弊分析到落地实现完整讲一遍。

一、作弊手法盘点：知道对手是谁，才知道防线怎么设

三轮现场调研 + 上线后的数据审计，我们归纳出五类典型作弊手法：

手法	描述	对应防线
代打卡	同事顺路帮忙扫	二维码 + 定位双重绑定
集中补扫	月底一次把 30 天的全扫了	时间窗校验（错过即逾期）
复制二维码	拍张照片发群里，各自在家扫	动态码 / NFC 硬件标签
位置伪造	用虚拟定位 APP 改 GPS	多源定位交叉 + 异常检测
补录数据	事后在系统里手工填记录	补录需审批且显著标记

设计原则只有一条：让真实巡检的成本远低于作弊的成本。防线做到"作弊比干活麻烦"就够了，不必追求军事级防伪——那会把正常巡检也变得难以忍受。

二、三重校验设计：码、位置、时间

2.1 二维码方案与动态码升级

设备二维码包含设备唯一 ID，扫码即定位到巡检任务。但静态二维码有"拍照复制"漏洞，我们做了两级方案：

• 普通点位：静态二维码 + 定位校验兜底（大多数场景够用，成本低）；
• 关键点位：NFC 抗金属标签——手机碰一碰读取芯片唯一序列号，芯片无法被拍照复制，且油污车间里 NFC 标签比二维码耐脏得多（二维码贴纸在机床上三个月就模糊了）。

预算敏感的客户全部用静态码 + 定位，高价值设备点位用 NFC，按点位重要性分级投放，整套标识方案的成本账在客户那里非常好算。

2.2 定位校验：Haversine + 精度过滤

扫码成功后，APP 同时上报 GPS 坐标，服务端计算与设备台账登记坐标的距离：

private static final double EARTH_R = 6371000; // 米

public double distanceMeters(double lat1, double lon1, double lat2, double lon2) {
    double dLat = Math.toRadians(lat2 - lat1);
    double dLon = Math.toRadians(lon2 - lon1);
    double a = Math.sin(dLat / 2) * Math.sin(dLat / 2)
             + Math.cos(Math.toRadians(lat1)) * Math.cos(Math.toRadians(lat2))
             * Math.sin(dLon / 2) * Math.sin(dLon / 2);
    return 2 * EARTH_R * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a));
}

public CheckResult verify(Device device, Location report) {
    if (report.getAccuracy() > 100) {
        return CheckResult.weakSignal();   // 定位精度差于100米，降级处理而非直接拒绝
    }
    double dist = distanceMeters(device.getLat(), device.getLng(),
                                 report.getLat(), report.getLng());
    return dist <= device.getAllowedRadius()   // 默认50米，可按点位配置
        ? CheckResult.pass()
        : CheckResult.tooFar(dist);
}

三个现场经验：

1. 精度过滤必须做在距离判断之前。车间钢结构屋顶下 GPS 精度经常到 200 米开外，不做过滤会大量误杀真实巡检。
2. 误杀降级而不是拒绝。定位不佳时允许"拍照留证 + 事后确认"通道，把判定交给人工，而不是让巡检员在设备旁边反复刷新 GPS。
3. 虚拟定位检测用交叉信号。GPS 能伪造，但 Wi-Fi BSSID、基站信息、气压计难以全套伪造。我们用"GPS 与 Wi-Fi 指纹不一致次数"作为风险分，风险高的记录转人工审计，而不是直接判作弊——误判一个诚实的巡检员，比放过十个作弊的伤害大。

2.3 时间窗：逾期就是逾期，没有"补勾"

巡检计划定义了时间窗（如每班次 8:00–12:00），窗口内扫码才有效。窗外的记录分两种：逾期（照实记录，影响达成率）和补录（需班组长审批，带"补录"标记且不参与达成率统计）。

上线时客户最抗拒的就是"不能补"："设备员有时候就是忙忘了，你就让人家补一下嘛。"我们最终坚持的折中是：补录可以，但补录永远可见、永远不计入考核数据。一个月后客户主动把补录审批权限收紧了——因为补录多的班组在别的数据上确实更差，管理价值自己浮现了。

三、离线缓存：车间里没有"良好的网络环境"

地下管网、电梯井、冷库、钢结构厂房深处——巡检路径上一半的点位信号是漂的。离线优先（Offline-first）不是锦上添花，是及格线。

3.1 APP 侧结构

操作层：扫码 → 打卡 → 填写检查项 → 拍照
   ↓ 全部写入
本地库：outbox 待同步队列（记录 + 图片引用，带 seq 自增号）
   ↓ 网络可用时
同步器：按 seq 顺序批量上传 → 服务端确认 → 标记已同步 → 清理

本地用 SQLite 的 outbox 表做待同步队列，每条记录带自增 seq，同步器批量推送：

async function sync() {
  if (!(await navigator.onLine)) return;
  const batch = await db.outbox.orderBy('seq').limit(20).toArray();
  if (batch.length === 0) return;
  const res = await api.post('/inspection/sync', {
    deviceId: deviceUuid,
    lastAckedSeq: local.lastAckedSeq,
    records: batch,
  });
  // 服务端按 seq 幂等：重复推送返回已处理结果，不产生重复记录
  await db.outbox.bulkDelete(res.ackedSeqs);
  local.lastAckedSeq = Math.max(...res.ackedSeqs);
}

3.2 服务端幂等与冲突处理

同步协议的核心约定：

1. 服务端以 terminalId + seq 为幂等键，重复推送直接返回首次处理结果，不产生重复数据。
2. 基础数据（巡检项定义、设备信息）走版本号拉取：APP 每次联网先问"配置版本号是多少"，变了才全量拉，省流量也避免半新半旧的配置。
3. 冲突极少发生但必须有策略：同一巡检任务被两台终端打卡（比如换班），以服务端先到达者为准，后到的返回冲突提示；无法自动判断的（如检查项填写不一致）标记待人工合并。

实测数据：某冷链仓库客户巡检点位 80% 处于弱网区，离线方案上线后，巡检记录的"当日闭环率"从 54% 提升到 96%——提升全部来自"以前因为没信号干脆不记录"的部分。

四、拍照水印：让照片会"自证"

检查项要求拍照时，APP 端在照片上实时叠加水印：时间、坐标、设备编号、人员姓名，同时读取 EXIF 原始拍摄时间。服务端校验两条：水印时间与 EXIF 时间偏差超过 5 分钟标记异常（防用旧照片）；EXIF 的 GPS 与上报坐标偏差过大标记异常（防拿别处照片冒充）。

不要试图做"AI 判断照片是不是现场拍的"——成本高、误判多。水印 + EXIF 交叉验证这个朴素方案，覆盖了 95% 的照片造假场景，剩下 5% 交给人工审计抽检就够了。

五、踩坑记录

坑一：Android 定位权限的"仅使用期间"。很多巡检员把权限设成"仅使用时允许"，APP 切后台再回来定位就失败。方案：打卡流程强制在 App 前台完成（这就是巡检场景的天然形态），并在权限检测失败时用图文引导开启，而不是默默拿不到坐标。

坑二：NFC 标签被手机壳屏蔽。客户用了带金属背板的手机壳，NFC 感应失败率 30%。采购标签时选抗金属 + 大感应距离型号，现场实测再批量铺。

坑三：时间同步。离线终端的系统时间不准，补传上来的打卡时间早于真实时间 2 小时，统计口径全乱。方案：APP 每次联网与服务端做时间对齐，本地记录同时存"设备时间"与"服务端校正时间"两个字段，统计一律用后者。

写在最后

巡检模块是整个运维系统的"数据入口"，它做不实，后面的保养分析、健康评分全是空中楼阁。回过头看，这个模块的设计哲学可以浓缩成一句话：用工程手段降低真实记录的成本，用管理规则提高造假的成本，中间给人工审计留一道安全的缓冲带。