更新日志

• v0.4.24

  手机脚本 v2.2：通知使用权自检 + 通知捕获统计

  随交付包发布

  场景：用户实收 10 元，但站点没有回执。

  查看完整变更

  场景：用户实收 10 元，但站点没有回执。 排查结论：手机脚本完全没有上报"回执"（排障日志里只有心跳，没有一条 receipt）； 且手机心跳自 02:37:22 后中断 → 脚本未在运行 / 未捕获到收款通知。 本版给手机脚本加上"通知侧"的自检与统计，让这类问题一眼可判。

  一、本次排查证据

  检查	结果
  回执表 wxpay_receipts	0 条
  上报尝试日志	最后一条是 02:37:22 心跳（V2232A 200）；没有任何 receipt 类型请求
  待审核订单	存在 10.00 元订单（#7，用户 3，1000 TKN）→ 回执到达即会唯一匹配并自动入账
  自动入账开关	已开启（上限 1000 元）
  设备在线	最后一次心跳 02:37:22，距排查时（02:46）已 9 分钟 → 脚本大概率已停止

  → 结论：服务端没问题，卡在"手机没把这条收款通知报上来"。

  二、手机脚本 v2.2 的加固

  #	改动	作用
  1	启动自检通知使用权	events.observeNotification() 失败时，日志明确提示"请到 设置 → 应用 → 特殊权限 → 通知使用权 允许 AutoX.js"（否则脚本看似在跑却永远收不到通知）
  2	通知捕获统计	每 30 分钟记录一次「本次运行已捕获微信通知 N 条」；收款后仍为 0 就说明通知根本没到脚本（权限/微信通知被关）
  3	未识别提示	非收款通知打印"如这其实是收款通知，请把本行原文发给开发者校准关键词"
  4	通知编号	日志改为 [微信通知 #N] 原文，便于对照计数

  三、需要用户配合的动作

  1. 用 v2.2 脚本覆盖手机上现有脚本，重新运行；
  2. 日志必须出现 已开启微信通知监听 —— 若出现 无法开启通知监听，先授予通知使用权；
  3. 保持脚本运行（AutoX.js 开前台服务、系统关闭电池优化、锁定后台任务）；
  4. 再收一笔款 → 刷新自检页看「最近上报尝试」是否出现 receipt 记录；
  5. 若日志里出现 [微信通知 #N] ... 但脚本判定为"非收款通知"，把该行原文发来即可校准关键词。
• v0.4.23

  修复动态码页轮询：刷新可见 + 修掉 2 个 JS 缺陷

  随交付包发布

  现象：动态码页写着"页面每 5 秒自动刷新"，但看起来并没有刷新。

  查看完整变更

  现象：动态码页写着"页面每 5 秒自动刷新"，但看起来并没有刷新。 结论：轮询一直在正常请求（nginx 日志每 5 秒一条 GET /payment-receipt.php?order_id=N 200）， 问题出在前端脚本——数据没变化时画面文字也不变，而且脚本里有两处缺陷。

  一、实测（先确认"到底有没有刷新"）

  02:37:46 / 02:37:51 / 02:37:56 / 02:38:01 …  每 5 秒一条
  127.0.0.1 GET /payment-receipt.php?order_id=7 → 200

  响应体（gzip 后 228 字节，解压后 355 字节）：

  {"ok":true,"enabled":true,"order_id":7,"receipt":null,"device_online":true,
   "device_last_seen":"2026-10-03 02:37:22","device_name":"V2232A","server_time":"…"}

  → 接口正常、轮询正常；但页面没有任何"刷新过"的视觉反馈，数据不变时看起来就像卡住了。

  二、修复的三件事

  #	缺陷	影响	修复
  1	刷新不可见	数据没变化时页面文字不变，用户以为没刷新	新增独立提示条（每 1 秒更新）：「最后更新：X 秒前（每 5 秒自动刷新）｜服务器时间 …」
  2	clearInterval(pollTimer) 变量名不存在（该作用域里是 timer）	走到"已自动入账"分支时抛 ReferenceError，状态不更新	改用 stop()（正确停表）
  3	替换 catch 时漏掉收尾 });	整段轮询脚本语法错误 → 完全不执行	已补回；并用 node --check 校验内联脚本语法

  另外：刷新失败不再静默吞掉 —— 连续 3 个周期（15 秒）没成功刷新时，提示条会变红显示"…——刷新异常，正在重试…"； 控制台也会打印 [wxReceipt] 刷新失败：…，便于排查登录过期 / 网络问题。

  三、验证

  内联 JS 语法：node --check → 全部通过 ✓（修复前报 missing ) after argument list）

  轮询行为（Node + DOM 桩，qdcms-release/test-polling.js）→ 9 / 9 通过：

  [PASS] 轮询脚本加载无异常（无 pollTimer 之类的 ReferenceError）
  [PASS] 状态文字显示"尚未收到回执"
  [PASS] 状态文字显示真机在线与设备名（监听设备在线（V2232A…））
  [PASS] 已插入"最后更新"提示条元素
  [PASS] 存在 1 秒刷新提示定时器
  [PASS] 提示条显示"最后更新：2 秒前（每 5 秒自动刷新）｜服务器时间 …"
  [PASS] 刷新失败时提示条可见（刷新异常，正在重试）
  [PASS] 收到已入账回执时显示"已自动入账"
  [PASS] 已到账后停止轮询（clearInterval 被调用）

  线上页面：HTTP 200，页面已含 wxReceiptTick / 「最后更新」提示条 ✓

  四、请做一次强制刷新

  浏览器可能缓存了旧页面脚本，请按 Ctrl + F5（手机：下拉刷新/清缓存）后再看动态码页 —— 页面底部会出现 "最后更新：X 秒前（每 5 秒自动刷新）"，数字每秒跳动，即代表实时刷新正常。

