更新日志

• v0.4.34

  短视频 / 短剧上传页新增真实上传进度条

  随交付包发布

  需求："给短视频和短剧上传页面增加上传进度条显示"。

  查看完整变更

  需求："给短视频和短剧上传页面增加上传进度条显示"。

  一、为什么不能沿用 fetch

  fetch() 无法获取"已上传字节数"（只能等到响应返回），浏览器里唯一能给真实上传进度的是 XMLHttpRequest 的 xhr.upload.onprogress。因此本次新增通用组件并改造提交方式。

  二、新增：assets/js/upload-progress.js（通用上传进度条）

  能力	说明
  真实进度	按已传字节计算百分比（不是假动画）
  数据信息	已传 / 总量、实时速度（KB/s、MB/s）、预计剩余时间
  三阶段状态	① 上传中（蓝紫渐变）→ ② 服务器处理中（橙色动画，转码/截图期间；避免用户以为卡死）→ ③ 成功（绿色）/ 失败（红色）
  失败可读	服务端 JSON 的 error 原样显示；非 JSON 响应提示"服务器返回异常（HTTP xxx）"；区分网络中断 / 超时 / 取消
  交互保护	上传期间禁用提交按钮（防重复提交），失败后自动恢复可重试
  零侵入	只依赖一个容器元素（#uploadProgress）；若缺失组件会自动创建并插到表单后；样式由组件自身注入

  用法：

  QdUpload.attach(formEl, { box: '#uploadProgress', button: btn, timeout: 1800000,
                            onSuccess: function (d) { location.href = d.redirect; } });

  三、三个页面接入

  页面	改动
  post-video.php（短视频）	fetch → QdUpload.submit()（保留原 FormData 组装与错误提示；失败原因同时写入原错误框）
  drama-upload.php（短剧上传）	传统表单 POST → XHR + JSON 分支：新增 $isAjax 判定、门禁/成功/错误三处 JSON 返回；表单接入 QdUpload.attach()
  drama-update.php（短剧编辑 / 追加剧集）	同上（两个表单各自独立进度条：#uploadProgressEdit、#uploadProgressAdd）

  踩坑记录（已修）：这两个短剧页在文件顶部就 require header.php，整页 HTML 已进入输出缓冲； 若直接 echo json_encode(...)，响应会变成「HTML + JSON」导致前端 JSON.parse 失败。 因此新增 dramaUploadJson() 助手：先 ob_end_clean() 清空缓冲再输出 JSON 并 exit。

  顺带统一：短剧剧集（上传与追加）也接入 convertVideoToMp4() —— MOV/MKV/AVI 等容器会自动转封装/转码为 MP4， 与短视频动态保持一致（此前短剧允许 mkv/mov 却原样落盘，浏览器可能无法播放）。

  四、验证

  测试	结果
  进度条组件行为（Node + DOM/XHR 桩，test-upload-progress.js）	23 / 23 通过：50% 进度、3.00 MB / 8.00 MB ｜ 6.59 MB/s ｜ 剩余约 1 秒、处理中状态、成功/失败/网络/超时、按钮恢复、attach 拦截
  post-video.php / drama-upload.php 页面渲染	HTTP 200，含进度条容器与 JS 引用 ✅
  drama-update.php（临时短剧 + 所有者会话）	HTTP 200，两个容器 + 2 处 QdUpload.attach ✅（验证后临时数据已删除）
  短剧 AJAX JSON 分支	{"success":false,"error":"请至少上传一集视频"}、CSRF 失败 JSON、非 XHR 仍是 HTML（传统流程不受影响）✅
  真实上传回归（AJAX + MKV）	{"success":true,"moment_id":"19"}，落盘 moment_v_*.mp4（已转 MP4）✅
  数据卫生	测试动态/短剧/分类/会话文件全部清理；moments 16、moment_media 20、short_drama 0（与测试前一致）✅

  本次改动不需要重启 PHP / 重载 nginx（纯 PHP + JS）。 但 v0.4.33 的 15 分钟超时配置仍需你在宝塔执行一次「PHP 8.0 重启 + Nginx 重载配置」才生效。

