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

package/src/components/xform/docs//346/265/217/350/247/210/345/231/250/345/264/251/346/272/203/346/262/273/347/220/206/344/270/216/344/277/256/345/244/215/350/220/275/345/234/260/346/226/271/346/241/210.md

@@ -0,0 +1,324 @@
+# 浏览器崩溃治理与修复落地方案
+
+## 1. 文档信息
+
+- 编制日期：2026-09-20
+- 当前实施仓库（测试源仓）：`D:\develop\code\company\2024\dev\sf-cloud-web-com-dev@publish_dev`
+- 正式源仓：`D:\develop\code\company\2024\dev\sf-cloud-web-com@publish`
+- 发布删减版：`E:\develop\code\comapny\2026\sf-cloud-web-vue-tw\@wjlfw\_zs`
+- 当前状态：P0 数据表格、自动保存队列和 Blob URL 释放已在测试源仓实施；KeepAlive 治理待确认后实施；正式源仓尚未同步。
+
+## 2. 问题结论
+
+浏览器崩溃不是单一原因造成，主要风险是页面长期运行后，多个运行时对象叠加并持续占用内存：
+
+1. 数据表格多次查询后，旧行 schema、组件引用或异步响应未及时失效。
+2. 用户连续点击查询时，并发请求乱序返回，旧数据可能覆盖新数据并重复创建行级对象。
+3. 编辑表自动保存请求重复进入队列，慢接口情况下形成任务积压。
+4. 下载、导入结果、打印和上传预览创建的 Blob URL 未释放。
+5. KeepAlive 长期保留多个重型页面，导致表格、表单、图表、事件和定时器一直存活。
+6. 超大查询、导入、导出或图片预览在短时间内形成内存峰值。
+
+删减页面只能减少初始路由和静态资源，能够降低基础占用，但不能解决运行期间的引用残留、并发请求、任务队列、Blob URL 和 KeepAlive 实例累积。因此删减版只能缓解，不能作为浏览器崩溃的根本修复手段。
+
+## 3. 数据表格对象关系
+
+### 3.1 fieldSchemaMap
+
+`fieldSchemaMap` 保存每一行独立的字段 schema。schema 是字段组件的配置和运行时状态描述，不是 Vue 组件实例。
+
+```js
+fieldSchemaMap = {
+  row_001: {
+    input_product_name: productNameSchema,
+    input_amount: amountSchema,
+  },
+  row_002: {
+    input_product_name: productNameSchema2,
+    input_amount: amountSchema2,
+  },
+};
+```
+
+### 3.2 refList
+
+`refList` 保存已经挂载的 Vue 字段组件实例，推荐键格式为：
+
+```js
+refList = {
+  input_product_name_row_001: productNameComponent,
+  input_amount_row_001: amountComponent,
+};
+```
+
+行键使用 `_X_ROW_KEY`。schema 与 ref 使用相同行键建立对应关系，但二者不能合并：
+
+- `fieldSchemaMap[rowKey][fieldName]`：字段配置和状态。
+- `refList[fieldName + "_" + rowKey]`：已经挂载的组件实例。
+
+虚拟滚动时，单元格组件可能销毁后重新创建，因此单个单元格销毁时只注销 ref，不能立即删除整行 schema。只有在行被真正删除、查询整体替换数据或整张表销毁时，才清理对应 schema。
+
+## 4. 已实施的 P0 修复
+
+核心文件：`src/components/xform/form-render/container-item/data-table-mixin.js`
+
+### 4.1 查询为空时清理 schema
+
+查询或赋值结果为空时立即执行：
+
+```js
+if (rowLength === 0) {
+  this.fieldSchemaMap = {};
+  return;
+}
+```
+
+修复原先 `rowLength > 0` 才重建、空结果继续保留上一批 schema 的问题。
+
+VXE 在查询 Promise 完成前仍可能短暂渲染旧行，并把刚清空的 schema 懒建回来。因此查询换批后还会在组件更新及下一宏任务中，按当前有效行键再次清理旧行 schema 和 ref，覆盖空结果及换页的卸载时间窗。ref 清理只遍历实际存在的引用一次；schema 采用一次性压缩替换，避免“旧行数 × 组件列数”组合扫描和逐条响应式删除造成查询后卡顿。
+
+### 4.2 查询并发控制
+
+- 普通查询开始前取消上一次普通查询。
+- 每次查询生成递增序号。
+- 只有当前序号的响应可以写入表格。
+- 组件销毁后到达的响应不再处理。
+- 导出查询独立运行，不被普通查询取消。
+
+这样可以防止连续点击查询时旧响应覆盖新响应，以及同一批数据被重复初始化。
+
+### 4.3 旧行 ref 清理
+
+查询整体替换数据后：
+
+1. 记录查询前的 `_X_ROW_KEY`。
+2. 对比查询后的有效行键。
+3. 在组件更新完成后，精确删除旧行对应的 `fieldName_rowKey` 引用。
+4. 正常组件生命周期仍负责常规注销，该逻辑只作为异常残留兜底。
+
+### 4.4 删除行时释放运行时状态
+
+普通表、编辑表和树表删除行时统一释放：
+
+- `fieldSchemaMap[rowKey]`；
+- 该行自动保存定时器；
+- 该行尚未执行的自动保存任务。
+
+行组件销毁时继续由字段组件注销自身 ref。
+
+### 4.5 表格销毁清理
+
+表格 `beforeDestroy` 中执行：
+
+- 标记表格已经销毁；
+- 取消当前查询；
+- 使自动保存任务代次失效；
+- 清除自动保存定时器和等待项；
+- 清空 `fieldSchemaMap`；
+- 清空行键数据；
+- 注销表格引用。
+
+### 4.6 自动保存队列
+
+自动保存采用串行队列，规则如下：
+
+- 同一行短时间连续修改合并为一次任务。
+- 保存请求执行期间再次修改，前一次完成后补存最新版本。
+- 粘贴、失焦和 change 触发统一进入同一个串行 worker，不再存在两套自动保存并发竞争。
+- 不允许同一行无限并发保存。
+- 最多保留 20 个待保存行，超过后提示用户稍后编辑。
+- 行删除、表格销毁后，相关待执行任务失效。
+- 自动保存的写入请求和保存后回查共用 CancelToken；行删除或表格销毁时会取消当前自动保存。手动保存仍按原交互执行，不纳入自动保存 worker。
+- worker 每次只持有当前行，等待行保存在可清空的 map/order 中；销毁时不会留下整条 Promise 回调链引用组件和行对象。
+
+### 4.7 Blob URL 释放
+
+以下场景已补充 `URL.revokeObjectURL`：
+
+- 文件库下载；
+- 私有文件下载；
+- 表单导入结果下载；
+- 打印预览；
+- 二维码文件解析；
+- 聊天附件；
+- 普通上传、OBS 上传及 VabUpload2 上传预览；
+- 表单字段附件预览。
+
+下载完成后释放；打印预览延迟 60 秒释放；上传预览在文件删除、值替换、组件销毁时释放。异步请求在组件销毁后才返回时，立即释放刚创建的 URL。
+
+## 5. KeepAlive 治理方案
+
+### 5.1 当前问题
+
+项目使用自定义 `BaseKeepAlive`，内部已经支持 `max`，但 `AppMain.vue` 未传入该参数，实际缓存实例没有上限。
+
+KeepAlive 页面切换时只触发 `deactivated`，不会触发 `beforeDestroy`。因此数据表格、行 schema、表单数据、图表、定时器、事件监听和请求可能一直保留。
+
+### 5.2 不允许只增加 max
+
+直接设置 `max=8` 会按最久未访问顺序销毁页面。如果最老页面是未保存的编辑表单，用户数据会静默丢失。
+
+因此 `max` 必须和未保存状态保护一起实施。
+
+### 5.3 推荐策略
+
+| 项目 | 推荐值或规则 |
+| --- | --- |
+| 普通页面最大实际缓存实例 | 8 |
+| outLink 最大实例 | 3 |
+| 当前页面 | 不淘汰 |
+| 未保存表单 | 不自动淘汰 |
+| 正在上传、导入或自动保存 | 不自动淘汰 |
+| 大报表、文件预览 | 默认不缓存 |
+| 全部实例均受保护 | 临时允许超过上限并记录告警 |
+
+### 5.4 dirty 状态管理
+
+在 `tagsView` 中按 `viewKey` 保存页面状态：
+
+```js
+dirtyViews = {
+  "/form/edit?id=001": true,
+};
+```
+
+提供以下动作：
+
+- `markViewDirty(view)`：字段第一次修改时调用。
+- `markViewSaved(view)`：保存成功后调用。
+- `clearViewDirty(view)`：确认放弃修改并关闭时调用。
+
+不建议深度监听整个大表单。应复用字段 change、表格编辑、附件修改等已有事件，在第一次变化时标记 dirty。
+
+### 5.5 安全 LRU
+
+修改 `src/utils/keepAlive.js`，淘汰候选必须满足：
+
+```text
+不是当前页面
+且不在 protectedKeys
+且不是正在执行关键任务的页面
+```
+
+从符合条件的页面中选择最久未访问的实例销毁。如果没有候选，则本次不淘汰。
+
+页签数量与实际实例数量分离：页签仍可保留；被淘汰页面再次点击时重新创建。
+
+### 5.6 关闭页签保护
+
+以下操作都必须检查 dirty 状态：
+
+- 关闭当前；
+- 关闭其他；
+- 关闭全部；
+- 退出登录；
+- 路由跳转到不再保留当前表单的流程。
+
+显式关闭时可以弹出“内容尚未保存，是否放弃修改”。自动 LRU 淘汰不能弹异步确认，只能跳过受保护页面。
+
+### 5.7 activated/deactivated 规范
+
+重型缓存页面在 `deactivated` 时应暂停：
+
+- 轮询和刷新定时器；
+- 只服务于当前页面的查询；
+- window/document 事件；
+- 图表动画、视频；
+- 临时弹层和非必要后台计算。
+
+在 `activated` 时恢复必要监听，并根据路由参数或数据时间决定是否刷新。
+
+`deactivated` 时不能清空表单数据、行 schema 和未保存编辑状态；这些对象只能在真正关闭或淘汰触发的 `beforeDestroy` 中清理。
+
+### 5.8 outLink 和微应用
+
+`outLink` 使用 `v-for + v-show` 保存实例，不受 `BaseKeepAlive max` 控制，需要单独实现最多 3 个实例的 LRU。
+
+qiankun 微应用也不受主应用 KeepAlive 直接控制，需要通过微应用的停用、卸载和资源清理接口治理。
+
+## 6. 建议的数据量限制
+
+以下参数尚未实施，需要业务确认：
+
+| 场景 | 推荐初始限制 |
+| --- | --- |
+| 普通列表默认每页 | 200 行 |
+| 普通查询单次硬上限 | 1000 行 |
+| 前端导入文件 | 10 MB |
+| 前端同步解析行数 | 10000 行 |
+| 更大导入 | 后端异步任务 |
+| 大数据导出 | 后端或分页导出 |
+
+限制值应允许按具体业务配置，但必须保留系统级硬上限，避免脚本或配置错误造成单次内存峰值。
+
+## 7. 测试方案
+
+### 7.1 数据表格稳定性
+
+1. 同一列表连续点击查询 100 次。
+2. 交替查询有数据和空结果。
+3. 快速切换查询条件，模拟前一个请求比后一个请求更晚返回。
+4. 重复新增、删除普通行、编辑行和树表行。
+5. 检查 `fieldSchemaMap` 键数量是否和当前有效行一致。
+6. 检查 `refList` 是否不存在已经删除或查询替换掉的行键。
+
+### 7.2 自动保存
+
+1. 同一行连续编辑多个字段。
+2. 保存接口延迟情况下继续编辑同一行。
+3. 粘贴后立即失焦或继续修改同一行，确认始终只有一个保存请求在执行，且最终版本会补存。
+4. 同时编辑 20 行以上，确认系统不会无限创建请求。
+5. 保存过程中删除该行，确认当前请求被取消且不再回写。
+6. 保存过程中关闭表格页签，确认当前请求被取消且等待队列释放。
+
+### 7.3 Blob URL
+
+反复执行上传预览、删除、替换、下载、导入结果下载和打印预览，使用浏览器 Memory 面板确认 Blob 数量能够回落。
+
+### 7.4 KeepAlive
+
+实施后需要验证：
+
+1. 连续打开 20 个普通页面，实际缓存实例不超过 8。
+2. 页签仍保留，被淘汰页面可以重新创建。
+3. 未保存表单不会被自动淘汰。
+4. 关闭未保存页签会提示。
+5. “关闭其他”和“关闭全部”不会跳过保护逻辑。
+6. outLink 实例不超过 3。
+7. 页面切走后轮询、定时器和事件监听停止。
+
+### 7.5 浏览器长稳测试
+
+建议进行不少于 2 小时的综合操作：查询、切菜单、编辑、上传、下载和导入循环执行。记录：
+
+- Chrome 任务管理器内存；
+- DevTools Performance Monitor 的 JS heap、DOM nodes、event listeners；
+- Memory Heap Snapshot 中组件实例、Blob、闭包和 detached DOM 数量；
+- 是否存在内存只上升、不回落的趋势。
+
+## 8. 发布步骤
+
+1. 在测试源仓完成 P0 构建和专项测试。
+2. 实施并验证 KeepAlive 治理。
+3. 完成长稳测试和业务回归。
+4. 将确认后的修改同步到正式源仓。
+5. 使用正式源仓最新代码执行 JKS 发布流程。
+6. 将构建产物发布到删减版环境。
+7. 观察生产环境浏览器内存和崩溃反馈，保留快速回退版本。
+
+不建议直接从测试工作副本整体覆盖正式源仓，应按确认后的文件或提交同步，避免夹带测试源仓中已有的无关修改。
+
+## 9. 当前验证结果
+
+- 修改文件 JavaScript 静态解析通过。
+- 测试源仓生产构建通过。
+- 最新构建 Hash：`a1b3d085c11a9f2d`。
+- 全仓 `createObjectURL` 文件扫描均已存在对应释放路径。
+- 正式源仓和发布删减版尚未修改。
+
+## 10. 待确认事项
+
+1. KeepAlive 是否按“普通页面 8 个、outLink 3 个、dirty 页面保护”的推荐方案实施。
+2. 普通查询是否采用“默认 200 行、单次最多 1000 行”。
+3. 导入是否采用“10 MB、10000 行”的默认限制。
+4. 测试环境专项和长稳测试通过后，是否同步到正式源仓。