7.1 KiB
title, description, date, draft, tags
| title | description | date | draft | tags | |||||
|---|---|---|---|---|---|---|---|---|---|
| 误判的一天：四个系统都在骗我 | 谁在线判断错、推送路由推错群、字段覆盖率 59% 没人发现、iOS 不认代理 IP——今天修复了四个系统的四种误判，共同点：都在用错的数据源做判断。 | 2026-08-07T17:50:00+08:00 | false |
|
背景
今天是个"误判日"——四个独立的系统，四个不同的误判，分布在四条完全不同的工作线上：
- 谁在线：定时任务被当成"真人活跃"
- 推送去哪：寄修单被推给固定供应商群
- 覆盖多少：最缺的字段 59% 覆盖率，半年没人发现
- 你在哪：iOS 系统判定，代理 IP 骗不过
它们的共同点惊人的一致：都在用错的数据源做判断。
一、谁在线：定时任务假装成真人
需求
团队要一个"谁在线"的工具——热线的伙伴们想一眼看到谁在干活。
实现
基于操作审计库（op_history.db）判断活跃度：每次建单/派单/关单都记录操作人和时间。这比"打开过页面"（凭证上报）准确得多——记录的是真实操作，不是停留在页面。
误判
下午巡检时发现：黄圆圆每天 10:15 / 10:21 准时"活跃"——但那是定时任务用她的凭证跑的（巡检批量建单），不是她本人在操作。系统把她标记成"在线"，误导了团队判断。
修复
把"审计操作人"和"凭证匹配人"分离：
create_wo --name 黄圆圆 --op-user "系统自动-黄圆圆"
# 审计记录：系统自动-黄圆圆（不干扰在线判断）
# 凭证使用：黄圆圆（正常调 API）
定时任务链路统一传 系统自动- 前缀，Dashboard / who_online 自动过滤。从此机器干的事和真人干的事分得清清楚楚。
教训：用操作记录判断"谁在线"，前提是先区分"谁操作"和"谁的系统在操作"。自动化系统的影子，会让判断失真。
二、推送去哪：寄修单进了供应商群
需求
4 个城市的工单要推送到各自的固定供应商群，让服务商第一时间看到单子。
误判
一个长沙客户的寄修单（寄回武汉总仓修，ownerGroupName=电脑工程师(寄修组)），推送时因为"客户在长沙"被判定为"长沙固定供应商单"，推错了群——寄修单不该进城市固定供应商群，该进寄修组群。
根因
推送代码在采集工单时丢弃了 ownerGroupName 字段——后续所有判断都基于"客户城市"，根本不看"这个单是寄修还是上门"。
修复
- 采集映射保留 ownerGroupName
- 寄修单 → 寄修组群（
_pick_repair_engineer），不再推城市群 - 顺带修了一个脆弱的"武汉判定"：只看地址含不含"武汉"两个字，城市=武汉但地址没写武汉就漏判——改为城市=武汉即算武汉
教训：路由判断要有完整的上下文。只按一个维度（城市）做决定，就会漏掉另一个维度（寄修/上门）的业务含义。
三、覆盖多少：最低的字段，半年没人发现
需求
三方平台同步（神州邦邦/修吧/大鱼 → WPS 主表）要检查字段覆盖率，确保数据完整。
误判
发现"更换备件"字段实际覆盖率只有 59%（133/224）——全场最低，却一直没人发现。
根因
覆盖率检查脚本的字段清单里漏了"更换备件"。清单没列它 → 从不检查它 → 它缺失到 59% 也没人知道。
检查范围本身就是数据源的一部分——清单漏字段 = 检查系统自身失明。
修复
- 补上字段清单，覆盖率 59% → 62%（子表能补的全补完）
- 剩余缺失逐条分类：已取消的 11 条（合理）、进行中 31 条（未到备件阶段）、已修复 31 + 待验收 12 条（三方平台本身没返回备件数据——是否漏提取，待深入）
教训："检查覆盖率的检查"也要被检查。没有元检查，最低的字段会永远沉默。
四、你在哪：iOS 不认代理 IP
需求
一张中国电信 CTExcel UK 的 eSIM，官方要求"在英国或欧盟当地激活"。人在国内，社区玩法：英国 IP + WiFi Calling + 拨 888 云激活。
实现
从零搭跨国链路：
手机 (Shadowrocket)
→ DE 法兰克福 (WS+TLS de.ippt.cc:443)
→ 英国机 (明文 VLESS :8443)
→ 英国 IP 出口 (伦敦)
踩了 Reality 在容器 NAT 机上不工作的坑（TLS 握手过、数据流不通，改明文 VLESS 才通），链路验证全通过：浏览器定位伦敦 ✅、DNS 出英国 ✅、UDP 通 ✅。
误判
WiFi Calling 拉不起来。抓了 Shadowrocket 的 PacketTunnel 日志（1938 行），一搜吓一跳：
| 检查项 | 结果 |
|---|---|
gs-loc-cn.apple.com（Apple 中国定位） |
52 次 🔴 |
epdg / ims / 3gppnetwork（WiFi Calling 隧道） |
0 次 |
| UDP 500/4500（IPsec） | 0 次 |
iOS 压根没发起 WiFi Calling。它在疯狂访问 Apple 定位服务——判断设备在哪国，用的是 Apple 定位 + eSIM 的 IMSI，不是你的代理 IP。
根因
浏览器看到的 IP ≠ iOS 认为你在哪。
iOS 判断国家靠三样：Apple 定位服务（gs-loc/wloc）、eSIM 的 IMSI（MCC/MNC）、能否连上运营商 EPDG 网关。代理只能改 IP，改不了这三样。日志证明 iOS 判定我在中国区，认为在"家"就不需要 WiFi Calling，EPDG 隧道一次都没发起。
社区能"云激活"成功的人，用的是专门的 IPsec 隧道方案，不是常规 SS/VLESS 代理——iOS 的 com.apple.epdg 系统扩展默认不走你的 TUN。
教训：系统级判定（运营商/OS 的国家识别）用网络层伪装不了。技术有边界，日志会告诉你边界在哪——10 秒止损，比硬闯一整天更专业。
五、方法论沉淀：判断的四个数据源原则
| # | 原则 | 今天的事例 |
|---|---|---|
| 1 | 区分"谁操作"和"谁的系统在操作" | 定时任务冒充真人活跃 |
| 2 | 路由判断要有完整上下文 | 只按城市判，漏掉寄修/上门维度 |
| 3 | 检查清单本身要被检查 | 字段漏检，59% 半年无人知 |
| 4 | 系统级判定，网络层伪装不了 | iOS 不认代理 IP |
四个误判的共性：都输在"用什么数据做判断"上。
- 判断在线 → 要用"真人操作"数据，排除"系统操作"影子
- 判断推送路由 → 要用"城市+寄修状态"全量数据，不能只看城市
- 判断覆盖率 → 检查清单要完整，缺失字段本身就是盲区
- 判断位置 → 要用系统认可的数据（IMSI/EPDG），IP 代理是无效信号
总结
判断的准确性 = 选对数据源 + 完整上下文 + 检查元层 + 尊重系统边界。
今天四个误判，没有一个是"代码写错"，全是**"判断依据选错"**。这也提醒我：排障时先问"这个判断依赖什么数据、数据对吗"，往往比盯着代码更快找到真相。
本文已脱敏，不含真实域名、IP、UUID 或凭证。