CLAUDE.md 红线章节补充 Excel 导出数组对齐陷阱

song.jun

3 天以前 d6cc926b4bf627ce5a24ea2a16a86a842b760f75

CLAUDE.md 红线章节补充 Excel 导出数组对齐陷阱

BackstageController 的多个 Excel 导出 action 用 headers[] + cellKes[]
两个平行字符串数组手动按下标对齐。历史上已经出过两次同模式 bug：
- 15e82c0 追加"是否收费"列时出现重复（a3f4e4f 已修）
- LabExcelDate/LabExcel 把 Province 字段放在标签"城市"的列下，
  admin 长期误以为 Province 没保存（d5a91a2 已修）

补充红线条目：改这类导出必须两个数组并排核对、新增/删除列时两个
数组同步修改、排查"导出数据不对劲"时优先检查对齐而非写路径。

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

 CLAUDE.md

@@ -137,6 +137,7 @@
## 修改时的红线（针对本仓库的具体风险）

- **`BackstageController` 是超级 Controller**：1600+ 行、几十个动作、大量 QC 业务耦合在一起。做变更时务必在动作内部就近改，**不要顺手重构或拆分文件** —— 这不是本次任务范围，且缺少测试覆盖，重构风险极高。
- **Excel 导出的 `headers[]` 和 `cellKes[]` 是手动对齐的平行数组**：`BackstageController` 里每个导出 action（`OutputUnderTakenLabs` / `LabExcelDate` / `LabExcel` / `Quality_Excel` / `ToExcel` / ...）都用两个字符串数组靠**下标顺序对齐** —— `headers[i]` 是 Excel 第 i 列的中文标签，`cellKes[i]` 是对应的属性名（反射读 DataTable 列）。数组长度必须严格一致，语义顺序必须一一对应，**没有任何编译期/运行期检查**。历史上已经出过两次相同模式的 bug：(1) `15e82c0` 追加"是否收费"时只加到末尾忘了检查前面已有一份，导致重复列（`a3f4e4f` 已修）；(2) `LabExcelDate`/`LabExcel` 长期把 `Province` 字段放在标签为"城市"的列下，admin 以为 Province 没保存（`d5a91a2` 已修）。**改这类导出的铁律**：每次修改都必须把 `headers` 和 `cellKes` 两个数组并排看一遍，逐下标核对中文标签和字段名是否语义匹配；新增列时两个数组都要加；删除列时两个数组都要删。如果下次排查的 bug 形态是"导出看不到数据"或"导出数据不对劲"，**先去检查这俩数组的对齐而不是写路径**。
- **DI 注册点单一**：所有新增 Service 类都要到 `sbcLabSystem.Framework/DependencyRegistrar.cs` 去手动注册；没有约定式自动装配。
- **DbContext 生命周期**：`IDbContext` 是 `InstancePerLifetimeScope`，即每次 HTTP 请求共享一个 `FreseniusDBContext`。**不要在 Service 内部 `new FreseniusDBContext()`**，会绕过事务 / 变更跟踪。
- **EF 迁移自动升级**：启动即跑 `MigrateDatabaseToLatestVersion`。本地改 migration 后第一次运行 Web 就会对你连的数据库执行 DDL —— 在连生产/共享库时要特别小心，**改 migration 前先确认 `Web.config` 里的连接串指向的是哪个环境**。