cloud-web-corejs 1.1.0-dev.6 → 1.1.0-dev.61

package/src/components/xform/docs/2026-09 /346/265/217/350/247/210/345/231/250/345/264/251/346/272/203/346/262/273/347/220/206P0/344/273/243/347/240/201/350/257/204/345/256/241.md"

@@ -0,0 +1,255 @@
+# 2026-09 浏览器崩溃治理 P0 代码评审
+
+## 1. 文档信息
+
+- 评审日期：2026-09-20
+- 对照方案：`src/components/xform/docs/浏览器崩溃治理与修复落地方案.md`
+- 评审仓库（测试源仓）：`D:\develop\code\company\2024\dev\sf-cloud-web-com-dev@publish_dev`
+- 评审范围：方案第 4 节已实施的 P0 代码（数据表格、自动保存队列、Blob URL 释放）
+- 不在本次范围：KeepAlive 治理、数据量硬上限、正式源仓同步
+
+## 2. 评审结论
+
+### 2.1 2026-09-20 三次复评（自动保存并发与销毁引用补修后）
+
+**上次评审指出的必须修、建议修，主路径已经改成功。** 可以进入方案第 7 节专项回归，仍不建议直接同步正式源仓。
+
+| 原问题 | 复评结果 |
+| --- | --- |
+| 5.1 上传弹窗 / 粘贴 / 聊天附件 Blob 不释放 | **已关闭。** `handleClose` 先 `revoke` 再清空；粘贴删除/确认会释放；`onlineTalk.deleteFile` 删除前释放。`VabUpload`、`obsUpload` 动态实例关闭后 `$destroy()` 并卸 DOM。 |
+| 5.2 查询成功副作用无代次 | **已关闭。** `emitTableDataLoaded(rows, tableOption, querySeq)` 延迟回调会核对 `tableQuerySeq` 和 `tableDestroyed`。`loadDefaultViewList`、H5 列表同样带代次。 |
+| 6.2 自动保存把失败当成功 | **已关闭。** 仅 `saveResult === true` 才推进 `savedVersion`；worker 等待行锁释放且可由代次/CancelToken 中止；销毁后不再弹错或回写。 |
+| 6.3 查询并发只覆盖 PC 主通道 | **已关闭。** `loadDefaultViewList` 与 `list-h5-item.vue` 已有代次、CancelToken、导出隔离。 |
+| 6.4 普通表删行不同步 `rowIdData` | **已关闭。** `deleteRow` 在更新模型后调用 `initRowIdData()`。 |
+| 6.1 取消查询向 VXE `reject` | **维持原策略。** 请求层能识别 CancelToken；用 resolve 空数据会有清空当前表的风险。需在连续快速查询时实机看 loading。 |
+| 粘贴自动保存绕过队列 | **已关闭。** 粘贴、失焦、change 统一进入 `enqueueEditRowAutoSave`，由单 worker 串行消费并按行版本合并。 |
+| 销毁后 Promise 队列保留组件 | **已关闭。** 改为可清空的 map/order worker；自动保存写入和回查共用 CancelToken，删行或销毁时取消当前请求。 |
+
+代码修复阶段完成。下一步是方案 7.1–7.3 专项测试，不是继续改 P0 主逻辑。
+
+### 2.2 复评残留（不阻断专项测试）
+
+1. **树表查询成功后的展开动画代次：已关闭。** 两处 `setTreeExpand` 的 `$nextTick + setTimeout` 均在执行前核对 `queryContext.seq`、`tableQuerySeq` 和 `tableDestroyed`，旧查询不再操作旧行对象。
+2. **`VabUpload2` 动态弹窗实例销毁：已关闭。** `index.js` 已挂 `$destroyOnDialogClose`；`handleClose` 在下一更新周期执行 `$destroy()` 并移除动态根 DOM，与 `VabUpload` / `obsUpload` 行为一致。
+3. **校验失败的自动保存会直接出队。** 这是正确行为（避免死循环），但保存过程中若用户又改了该行，这次增量也会被丢掉，需要再失焦才会排入。可接受。
+
+## 3. 方案落地对照（三次复评后）
+
+| 方案项 | 核心位置 | 落地情况 | 二次复评 |
+| --- | --- | --- | --- |
+| 4.1 查询为空时清理 schema | `initFieldSchemaData` | 已做 | 通过 |
+| 4.2 查询并发控制 | `startTableQuery` / `isCurrentTableQuery` / `finishTableQuery` | PC 主查询、默认视图、H5、树表延迟展开均已做 | 通过 |
+| 4.3 旧行 ref 清理 | `pruneStaleRowRefs` | 已做 | 通过 |
+| 4.4 删除行时释放运行时状态 | `releaseRowRuntime` / `deleteRow` | 已做，普通表已同步 `rowIdData` | 通过 |
+| 4.5 表格销毁清理 | `beforeDestroy` | 已做 | 通过 |
+| 4.6 自动保存队列 | `enqueueEditRowAutoSave` / `runEditAutoSaveWorker` | 粘贴、失焦、change 已统一，支持取消当前自动保存 | 通过 |
+| 4.7 Blob URL 释放 | 下载、导入、打印、表单字段、上传弹窗、聊天附件 | 已补关闭/粘贴/删除路径，三套动态上传弹窗关闭后销毁根实例 | 通过 |
+| 5 KeepAlive | `AppMain.vue` / `keepAlive.js` | 未实施 | 符合方案待确认 |
+| 6 数据量限制 | 列表分页、导入 | 未实施 | 符合方案待确认 |
+
+## 4. 已通过的实现
+
+### 4.1 空查询不再残留上一批 schema
+
+`initFieldSchemaData` 在 `rowLength === 0` 时直接清空 `fieldSchemaMap`，修复原先只在 `rowLength > 0` 时重建、空结果继续占用上一批行 schema 的问题。
+
+```js
+if (rowLength === 0) {
+  this.fieldSchemaMap = {};
+  return;
+}
+```
+
+文件：`src/components/xform/form-render/container-item/data-table-mixin.js`
+
+### 4.2 普通查询有代次和 CancelToken，导出查询独立
+
+- 普通查询开始前取消上一次普通查询。
+- 每次查询生成递增序号，只有当前序号且未销毁的响应可以写入表格。
+- `exportAjax` 通过 `customParam.export` 独立运行，不被普通查询取消。
+
+### 4.3 查询整体替换后兜底清理旧行 ref
+
+`initValue` 每次为行生成新的 `_X_ROW_KEY`，随后调用 `pruneStaleRowRefs`。该方法在 `$nextTick` 中按 `fieldName_rowKey` 精确删除残留引用，并检查 `tableDestroyed`。与方案 4.3 一致：正常生命周期仍负责常规注销，这里只做异常残留兜底。
+
+### 4.4 删行和销毁会释放运行时状态
+
+普通表、编辑表、树表删除行时会释放：
+
+- `fieldSchemaMap[rowKey]`
+- 该行自动保存定时器
+- 该行尚未执行的自动保存任务（`pendingEntry.cancelled = true`）
+- 该行正在执行的自动保存请求（CancelToken）
+
+表格 `beforeDestroy` 会：
+
+- 标记 `tableDestroyed`
+- 取消当前查询
+- 使自动保存任务代次失效
+- 取消当前自动保存并清除定时器、等待 map 和顺序队列
+- 清空 `fieldSchemaMap` 和 `rowIdData`
+- 注销表格引用
+
+### 4.5 自动保存队列主体符合方案
+
+- 同一行短时间连续修改合并为一次任务。
+- 保存执行期间再次修改，完成后按最新 `version` 补存。
+- 粘贴、失焦和 change 共用单 worker，全表不会出现两套自动保存并发。
+- 最多保留 20 个待保存行，超过后提示稍后编辑。
+- 行删除、表格销毁后，相关待执行任务失效。
+- 自动保存写入和保存后回查共用 CancelToken，删行或销毁时会取消；手动保存维持原交互。
+- 等待任务存放在可清空的 map/order 中，不再用 Promise 链为每一行注册闭包。
+
+### 4.6 下载、打印、表单字段附件预览已补释放路径
+
+以下场景已存在对应 `URL.revokeObjectURL`：
+
+- 文件库下载、私有文件下载
+- 表单导入结果下载
+- 打印预览（延迟 60 秒）
+- 二维码文件解析（销毁和替换时释放）
+- 表单字段附件预览（`vabUpload2-widget.vue` 使用 `ownedBlobUrls`，删除、`setValue`、销毁都会释放；组件销毁后才返回的请求会立即释放刚创建的 URL）
+- 普通上传、OBS 上传、VabUpload2 的单文件删除和组件销毁
+
+下载完成后用 `setTimeout(..., 0)` 释放，打印预览延迟 60 秒释放，与方案一致。
+
+## 5. 首次评审的必须修（二次复评：主路径已关闭）
+
+以下为 2026-09-20 首次评审原文，便于对照。二次复评结论见第 2.1 节。
+
+### 5.1 上传弹窗 Blob URL 在会话内不会真正释放
+
+**严重程度：** 高（长稳内存泄漏，直接对应方案 4.7）
+
+**问题：** 方案要求上传预览在文件删除、值替换、组件销毁时释放。当前 `revoke` 主要挂在 `removeFile` 和组件 `beforeDestroy`。
+
+`VabUpload`、`VabUpload2`、`obsUpload` 是全局单例弹窗：`el-dialog` 使用 `v-if` 开关，关闭弹窗不会销毁外层组件，整个浏览器会话内 `beforeDestroy` 都不会走。
+
+因此以下路径会把 `blob:` URL 留在内存里：
+
+| 路径 | 现状 |
+| --- | --- |
+| `handleClose` / `clearFileInfo` | 只把 `fileList` 置空，不 `revoke` |
+| `deletePasteFile` | 直接 `splice`，不 `revoke` |
+| `confirmPasteFile` | `pasteList = []`，不 `revoke` |
+| 关闭弹窗 | 不清 `pasteList`，下次打开继续累积 |
+
+反复打开上传、粘贴图片、关闭弹窗，正是方案要防的“内存只升不降”。
+
+`onlineTalk.deleteFile` 同样只 `splice`。聊天组件通常长期存活，删除附件后预览 URL 要等到组件销毁才释放。
+
+**涉及文件：**
+
+- `src/components/VabUpload/mixins.js`
+- `src/components/VabUpload2/mixins.js`
+- `src/components/obsUpload/mixins.js`
+- `src/components/onlineTalk/mixins.js`
+
+**修复要求：**
+
+1. `handleClose` 先调用 `revokeUploadObjectUrls()`，再清列表、关弹窗。
+2. `deletePasteFile`、`confirmPasteFile` 先 `revoke` 再丢掉引用。
+3. 关闭弹窗时同步清空并释放 `pasteList`。
+4. `onlineTalk.deleteFile` 删除前释放该文件的 Blob URL。
+5. 三套上传组件行为对齐。
+
+### 5.2 查询成功副作用没有带代次，旧结果可能覆盖新数据
+
+**严重程度：** 高（乱序覆盖，直接对应方案 4.2）
+
+**问题：** `done()` 已经用 `isCurrentTableQuery` 挡住过期写入，但随后会 `finishTableQuery`，再异步派发 `emitTableDataLoaded`。这个延迟回调不再检查序号。
+
+```js
+emitTableDataLoaded(rows, tableOption) {
+  this.$nextTick(() => {
+    setTimeout(() => {
+      dataTableConfig.callback && dataTableConfig.callback(rows);
+      tableOption && tableOption.callback && tableOption.callback(rows);
+      this.handleCustomEvent(
+        this.widget.options.formScriptCallback,
+        ["rows"],
+        [rows]
+      );
+    }, 0);
+  });
+}
+```
+
+`tableOption.callback` 会执行 `formModel[fieldKeyName] = rows`。可能时序：
+
+1. 查询 A 完成，`initValue(A)`，安排延迟回调。
+2. 查询 B 完成，`initValue(B)`。
+3. A 的 `setTimeout` 先执行，把模型写回 A。
+
+表格界面可能只闪一下，但 `formScriptCallback` 会按过期 `rows` 再跑一遍，可能补发请求或再次初始化行对象，把 4.2 的并发控制绕开。
+
+这里不能再复用 `isCurrentTableQuery`：成功后 `tableQueryCancelSource` 已被置空，检查会恒为 false。
+
+**涉及文件：** `src/components/xform/form-render/container-item/data-table-mixin.js`
+
+**修复要求：** 派发时捕获当前 `tableQuerySeq`，回调里仅当 `seq === this.tableQuerySeq && !this.tableDestroyed` 时执行副作用。
+
+## 6. 首次评审的建议修（二次复评：6.2–6.4 已关闭，6.1 维持）
+
+### 6.1 取消查询向 VXE Promise `reject`，可能误伤当前表
+
+过期响应和 CancelToken 中断都会把错误 `reject` 给 vxe-table proxy。proxy 通常把这次失败当成当前查询失败：loading 被提前关掉，或弹出取消错误。
+
+更稳妥的做法：`axios.isCancel(error)` 时静默结束，不要当业务失败。
+
+### 6.2 自动保存把 `saveEditRow` 失败当成成功
+
+`runSave` 在 `await this.saveEditRow(...)` 之后无条件推进 `savedVersion`。`saveEditRow` 在行锁占用、校验失败时返回 `false` 且不抛错，循环仍会把当前版本标成已保存并出队。
+
+粘贴自动保存和失焦自动保存共用 `treeSingleSavePending` 时，后一次会被提示“正在保存”，然后被队列当成已保存丢掉。
+
+另外，`saveEditRow` 内部在请求返回后仍会 `$message` 和写表格，没有判断 `tableDestroyed`。方案写明“已销毁组件上不弹错误”，目前只有队列外层 `catch` 守了这一条。
+
+**修复要求：**
+
+- 判断 `saveEditRow` 返回值；`false` 且非校验失败时不要推进 `savedVersion`，或短暂重试。
+- `saveEditRow` 在 `tableDestroyed` 后不要弹错、不要回写表格。
+
+### 6.3 查询并发只覆盖了 PC 主通道
+
+受保护的是 `proxyConfig.ajax.query`。以下路径仍是旧逻辑：
+
+- `loadDefaultViewList`：`loadAccessData` 的回填/刷新，无代次、无取消。
+- `list-h5-item.vue`：H5 列表查询，连续点击仍可能乱序覆盖。
+
+如果 H5 列表和单据内嵌表也在崩溃场景中，P0 的并发控制不完整。
+
+### 6.4 普通表 `deleteRow` 没有同步 `rowIdData`
+
+编辑表 `removeEditRow`、树表 `removeTreeRowsByKeys` 都会 `releaseRowRuntime` 并刷新行键。普通表 `deleteRow` 只释放了 schema、定时器和待保存项，没有调用 `initRowIdData()`。
+
+`rowIdData` 会留下已删行的键。若后续某条路径只调用 `initFieldSchemaData()`、不重建行键，可能给幽灵行再创建一份 schema。
+
+## 7. 不作为缺陷的项
+
+以下与方案一致，或方案已标明待确认，不按漏改处理：
+
+1. 手动保存不由自动保存 worker 取消；其确认和错误处理继续维持原交互。
+2. 自动保存全表串行、最多 20 行，比“同一行不并发”更严，可接受。
+3. 下载用 `setTimeout(..., 0)` 释放、打印预览延迟 60 秒，符合方案。个别浏览器若点击下载后立刻 revoke 失败，再把延迟调到 1 秒即可。
+4. KeepAlive、默认 200/1000 行、导入 10MB/10000 行：方案第 10 节仍待确认，代码未做是预期状态。
+5. 取消查询继续向 VXE `reject`（6.1）：请求层能识别 CancelToken，不能改成 resolve 空数据，否则可能清空当前表。
+
+## 8. 下一步
+
+代码修复阶段完成，优先做方案第 7 节测试，不必再改 P0 主逻辑：
+
+- 7.1 数据表格稳定性：连续查询、空结果、乱序返回、增删行、检查 `fieldSchemaMap` / `refList`；树表连点查询时看展开是否打到错误节点
+- 7.2 自动保存：同行连续改、慢接口、超过 20 行、保存中删行/关页
+- 7.3 Blob URL：反复打开上传弹窗、粘贴预览、删除、确认、关闭，再用 Memory 面板看 Blob 是否回落
+
+树表延迟展开和 `VabUpload2` 实例销毁两处残留均已合入。KeepAlive 和数据量限制仍按方案第 10 节单独确认，不并入本次 P0 收口。
+
+## 9. 验收标准
+
+P0 允许同步正式源仓的前提：
+
+1. 第 5 节两项必须修已合入（二次复评：已合入）。
+2. 第 6 节 6.2、6.3、6.4 已合入；6.1 维持 reject 策略，专项测试确认 loading 可接受。
+3. 方案 7.1–7.3 专项测试通过。
+4. 不从测试工作副本整体覆盖正式源仓，只同步确认后的文件或提交。