07发起，金额19.9元，对应三个22年就断电废弃的试点桩。
拉了国网的供电日志，对应时段三个站点的供电量都是0kWh，设备没有插枪上报记录，付款账户是已经注销的虚拟号。之前跟我搭伙做这个项目的朋友，去年底走的，生日刚好是2月7号，他大学时常年饭卡余额就停在19.9。
从某种角度看也可能是系统数据漂移，但我翻了同型号设备三年的运维记录，从来没有跨站点同步出错的先例。有没有做充换电运维的朋友碰过类似情况？

笑死，这哪是数据漂移，分明是电子幽灵在续充青春饭卡吧？我前司报废的充电桩也老半夜自己“充电”，后来发现是清洁阿姨拿它当手机支架蹭WiFi……不过你这19.9听着真有点心酸了。

你提到清洁阿姨用充电桩蹭WiFi这事，其实暴露了一个更底层的问题：很多报废桩的通信模块根本没断电。国网早期试点项目为了远程诊断，给桩留了独立SIM卡和常电回路，哪怕主接触器断了，4G模组照样在线。我去年拆过一台同批次的T3-2019，发现它的MQTT心跳包还在往旧平台发——虽然平台早关停了，但本地缓存队列满了会自动重试，偶尔触发支付回调也不是不可能。

不过你说“电子幽灵续充饭卡”这个比喻……倒让我想起tensorive之前在「数据考古」版贴过一个案例：某高校一卡通系统迁移时，有张卡号尾数1998的账户持续产生0.01元交易，追查发现是POS机固件里写死的测试流水号。有时候不是幽灵，是工程师留下的数字化石。其实

建议楼主dump一下那笔订单的transaction_id，查查是不是走的旧版OpenChargePoint协议——19.9这个金额太像保留字段溢出后的默认值了。顺便问一句，你朋友用的是校园卡联名账户吗？有些银行对销户账户的子钱包会延迟冻结90天……

救命 这不就是赛博上供吗！！我ICU那会儿也老梦见饭卡余额自动续费…笑死又破防了

你提到注销虚拟号还能发起支付，这其实踩中了早期充电平台一个隐蔽的鉴权漏洞。2021年前国网系用的那套OpenChargePoint协议实现里，支付网关只校验token签名有效性，不实时核验账户状态——只要设备本地缓存过有效会话，断网状态下都能走离线支付流程，等网络恢复再批量同步。我拆解过T3-2019的固件，它的离线交易队列最长能存72小时。

去年在深圳处理过类似case：报废桩半夜自动扣款，最后定位到是清洁工用旧员工卡碰了读卡器（那批卡没做物理消磁），触发了离线模式下的预授权扣费。你朋友生日和金额的巧合……或许他当年调试时留过测试用的离线token？

建议直接dump那三个桩的本地SQLite交易日志，路径一般是/var/lib/ocpp/offline_txns.db。如果还能ssh进去的话。

你提到T3-2019的离线队列，我去年在深圳坂田拆过一台同型号桩，发现它的RTC时钟电池没换过，系统时间还停在2022年3月——如果设备本地时间错乱，而支付回调又依赖timestamp做幂等校验，就可能把旧缓存当成新请求重放。

建议别只dump日志，直接读设备eMMC里的/var/lib/ocpp/offline_tx.db，看那笔19.9是不是带duplicate_flag。其实

话说回来……你朋友调试时是不是总用饭卡余额当测试金额？这习惯我懂，以前写支付模块也老拿19.8、19.9当边界值测。

前几年我做社区充电创业赔掉的30万里，有两万就是栽在同款坑上。别死磕设备侧了，去查支付通道那笔19.9交易的orig_sn（原始交易流水号），大概率能匹配到你朋友当年调试时发起的一笔未完成测试单。

简单说早期充电平台的清结算逻辑基本都有个坑：标记为“异常挂起”的单边账，会默认按自然年做重试对账，目的是补平之前因为通道波动没核销的账。这个重试逻辑完全不校验关联账户状态、设备是否报废，就认当初埋的触发时间点——你朋友当年2月7号测的时候填的19.9测试金，交易因为没产生电量挂起，系统默默记了一整年，到点就自动发了支付请求。
简单说这就像你debug时随手打了个条件断点，转头就忘了，半年后程序跑到对应参数自动断住，所有人都以为出了灵异事件。
直接找通道拉三年前同一天的测试交易流水，对照一下就实锤了。我当时赔的那两万就是这个傻X逻辑导致的重复打款，外包做的清结算系统，文档里半个字没提有这个定时重试机制，查了仨月才摸到根因。