• v0.4.22

  修复：动态码页"监听设备"显示成测试名

  随交付包发布

  现象：个人支付动态码页刷新后，"监听设备"一直显示 模拟真机心跳（而不是手机真机）。

  查看完整变更

  现象：个人支付动态码页刷新后，"监听设备"一直显示 模拟真机心跳（而不是手机真机）。 性质：显示逻辑缺陷 + 开发排障数据污染，已修正并清理。

  一、原因

  动态码页轮询 payment-receipt.php?order_id=N，其中 device_name/device_last_seen/device_online 直接取 settings.wxpay_receipt_last_device / last_seen —— 而这两个 key 是可变的： 任何一次心跳都会覆盖它，包括开发者排障时发的测试心跳（本例就是 模拟真机心跳） 和自检页的"一键模拟上报"。

  二、修复

  #	改动	说明
  1	新增 wxreceipt_current_device()	在线状态改为取上报尝试日志里最近一条"来自非回环地址"的记录（即真实设备）；只有在查不到时才回退 settings
  2	payment-receipt.php GET 应答改用该函数	动态码页显示的设备名/时间/在线判定从此只反映真机，自检与测试再也污染不了
  3	清理历史污染	删除开发排障期间产生的本机测试尝试记录；last_device/last_seen 回填为手机真机最近一次心跳

  三、验证（线上实测）

  修复前：动态码页显示 模拟真机心跳（开发者测试名），last_seen=02:31:33

  修复后（payment-receipt.php?order_id=7 实际应答）：

  {"ok":true,"enabled":true,"order_id":7,"order_status":0,"amount":"10.00",
   "device_online":true,"device_last_seen":"2026-10-03 02:28:03","device_name":"V2232A", ...}

  检查	结果
  动态码页数据源 device_name	V2232A（手机真机名）✓
  device_online	true ✓
  自检页「监听设备（真机）」	在线 · V2232A ✓
  排障日志残留	仅保留手机真机 3 条；本机测试记录已清理 ✓

  说明：设备"在线"窗口为 10 分钟。手机脚本每 3 分钟发一次心跳； 若超过 10 分钟没有新心跳，页面会（正确地）显示"离线"——这可以帮助判断脚本是否还在运行。