• v0.4.33

  短视频上传：支持 MOV/MKV/AVI 等自动转 MP4；超时对齐 15 分钟

  随交付包发布

  需求："检测网站短视频上传报错"。结论：上传功能本身正常（14 次提交：200 ×10 / 499 ×3 / 400 ×1），

  查看完整变更

  需求："检测网站短视频上传报错"。结论：上传功能本身正常（14 次提交：200 ×10 / 499 ×3 / 400 ×1）， 报错来自格式与体积限制以及弱网超时，本次针对性修复。

  一、体检结论

  项目	结果
  上传端点 POST /post-video.php	200 ×10、499（客户端主动断开）×3、400 ×1 —— 无 500/502/413 ✅
  已成功入库	moments 今日新增 13 条，moment_media 记录齐全 ✅
  最大成功视频	4.41 MB（10-02）；今日的 1.35~2.39 MB ✅
  PHP 限制	upload_max_filesize 500M / post_max_size 600M / max_execution_time 300 ✅
  nginx	client_max_body_size 600m（与 PHP 对齐）✅
  业务限制（真正卡点）	单视频 50MB（MOMENT_VIDEO_MAX_SIZE）、仅 mp4/webm、前端 5 分钟超时 ⚠️

  报错成因（按出现概率）：

  1. 格式不支持：只接受 video/mp4、video/webm → 手机下载来的 MKV / MOV / AVI / TS 会被拒： xxx.mkv 不是支持的视频格式（仅支持 MP4 / WebM）；
  2. 体积超限：超过 50MB → xxx 超过 50MB 限制（而 php/nginx 允许到 500M/600M，限制在业务层）；
  3. 弱网超时：前端 AbortController 5 分钟 + PHP/FastCGI 300s → 手机上传大文件超时中断（日志里的 499）。

  二、修复内容

  #	改动	说明
  1	新增 convertVideoToMp4()（includes/fn-upload.php）	先用 -c copy -movflags +faststart 无损转封装（MKV/MOV/TS/FLV 内含 H.264 时通常数秒完成）；失败再回退 libx264 + aac 转码
  2	放宽视频白名单（includes/fn-moments.php）	新增 video/quicktime(mov)、video/x-matroska(mkv)、video/x-msvideo(avi)、video/x-m4v、video/mp2t(ts)、video/x-flv、video/x-ms-wmv、video/3gpp、video/mpeg、video/ogg
  3	上传后自动转 MP4 落盘	非 mp4/webm 的容器自动转成 .mp4 后发布（转封装失败则保留原文件并交给后台压缩流程重试）；file_size 记录实际落盘大小
  4	前端放宽可选类型	accept 与类型正则同步扩展（含 .mov/.mkv/.avi/.ts/...），提示文案改为支持的完整列表
  5	超时对齐 15 分钟	前端 AbortController 300s → 900s；php.ini max_execution_time/max_input_time 300 → 900；nginx fastcgi_send/read_timeout 300 → 900
  6	上传期间显示已用时间	按钮文案变为"发布中… 已用 N 秒（请勿关闭页面）"，减少误判卡死而重复提交（此前的 499 多为此因）
  7	nginx fastcgi_request_buffering off	大文件请求体直接流给 PHP，避免 nginx 先整包落盘再转发（省一半磁盘 I/O）

  三、验证（真实端到端）

  用 ffmpeg 生成 2 秒 H.264+AAC 测试视频 → 转封装为 .mkv → 通过真实登录会话上传：

  POST /post-video.php（media[]=vtest_upload.mkv;type=video/x-matroska）
  → {"success":true,"moment_id":"18","redirect":"video-play.php?id=18&index=0"}   ✅
  
  落盘：uploads/moments/2026/10/moment_v_1791626149_9548.mp4（30,579 B，扩展名已是 .mp4）✅
  ffprobe：h264,video / aac,audio； duration=2.001；format=mov,mp4,m4a,3gp,3g2,mj2 ✅
  同目录残留 .mkv：0 个 ✅   封面已生成：uploads/covers/moments/thumb_1791626150_5795.jpg ✅

  测试数据已全部清理：moment 18、moment_media 记录、视频文件、封面、测试分类均已删除， moments 恢复 16 条 / moment_media 20 条，上传目录无残留、无遗留 ffmpeg 进程 ✅

  四、需要用户操作（生效用）

  1. 宝塔 → 软件商店 → PHP 8.0 → 重启（max_execution_time/max_input_time = 900 生效）；
  2. 宝塔 → 软件商店 → Nginx → 重载配置（fastcgi_*_timeout = 900 与 fastcgi_request_buffering off 生效）。

  可选项：若希望放宽单视频 50MB 限制，改 includes/fn-moments.php 第 22 行 define('MOMENT_VIDEO_MAX_SIZE', 50 * 1024 * 1024) 即可（php/nginx 已允许到 500M/600M）； 但手机弱网下上传体积越大越易失败，建议同时考虑保持 50MB 并提示用户压缩。

