# #8 【三个站点全面体检：9000 / 9001 / 任务系统(8190) 偶尔卡顿·要加载·打不开】★本条是**总览项**：看板已有相邻条目，修前先读、别重复修 —— #9「9001 假死根治：电脑B 的模型服务一重启（换档/调参），9001 就死等那条断连接」很可能是本条的「打不开」根因之一；#4「输入框丢字/页面闪一下」很可能是本条的「偶尔卡一下」根因之一。用户 2026-10-15 交办（原话：「9000 9001以及我们的任务系统 三个网站经常都会偶尔卡一下，偶尔要加载一下，偶尔打不开，他们老是出这些bug，能不能全面的检查一遍？」）。**本次是执行不是审计** ✗ 只交报告=没完成。范围：9000(晚风云) / 9001(本地27B) / 8190(任务系统) + 手机入口 9443/9444/9445。现象：偶发卡顿、需要重新加载、偶发打不开（间歇性 → 要抓"什么时候发生"）。① **服务面**：六个 systemd user 服务状态与重启记录（`systemctl --user show -p NRestarts`）、端口占用与冲突、证书有效期、ufw 放行、磁盘/内存/文件描述符上限。② **后端面**：`hermes_bridge.py` 逐条审（单线程 HTTPServer？是否有阻塞调用、SSE 长连接的心跳与断线重连、连接数上限、超时设置、异常吞掉的位置）；上游 27B(B:8080) 与云 API 的超时/重试/排队；日志里的 5xx、ConnectionReset、超时（`journalctl --user -u hermes-webchat*` 按小时统计）。③ **前端面**：首屏体积（ui.html 136KB 是否可减）、SSE 断线重连体验、`偶尔要加载一下` 是不是重连/重渲染导致（与今天 #4「输入框丢字/页面闪一下」很可能是同一个根因，一并查 ✗ 别各修各的）；PWA/缓存策略（现 sw.js 只做通知、不缓存 ✓ 已核）。④ **数据面**：8190 的 `MD_LOCK` 并发写（#17 已加锁）、`task_state.json` 读写、`ai_done` 并发；三个站点统一走一次并发压测。⑤ **网络面**：局域网延迟/丢包实测（本人实测过手机 ping 730ms、平板 27ms → 手机侧要单独看）、mihomo 代理是否意外代理内网、手机 WiFi 休眠省电。⑥ **交付要求**：**必须给"之前 vs 现在"的实测数字**（每站至少 30 次请求的 p50/p95 延迟、断线重连成功率、并发下的错误率）✗ 别只说"已优化"；每个真bug要写清根因+修法+防复发；查不出根因的项也要列出来并给"下一步怎么抓"。⑦ **改动纪律**：动服务/改码前先 `cp -a` 备份、改完先验证再重启、重启 9000/9001 前先告知用户 ✓ 全部登记 `三agent操作日志.md`。⑧ **验收**：① 三站各 30 次实测数据表（前/后）② 能复现的 bug 给出复现步骤 ③ 已修的项给"改了什么文件+怎么验证的" ④ 未修的项写明原因与下一步。

归属日期: 2026-10-15
序号: 8
当前状态: ✅ 已完成（用户勾选）
被接手次数: 2

该任务出现时间为
2026-10-15-本次第一次
2026-10-15-本次第二次

---

## 2026-10-15 第1次
- 执行者: 用户
- 做了什么:
- 证据（真命令 + 原始输出）:
- 结论:
- 遗留/卡点:

## 2026-10-15 第2次（勾选完成）
- 执行者: 用户
- 返工原因/问题: 条目在页面上直接打钩完成（未经 AI 接手）→ 自动补建任务日志，保证「打钩的条目必有日志」，任务日志与待办 1:1
- 上次判断错在哪:
- 本次怎么改:
- 证据（真命令 + 原始输出）:
- 结论: