12451
86a52ce293
refactor(api-server): 拆分 db/migrate.rs::run（174 → 20 行），行为零改动
`run` 在 2026-09 被拆过一次（280 → 46 行，把建表 SQL 抽成 `const SCHEMA_SQL`），
但后续每一轮迁移改动都往它里面追加（`LEGACY_COLUMN_TARGETS` 列对齐、
`ensure_active_order_unique`、各处列注释对齐……），**它又长回 174 行**，重新成为全仓最长函数。
## 改法：按"迁移阶段"切五个私有函数，顺序与容错口径逐条保留
| 阶段 | 内容 | 容错口径 |
|---|---|---|
| `apply_schema` | 执行 `SCHEMA_SQL` 建表 | ⛔ 上抛（表不在，后续无从谈起） |
| `align_column_metadata` | `abstract_id` 可空化 + 5 处列注释对齐 | 混合：`abstract_id`/`cabinets.status` 只记 ERROR，其余 4 条上抛（**逐条保留原口径**） |
| `create_indexes_and_columns` | `create_indexes` / `ensure_energy_report_indexes` / `add_columns_if_not_exists` | 第 1、3 条上抛，第 2 条（纯性能优化）只记 ERROR |
| `align_legacy_structures` | `align_legacy_columns` / `ensure_active_order_unique` | 均只记 ERROR（业务侧已有兜底） |
| `seed_defaults` | `seed_permissions` / `seed_roles` | ⛔ 上抛（没权限码平台等于不可用） |
`run` 本体只剩 5 行调用 + 收尾日志。**顺序即依赖顺序**，与拆分前逐条一致。
## 大段解释性注释：上移为 `///` 文档，不是删除
`align_column_metadata` 一度仍有 123 行 —— 但**里面全是解释性注释**（为什么
`compartments.status` 旧注释是错的、`cabinets.status` 为什么不是"在线"、
`charge_orders.status` 的 `2` 为何保留不用）。
这些说明**逐字上移到该函数的 `///` 文档**（rustdoc 同样渲染、读者同样能看到），
函数体因此降到 80 行以内 —— **零信息损失**。
## 验证（三条机械判据，全部可复跑）
新增验证器 `.git/verify_refactor.py`（本地工具，不入库），对任意文件证明"只搬代码、未改语义"：
1. **被移除的非注释代码行 = 0** —— 即所有原可执行语句都还在（本次实测 0 种）；
2. 新增的非注释代码行**只有脚手架** —— 实测仅 5 个 `async fn` 签名 + 5 个 `}` +
5 个 `Ok(())` + 5 条调用语句；
3. 文件内 `r#"..."#` **SQL 字面量逐条与 HEAD 相同** —— 实测 7 条全同。
> ⚠️ 这个验证器**先被我自己的自证抓出过一个假绿**：早期版本用反斜杠路径调
> `git show HEAD:<path>`，失败后"跳过并返回通过" —— 等于什么都没查。
> 已修：git 路径强制正斜杠；已跟踪文件取不到 HEAD 内容时**判为"验证器失效/本项未验证"并 exit 1**，
> 绝不当成通过。并实测：植入 `VARCHAR(20)→VARCHAR(30)` 后 **exit 1 且列出被移除的代码行**。
- `cargo check --all-targets`：零 error / 零 warning；
- `cargo test --bin pms-api`：**182 passed**（与基线一致，未减少）；
- 长函数总数：**8 → 7**（`migrate.rs::run` 已消除）。
其余 7 个（`hooks.rs::login` 95、`report_worker.rs::handle_auth_str` 88、
`middleware/auth.rs::auth_middleware` 87、`h5.rs::get_compartment_detail` 87、
`report_worker.rs::settle_finished_order` 85、`charge_orders.rs::list_charge_orders` 84、
`cabinets.rs::get_cabinet_detail` 83）沿用同一套改法与验证判据继续处理。
2026-09-20 05:13:08 +08:00
..
2026-09-20 05:13:08 +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