• v0.4.32

  错误日志体检：清理历史噪音、补齐 favicon/robots、日志分流与 PHP 日志落地

  随交付包发布

  需求："检测网站错误日志"。范围：10123.xn--fiqs8s.error.log（2596 行 / 793 KB，覆盖 10-02 10-10）

  查看完整变更

  需求："检测网站错误日志"。范围：10123.xn--fiqs8s.error.log（2596 行 / 793 KB，覆盖 10-02 ~ 10-10） 与访问日志近 5000 条。

  一、体检结论：站点健康，无致命错误

  类别	条数	结论
  PHP Fatal / Parse error	0	✅ 无致命错误
  502 / 504 / FastCGI 错误	0	✅ PHP-FPM 正常
  数据库错误	0（MySQL error log 亦为空）	✅ 正常
  /im-stream 上游提前关闭	458	⚠️ 良性：客户端换令牌/切页导致 SSE 主动断开（见下）
  uploads/agent-icons/agent-default.png 缺失	248	✅ 已解决（文件 10-02 20:54 补齐，此后 0 条）
  assets/images/default-avatar.png 缺失	17	✅ 已解决（同上）
  robots.txt 缺失	124（今日 16）	⚠️ 仍在发生 → 本次补齐
  favicon.ico 缺失	52（今日 1）	⚠️ 仍在发生 → 本次补齐
  扫描器探测（.env / .git / wp-* / 各类 shell）	~100	✅ 站点正确返回 404，无需处理

  404 占比：近 5000 条访问中 404 有 2458 条（49%），绝大多数是自动化漏洞扫描（/wp-content/...、/.env、/chosen.php、/1.php 等）， 属正常现象；403 共 336 条，其中 210 条是 GET /（带 WP 风格参数）—— 站点安全层正常拦截。

  二、/im-stream 458 条的成因（已确认非故障）

  • nginx 侧 SSE 代理配置完全正确（proxy_buffering off、proxy_read_timeout 3600s、gzip off 等）；
  • Go 侧 im_sse.go 亦正确（text/event-stream、X-Accel-Buffering: no、20 秒心跳、Flush()、客户端断开即 return）；
  • 实证：ajax-im-token.php 今日调用 242 次、中位间隔 11 秒，每次换新令牌都会关闭旧事件流 → nginx 便记录一条 "upstream prematurely closed"。属于 SSE 正常重连的副产物。

  处理：在该 location 内把这类日志分流到独立文件并只记 crit，主错误日志从此清爽：

  location = /im-stream {
      error_log D:/BtSoft/wwwlogs/im-stream.error.log crit;
      ...
  }

  三、本次修复

  #	项目	内容
  1	robots.txt	新增（569 B）：放行正常抓取，屏蔽 /admin/ /data/ /includes/ /install/ /vendor/ 等敏感路径，并拒绝 Semrush/Ahrefs/MJ12 等扫描型爬虫
  2	favicon.ico	由站点 logo 生成多尺寸 ICO（16/32/48/64，12,431 B，魔数 00 00 01 00、4 张图像），另生成 apple-touch-icon-180/192.png
  3	nginx 日志分流	/im-stream 的良性错误写入 D:/BtSoft/wwwlogs/im-stream.error.log（crit 级），主日志不再被淹没
  4	PHP 错误日志落地	php.ini 的 error_log = syslog → error_log = D:/BtSoft/php/80/logs/php_errors.log（Windows 下 syslog 等于丢弃，PHP 报错此前无处可查）

  四、验证

  检查	结果
  nginx -t	syntax is ok / test is successful ✅
  /robots.txt（Host=127.0.0.1 / 192.168.0.100 / 域名入口 :65500）	HTTP 200（569 B）✅
  /favicon.ico	HTTP 200（12,431 B，有效 ICO，4 尺寸）✅
  /assets/images/apple-touch-icon-180.png	HTTP 200 ✅
  首页 / receipt-check.php	HTTP 200 ✅（38.5 KB / 13.8 KB）
  备份	D:\BtSoft\backup\qdcms-logfix-20261010-174609（nginx 配置、php.ini 均已备份）

  五、需要用户点击生效的两项

  1. 宝塔面板 → 网站 → 设置 → 配置文件 → 保存/重载（或 软件商店 → Nginx → 重载配置） —— 让 /im-stream 日志分流生效（nginx -s reload 需管理员权限，命令行被拒 Access is denied）；
  2. 宝塔 → 软件商店 → PHP 8.0 → 重启 —— 让 error_log 指向文件生效（此后 PHP 报错会写入 D:/BtSoft/php/80/logs/php_errors.log）。

  另可选（生产建议）：把 display_errors 关掉，避免报错信息直接显示给访客（与上面同一次重启即可生效）。