• v0.4.21

  手机上报已打通；修正"服务器自检"覆盖真机在线状态的问题

  随交付包发布

  性质：修复 + 排障收尾。需求："是否收到回执"。

  查看完整变更

  性质：修复 + 排障收尾。需求："是否收到回执"。 结论：手机上报通道已完全打通（手机心跳三次全部 HTTP 200）；尚未收到"回执" —— 回执需要真实微信收款到账通知被手机捕获。

  一、本次证据（手机已成功上报）

  192.168.0.104 POST /payment-receipt.php 200  02:27:16   ← 手机（okhttp/4.10.0）心跳成功
  192.168.0.104 POST /payment-receipt.php 200  02:27:50
  192.168.0.104 POST /payment-receipt.php 200  02:28:03

  排障日志同步记录（wxpay_receipt_attempts）：

  id	来源	结果	原因	Content-Type	请求体
  23–25	192.168.0.104	200	心跳（设备在线标记已刷新）	application/json; charset=utf-8	{"type":"heartbeat","device":"V2232A"}

  → v2.1 脚本的"显式 JSON body"生效，400 已消失、鉴权通过 ✓ → 回执（receipt）条数为 0：说明还没有微信收款通知被手机捕获（不是通道问题）

  二、本次修复：服务器自检不再抢占"监听设备"

  自检页「一键模拟上报」是服务器自己发的，但它也刷新了"监听设备/最后心跳"， 于是页面显示成"服务器自检"，把真机是否在线盖掉了。

  改动	说明
  回执端点识别 selftest 标记	请求体带 selftest: true 时不刷新 last_seen/last_device
  自检页模拟上报带 selftest: true	自检只验证链路，不再影响设备在线状态
  自检页文案	「监听设备」→「监听设备（真机）」，避免歧义

  三、验证

  用例	结果
  触发一次自检（ping）	last_device 保持不变 ✓（不再被覆盖）
  模拟一次真机心跳	last_device 正常更新为设备名、last_seen 刷新 ✓
  自检页	HTTP 200 ✓

  四、要"收到回执"需要做什么

  需要有真实的微信收款到账通知：

  1. 保持手机脚本运行（现在心跳正常，说明在跑）；
  2. 用另一个微信扫你的收款码付一笔（建议 0.01 元，或与某笔待审核订单金额完全相同的数额）；
  3. 刷新自检页 → 「近 24 小时回执」应变为 1，且「最近上报尝试」会出现一条回执记录；
  4. 金额与某笔待审订单唯一匹配时，自动入账会立即生效（后台「收款码解析」可看到记录）。

  若付了款仍无回执：把手机 DEBUG: true 日志里的 [微信通知] ... 几行发来，据此校准 INCLUDE / ANCHOR 关键词（微信"收款到账"通知的实际文案各地略有差异）。

• v0.4.20

  排障补全：记录 Content-Type + 请求体密钥脱敏 + 手机脚本 v2.1

  随交付包发布

  性质：排障能力补全 + 手机脚本加固。场景：手机上报已从 401（鉴权）前进到 400（请求体），

  查看完整变更

  性质：排障能力补全 + 手机脚本加固。场景：手机上报已从 401（鉴权）前进到 400（请求体）， 需要看清"手机到底发了什么"。

  一、本次「再次检测」结论

  检查	结果
  自检页「模拟上报」	02:08:27、02:09:05 两次点击 → HTTP 200 ✓（last_seen 随之刷新，监听状态=在线）
  手机脚本上报	自 02:04:06 之后没有任何请求（这期间只有服务器自测与模拟上报）
  回执	0 条

  → 服务端一切正常；需要手机脚本再运行一次才能拿到新的排障数据。

  二、改动

  #	改动	说明
  1	尝试日志新增 content_type 列	记录设备请求的 Content-Type。若显示 application/x-www-form-urlencoded，即可确认手机把 JSON 当表单发送了（服务端 json_decode 失败 → 400）
  2	请求体日志密钥脱敏	body_head 写入前把站点密钥替换为 ***，避免密钥落进退障日志
  3	手机脚本 v2.1	改用 http.request(... {method:'POST', contentType:'application/json; charset=utf-8', body: ...}) 显式声明 JSON body；http.request 不可用时自动回退 http.post；仍保持"签名头 + 令牌头"双鉴权与 401 自动回退

  三、验证

  用例	结果
  JSON + 正确签名	HTTP 200，日志 content_type=application/json ✓
  表单编码请求	HTTP 401（无鉴权头），日志记录 content_type 与 body_head ✓
  请求体里带密钥	日志存为 "token":"***" ✓（密钥不外泄）
  手机脚本 v2.1	node --check 通过 ✓

