12451
9e935fdda9
refactor(api-server): 8 个超 80 行函数全部拆分完毕（行为零改动）+ 补 171 条 SQL 快照守门断言
## 结果
| 函数 | 前 | 后 | 拆出的 helper |
|---|---:|---:|---|
| `db/migrate.rs::run` | 174 | 20 | `apply_schema` / `align_column_metadata` / `create_indexes_and_columns` / `align_legacy_structures` / `seed_defaults` |
| `routes/auth.rs::login` | 95 | 77 | `login_guard` |
| `workers/report_worker.rs::handle_auth_str` | 88 | 70 | `deliver_auth_str` |
| `middleware/auth.rs::auth_middleware` | 87 | 71 | `load_effective_scope` |
| `routes/h5.rs::get_compartment_detail` | 87 | 65 | `build_compartment_detail_response` |
| `workers/report_worker.rs::settle_finished_order` | 85 | 71 | `write_back_order_energy` |
| `routes/charge_orders.rs::list_charge_orders` | 84 | 61 | `append_order_filters` |
| `routes/cabinets.rs::get_cabinet_detail` | 83 | 74 | `ensure_cabinet_access` |
**全仓超 80 行的生产函数：0 个**（重构前 8 个）。`routes/mod.rs` 的 `.route(` 仍 **80**。
## 怎么保证"行为零改动"：机械验证器，不是靠人眼
新增本地工具 `.git/verify_refactor.py`（不入库），对每个文件给出三条判据：
1. **被移除的非注释代码行 = 0** —— 即原可执行语句**全部还在**
（搬进 helper 的行仍存在，故不计为移除；只有真正被改写/删掉的行才会出现）；
2. 新增的非注释代码行**只有脚手架**（函数签名/花括号/`Ok(())`/调用/`let` 绑定/尾表达式）；
3. 文件内 `r#"..."#` **SQL 字面量逐条与 HEAD 相同**。
7 个文件**全部通过三条**（被移除均为 0；`cabinets.rs` 12 条、`h5.rs` 27 条、
`migrate.rs` 7 条、`middleware/auth.rs` 3 条 SQL 字面量逐条一致）。
> ⚠️ **这个验证器本身被自证抓出过一个假绿**：早期版本用反斜杠路径调
> `git show HEAD:<path>`，失败后"跳过并返回通过"——等于什么都没查。
> 已修：路径强制正斜杠；**已跟踪文件取不到 HEAD 内容时判为"验证器失效/本项未验证"并 exit 1**。
> 实测植入 `VARCHAR(20)→VARCHAR(30)` 后 exit 1 且列出被移除行。
## 补 171 条 SQL 快照守门断言
这些 handler **原本没有任何测试覆盖**（tasks/002 的风险结论）。
新增 `routes/mod.rs::sql_snapshot_guards`：从 7 个文件**程序化提取**全部含 SQL 的字面量，
用 `include_str!` 把源文件本身作为被测对象 —— **SQL 文本/字段顺序/`?` 占位符一旦被改，测试立即失败**
（覆盖 `auth.rs` 5 + `cabinets.rs` 27 + `charge_orders.rs` 14 + `h5.rs` 52 +
`middleware/auth.rs` 18 + `report_worker.rs` 27 + `migrate.rs` 28）。
> ⚠️ **第一版守门断言也是假绿，靠自证发现**：提取规则只收"以 `SELECT` 开头"的字面量，
> 于是 `charge_orders.rs` 只捕到 2 条，**恰恰漏掉与 `.bind` 顺序一一对应的
> `" AND cabinet_id = ?"` 等片段** —— 我把 SQL 改了一个字符，断言却仍然通过。
> 已放宽为正则（含 `?` 且以 SQL 子句开头 / 含 SQL 关键字），该文件覆盖 2 → 14 条。
> 重新自证：改字符 → **FAILED 并打印出错片段**；还原 → 通过。
## 顺带修掉两处"由我自己的判据逼出来的代码退化"
子代理如实报告：它们为迁就验证器**过窄**的 SCAFFOLD 正则，做了两处不该做的让步 ——
这是判据塑造代码，必须纠正：
1. `append_order_filters` 被写成**体内无 `await` 的 `async fn`**（`clippy::unused_async` 的典型告警）
→ 改为同步 `fn`，调用点去掉 `.await`；
2. `ensure_cabinet_access` / `login_guard` 的签名被压成**单行 113+ 字符**
→ 恢复常规多行格式。
验证器的 SCAFFOLD 正则同步放宽（支持多行签名/形参行、普通与非 await 调用、裸标识符尾表达式），
放宽后 7 个文件复检仍全过。
## 验收
- `cargo check --all-targets`：**0 error / 0 warning**；
- `cargo test --bin pms-api`：**189 passed**（基线 182 + 7 条守门，**未减少**）；
- 长函数：**0 个**；路由：**80 条**；
- 错误处理口径逐条保留（`?` 上抛 vs 只记 `ERROR` 未互换），已在各 helper 的
`///` 文档注明来源与口径；`middleware/auth.rs` 的组织隔离/`user_scopes` 语义（
未配置=不限制、总管理员豁免、失败安全退回"不限制"）**逐字未改**。
2026-09-20 05:22:56 +08:00
..
2026-09-20 05:22:56 +08:00
2026-09-20 04:42:51 +08:00
2026-09-20 04:42:51 +08:00
2026-09-20 05:04:53 +08:00
2026-07-02 05:38:01 +08:00