• v0.4.31

  修复手机脚本 ReferenceError：screenOnOk 未定义；新增脚本端到端桩测试

  随交付包发布

  用户报错：错误: ReferenceError: "screenOnOk" 未定义。

  查看完整变更

  用户报错：错误: ReferenceError: "screenOnOk" 未定义。 性质：v2.8 引入的作用域缺陷（我方 bug），已修复并补上自动测试防止复发。

  一、根因

  v2.8 我把"屏幕常亮"的变量声明写在了 main() 函数内部：

  function main() {
      var screenOnOk = false;     // ← 只属于 main 的作用域
      ...
  }
  function sendHeartbeat() {
      ... screen: screenOnOk ? 1 : 0   // ← 另一个函数里引用 → ReferenceError
  }

  而 wakeLockOk / foregroundOk / stableModeOk / notifSeen / lastHbAt 都是模块级声明， 唯独 screenOnOk 漏在了函数内 → 每次发心跳就抛 ReferenceError， 脚本启动后立刻中断（心跳发出前就报错），照旧收不到回执。

  二、修复（v2.8.1）

  • 把 var screenOnOk = false; 移到模块级（与其它状态变量并列），main() 内只做赋值；
  • 静态检查：sendHeartbeat() 引用的 6 个状态变量全部在顶层声明 ✓；
  • node --check 通过 ✓。

  三、新增：脚本端到端桩测试（qdcms-release/test-listener.js）

  用 Node + AutoX.js API 桩（http / events / device / $settings / storages / files / Packages / context） 把手机脚本完整跑一遍，无需真机即可捕获"只在手机上才暴露"的错误：

  检查项	结果
  脚本启动无异常（无 ReferenceError）	✅
  已开启通知监听 / 唤醒锁 / 屏幕常亮	✅
  心跳报文含 ver/screen/wake/notif/gap 且带双鉴权头	✅
  模拟"微信支付 收款到账 10.00 元" → 正确解析金额并上报 receipt	✅
  非收款通知 → 回传通知样本	✅
  非微信通知 → 忽略	✅
  合计	15 / 15 通过

  反向验证（把 bug 精确还原后再跑）：测试立即报 [FAIL] 脚本启动无异常 → screenOnOk is not defined（5 项失败，退出码 1） —— 与用户在手机上看到的报错完全一致，证明该测试确实能拦住此类缺陷。

