| | |
|---|
| | | - **本地打包形态压测（headless Chrome，20 轮菜单切换）**：导航 17~89ms、0 JS 错误、DOM 恒 949 节点无累积、堆内存 11~37MB 无泄漏、最长长任务 80ms → 应用 JS 层无死循环/大计算/泄漏。 |
|---|
| | | - **已加 Tomcat 访问日志**（`server.tomcat.basedir: .` + accesslog，jar 同级 `logs/access.*.log`，pattern 含 `%D` 耗时，静态资源也记录）——本地实测 chunk 请求 3ms。**重新打包发布后**，下次崩溃看 access log：chunk 请求是否到达、耗时多少 → 直接定位「服务器慢」还是「客户端没发出请求」。 |
|---|
| | | - 待用户：重新打包发布后，崩溃时看 ①服务器 `logs/access.*.log` ②客户端 F12 Network 中 `chunk-*.js` 请求状态（pending/stalled/耗时）。 |
|---|
| | | - **根因实锤（本机实验复现）**：Tomcat 9 NIO 下慢连接不占线程（slowloris 无效，已测），但**慢速 multipart 上传会占线程**——240 个慢上传占满线程池后，chunk 与 batches 请求全部 pending/超时（与用户现象一致）。**数据导入是同步长任务**（4 万行导入占 1 个线程 5 分钟，前端超时 600s），多用户同时导入/目录导入串行 → 200 线程耗尽 → 新请求（batches、静态文件）排队 pending → 浏览器等 →「无响应」弹窗。**只崩数据导入页**因为它进页即发 2 个 batches 请求且用户多在导入场景操作；其他页面在同样时刻也会 pending 只是未被注意。 |
|---|
| | | - **机制可复现（本机实验，非实锤）**：Tomcat 9 NIO 下慢连接不占线程（slowloris 无效，已测），但**慢速 multipart 上传会占线程**——240 个慢上传占满线程池后，chunk 与 batches 请求全部 pending/超时（与用户现象一致）。**数据导入是同步长任务**（4 万行导入占 1 个线程 5 分钟，前端超时 600s），多用户同时导入/目录导入串行 → 200 线程耗尽 → 新请求（batches、静态文件）排队 pending → 浏览器等 →「无响应」弹窗。**只崩数据导入页**因为它进页即发 2 个 batches 请求且用户多在导入场景操作；其他页面在同样时刻也会 pending 只是未被注意。 |
|---|
| | | - **修复（commit 728b372，已验证）**：① `server.tomcat.threads.max: 500`（application.yml + example）；② 数据导入页 `loadBatches`+`loadOverview` 合并为 `loadData`（进页/刷新/导入后只发 1 个 limit=200 请求，表格取前 50，概览复用同批数据）。**修复验证**：同样 240 慢上传压力下，batches 0.2s、chunk 0.1s 正常。 |
|---|
| | | - **遗留（建议下一步根治）**：导入异步化（@Async 独立线程池执行导入、前端轮询进度），彻底不占 Tomcat 请求线程；或 nginx 托管静态资源。对方 dev 机单用户也 pending，需看对方后端日志（可能 DB 连接/锁，或对方当时在跑导入），与本修复不冲突。 |
|---|
| | | - **用户反驳（08-28 晚）→ 线程池耗尽不是当前场景实锤根因**：崩溃时仅 3 个用户（1 人已登入、1 人未登入、1 人登入后即出问题），时间上不可能占满 200 线程。线程池 500 + batches 合并的修复仍有效（降低同类风险），但不要对用户宣称根因已实锤。真正待取证：重新打包发布后崩溃时看 ①服务器 `logs/access.*.log`（chunk/batches 是否到达、%D 耗时）②对方 dev 机（单用户也 pending 的复现机）后端日志（是否 DB 连接/锁/SQL 卡住）。 |
|---|
| | | |
|---|
| | | ### 3. 待办不变 |
|---|
| | | ### 3. 前端 API 全局超时保护（已完成并推送 commit 41487b9） |
|---|
| | | - 背景：用户要求所有向后台的 API 请求都加超时保护，超时优雅提示（网络/服务器异常），不要无限 pending。 |
|---|
| | | - 实现：`src/api/index.js` axios 实例默认 `timeout: 15000`；响应拦截器里 `ECONNABORTED` → 弹「请求超时：服务器繁忙或无响应，请稍后重试」、无 `response` → 弹「网络异常：无法连接服务器」，并给 error 打 `_toast` 标记，页面 catch 里 `if (e && e._toast) return` 避免重复弹；401 跳登录逻辑不变。 |
|---|
| | | - 长耗时请求显式覆盖：文件上传 600s/300s（原有）、`/audit/execute` 120s、`/audit/review` `/audit/markAudited` `/explain/save` 60s、`/llm/chat` 120s、报表导出 120s、报表预览/就绪 60s、验证码接口 10s、登录 15s。 |
|---|
| | | - 覆盖文件 11 个（api/index.js、AiChatDialog、Captcha3D、AuditResult、DataImport、DataView、ExplainReview、Login、ReportExport、RuleManage、UserManage），node24 构建通过，已提交推送。 |
|---|
| | | |
|---|
| | | ### 4. 待办不变 |
|---|
| | | - `docs/打包部署说明.docx` 第六节「外置 application.yml 需包含完整配置」改为「属性级合并」后重新导出 docx（未做）。 |
|---|
| | | - 崩溃根因确认后：修正 commit `cf57c2b` 中「指向客户端环境」的旧结论。 |
|---|
| | | |
|---|
