| | |
|---|
| | | > **每天结束时**：把当天进展、踩过的坑、新需求、未完成事项更新到本文件，然后可以放心开新对话。 |
|---|
| | | > **协作约定（2026-08-31）**：说「提交」= 本地 commit + 推送到远端 git（origin main，Gitblit），不再只做本地 commit。 |
|---|
| | | |
|---|
| | | ### 10-14（3）：Excel COM 打不开部分生成件 → 改用 WPS KET.Application（坑与绕法） |
|---|
| | | |
|---|
| | | - **现象**：用 `New-Object -ComObject Excel.Application` 自动核对生成件时，`Workbooks.Open` 报「不能取得类 Workbooks 的 Open 属性」。**同一次脚本里**预测件、母版 `2026年9月道路运输量汇总表.xlsx`、`生成_道路运输量汇总表_2026-07_验证.xlsx` 都打得开；打不开的是 `生成_道路运输量汇总表_2026-09 (12).xlsx` 与 `输出\生成_道路运输量汇总表_2026-08_四页数据驱动_2026-09-13.xlsx` → **是文件级的，不是环境级**。 |
|---|
| | | - **已排除（均实测，不是原因）**：① 文件被 WPS/微信占用——按字节复制到本地（SHA256 一致）后在独立 Excel 实例里**仍然打不开**；② 网络来源标记——副本没有任何 Zone.Identifier 附加流；③ `calcPr fullCalcOnLoad="true"`——把它去掉后仍失败；④ OPC 部件缺失——打不开的文件与能打开的文件**部件列表完全一致**。根因未定位，不要再盲目二分。 |
|---|
| | | - **可用绕法**：① **WPS 的 COM 组件 `KET.Application`**（注意 `ET.Application` 未注册，报 0x80040154）能打开这些文件，`WorksheetFunction.Sum` / `UsedRange` / `Count` 均正常——本轮实测读到生成件 594 个数值格、SUM=`658615.2874963345`；② `openpyxl(data_only=True)` 读缓存值对所有文件都可用；③ 需要在 Python 里复现 Excel 状态栏求和时，按**行序**用 double 累加——在 Excel 能打开的那份上实测与 COM SUM **完全一致**（`658615.287496335`）。 |
|---|
| | | - **顺带的显示坑**：Excel 显示末位是"四舍五入"，Python/.NET 的 `F8` 是"银行家舍入"，同一个数可能显示差最后一位。本轮：预测件 SUM=`658615.287496335` → 显示 `…49634`；生成件 SUM=`658615.2874963345` → 显示 `…49633`；**底层只差 4.66e-10**，却被显示成"差 1e-8"。 |
|---|
| | | - **进程卫生**：`Excel.Application` 会真的拉起 `EXCEL.EXE`。新建前记录 EXCEL/ET 的 PID，用完先 `Quit()` 再 `ReleaseComObject`，只清理自己拉起的 PID；**绝不要对"挂上去/复用"的实例调 `Quit()`**——Excel/WPS 都会注册到 ROT，`Quit` 可能把用户正开着的窗口关掉。 |
|---|
| | | - **快查文件是否被占用**：`[System.IO.File]::Open($p, [System.IO.FileMode]::Open, [System.IO.FileAccess]::ReadWrite, [System.IO.FileShare]::None)` 抛 Access denied 即被占用；但被占用不是本坑的原因（副本同样打不开）。 |
|---|
| | | - **已按 AGENTS §0 同步到顶层** `C:\Users\jcxiong\.codex\AGENTS.md` 第 11 节（跨项目通用）。 |
|---|
| | | - **数据边界**：本轮只读；未修改/未保存任何原始业务文件。`_tmp\_cmp_1014\` 下留了副本 `gen12_copy.xlsx` 与去掉 `fullCalcOnLoad` 的对照件 `gen12_nocalc.xlsx`（临时产物，按约定不删、不入库）。 |
|---|
| | | |
|---|
| | | ### 10-14（2）：重启后端加载合并后新代码并核验生效【无代码改动】 |
|---|
| | | |
|---|
| | | - **做了什么**：按 10-14（1）的接手提示，只停后端链（`cmd 27476` → `maven java 3948` → `app java 28136`），前端 8080 不动；再执行 `start-dev.ps1`（脚本检测到 8080 已监听 → 跳过前端，只拉起后端）。新后端进程 **PID 21640**，08:35:08 启动。 |
|---|
| | | - **核验生效**：`target/classes` 于 08:34:45 重新编译，`ReportExportService`、`SummaryLayoutExpander`、`SummaryMissingDataCheck`、`SummaryWorkbookFiller`、`FreightReadinessCheck` 均为本次编译产物；字节码含新映射 `/summaryWorkbook/missing`、`/summaryWorkbook/freightCheck` 与参数 `titlesOnly`；`backend.log` 两条就绪标志齐全（`Tomcat started on port(s): 8090`、`Started TrafficAuditApplication in 8.691 seconds`）；`GET /api/version` 返回 HTTP 200。 |
|---|
| | | - **未做 / 边界**：本轮无代码改动、未导入或覆盖任何业务数据；只读接口 `summaryWorkbook/missing|freightCheck` 直接请求返回 401（`JwtAuthFilter` 要求登录），未用账号登录调用。同事这批「汇总大表」改动（多为【待验收】）仍需用户在页面重新生成 2026-09 验收。 |
|---|
| | | |
|---|
| | | ### 10-14（1）：重启后拉起前后端 + 拉取合并同事 34 个提交（汇总大表）【无代码改动】 |
|---|
| | | |
|---|
| | | - **本轮（未改代码）**：电脑重启，用 `start-dev.ps1` 拉起前后端，脚本输出后端 OK、前端 OK；前端 http://localhost:8080，后端 8090，日志见 `backend.log` / `traffic-audit-web/frontend.log`。 |
|---|
| | | - **git**：本地原为 `a2dfe61`，落后 `origin/main` 34 个提交；已 `git fetch origin` + `git merge --ff-only origin/main` 快进到 `697891d`。这批提交是同事"汇总大表"系列：`ReportExportService`、`SummaryLayoutExpander`、`SummaryMissingDataCheck`、`FreightReadinessCheck`、`ReportExport.vue`，以及配套母版/规格/验证方法文档（多为【待验收】）。 |
|---|
| | | - **【接手注意·已处理】**：当时 8090 的后端是合并前（08:23）启动的旧字节码；已由下一节 10-14（2）重启（新进程 PID 21640，08:35:08 启动）加载同事最新代码，并核验生效。 |
|---|
| | | - **数据边界**：本轮未改代码、未跑测试、未导入/覆盖任何业务数据。 |
|---|
| | | - **工作区**：仅保留约定不入库的临时目录/文件（`_tmp_doc_compare/`、`_tmp_flow_table/`、`_tmp_holiday_verify/`、`_tmp_rail_label/`、`_tmp_pack_smoke_trend.docx`）和用户数据 `docs/专项统计/重要节假日/观测站分日调查数据 (2026年10月1日).xls`，不要删除或误提交。 |
|---|
| | | |
|---|
| | | ### 10-13（1）：汇总大表《货运周转量排名》块错位修复（母版删多余标题行 + 代码按「全省」行锚点对齐 + 写后自检）【待验收】 |
|---|
| | | |
|---|
| | | - **现象（用户报告 + 核对）**：9 月 ②③ 入库后，生成件《货运周转量排名》整块错位一行——全省值落到**表头行**（覆盖「累计完成(万吨公里）」文字）、市州值与市州名**错开一行**（武汉行装黄石的数…林区行是母版旧值）、**武汉的值丢失**；`RANK/占比/Q/R` 随错位一并错。 |
|---|