• v0.4.30

  手机脚本 v2.8：内置屏幕常亮保活

  随交付包发布

  需求："再次检测手机脚本"。检测结论：脚本功能全正常（ver=2.7、wake=1、心跳按 1.73.1 分钟稳定上报），

  查看完整变更

  需求："再次检测手机脚本"。检测结论：脚本功能全正常（ver=2.7、wake=1、心跳按 1.7~3.1 分钟稳定上报）， 唯独 fg=0 / stable=0 —— AutoX.js 的「前台服务 / 稳定模式」在该机型上无法通过脚本设置生效 （重启脚本后依然为 0）。既然 API 开关不生效，v2.8 直接内置最确定有效的兜底。

  一、本次检测（03:29:56 心跳）

  {"type":"heartbeat","device":"收款手机","ver":"2.7","notif":0,"gap":0,"wake":1,"fg":0,"stable":0}

  项目	结果
  脚本版本	v2.7 ✅
  唤醒锁	wake=1 ✅
  前台服务 / 稳定模式	fg=0 / stable=0 ⚠️（重启后仍为 0 → 脚本设置不生效）
  心跳节奏	03:25→03:28（3.1 分）、03:28→03:29（1.7 分）✅（手机被使用时正常）
  回执	0 条

  二、v2.8 改动

  改动	说明
  内置屏幕常亮（device.keepScreenOn()，配置项 KEEP_SCREEN_ON）	脚本运行期间屏幕不灭 → 进程始终处于前台活动状态，OriginOS/Android 不会清理它；配合充电器即等效于彻底解决"进程被杀"
  心跳新增 screen 字段	服务端可远程确认屏幕常亮是否生效
  使用说明补充	明确提示"请把收款手机插上充电器"

  为什么用它：PARTIAL_WAKE_LOCK 只能防"CPU 休眠"，防不住系统杀进程； 而"屏幕常亮 + 充电"会让 App 处于前台活跃状态，是该机型上最可靠的保活方式。

  三、验证标准

  换 v2.8 后（插上充电器），自检页心跳报文应为：

  {"type":"heartbeat","device":"收款手机","ver":"2.8","notif":N,"gap":2~4,"wake":1,"fg":0/1,"stable":0/1,"screen":1}

  screen:1 且 gap 稳定在 2~4 分钟 → 保活到位；随后收款即可产生回执并自动入账。

• v0.4.29

  手机脚本 v2.7：稳定模式保活；实测"进程被反复杀掉"

  随交付包发布

  需求："检测手机脚本"。本次诊断出关键性质变化：不是"冻结"，而是进程被系统反复杀掉。

  查看完整变更

  需求："检测手机脚本"。本次诊断出关键性质变化：不是"冻结"，而是进程被系统反复杀掉。

  一、实测（03:25:08 心跳报文）

  {"type":"heartbeat","device":"收款手机","ver":"2.6","notif":0,"gap":0,"wake":1,"fg":0}

  字段	值	判断
  ver	2.6	✅ 已换到 v2.6
  wake	1	✅ 唤醒锁成功
  fg	0	⚠️ 前台服务始终没开（唯一拦路项）
  gap	0	⚠️ 每次心跳都是 0 = 脚本刚重启，说明进程被反复杀掉

  心跳间隔：02:27~02:28 → 02:37 → 02:49 → 03:06 → 03:11 → 03:25（间隔 4~17 分钟且 gap=0）。 → Android 16 + OriginOS 在持续清理 AutoX.js 后台进程；脚本活不过 3 分钟心跳周期，自然收不到收款通知。

  二、v2.7 改动

  改动	说明
  开启 AutoX.js「稳定模式」（$settings.setEnabled('stable_mode', true)）	官方推荐的保活开关：进程被杀后可自动恢复；这是该机型最有效的自救手段
  稳定模式开启后复检	读取 $settings.getEnabled('stable_mode') 确认是否真的生效
  心跳新增 stable 字段	服务端可远程确认保活是否到位
  日志汇总	心跳日志一次显示：通知数 / 间隔 / 唤醒锁 / 前台服务 / 稳定模式

  三、手机上必须打开的两个开关（否则一定会被杀）

  1. AutoX.js → 设置 → 打开「稳定模式」+「前台服务」；并在 系统 → 通知 → 允许 AutoX.js 发送通知 （前台服务依赖通知权限，缺它就永远是 fg:0）；
  2. Vivo/OriginOS：设置 → 电池 → 后台耗电管理 → AutoX.js → 允许后台高耗电； 应用自启动允许；多任务界面加锁；关闭「睡眠模式 / 超级省电」。

  兜底方案（任一即可，效果立竿见影）：

  • 收款手机长期插电 + 屏幕常亮（开发者选项 →「充电时屏幕不休眠」）；
  • 或换一台不装其他应用的旧手机专跑本脚本（白名单更干净）；
  • 或改用站点内置的官方支付网关（支付宝/微信 APIv3），不需要手机即可自动到账。

  四、验证标准

  换 v2.7 后，自检页心跳报文应为：

  {"type":"heartbeat","device":"收款手机","ver":"2.7","notif":N,"gap":2~4,"wake":1,"fg":1,"stable":1}

  fg:1 且 stable:1 且 gap 稳定在 2~4 分钟 → 保活到位，之后收款才能收到回执。