• v0.4.19

  排障增强：上报尝试日志覆盖全部分支，含请求体头部

  随交付包发布

  性质：排障能力补全。需求："检测模拟上报是否成功 / 依然没有回执"。

  查看完整变更

  性质：排障能力补全。需求："检测模拟上报是否成功 / 依然没有回执"。

  一、模拟上报结论：成功

  手机在 02:03:40、02:04:09、02:05:29 三次点击自检页「模拟一次上报」，全部返回 HTTP 200， 服务端 wxpay_receipt_last_seen 随之刷新、last_device = "服务器自检"。 → 服务端端点、密钥、路径、回退逻辑全部正常；问题只在手机脚本如何构造请求。

  二、新发现：手机上报从 401 变成 400（鉴权已通过）

  手机脚本在 02:04:05–02:04:06 的三次上报返回 HTTP 400（此前是 401）。 说明鉴权已通过（v2 脚本的令牌头生效），现在卡在请求体参数上。

  三、本次改动

  改动	说明
  尝试日志覆盖全部早退分支	心跳成功、JSON 非法、体积超限、type 非法、receipt_id 非法、amount 非法、限流、IP 白名单、未启用、鉴权失败——每一条都落库
  新增 body_head 列	记录请求体前 200 字符，直接看到手机实际发了什么（是空、被截断、还是字段名不对）
  老表自动升级	检测到 wxpay_receipt_attempts 缺列时自动 ALTER TABLE 补 body_head

  四、验证

  用例	结果
  心跳（正确签名）	HTTP 200，日志记 心跳（设备在线标记已刷新） ✓
  非 JSON 请求体	HTTP 400，日志记 请求体不是合法 JSON 对象 + body_head=not-json ✓
  type 非法	HTTP 400，日志记 type 非法：nope + body_head={"type":"nope"} ✓
  amount 非法	HTTP 400，日志记 amount 非法：abc ✓
  鉴权失败	HTTP 401，日志记原因 + has_sign/sign_len/has_token ✓

  下一步：手机脚本再运行一次，自检页「最近上报尝试」会直接显示 400 的具体原因与请求体开头， 据此一眼定位（空体 / 字段名不对 / 编码问题）。

• v0.4.18

  排障能力 + 手机上报鉴权兼容：定位到"手机 401 鉴权失败"

  随交付包发布

  性质：缺陷修复 + 排障增强。需求："依然没有回执 / 检测手机回执失败的原因"。

  查看完整变更

  性质：缺陷修复 + 排障增强。需求："依然没有回执 / 检测手机回执失败的原因"。 本次拿到决定性证据：手机已经在连服务器了（自检页 HTTP 200）， 上报请求也到达了端点，但被 401 鉴权拒绝——失败点从"网络"收敛到"鉴权"。

  一、关键证据（nginx 日志）

  192.168.0.104  GET  /receipt-check.php  200   ← 手机（Android 16 / Vivo 浏览器）能访问服务器
  192.168.0.104  POST /payment-receipt.php 401  ← 手机脚本（okhttp/4.10.0）上报被拒
  192.168.0.104  POST /payment-receipt.php 401
  192.168.0.104  POST /payment-receipt.php 401

  二、修复内容

  #	改动	说明
  1	回执端点支持"签名失败 → 明文令牌回退"	安卓运行环境（AutoX.js / okhttp）可能对请求体重编码，使设备端 HMAC 与服务端 hash_hmac 字节不一致；此时若同时带了 X-WXPay-Token 且正确，则按令牌模式放行。仍拒绝无密钥的伪造请求
  2	新增上报尝试日志表 wxpay_receipt_attempts	每次设备请求记录：IP、UA、结果码、原因、是否带签名头/签名长度/是否带令牌头/请求体长度、设备名；保留最近 300 条
  3	自检页新增三块	① 最近上报尝试（含"怎么读"对照：401+签名长度正常=密钥不一致；401+无签名头=脚本版本问题；403=IP 白名单；503=未启用）② 设备密钥对照（掩码）（与手机日志 dbb0****1b02 直接对比）③ 一键模拟上报按钮（服务器代发心跳，验证端点链路）
  4	新增手机脚本 v2：install/wxpay-receipt-listener.js	① 每次上报同时发送签名头与令牌头；② 收到 401 自动改用"仅令牌头"重试；③ 启动自检并把失败原因翻译成中文（401=密钥不符 / 503=未启用 / 连接失败=地址或网络）；④ SERVER/TOKEN 已预填

  三、验证

  用例	结果
  错误签名 + 正确令牌	HTTP 200 ✓（回退放行）
  无签名 + 正确令牌	HTTP 200 ✓
  错误签名 + 错误令牌	HTTP 401 ✓（仍然拒绝伪造）
  无签名 + 无令牌	HTTP 401 ✓
  尝试日志记录	已写入 结果/原因/签名长度/令牌头/请求体长度 ✓
  自检页	三块新内容齐全、0 告警、一键模拟上报返回 HTTP 200 ✓
  手机脚本 v2 语法	node --check 通过 ✓

  四、手机端需要做的（二选一）

  方案 A（推荐）：用包内 install/wxpay-receipt-listener.js（v2）替换手机上现有脚本 → 运行 → 日志出现 [自检] 心跳成功 即完成。

  方案 B（最小改动）：若想保留现有 v1 脚本，只加一行——在 httpPostOnce() 的 headers 里补：

  "X-WXPay-Token": CONFIG.TOKEN,

  （服务端已支持签名失败时按令牌放行。）

• v0.4.17

  修复：手机自检页重复定义 CMS_VERSION 告警

  随交付包发布

  性质：缺陷修复。现象：手机打开自检页时页面顶部打印

  查看完整变更

  性质：缺陷修复。现象：手机打开自检页时页面顶部打印 Warning: Constant CMS_VERSION already defined in .../config/config.php on line 27。

  根因

  receipt-check.php（v0.4.16 新增）自己写了一句 define('CMS_VERSION', 'receipt-check')， 随后 require includes/functions.php 又会经 config/config.php 再定义一次 → PHP 报 「Constant already defined」。线上 php.ini 是 display_errors = On，因此告警直接显示在页面上。

  修复

  改用站点标准引导链（与 payment-code.php / payment-receipt.php 一致）：

  // 修复前
  define('CMS_VERSION', 'receipt-check');
  require_once __DIR__ . '/includes/functions.php';
  
  // 修复后
  require_once __DIR__ . '/includes/auth.php';   // auth.php → functions.php → config/config.php（此处定义 CMS_VERSION）

  验证（修复前 → 修复后）

  入口	修复前	修复后
  Host: 192.168.0.100	HTTP 200，页面含 Warning: Constant CMS_VERSION already defined	HTTP 200，告警命中 0 ✓
  Host: 10123.xn--fiqs8s	同上	HTTP 200，告警命中 0 ✓
  Host: 127.0.0.1	同上	HTTP 200，告警命中 0 ✓

  页面内容全部保留（自检结论、监听开关/密钥/自动入账状态、监听设备在线状态、回执计数、IP 白名单、 脚本应填的 SERVER、页内二维码），且不输出设备密钥 ✓。

