Skip to content

U
ubains-module-test
提交 eebe75d4 authored 作者: 陈泽健's avatar 陈泽健
浏览文件
操作

docs(monitor): 记录 token 有效期限制评估结论并清理临时探针脚本 

- 报告 token 评估结论：维持 7 天有效期、不加访问次数限制，报告 14 天清理兜底
- 清理仓库根/deploy/ 下无引用的一次性诊断探针脚本（check_*/_diag*/debug_*/tmp_test 等，多数含硬编码明文密码）
- 保留已跟踪正式文件与可复用运维脚本（trigger_*/fix_*/upload_docs* 等）
Co-Authored-By: 's avatarClaude <noreply@anthropic.com>
上级 07d17632
显示空白字符变更
内嵌 并排
正在显示 包含 354 行增加 和 14 行删除
Docs/需求文档/服务监测/HANDOFF.md
浏览文件 @ eebe75d4
# HANDOFF — 服务监测模块实施进度 # HANDOFF — 服务监测模块实施进度
> 最后更新：2026-07-27 ｜ 分支：troubleshoot-ai-assistant ｜ 模块：service-monitor > 最后更新：2026-08-31 ｜ 分支：troubleshoot-ai-assistant ｜ 模块：service-monitor
> 状态：**定时任务修复完成 + Docker 容器化方案设计完成 + Vue 前端迁移规划完成，待部署** > 状态：**报告链接免登访问已修复并部署复测通过（07d17632）+ token 限制评估结论：维持 7 天有效期不加次数 + 临时探针脚本已清理（未提交）**
--- ---
...@@ -225,21 +225,21 @@ templates/service_monitor/{index,targets,run,report}.html ...@@ -225,21 +225,21 @@ templates/service_monitor/{index,targets,run,report}.html
**建议执行顺序**：先容器化部署落地，再并行推进 Vue 重构 **建议执行顺序**：先容器化部署落地，再并行推进 Vue 重构
### 8.2 待执行任务 ### 8.2 待执行任务（历史，已部分完成）
| 优先级 | 任务 | 说明 | | 优先级 | 任务 | 说明 | 状态 |
|--------|------|------| |--------|------|------|:----:|
| **P0** | 部署容器化版本到 5.60 | 需先确认 Docker 已安装，执行 `docker_deploy.sh` | | **P0** | 部署容器化版本到 5.60 | 需先确认 Docker 已安装，执行 `docker_deploy.sh` | ✅ 已上线 |
| **P0** | 更新 5.44 定时任务 end_date | 当前 end_date=2026-07-22 已过期 | | **P0** | 更新 5.44 定时任务 end_date | 当前 end_date=2026-07-22 已过期 | ✅ 已更新为 2027-08-31 |
| P1 | 修复 APScheduler day_of_week 约定 bug | `from_crontab('1-5')` 实际是周二到周六 | | P1 | 修复 APScheduler day_of_week 约定 bug | `from_crontab('1-5')` 实际是周二到周六 | ✅ 已修复 |
| P2 | SQLite 迁移 | 替换 JSON 文件存储 | | P2 | SQLite 迁移 | 替换 JSON 文件存储 | ⏳ |
| P2 | Vue 前端开发 | 按任务清单执行 | | P2 | Vue 前端开发 | 按任务清单执行 | ⏳ |
### 8.3 遗留问题 ### 8.3 遗留问题（历史，已解决）
1. **5.44 定时任务 end_date 已过期**（2026-07-22），需通过 API 更新 1. ~~**5.44 定时任务 end_date 已过期**（2026-07-22）~~ ✅ 已更新为 2027-08-31
2. **APScheduler day_of_week 约定 bug**：`CronTrigger.from_crontab('1-5')` 按 APScheduler 约定是周二到周六，非周一到周五，需改为 `CronTrigger(day_of_week='0-4')` 2. ~~**APScheduler day_of_week 约定 bug**：`CronTrigger.from_crontab('1-5')` 按 APScheduler 约定是周二到周六~~ ✅ 已修复（见 9.1）
3. **容器化尚未部署**：需在 5.60 上执行部署脚本验证 3. ~~**容器化尚未部署**~~ ✅ 2026-08-13 已上线 5.60
### 8.4 本次新增文件 ### 8.4 本次新增文件
...@@ -252,3 +252,343 @@ templates/service_monitor/{index,targets,run,report}.html ...@@ -252,3 +252,343 @@ templates/service_monitor/{index,targets,run,report}.html
| `Docs/需求文档/服务监测/PRD_问题处理_定时任务并发执行失败.md` | 问题处理文档 | | `Docs/需求文档/服务监测/PRD_问题处理_定时任务并发执行失败.md` | 问题处理文档 |
| `Docs/需求文档/服务监测/PRD_计划执行_定时任务并发执行失败修复.md` | 计划执行文档 | | `Docs/需求文档/服务监测/PRD_计划执行_定时任务并发执行失败修复.md` | 计划执行文档 |
| `Docs/需求文档/Flask模板迁移Vue前端任务清单.md` | Vue 迁移任务清单 | | `Docs/需求文档/Flask模板迁移Vue前端任务清单.md` | Vue 迁移任务清单 |
---
## 9. 2026-08-17 会话进度追加
### 状态更新
**容器化部署已上线** ✅：
- 5.60 容器 `troubleshoot` 运行中，启动于 2026-08-13 12:25（北京时间）
- supervisor 管理 nginx + Flask 双进程
- 三个定时任务均正常工作，5.44 end_date 已更新为 `2027-08-31`
### 9.1 修复 APScheduler day_of_week 约定 bug ✅
**问题**：`CronTrigger.from_crontab('1-5')` 按 APScheduler 约定 day_of_week 0=周一，1=周二…6=周日，导致 `1-5` 被解释为**周二到周六**，而非预期的周一到周五。
**实测验证**：
- 2026-08-15（周六）三个任务均执行 → 确认 `1-5` 确实包含周六
- 修复前 `from_crontab('30 8 * * 1-5')` 首次触发：Tue 08-18
- 修复后 `from_crontab('30 8 * * 0-4')` 首次触发：Mon 08-17
**修复方案**（`schedule_service.py`）：
1. 新增 `_convert_dow_to_apscheduler(cron_expr)` 函数：将 cron 表达式的 day_of_week 字段统一 -1 偏移（标准 cron 1=周一 → APScheduler 0=周一）
2. 支持单值、范围、列表、混合格式
3. 在 `_add_job()` 中调用转换函数，将转换后的表达式传给 `CronTrigger.from_crontab()`
**修改文件**：
- `skill/code/web/service_monitor/services/schedule_service.py` — 新增 `_convert_dow_to_apscheduler` 函数 + `_add_job` 中调用
**新增文件**：
- `skill/code/web/service_monitor/tests/test_schedule_service.py` — 15 个测试用例（11 转换 + 3 APScheduler 真实触发验证）
**验证**：全套 253 测试全绿 ✅
### 9.2 待办更新
| 优先级 | 任务 | 说明 |
|--------|------|------|
| P2 | SQLite 迁移 | 替换 JSON 文件存储 |
| P2 | Vue 前端开发 | 按任务清单执行 |
### 9.3 遗留问题
1. **4 个 routes 页面测试失败**（`test_routes_sm.py::TestPages`）：返回 200 而非 302，因前端改为 Vue SPA 后页面路由由 `index.html` 处理，无重定向。需后续更新测试断言。
### 9.4 本次新增/修改文件
| 文件 | 说明 |
|------|------|
| `skill/code/web/service_monitor/services/schedule_service.py` | 修改：新增 `_convert_dow_to_apscheduler` 转换函数 |
| `skill/code/web/service_monitor/tests/test_schedule_service.py` | 新增：15 个 day_of_week 转换测试用例 |
---
## 10. 2026-08-29 会话进度追加（三问题修复 + 部署复测）
### 10.1 背景（为什么做）
用户连续反馈 3 个问题：
1. **触发巡检（如 5.44 全量巡检）完成后，日志里看不到钉钉通知发送的痕迹**（"触发过会发通知吧？"）
2. **手动重跑 5.44 定时任务，发送的内容特别少**（约 40 行，正常应几百项）
3. **每天 09:30 报告缺失告警误报**：把从未配定时任务的内置目标「本机（当前服务器）/local」报成"2 天无新报告（上次：无报告）"
### 10.2 根因与修复（全部已部署复测）
#### ✅ 根因 1：service_monitor 孤儿 logger（通知日志不可见）
**现象**：钉钉机器人实际**一直在发**（errcode 0 成功），只是 `钉钉通知已发送` 这行日志永远看不到。
**根因**：`service_monitor/` 9 个模块用裸 `logging.getLogger("service_monitor.X")`，脱离了 `utils/logger.py` 的 `troubleshoot` 命名空间（根 logger 有 StreamHandler+RotatingFileHandler）。孤儿 logger 的事件 propagate 到全局 `root` logger（默认 WARNING、无 handler），**INFO/WARNING 全部静默丢弃**。
**修复**：8 个文件头部 `import logging` + `logging.getLogger(...)` → `from utils.logger import get_logger` + `logger = get_logger("service_monitor.X")`（自动归入 `troubleshoot` 命名空间）：
- `routes.py`、`utils/check_modules.py`、`services/{target_service, notification_service, report_service, statistics_service, compare_service, schedule_service}.py`（schedule 此前已正确）
- `utils/crypto.py` **故意不改**：其 docstring 声明"模块自包含，不依赖全局 utils/logger"，自带 StreamHandler，保持隔离
**验证**：
- 容器内 import 探针：9/9 模块 logger.name 均为 `troubleshoot.service_monitor.*`，parent=troubleshoot ✅
- 本地 PROBE 日志写入 app.log ✅
#### ✅ 根因 2：bash 资产 CRLF 导致模块输出几乎全空（"发送内容少"）
**现象**：5.44 full 巡检 01_system_basic 输出被截断到 ~40 行，主机名/IP/内存等项缺失。
**根因**：Windows 上传的 `assets/*.sh` 是 CRLF，Linux bash 执行时把 `\r` 当命令内容的一部分，大量命令失效。
**修复**（双层）：
- `utils/executor.py` 上传/布置脚本时强制 LF：`dst.write_bytes(data.replace(b"\r\n", b"\n"))`（write_bytes 3 处 + config write_text，见 325/445 行附近）
- 本地 assets `.sh`/`.template` 统一转 LF（git 已跟踪）
**验证**：5.44 full 复测 = **42 模块 / 509 项**（正常 486 / 警告 10 / 严重 13），`01_system_basic` 18 项完整（主机名、内核、负载、CPU 核心等全有值）✅
#### ✅ 根因 3：check_missing_reports 每日误报内置目标
**现象**：09:30 报告缺失告警误报 `本机（当前服务器）/local` 无报告。
**根因**：`check_missing_reports` 对**所有**目标做缺失判定，内置目标从未配定时任务 → 永远"无报告"。
**修复**（`report_service.py:838` check_missing_reports）：仅检查**启用了定时任务**的目标（`schedule_service.list_schedules()` 中 enabled 且 target_id 非空）；schedules.json 读取失败回退为检查全部目标（保持原行为兜底）。
**验证**：
- 新增 4 个单测（`test_report_service.py`）：仅定时目标参与判定 / 无定时任务返回空 / 最近有报告不缺失 / 过期报告 missing_days=真实天数
- 容器内实测 `check_missing_reports(2)` 返回 **0 个缺失**（之前会报 local）✅
- 全套 257 测试全绿 ✅
#### ✅ 附带：通知发送结果日志（runner_service）
`run_inspection_sync` 通知块增加结果日志（`runner_service.py:376-403`）：
```
巡检完成通知：已发送（report_id=…）
未找到报告 …，跳过
发送通知失败: …
连续异常告警检查失败: …
```
配合根因 1 的 logger 修复，通知结果现在**可在 app.log 留痕验证**。
### 10.3 部署与复测（关键流程，接手者复用）
**生产拓扑**（5.60，2026-08-29 已确认）：
- 容器 `troubleshoot`（`troubleshoot:latest`，supervisord 管 nginx:80 + Flask:8088，健康检查 `curl http://localhost/api/health`）
- 端口映射 `8088→80`（nginx）
- 镜像真实 build 源：**`/data/third_party/monitor-platform/`**（`skill/code/web/` + `skill/code/requirements.txt` + `frontend/dist/`）
- `docker-compose.yml` 在该目录，`docker compose up -d --build` 重建
- volume：monitor-data→`/app/web/service_monitor/data`、logs→`/app/web/logs`、users.json、dist、搜索索引.json（只读）
**本次部署方式**（热更新，未重建镜像）：
1. 18 个改动文件（代码+assets）LF 同步到 build 源 `/data/third_party/monitor-platform/skill/code/web/service_monitor/`，md5 18/18 校验
2. `docker cp` 逐文件注入容器 `/app/web/service_monitor/`，清 `__pycache__`，`docker restart troubleshoot`
3. 容器内 md5 复验 MATCH + logger 探针 9/9 归位 + health healthy
**复测**（5.44 full，report `20260829_034555_f7ee98`）：
- `POST /api/service-monitor/schedules/sched_042074c6-5e2/run` 触发（管理员登录 + Cookie）
- 巡检 4 分钟（03:41:53→03:45:55）→ 报告 509 项
- app.log 关键行：
```
保存报告: 20260829_034555_f7ee98 (目标=新统一平台5.44, 套件=full, 项=509)
报告保存完成: 20260829_034555_f7ee98
钉钉通知已发送 ← 之前永远不可见
巡检完成通知：已发送（report_id=20260829_034555_f7ee98）
巡检执行完成: success=True
```
### 10.4 当前状态
- **代码已改完 + 本地 257 测试全绿 + 生产容器已热更新并复测通过**
- **改动尚未 git 提交**（分支 `troubleshoot-ai-assistant`，勿 merge master）
- 待办表更新：SQLite 迁移 / Vue 前端（P2，历史遗留，与本批无关）
### 10.5 本次改动文件清单
| 文件 | 改动 |
|------|------|
| `service_monitor/services/notification_service.py` | logger 迁移（通知发送本就正常，只是日志不可见） |
| `service_monitor/services/runner_service.py` | logger 迁移 + 通知结果日志块 |
| `service_monitor/services/report_service.py` | logger 迁移 + check_missing_reports 仅查定时目标 |
| `service_monitor/services/{schedule_service,target_service,statistics_service,compare_service}.py` | logger 迁移 |
| `service_monitor/routes.py`、`utils/check_modules.py` | logger 迁移 |
| `service_monitor/utils/executor.py` | 上传/布置脚本强制 LF（CRLF 根因） |
| `service_monitor/assets/*.sh` + `config.sh.template`（8 个） | 统一转 LF |
| `service_monitor/tests/conftest.py` | tmp_data 补 `schedule_service.SCHEDULES_FILE` patch |
| `service_monitor/tests/test_report_service.py` | +4 check_missing 单测 |
### 10.6 踩坑（本次新增，务必注意）
1. **孤儿 logger 是最隐蔽的坑**：模块里用 `logging.getLogger()` 拿到的事件若不在 `troubleshoot` 命名空间，会被全局 root logger（WARNING 无 handler）**静默丢弃**——功能正常但日志全无。排查"日志不可见"先验 `logger.name` 前缀 + `parent`。
2. **部署热更新必须同步 build 源**：容器 `/app/web/` 是**镜像层**，`docker cp` 只改运行中容器；不同步 `/data/third_party/monitor-platform/` 会在下次 `--build` 时**回滚**。同理 `/opt/troubleshoot` 是 nohup 旧运行源，也要防 systemd 回退路径用旧代码。
3. **urllib POST 被降级为 GET**：urllib 复用连接时对无 body 的 POST 可能自动发 GET → 拿到 404 而非 405/200。排查 404 先看 nginx access log 的 method；用 raw socket 显式 POST 即可（本次 `RAW POST 200 triggered=true`）。
4. **报告文件路径**：`/app/web/service_monitor/data/reports/<rid>.json`（注意实际在 reports/ 根，不是 reports/index/reports/）。
5. **Windows 控制台打印容器输出**：GBK 控制台遇 emoji/中文会 UnicodeEncodeError，脚本内 `sys.stdout = TextIOWrapper(sys.stdout.buffer, encoding='utf-8', errors='replace')` 包裹；复杂引号命令用 `base64` payload 传参。
### 10.7 下一步（优先级排序）
1. **git 提交本批改动**：`troubleshoot-ai-assistant` 分支（勿 merge master），Conventional Commits，例如 `fix(service-monitor): 修复通知日志不可见/CRLF 输出缺失/报告缺失误报`，并同步 `Docs/需求文档/服务监测/HANDOFF.md` 的提交记录
2. **考虑重建镜像**：本次是 docker cp 热更新，长期稳妥做法是 `docker compose up -d --build`（build 源已同步，重建后代码一致）
3. **回归确认定时任务**：周一到周五 08:30（5.44）自动巡检时，验证 app.log 有 `巡检完成通知：已发送` + `钉钉通知已发送`，且**不再**出现 09:30 报告缺失误报
4. **清理临时探针脚本**：仓库根/`deploy/` 下 `check_*.py`、`_diag_*.py`、`debug_notification.py` 等临时文件按需归档或删除
5. （历史遗留 P2）SQLite 迁移 / Vue 前端开发
### 10.8 本次验证用的关键命令
```bash
# 触发 5.44 full 巡检（管理员 Cookie + 显式 POST）
POST /api/service-monitor/schedules/sched_042074c6-5e2/run
# 看通知日志（容器内）
docker exec troubleshoot tail -50 /app/web/logs/app.log | grep -E '通知|保存报告|巡检执行完成'
# 验证 check_missing（容器内）
docker exec troubleshoot python3 -c "$(echo <b64> | base64 -d)" # from service_monitor.services import report_service; check_missing_reports(2)
```
---
## 11. 2026-08-31 会话进度追加（报告链接免登访问 + 生产 docker compose 重建）
### 11.1 背景（为什么做）
用户反馈：**钉钉通知里的"完整报告"链接**（含 `?token=...`）在未登录浏览器点击后，
被重定向到登录页并提示"登录已过期"。
复现链接示例：
```
http://192.168.5.60:8088/login?next=/service-monitor/report/20260831_010950_bce779?token=rpt_f129...
```
### 11.2 根因（三层鉴权链路都挡在访客前）
1. **前端路由守卫**：Vue Router 把 `/service-monitor/report/:id` 视为必须登录页面，未登录一律跳登录（`next` 还带了 `?token=`）
2. **后端详情 API**：`api_get_report` 只认 session，访客请求直接 401
3. **Axios 全局 401 拦截器**：把 token 访客的 401 也当"登录已过期"，再跳一次登录页 → 用户看到误导性提示
### 11.3 修复方案（只放读，不扩权）
| 层 | 改动 | 要点 |
|----|------|------|
| 后端 `routes.py` | `api_get_report` 优先校验 `request.args['token']` | 有效 token 允许**只读**详情访问；token 缺失/无效回退到原登录校验 |
| 后端 | 删除/批量删除/对比等**写操作不动** | token 不获得任何写权限，权限范围不扩大 |
| 前端 `router/index.ts` | 路由守卫仅放行 `MonitorReportDetail` **且带 token** 的请求 | 其他带 token 页面仍走正常认证 |
| 前端 `api/report.ts` | `getReport(id, token?)` 把 token 作为 **query params** 发送 | 用参数对象避免手工拼接编码问题 |
| 前端 `ReportDetail.vue` | 详情加载时把当前路由 token 传给 `getReport`；导出链接统一 URL 编码 | token 特殊字符不破坏查询串 |
| 前端 `utils/http.ts` | 401 分支区分"报告 token 访客" vs "会话失效" | token 访客显示「报告链接无效或已过期」，**不**跳登录不清 session |
### 11.4 测试（263 → 269 全绿）
- `test_routes_sm.py` 新增 `TestReportTokenAccess` 类 4 用例：
- 无 session + 有效 token → 详情 200
- 缺 token / 错误 token → 401 需登录
- 过期 token → 401
- token **不能**删除报告（写权限未扩大）
- `test_report_service.py` 新增 token 校验单测（有效/错误/过期/缺字段）
- 全套 pytest **269 用例全绿**（本机本地环境）
- 前端：`vue-tsc --noEmit` 类型检查通过 + 生产 build 成功（dist 含修复 bundle）
### 11.5 部署（本次为**镜像重建**，非热更新）
生产拓扑延续 10.3：build 源 `/data/third_party/monitor-platform/` + `docker compose up -d --build`。
步骤：
1. 本机构建新前端 dist（含修复 bundle）
2. 同步 build 源：后端改动文件 + 新 `frontend/dist/` 上传到 `/data/third_party/monitor-platform/`
3. 服务器 `docker compose up -d --build` 重建镜像重启容器（**不是** `docker restart`）
4. 容器内部 md5/代码版本校验 + 健康检查
### 11.6 生产复测结果（已验证 ✅）
- **访客免登**：无登录 Cookie 直接打开 `report/20260831_010950_bce779?token=...` → 进入报告详情（不再重定向登录）
- **详情 API**：带 token 访客请求返回 200
- **导出**：带 token 访客导出 MD/JSON 仍可用
- **错误/过期 token**：显示「报告链接无效或已过期」，不误报"登录已过期"、不跳登录
- **权限未扩大**：无 token / token 错误时未登录访问详情仍 401 或跳登录；删除/写操作仍需要管理员登录
- **普通页面回归**：未登录访问报告列表等其他服务监测页面仍跳转登录
### 11.7 git 提交
- 已提交并推送：**`07d17632`**
`fix(service-monitor): 报告链接免登访问 + 钉钉链接直达报告详情`
- 后端 token 只读鉴权、前端路由守卫/API/401 拦截器区分访客 token、导出 URL 编码
- 测试 269 全绿、dist 重建、生产 docker compose 重建并复测通过
- 分支 `troubleshoot-ai-assistant`（**勿 merge master**）
### 11.8 本次改动文件清单
| 文件 | 改动 |
|------|------|
| `skill/code/web/service_monitor/routes.py` | `api_get_report` 支持 token 只读访问 |
| `frontend/src/router/index.ts` | 守卫放行带 token 的报告详情 |
| `frontend/src/api/service-monitor/report.ts` | `getReport(id, token?)` query 传参 |
| `frontend/src/views/service-monitor/ReportDetail.vue` | token 传入详情/导出 |
| `frontend/src/utils/http.ts` | 401 拦截器区分访客 token |
| `skill/code/web/service_monitor/tests/test_routes_sm.py` | +TestReportTokenAccess 4 用例 |
| `skill/code/web/service_monitor/tests/test_report_service.py` | +token 校验单测 |
| `frontend/dist/` | 生产 build（含修复 bundle） |
| `Dockerfile` 等 | 重建相关微调 |
### 11.9 踩坑 / 注意（本次新增）
1. **token 是能力边界**：token 只应该解锁"读报告详情/导出"，任何写操作（删除、批量删除、对比、触发巡检）绝不能因 token 放行——改权限要当安全变更对待，回归测试必须覆盖"token 无权写"。
2. **Axios 401 双语义**：同一个 401 状态码可能是"访客 token 失效"或"登录过期"，处理方法完全不同（前者显示链接失效、后者清 session 跳登录）。用 `error.config.params.token` / URL 含 `token=` 区分，且**不要在 token 分支清除用户会话**。
3. **前端 build 产物是部署的一部分**：改前端源码后必须重新 build 并替换 `frontend/dist/`，再同步 build 源重建镜像；只改源码不重建，线上仍是旧 bundle。
4. **路由守卫判断抽纯函数更可测**：守卫里"是否 token 访客报告页"的判断逻辑建议独立成纯函数，便于后续前端单测（当前项目无前端测试框架，本次用 vue-tsc + build 验证）。
### 11.10 下一步（优先级排序）
1. **回归确认定时任务**：下次工作日定时巡检（5.44 08:30）后，确认钉钉"完整报告"链接访客可直达（本轮已修）
2. **考虑给 token 加查看限制**（可选）：报告 token 长期有效，若担心泄露，可加有效期/访问次数/按报告自定义失效时间（现状：14 天报告清理时一并过期）→ **已评估，维持现状，见 12.1**
3. **清理临时探针脚本**：仓库根/`deploy/` 下临时 `check_*.py`、`_diag_*.py` 等按需归档或删除（10.7 遗留）→ **已清理，见 12.2**
4. （历史遗留 P2）SQLite 迁移 / Vue 前端开发
---
## 12. 2026-08-31 会话进度追加（token 限制评估 + 清理临时探针脚本）
### 12.1 报告 token：评估结论 — 维持「仅有效期限制」，不加访问次数
**需求**：11.10 提到的可选「给 token 加查看限制」。
**评估结论**（与用户确认）：**不加访问次数限制，维持现有有效期机制**。
- token 有效期 `ACCESS_TOKEN_DAYS = 7`（`report_service.py:33`）
- `validate_access_token()`（`report_service.py:604`）校验格式/报告绑定/有效期
- 报告保留 14 天，`cleanup_expired()` 到期删除报告，token 随之失效
- **本轮不改任何代码**（`report_service.py` / `routes.py` / 前端均不动）
后续如需收紧（如加访问次数/按报告自定义失效），方案已备好，见 12.4 备忘，接入时注意并发原子消费与历史报告兼容。
### 12.2 清理临时探针脚本（已完成 ✅）
**范围**：只删纯探针（一次性诊断/排查脚本，全部未跟踪、无正式引用），保留可能复用脚本。
**已删除**（未 git 跟踪，删除不影响历史）：
- **仓库根目录**：22 个 `check_*.py`（app_log/code_version/container_status/data_dir/docker_logs/flask_*/logs_direct/monitor_data/reports/running_process/running_scheduler/schedule_issue/scheduler_*/supervisor*/task_result/threads）、`debug_notification.py`、`final_check.py`、`final_diagnosis.py`、`test_docker_on_989.sh`、`test_scheduler2/4/_init.py`、`test_sudo_config.py`
- **deploy/**：`_diag*.py`（14 个）、`_debug_500.py`、`_deploy_and_test.py`、`debug_inspect*.py`（4 个）、`_probe_544_candidates.py`、`_run_diag*.py`（3 个）、`_run_verify_560.py`、`_verify_sign_fix.py`、`_final_check.py`、`_final_verify.py`、`cat_log.py`、未跟踪 `check_*`（inspect_error/local_ssh/logs/report/run_logs/schedules/ssh_config/sudo，8 个）、一次性 `test_*`（full_inspect/pdf/pdf2/quick_inspect/sse/ssh）、`verify_69_deploy.py`
- **deploy/tmp_test/** 整个目录（19 文件 ~5.8MB，含 5.44/5.60 抓包 bundle `app_544_latest.js`/`app_backstage.js`）
**明确保留**（勿再删）：
- 已跟踪正式文件：`deploy/check_service.py`、`deploy/build_index.py`、`deploy/upload_to_server.py`、`deploy/verify_deployment.py`、`deploy/deploy_docker.py`、`deploy/deploy_service_manage.py`、`deploy/verify_new_features.py`、`deploy/deploy_to_69.py`、`skill/code/web/service_monitor/utils/check_modules.py`
- 可能复用脚本（用户确认保留）：根目录 `api_trigger.py`、`trigger_*`、`deploy_fix*.py`、`download_*.py`、`fix_*.py`、`force_rebuild.py`、`rebuild_and_deploy.py`、`restart_and_verify.py`；`deploy/` 下 `deploy_frontend*.py`、`deploy_to_560.py`、`upload_backend.py`、`upload_dist.py`、`upload_docs*.py`（含 v2~v10/final/final2/win）、`upload_skill.py`、`encode_docs.ps1`、`upload_docs.ps1`
**验证**：
- 删除前逐文件 `git grep` 复核引用：仅 `HANDOFF.md` 自身提及 `debug_notification`/`check_container_status`；bash 资产中的 `check_app_log_errors()`/`check_container_status()` 是函数名，与根目录探针脚本无关，不误删
- `git status` 无已跟踪文件被删（无 `D` 状态）；保留文件全部在位
- 全套 pytest **269 用例全绿**（纯删未跟踪脚本，无影响）
### 12.3 踩坑 / 注意（本次新增）
1. **探针脚本多为硬编码明文密码**（`Ubains@123`，违反 CLAUDE.md「密码禁止硬编码」）：本次删除的 `_diag*`/`debug_*`/`check_*` 系列绝大多数含明文凭据，删掉顺带降低泄漏面。**今后排查勿再在仓库根/`deploy/` 裸建诊断脚本**，如需临时探针放 `.tmp/` 并加入 `.gitignore`，且禁止硬编码密码。
2. **bash 资产里的同名函数不是探针**：`assets/service/*.sh` 中 `check_app_log_errors()`/`check_container_status()` 是监测模块函数，与根目录探针脚本无引用关系——清理时按「文件名 + git grep」判断，勿按关键词批量删。
### 12.4 备忘：token 加访问次数的备用方案（当前未做）
若后续要加访问次数限制（用户当前已确认不加）：
- `report_service.py` 增加 `ACCESS_TOKEN_MAX_USES` 常量 + `save()` 写 `access_token_used_count`/`access_token_max_uses`/`access_token_issued_at`/`access_token_invalidated_at`
- `validate_access_token()` 改为「校验 + 原子递增」（进程内锁 `_token_lock` 包住读-判-增-写，单进程部署适用），成功后消费一次，失败请求不计
- `cleanup_expired()` 对「报告仍保留但 token 已过期/耗尽」仅清 token 不删报告
- 兼容：旧报告无新字段按原有效期校验，不重生成 token；详情/导出共用额度，登录访问不计入
### 12.5 下一步（优先级排序）
1. **回归确认定时任务**：下次工作日定时巡检（5.44 08:30）后确认钉钉链接访客可直达、`钉钉通知已发送` 留痕、09:30 无误报
2. **git 提交本次清理 + HANDOFF 更新**（分支 `troubleshoot-ai-assistant`，勿 merge master），Conventional Commits 如 `chore(monitor): 清理临时探针脚本 + 记录 token 限制评估结论`
3. （历史遗留 P2）SQLite 迁移 / Vue 前端开发
Markdown 格式
0% 或
您添加了 0 人 到此讨论。请谨慎行事。
请先完成此评论的编辑！
请 注册 或者 后发表评论