• v0.4.28

  手机脚本 v2.6：前台服务复检与指引；v2.5 状态实测

  随交付包发布

  需求："检测手机脚本"。本次从服务端直接读到手机脚本的自检数据（v2.5 起心跳携带诊断字段）。

  查看完整变更

  需求："检测手机脚本"。本次从服务端直接读到手机脚本的自检数据（v2.5 起心跳携带诊断字段）。

  一、手机脚本实测状态（03:11:03 心跳报文）

  {"type":"heartbeat","device":"收款手机","ver":"2.5","notif":0,"gap":0,"wake":1,"fg":0}

  字段	值	判断
  ver	2.5	✅ 手机上已是新脚本
  wake	1	✅ 部分唤醒锁获取成功（防冻结关键项已生效）
  fg	0	⚠️ 前台服务未开启 —— 仍会被系统挂起的主因
  notif	0	尚无微信通知（脚本重启后未收款）
  gap	0	该次为启动后首次心跳

  心跳时间线：02:27~02:28（启动）、02:37、02:49、03:06:51、03:11:03； 03:11 之后（至 03:17）无新心跳 → 仍需解决前台服务/白名单，否则会继续被冻结。

  二、v2.6 改动

  改动	说明
  前台服务开启后复检	读取 $settings.getEnabled('foreground_service') 确认真实生效状态，避免"以为开了"
  未生效时给出明确指引	日志提示：AutoX.js → 设置 → 打开「前台服务」；并在系统里允许 AutoX.js 发送通知（前台服务依赖通知权限）
  心跳继续携带诊断	ver/notif/gap/wake/fg，服务端自检页可见

  三、下一步（用户操作）

  1. 换 v2.6 脚本运行；日志若出现「前台服务未生效」→ 按提示在 AutoX.js 内开启并允许通知权限；
  2. Vivo/OriginOS：设置 → 电池 → 后台耗电管理 → AutoX.js → 允许后台高耗电；自启动允许；多任务加锁；
  3. 刷新自检页确认心跳报文变为 "ver":"2.6","wake":1,"fg":1，且 gap 稳定在 2~4 分钟（不再被冻结）；
  4. 然后在脚本运行期间收款一笔（例如与订单 #17 金额一致的 8.00 元）→ 站点应出现回执并自动入账。