• v0.4.16

  新增：手机回执上报「连通性自检页」

  随交付包发布

  性质：排障工具。需求："检测手机回执失败的原因"。

  查看完整变更

  性质：排障工具。需求："检测手机回执失败的原因"。 结论：服务端一切正常，手机从未成功上报过（详见升级说明与交付报告）；本版提供一个手机可直接打开的自检页， 让"手机→服务器"的连通性与监听状态变成一眼可见。

  一、新增 receipt-check.php（只读自检页）

  手机浏览器打开 http://<服务器局域网IP>/receipt-check.php（页面自带二维码，手机扫码即可打开），即可看到：

  展示项	用途
  顶部结论「手机与服务器连通 ✓」	能打开本页 = 手机到服务器的网络通
  回执监听开关 / 设备密钥 / 自动入账	服务端是否就绪
  监听设备 在线/离线（含设备名与最后心跳时间）	脚本是否真的连上了（在线窗口 10 分钟）
  近 24 小时回执条数 / 累计条数	有没有回执进来
  IP 白名单 + 本机看到的你的 IP	需要白名单时可照抄该 IP
  手机脚本应填的 SERVER 地址	免手工拼地址
  手机端 6 步排查清单	401=密钥、连接失败=网络等对照

  安全：只输出状态与计数；不输出设备密钥、不输出金额与用户名、不写任何数据。

  实测：

  • 三种入口（Host: 10123.xn--fiqs8s / 192.168.0.100 / 127.0.0.1）均 HTTP 200 ✓
  • 页面 10 项内容齐全、未泄露密钥 ✓
  • 页内二维码用内置解码器回解为 http://192.168.0.100/receipt-check.php ✓（与 v0.4.13 二维码模块联动）

  二、本次排查结论（证据）

  检查	结果
  nginx 日志中外网来源请求	0 条
  POST /payment-receipt.php 来源统计	127.0.0.1（42 次）、192.168.0.100（4 次）——全部是服务端自测
  settings.wxpay_receipt_last_seen / last_device	仅记录到自测设备（说明手机从未发送过心跳）
  服务端端点自测（局域网 IP + 正确签名）	HTTP 200 ✓
  Windows 防火墙 + 网络类别	规则已启用；无线网络已是专用(Private) → 规则生效 ✓
  局域网其它设备（192.168.0.109）曾成功访问	有记录（能连到本服务器）✓
  本机公网 IP:80 可达性	不可达（家宽未做端口映射）→ 手机必须与服务器同一 WiFi

  手机端可能原因（按可能性排序）：

  1. 脚本 CONFIG.SERVER 仍是默认的 http://39.96.90.85/payment-receipt.php（另一台服务器）→ 上报发到别处，本机自然什么都收不到；
  2. 脚本 CONFIG.TOKEN 未填或与站点密钥不一致 → 手机日志会出现 HTTP 401 签名校验失败；
  3. AutoX.js 未授予「通知使用权」/ 被系统杀后台 / 脚本未运行；
  4. 手机用的是 4G/5G（与服务器不同网）→ 家宽无公网映射，连不上；
  5. 微信通知被关闭或关键词不匹配（此时有心跳但没有回执，自检页可区分）。
