当前版本 v39发布 2026-10-03
v392026-10-03
上传链路专业化：手机端压缩（原图可选）· 小视频整段直传 · 修「老是提示仍在处理」
- 等待遮罩「仍在处理…」是误报，已修（用户原话：「经常提示仍在处理」）。等待遮罩原按固定 3 秒计时：任何操作只要超过 3 秒就无条件把文案改写成「仍在处理…」，把真实进度（「上传视频 45% · 3/17 片」）盖掉，再过 6 秒弹出带「重试/刷新页面」的面板 —— 而那个按钮正是 location.reload()，一点就把在途的上传掐断。现在 ① 每次进度上报（上传/压缩）都会把「无进展」秒表归零，只有真的 8 秒毫无进展才切换文案；② 逃生面板 8s→16s 才出现；③ 刷新前必须确认「可能还在上传，刷新会中断」。static/mobile/app.js 与首页内联副本 src/mobile/parts/10-_WAIT.js 同步修改（两份必须一致）。
- 手机端压缩 + 「原图」可选（用户原话：「就像微信一样 小视频手机端进行适当压缩 或者有个选项 原图可选项」）：新增 app.js compressVideo()，用 <video> 解码 → canvas 缩到 720p → MediaRecorder 录制（≈0.9Mbps），并在能取到音轨时保留声音；压缩前弹一次「压缩后上传（推荐）/ 原图上传 / 取消」，并探一次视频时长提示「压缩约需 N 秒」。超过 2 分钟的视频默认建议原图（压缩是实时的，等太久不如直传）。MediaRecorder 不可用（老安卓 / 低版本 iOS）时全部自动退回原片直传，绝不堵死上传。
- 小视频不再切分片：服务端本就有整段直传接口 /api/videos/upload（multipart，落库/落盘与分片 finish 完全同一条），前端 v39 对 ≤8MB 的视频改走它 —— 少掉 chunk+finish 两个往返。8MB 仍稳稳落在 gunicorn 单请求 120s 上限内（67KB/s 即可传完）；整段直传只试 1 次，遇到网络/超时/413/5xx 自动退回分片，遇到业务拒绝直接报错不重复落库。分片仍在（大原片必须），片长 4MB→6MB（服务端单片上限 8MB，留余量），片数更少、往返更少。
- 照片并发 2→3（inspect.js）：压缩后单张仅 0.2~0.5MB，服务端处理单张 123~453ms，3 条在途才喂得满上行。照片本身的压缩（1600px/质量 85）与逐张重试自 v34 起就是对的，本次不动。
- 仅清理陈旧注释里残留的旧线路（Cloudflare）字样：app/compress.py、app/main.py、app/routes_staff.py、static/mobile/app.js、static/mobile/inspect.js。服务端行为零改动（本次没有服务端逻辑改动，无需重建镜像，改代码 + docker restart 即生效）。
- 回归测试新增 G（/api/videos/upload 整段直传契约：200 + 字节一致 + 可播放）与 H（前后端常量自洽：前端片长 ≤ 服务端上限、直传阈值在 120s 可传完区间、__waitShow 必须归零秒表）——把这次的现场结论固化成断言，防止日后各改各的。
v382026-10-03
去臃肿：摘掉为规避旧线路抖动而加的全部机制（新线路不需要）
- 下线「弱网自愈 v32」（static/mobile/app.js）：删除每 18s 一次的 /api/ping 连接保活，以及导航 4s/9s 未换页就「换新连接重试」的兜底。该机制是当年针对「弱网上约 1/3 新连接丢 SYN」加的；新线路实测中继 20 次 TTFB 0.094s 零抖动，已无必要。后端 /api/ping 保活端点同步删除（app/main.py）。
- 下线前端 api() 的「GET 自动重试 3 次 + 3.5s 硬超时」（static/mobile/app.js）：改为单次请求 + 10s 有界超时；失败不再静默重试，而是明确把错误交给界面，由用户点「重试」（等待遮罩里的重试/返回按钮仍在）。首页内联的 api 猴子补丁分片 src/mobile/parts/11-api2.js 整个删除——它存在的原因就是「首页内联的是 app.js 的另一份副本」，脏且极易漂移。
- 下线企微凭据缓存「硬有效期」网络回退（app/wecom.py，access_token 与 jsapi_ticket 两处）：网络异常时不再回退到仍在 7200s 硬有效期内的旧凭据，改为记日志并返回 None（下次调用自动重试，自愈）。该回退是 2026-10-03 针对容器 DNS 故障加的，容器 DNS 已在 v35 显式修好（223.5.5.5 / 119.29.29.29）。
- 明确保留（不是网络补丁，是真功能 / 真安全网）：视频 4MB 分片上传（gunicorn 单请求 120s 超时的硬约束，256MB 视频不可能单请求传完）、离线队列（断网也能干活）、等待遮罩的瞬时反馈与用户手点的重试/返回入口、模块页 SSR 直出（点模块 0 个 XHR）。
v372026-10-03
外网入口切到自建边缘（东京）· 前端去掉失效备用域 · 日志改取通用转发头
- 链路（用户要求「老线路完全不用了」）：外网入口改为自建边缘 —— 东京 VPS 的 443 由 HAProxy 按 SNI 分流：本站域名走带正式证书的边缘 Caddy、经 SSH 反向隧道回源到 NAS:8090；其余 SNI 原样透传给原有代理进程（协议/证书/端口不变，客户端零改动）。实测中继 20 次 TTFB 0.094s 零抖动，对比原线路 0.37~1.02s 的剧烈抖动，现场「偶发长时间卡死」由此消除。
- 前端：删除导航失败时的「备用域」重试分支 —— app.js 第二次重试原会跳到另一个已失效的备用域名（实测 HTTP 000），等于把失败请求丢进死路；现改为同源、加缓存穿透参数重开一条新连接重试，自愈能力保留且不再依赖任何外部域名。
- 日志：请求日志的 IP 字段不再读取 CDN 专有请求头，改为通用 X-Forwarded-For → X-Real-IP → remote_addr。该字段仅用于排查日志，站内没有基于 IP 的鉴权或限流。
v362026-10-03
视频上传最后一步失败根因修复 + 去除「网络很慢」提示 + 上传提速（gzip/并发）
- 修复（用户现场反馈「视频上传依旧出错，最后缺少分片总数」）：前端 selectVideo 上传逻辑（static/mobile/app.js 的 uploadVideoChunked）在收尾调用 /api/videos/finish 时只送了 upload_id/name/size，**漏送 total（分片总数）**，服务端校验 total<=0 即返回 400「缺少分片总数」——分片其实已全部落盘，用户看到的就是「传到 100% 却失败」。v36 补上 total，并让进度文字显示「第 n/N 片」。
- 容错（服务端 routes_staff.video_finish）：total 缺失不再直接 400，改为按磁盘实收分片（uid.idx 从 0 连续）推断总数；推断仍为空才报「还没收到任何分片」。手机端强缓存里的旧版前端因此无需清缓存即可恢复上传。
- 去除提示（用户明确要求）：删除全部「网络很慢 / 网络较慢」措辞（app.js 等待遮罩、首页内联 _WAIT/_DESW/index 三处，共 4 文件 11 处）。改为中性表述（「仍在处理…」「这一步还没完成」「还没打开」「自动登录可能没完成」），保留「继续等/重试/返回」逃生入口。
- 提速①：新增 app/compress.py —— 直连路径（手机多数经 IPv6 直连 NAS，不经 Cloudflare）此前**没有任何压缩**，实测首页 88,303 字节裸奔下发；现对 html/js/css/json/svg/manifest 启用 gzip（<860B 或已压缩类型/流式响应自动跳过），首页约 88KB → 20KB 量级。
- 提速②：新增 mapLimit 并发闸门（app.js）——照片由严格串行改为并发 2 张（压缩与上传交错）、视频分片由串行改为并发 3 片。高延迟链路上墙钟时间由「N×RTT」降为接近 1×RTT。
- 重构（用户明确要求「不要屎山」）：首页 static/mobile/index.html 由「手抄多份已漂移的 JS 副本」改为**构建产物** —— 新增 src/mobile/index.tpl.html + src/mobile/parts/*.js（12 段内联脚本的单一来源）与 tools_build_index.py（--extract/--check/重建）。抽取重建后与原文件字节完全一致（88,311 字节，cmp 通过），此后前端只改一处、重建即生效，杜绝「改了 A 忘了 B」。
- 配套工具（可重复执行、幂等）：tools_patch_v36.py（函数替换 + 文案清扫 + ?v= 版本提升 + 禁用措辞自检）、patch_inspect_v36.py（巡检页并发与片数显示）。
v352026-10-03
企微链路故障根因修复（容器 DNS）+ 网络抖动不再拖垮全站
- 根因：NAS 主机 /etc/resolv.conf 中局域网解析器 192.168.10.200 对所有外部域名返回 REFUSED、IPv6 解析器 fd0f:88c6:fc2a::1 失效 → 容器继承后一切外部域名解析失败（socket.gaierror: Temporary failure in name resolution）。出网本身正常（绕过 DNS 直连 baidu/企微均 200）。
- 影响面：企业微信 gettoken / get_jsapi_ticket / OAuth 免登全部抛异常（requests 裸调用 → 路由 500）；JS-SDK 签名取不到 → 巡检端 wx.scanQRCode / wx.chooseImage 静默失败，现场表现为「点上传没反应 / 上传失败」。主机侧 docker pull 与隧道程序的 DNS 刷新一并受损。
- 修复：docker-compose.yml 给 xunjian 容器显式指定 dns: [223.5.5.5, 119.29.29.29]（不动主机、可秒回滚）。修复后容器内 qyapi.weixin.qq.com 等全部可解析，企微 probe：gettoken 与 jsapi_ticket 均 ok（应用名「巡检」），JS-SDK 签名签发成功。
- 加固：wecom.get_access_token / get_userid_by_code / get_userid_by_code_new / jsapi_ticket 由裸 requests 改为异常兜底 + 缓存凭据「硬有效期」回退，断网/DNS 抖动期间不再 500 拖垮免登与通知，网络恢复后自动自愈。
- 加固：/api/videos/chunk 增加单片大小上限（8MB，config.CHUNK_BYTES）——此前仅受全局 MAX_CONTENT_LENGTH(256MB) 约束，客户端异常或恶意调用可反复写盘塞满 tmp；回归测试新增 C6 断言（超大分片 → 413 且不落盘）。
- 遗留：主机层 DNS 未修（admin 无 root，需在飞牛面板或 root 下修正），隧道程序走 host 网络仍会每 5 分钟打印一次 DNS 刷新失败（隧道运行不受影响，但其重启依赖主机 DNS）。
v342026-10-03
上传可靠性专项 + 版本标识/更新记录 + 点击即显沙漏
- 修复「上传经常失败」根因：前端 api() 对所有请求硬编码 3.5s 超时并作用于上传，弱网必然中断；上传改走独立通道（照片 120s / 视频按体积动态）。
- 照片改为逐张上传（multipart 二进制），比原「6 张一批 base64」省约 25% 流量；单张失败不牵连其余，自带 3 次指数退避重试与上传进度。
- 视频改为分片续传（默认 4MB/片，逐片重试），突破 gunicorn 单请求 120s 超时与 Cloudflare 单请求 100MB 上限。
- 新增版本标识与更新记录：/api/version、巡检端「更新记录」页 /changelog、后台管理页版本徽标与更新记录入口。
- 修复「等待沙漏要等第二个页面快出来才显示」：首页菜单卡片是 <div onclick>，不在点击监听的白名单内；现支持 data-href/onclick 导航即刻显示沙漏。
- 照片/媒体响应增加长缓存头（内容不可变，7 天），弱网二次打开不再重复下载。
- 修复潜伏 bug：草稿照片放行正则只认 [0-9a-f]{32}.jpg，而开启水印后落盘名是 ...-wm.jpg → 未提交的照片一律 404，巡检端缩略图变破图，现场误判为「上传失败」反复重拍（老客户端同样受影响）。
v332026-09-30
弱网加固（现场电信线路实测驱动）
- 诊断信标 v31：把「请求消失」现象按网络切换/时序采集回传，用于区分源站问题与线路问题。
- 连接保活 v32：/api/ping 每 18s 维持热连接（不计入等待计数）；导航失败自动换备用域重试。
- 模块页 SSR：数据随 HTML 直出（window.__PRE__/__HOME__），点模块 0 个 XHR。
- BASEURL 切换为 https 域名（2026-09-29），配合企业微信内置浏览器。
v222026-09-28
第三轮现场反馈后的续修（备份 bak-20260928-195557-v22）
- 承接 v18–v21 走查项继续修补，明细见上级备份目录与 docs 记录。
v212026-09-28
双视角走查与专业化深化续（备份 bak-20260928-191549-v21）
v202026-09-28
走查修补（备份 bak-20260928-174452-v20）
v192026-09-28
走查修补（备份 bak-20260928-172307-v19）
v182026-09-28
双视角走查与专业化深化（docs 第 13 章）
- 以「巡检员视角 + 管理者视角」双视角走查现有功能，补齐专业化缺口。
v172026-09-28
注册码后台可查可改（docs 12.4–12.5）
- 后台新增注册码查看/修改接口与界面（此前注册码既看不到也改不了）。
- 本轮精确覆盖 14 个文件，MD5 校验 0 不一致；缓存号 v16→v17。
v162026-09-28
第三轮现场三条反馈闭环（docs 第 12 章）
- 修复「待裁决数据解决不了」——前端本地存储缺陷（服务端数据始终完好）。
- 补齐企业微信配置后台管理页面。
- 顺手修掉存量缺陷若干；settings 表建立（表数 19→20）。
v152026-09-28
第二轮反馈闭环 + 企业微信嵌入 + 现场照片水印（docs 第 11 章）
- 七条现场反馈处理；新增企业微信嵌入能力。
- 反作弊深化：现场照片叠加时间/人员/点位/GPS 水印（对标 P0）。
v142026-09-27
P0 位置签到＋离线冲突裁决 · P1 设备可靠性（docs 第 10 章上线记录）
- 位置签到（到位核验）：在线提交与离线补传共用同一判定函数，审计写入 audit_log。
- 离线队列可视化与冲突裁决；设备可靠性 MTBF/MTTR/可用率与运行停机状态。
- 重大隐患强约束（整改计划 + 复查销号）；隐患上报字段组与完成后评价。