• v0.4.27

  手机脚本 v2.5：心跳携带诊断信息，可远程判断脚本状态

  随交付包发布

  需求："检测手机脚本状态"。

  查看完整变更

  需求："检测手机脚本状态"。 结论：脚本在运行但仍被系统冻结 —— 心跳间隔 9.3 → 12.6 → 16.9 分钟（设定 3 分钟）， 且回执与"通知样本"均为 0 → 息屏期间通知仍被漏掉。

  一、本次检测证据（心跳间隔分析）

  相邻心跳	间隔	判断
  02:27:16 → 02:27:50 → 02:28:03	0.6 / 0.2 分钟	正常（脚本刚启动）
  02:28:03 → 02:37:22	9.3 分钟	疑似冻结
  02:37:22 → 02:49:58	12.6 分钟	疑似冻结
  02:49:58 → 03:06:51	16.9 分钟	疑似冻结（间隔反而变长）

  心跳只在"手机被使用/亮屏"时出现 → JS 定时器与通知回调仍被系统挂起， 说明 v2.4 的前台服务/唤醒锁在该机型上未生效（或手机上尚未换成 v2.4）。

  二、v2.5 的改进：把手机状态"上报"到服务端

  心跳报文新增诊断字段（会完整显示在站点自检页的「请求体」里）：

  字段	含义
  ver	脚本版本（服务端可核对手机跑的是哪一版）
  notif	本次运行捕获到的微信通知条数（为 0 = 通知根本没进脚本）
  gap	距上次心跳的分钟数（>7 分钟即被冻结过）
  wake / fg	部分唤醒锁 / 前台服务是否获取成功（1=成功）

  实测：心跳带 ver=2.5,notif=3,gap=17,wake=1,fg=1 → HTTP 200，诊断字段完整落库 ✓

  三、结论与下一步

  1. 换 v2.5 脚本后，先看自检页的「请求体」：

  • wake:0 或 fg:0 → 唤醒锁/前台服务没拿到（多为系统权限限制）；
  • ver 不是 2.5 → 手机上还是旧脚本；
  • notif:0 且收款后仍为 0 → 通知未进脚本（权限/微信通知被关）。

  1. 必须放开 Vivo/OriginOS 后台限制（否则唤醒锁也会被系统回收）： 设置 → 电池 → 后台耗电管理 → AutoX.js → 允许后台高耗电；应用自启动允许；多任务加锁； AutoX.js 内开启前台服务；关闭睡眠模式/超级省电。
  2. 最省心的替代方案：让收款手机长期插电并保持屏幕常亮 （开发者选项 → "充电时屏幕不休眠"），这样 JS 不会被挂起；或改用站点内置的官方支付网关（无需手机）。
• v0.4.26

  手机脚本 v2.4：前台服务 + 唤醒锁，根治"息屏漏收款通知"

  随交付包发布

  场景：连续两次"收款 10 元，动态码页无动静"。

  查看完整变更

  场景：连续两次"收款 10 元，动态码页无动静"。 根因找到了：手机脚本被 Android 息屏冻结（Doze），收款通知正好落在冻结期被漏掉。

  一、决定性证据：心跳间隔异常

  时间	事件	间隔
  02:27:16 / 02:27:50 / 02:28:03	心跳（脚本刚启动）	~40s
  02:37:22	心跳	9 分 19 秒
  02:49:58	心跳	12 分 36 秒
  02:49:58 之后	无任何请求（排查时已 9 分钟）	—

  脚本设定的是每 3 分钟一次心跳，实际却是 9~12 分钟 → 典型的 Doze/后台冻结： 进程还活着，但 JS 定时器与通知回调被系统挂起，冻结期间到达的微信收款通知会直接丢失 ✗。 两次收款（很可能发生在 02:3x、02:4x）正好落在这些"冻结窗口"里。

  同时：站点侧没有任何 receipt 请求、也没有通知样本 → 证明通知根本没进脚本（不是关键词问题）。

  二、v2.4 的修复

  #	改动	作用
  1	开启前台服务（$settings.setEnabled('foreground_service', true)）	通知栏常驻进程，显著降低被冻结/清理的概率
  2	获取部分唤醒锁（PowerManager.PARTIAL_WAKE_LOCK）	息屏后 CPU 仍运行，定时器与通知回调不被挂起
  3	冻结检测告警	心跳间隔 > 2 倍设定值时，日志明确打印"脚本曾被系统冻结，期间的收款通知会漏掉，请检查前台服务/电池白名单"
  4	退出时释放唤醒锁	避免耗电残留

  三、仍需在手机上确认的系统设置（Vivo / OriginOS 尤其重要）

  1. 设置 → 电池 → 后台耗电管理 → AutoX.js → 选「允许后台高耗电」；
  2. 设置 → 应用与权限 → 权限管理 → 自启动 → AutoX.js 允许；
  3. 多任务界面下拉 AutoX.js 卡片 → 加锁（防一键清理）；
  4. AutoX.js 内 → 设置 → 开启「前台服务」；
  5. 关闭系统的「睡眠模式/超级省电」。

  四、验证方式

  换 v2.4 脚本后，日志应出现：

  已开启前台服务（通知栏常驻，防系统冻结）
  已获取部分唤醒锁（息屏后脚本仍运行）
  [心跳] 已上报，站点应答 {"ok":true,...}        ← 应每 3 分钟稳定出现

  之后收款一笔（建议 10.00 元，与订单 #7 金额一致）→ 站点应在数秒内出现回执并自动入账； 若仍出现"脚本曾被系统冻结"告警，说明系统设置还没放开，按上面第 3 节逐项检查。

  长期建议：若你的收款渠道支持官方接口（支付宝/微信 APIv3），可以用站点已内置的官方支付网关， 完全不需要手机即可自动到账（后台「在线支付订单/支付设置」里配置）。