• v0.4.15

  新功能：微信收款回执「自动入账」

  随交付包发布

  性质：新功能（可选，默认关闭）。需求："将动态码页面的监听脚本收到回执后自动入账"。

  查看完整变更

  性质：新功能（可选，默认关闭）。需求："将动态码页面的监听脚本收到回执后自动入账"。 说明：此前回执只记录、由管理员人工审核入账；现在可开启回执即自动入账，并带 8 道安全闸门。

  一、新增文件与改动

  文件	说明
  includes/ReceiptCredit.php（新增）	自动入账引擎：闸门判定 + 事务 + 行锁 + 幂等 + 审计
  payment-receipt.php	回执入库后调用引擎；应答中返回 credited 与 auto_credit 结果；重复上报如实告知是否已入账；建表语句补 4 列
  payment-code.php	动态码页展示「已自动入账」（金额/设备时间/入账时间），并说明自动入账取决于后台开关
  admin/pay-qr.php	新增「微信回执自动入账」设置卡：开关、单笔上限、订单时间窗口、每小时上限；最近自动入账与未自动入账（含原因）两个列表
  wxpay_receipts 表	新增 credited_at / token_order_id / credit_note / credit_error（首次调用自动 ALTER TABLE，新装环境建表即含）
  database.sql	同步 4 列，全新安装无需手工执行

  二、8 道安全闸门（全部通过才入账，否则退回人工）

  #	闸门	默认值
  1	总开关 settings.wxpay_receipt_auto_credit	默认关闭（需显式开启）
  2	回执必须唯一匹配一笔待审核订单（match_state=matched，同额多单判 ambiguous 不入账）	—
  3	回执金额与订单金额分单位完全相等	—
  4	单笔上限 wxpay_receipt_auto_max_fen	100000 分（1000 元）
  5	订单创建时间窗口 wxpay_receipt_auto_window_min	1440 分钟（24 小时）
  6	每小时自动入账笔数上限 wxpay_receipt_auto_per_hour	60 笔
  7	事务 + SELECT … FOR UPDATE 行锁 + 订单状态二次校验（并发/重复上报不会重复加钱）	—
  8	回执幂等：credited_at 非空即视为已入账	—

  入账口径与「后台人工审核通过」完全一致（同一事务内完成）： 写一条 status=1 的 token_orders 流水 → addTokens() → returnExpiredTokens() → 订单置 1； 任何一步失败整体回滚并记录 credit_error，订单保持待审核状态，交由人工处理。

  三、实测（线上，11/11 通过，受控数据测后全部还原）

  [PASS] 开关关闭 → 不入账（code=DISABLED，订单保持 status=0）
  [PASS] 唯一匹配 + 金额相等 → 自动入账（code=CREDITED，status=1，余额 +7）
  [PASS] 应答告知已入账（credited=true）
  [PASS] 回执写入入账时间与充值流水号
  [PASS] 充值流水为已通过且注明「微信回执自动入账（设备 X｜回执 #N｜￥0.07）」
  [PASS] 重复回执不重复入账（duplicate=true，余额不变）
  [PASS] 金额无匹配订单 → 不入账（unmatched）
  [PASS] 同额多单 → 歧义且不入账（ambiguous）
  [PASS] 超单笔上限 → 不入账（OVER_LIMIT）
  [PASS] 超时间窗口 → 不入账（OUT_OF_WINDOW）
  [PASS] 人工审核路径不受影响
  结果：通过 11 / 失败 0

  后台设置卡实测：关闭动作 → DB wxpay_receipt_auto_credit=0 ✓；开启动作 → DB =1 ✓（往返正常） 动态码页实测：渲染含回执区块与「自动入账」说明 ✓ 测试数据清理：余额恢复原值、测试订单/回执零残留、设置恢复为指定值 ✓

  过程中发现并修复一处自身缺陷：后台 pay-qr.php 的 require ReceiptCredit 被放在 POST 处理之后， 导致 GET 渲染正常但表单保存报 Class "ReceiptCredit" not found。已把 require 移到文件顶部（第 14 行）并复测通过。

  四、安全提醒（重要）

  • 开启自动入账后，手机端设备密钥 = 可入账凭证。密钥只存在手机脚本与站点设置中，请勿外传/提交仓库； 一旦怀疑泄露，请立刻在后台关闭自动入账并更换 wxpay_receipt_token。
  • 建议保持保守闸门：单笔上限按你实际最大套餐设置；无人值守时可持续观察「未自动入账」列表。
  • 随时可一键关闭（后台开关 → 关闭），关闭后回执仅记录，回到原有人工审核流程。

第 5 / 10 页 · 每页 10 条 · 共 93 条