• v0.4.25

  远程诊断：未识别的微信通知原文可回传站点

  随交付包发布

  场景：实收 10 元，动态码页无动静。

  查看完整变更

  场景：实收 10 元，动态码页无动静。 排查：手机脚本在运行（02:49:58 心跳正常，设备名"收款手机"），但没有任何 receipt 请求 → 说明"收款通知没有被脚本捕获/识别"。此前只能靠手机日志判断，本版打通远程诊断。

  一、本次证据

  检查	结果
  手机心跳	02:49:58 正常（设备名"收款手机"）→ 脚本在运行
  receipt 请求	0 条（自 02:04 起从未出现过）
  回执表	0 条
  待审核订单	10.00 元订单 #7 仍在（回执一到即自动入账）
  浏览器轮询	每 5 秒 GET /payment-receipt.php?order_id=7 → 200 ✓（页面本身正常）

  → 结论：服务端与页面都正常，卡在"手机没把这条收款通知报上来"。

  二、新增能力（本版）

  #	内容	说明
  1	端点支持 type=notice（诊断专用）	只写排障日志：记录通知原文（前 200 字符）、原因、设备；绝不触碰订单/余额/回执；每小时最多 60 条
  2	手机脚本 v2.3	新增 REPORT_NOTICES（默认开）：凡被判定为"非收款"的微信通知，把原文回传到站点诊断日志（本地 10 秒限流）
  3	诊断日志展示	自检页「最近上报尝试」会显示这些样本，标题为「通知样本（未识别为收款）…」

  三、验证

  用例	结果
  POST {type:'notice', text:'微信支付 收款到账 10.00 元（样本）'}	HTTP 200 ✓，日志记为「通知样本（未识别为收款）：测试样本」+ 原文 ✓
  心跳	HTTP 200 ✓（原有链路不受影响）
  订单 #7 / 用户 3 余额 / 回执数	均未变化 ✓（诊断通道零副作用）

  四、下一步（用户操作）

  1. 换成 v2.3 脚本运行；
  2. 在脚本运行期间再收一笔（脚本看不到启动之前的历史通知）；
  3. 结果判读：

  • 诊断日志出现「通知样本…」→ 通知到了手机但关键词没匹配，把原文发来即可校准（我已能看到）；
  • 诊断日志连样本都没有 → 通知根本没进脚本（通知使用权未授予 / 微信通知被关闭）；
  • 出现 receipt 记录 → 已正常，将自动入账。

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