/table-test 表格性能报告与修改方向

摘要（TL;DR）

一、测量方法与可信度

1.1 测的是真实页面，不是复刻页

dev 默认账号 demo_zhangwei 没有被授予 menu.table_test 权限，直接访问 /table-test 会被路由守卫送到 /403（web/src/router/index.ts:445-448）。 本报告的测量方式是：在 Playwright 测试进程内拦截 /api/data/loaddata 中 s_power / s_user_power 的响应，补上这一条授权，从而进入真实页面。

该拦截只存在于测量进程，应用代码与后端数据都没有改动。因此本报告的数据包含了真实的 DefaultLayout（侧栏 / 顶栏 / 页签）外壳，而非隔离环境。

1.2 先排除"测量环境造成的假象"

低帧率最容易被怀疑成 headless 无 GPU 的软件光栅化。实测三种渲染路径：

1.3 决定性对照实验：冻结克隆

把现场 .stk-table（1000 行、虚拟滚动开启、529 个 td）整棵子树克隆一份，塞进同样宽高的容器，然后滚克隆。克隆不受 Vue 管理，滚动它不触发任何 JS 重渲染：

A/B/C/D 都在 60 FPS 附近 → 这套 CSS 本身不构成瓶颈。live 与 clone 的唯一差别就是"每帧有没有 JS 重渲染"， 而这个差别值 3~4 倍帧率。这也就是本报告把主线定在"减少每帧重渲染"的依据。

1.4 可信度分级

二、实测数据

2.1 帧率（1000 行，视口 1600×900，表格容器约 1308×656）

滚动期间实测 long task（>50ms）42 个，平均 77.8ms，最大 533ms —— 主线程被成片占满，这就是"FPS 特别低"的直接形态。

2.2 关键发现：代价与总行数无关

用页面自带的「数据量」下拉切换后测量：

• 1000 行与 5000 行帧率几乎相同（11.7 vs 11.3）→ 开销只跟"渲染出的单元格数"和"每帧改动的单元格数"有关。加数据量不是问题，虚拟滚动开着才是。
• 反过来，10 / 100 行因为虚拟滚动关闭、滚动时零 DOM 变更，纵向几乎满帧（60.7 / 58.8）—— 这从另一侧证明了"每帧重渲染"是主因。
• 100 行是一个糟糕的区间：虚拟门控是 >100 才开（G3Table.vue:251），所以 100 行会全量渲染 2300 个 td；纵向还行，横向只有 7.8 FPS（全表 2300 个 td 里含 400 个 sticky 固定列格，横向平移要整片重绘）。这是本报告见到的横向最差值。

2.3 点击进入编辑（关键：慢的只有"第一次"和"换行"）

2.4 编辑提交链路

errorCount 的小数据量标定（同一函数，仅改行数）：

严格线性 → 确认是 O(行数 × 列数)，且完全由行数放大。

2.5 可回收的性能：摘掉 editor 的对照

交替 3 轮（BASE→VAR→BASE→VAR→BASE→VAR）取中位，在页面内存中动态增删 21 个列的 editor 配置：

注意：这一项同时改变了"每格跑不跑 customCell"和"DOM 里有没有那个展示 span"，两者都归因于 editor 特性本身，故仍算作 editor 层的开销； 但它也说明去掉编辑器不是可行的修法（行内编辑是产品能力），只能定向削减这部分开销。

三、根因分析

3.1 因果主线

1. 滚动容器（.stk-table 自身，overflow: auto）触发原生 scroll。
2. 底座的 onTableScroll 用 rAF 节流后调用 updateVirtualScrollY（stk-table-vue/src/StkTable/StkTable.vue:1927-1964），换算出新的 startIndex / endIndex，写回 virtualScroll 这个 shallowRef 并 triggerRef。
3. 该 store 被模板消费 → StkTable 组件整体重渲染：表头 + 可见 25~26 行 × 22 列 ≈ 约 550 个单元格的 vnode 重建与 props / style 重写，另有约 12.8 个节点每帧进出 DOM。
4. 每帧 550 格的内联样式（--cw / min-width / 固定列 left·right）被重写 → 浏览器每帧各做 1 次样式重算与布局（实测 RecalcStyleCount 与 LayoutCount 均约 1 次/帧），随后是大面积重绘。
5. 叠加每格 displayValue 里重复跑的 validate / checkPrecision / formatDisplayValue，单帧落到 60~90ms，即 11~18 FPS。
6. 反证：克隆对照（不重渲染）→ 60 FPS；10/100 行（虚拟关闭、零 DOM 变更）→ 58~60 FPS；行列数越大越慢而总行数无影响 → 全部指向第 3 步。

3.2 根因一：首次点击触发全表列重建（点击卡顿主因）

1. mousedown → 底座选区变化 → handleAreaSelectionChange → activateEditing → editingActive.value = true（G3Table.vue:584-609、G3Table.vue:1255-1257）。
2. displayColumns 依赖 editingActive.value（G3Table.vue:923-925），于是 22 个列全部 map 成新对象。
3. resolveCustomCell 的注入判据里第一项就是 editingActive（utils/column.ts:121-134），因此 text / number / date 这些原本"非编辑态零组件开销"的列，此刻全部被挂上 customCell。
4. 新数组传给底座 props.columns → 引用变化 → 底座 watch 触发 handleDealColumns() + updateMaxRowSpan()，并在 nextTick 里 initVirtualScrollX() + updateFixedShadow() + updateCustomScrollbar()（stk-table-vue/src/StkTable/StkTable.vue:1240-1252）。
5. tableHeaders 更新 → cellStyleMap 重建（StkTable.vue:1433-1464，逐列重算 --cw / min-width / max-width / 固定列样式字符串）→ 全表重渲染 + 编辑器挂载 + 焦点恢复。

实测代价：394ms、966 次 tbody 节点变更。 注意这是每次页面加载只发生一次的成本；此后 editingActive 恒为 true，不再重建列 —— 这也解释了为什么"再点同一格"只要 0.6ms。

3.3 根因二：行级编辑态让整行挂编辑器（换行点击卡顿主因）

1. 行编辑状态是行级的：activateEditing 把整行标记为 editing，并在 WeakMap 里存 focusCol（G3Table.vue:439-483、G3Table.vue:584-609）。
2. createEditableCell 里只有 date 类型是"只给当前格挂编辑器"，其余类型（text / number）在行编辑态下整行都挂（utils/editable.ts:1177-1204）。
3. 于是换行点击 = 旧行约 17 个编辑器卸载 + 新行约 17 个挂载 → 70~72 次节点变更、94~187ms。

代码里已注明 date 必须"只挂当前格"的理由（切换格要重新挂载才能弹出日历面板，utils/editable.ts:1187-1201）。把同一策略推广到 text / number 是降低换行成本最直接的方向，但要一并处理键盘导航、Tab 跳格与焦点恢复这几条依赖"整行已挂载"的链路，见 §4.3 的取舍分析。

3.4 根因三：页面级 errorCount 全表校验（提交卡顿）

web/src/views/table-test/index.vue:615-625 的 errorCount 是 computed，遍历全部行 × 全部列，每格调用 validateCell（内含业务 validate + checkPrecision）。 由于 rows 是深层响应式 ref，任何行字段写入都会让它失效重算；而编辑提交（Enter / 失焦 / checkbox）恰恰就是写行字段。

这个 computed 的唯一消费者是工具栏那个「N 处待修正」徽章（index.vue:659-662）。 为了一次徽章更新，每次提交都要全表校验一遍 —— 1000 行 31~69ms、5000 行 215~434ms，是纯浪费。 另外 findFirstError（index.vue:535-551）在保存时已经独立跑了一遍同样的全表校验，两者重复。

3.5 根因四：每格重复求值 + 每格分配一个 computed

displayValue（utils/editable.ts:369-454）是常驻 customCell 在非编辑态的实际渲染函数， 它每次调用都会：跑业务 validate、跑 checkPrecision、跑 formatDisplayValue、构造 class 数组与 data 属性。 代码注释里明确写了不做任何缓存（utils/editable.ts:205-207），理由是避免"数据改了红底还在"的脏状态 —— 这个取舍在语义上是对的，但代价是每一帧、每一个可见格都重算一遍。

另外有一处纯浪费：每渲染一格就分配一个 computed。

// packages/ui/src/table/utils/editable.ts:375  —— 在 displayValue 函数体内
function displayValue(ctx, row, col, editor) {
  const { e, is } = useNamespace('table')   // ← 每次调用都新建一个 computed
  ...

// packages/ui/src/_composables/useNamespace.ts:46
const ns = computed(() => injected?.namespace.value ?? getGlobalConfig().namespace ?? COMPILE_TIME_NAMESPACE)

同样的写法还在 utils/editable.ts:717（createInput）与 utils/precision.ts:114（createFormatCell）。 按约 550 个可见格、每帧全部重渲染估算，每帧会新建数百个 computed 实例及其闭包； Trace 里 V8.GC_* 事件合计约占 4% 采样，与这个分配量吻合。

3.6 根因五：固定列 sticky 与横向滚动（待确认）

横向滚动单独测的一组数字：

同时抓到了固定列 class 的翻转序列：fixed-cell--active fixed-cell fixed-cell--left ↔ fixed-cell fixed-cell--left，来源是底座的 updateFixedShadow （stk-table-vue/src/StkTable/useFixedCol.ts:92-165），它按滚动位置重算 fixedCols → fixedColClassMap → 所有固定列 td 的 class 重新 patch。

另外，该 sticky 补丁本身是为了修"冻结列横滚抖动"而加的（packages/ui/src/table/style/_overrides.scss:416-477， 根因是底座只把 position: sticky 挂在滚动位置算出来的 --active 类上）。 所以"关掉补丁"不是可选修法，只能找等价但更省的实现。

3.7 根因六：次要项

• 无条件给 tbody 提升合成层：G3Table.vue:1936-1940 给 .stk-tbody-main 挂了 will-change: transform，注释写明是"transform 虚拟滚动模式"用的； 而底座只在 transform 模式（.exp-scroll-y）下才加（stk-table-vue/src/StkTable/style.less:392-396）。 本页 scrollbar=false、走原生滚动，这层提升属于白付成本（库在容器上另有 will-change: scroll-position，style.less:81）。
• 29 处 :has() 规则（G3Table.vue 内，用于从内容节点反查 td 的编辑/校验/只读态）。 :has() 在样式重算时需要做子树匹配，是每帧样式重算的放大器之一；但克隆对照证明它单独不构成瓶颈，属次要项。
• 固定列内阴影用 inset 0 0 0 100vmax 叠行状态色（style/_overrides.scss:497、509、540）。 这是为了在不覆盖库的 background-image 边框的前提下叠色，代价是每格一个巨大的内阴影；同样属次要项。

四、修改方向

按「收益 / 风险」排序。P0 = 建议先做，P1 = 值得做但需配套验证，P2 = 顺手清理。

五、如何验证（可复现）

本次排查新增了一批只读探针脚本，都放在 g3soft-libs/packages/ui/ 下，需要时可直接重跑（前置：后端 8088、前端 dev server 5090 已启动）：

建议的回归验证口径（修完后对照本报告基线的数值）：

1. 静止 61 FPS、纵向 12~18 FPS、横向 18~32 FPS、编辑态 8~11 FPS；
2. 首次点击 394ms / 966 次 DOM 变更；换行点击 94~187ms；同格点击 0.6ms；
3. errorCount 重算 1000 行 31~69ms、5000 行 215~434ms；保存端到端 318ms / 612ms；
4. 摘掉 editor 的对照值 25.2 FPS（纵向）/ 43.3 FPS（横向）—— 修完后应显著接近这组数，而不是被它反超。

提示：直接访问 /table-test 会因缺 menu.table_test 授权被送到 /403。 要么用探针脚本里的权限响应拦截，要么给 demo_zhangwei 补一条授权（sql/20_registration/13_table_test_menu.sql）。

六、本次没做的事 / 已知不确定

• 没有改动任何业务代码或组件库代码。所有实验都在浏览器内存里或测试进程内完成（例如临时增删列上的 editor、注入 <style> 覆盖 CSS、拦截 API 响应补权限），仓库源码为零改动。
• 生产构建 vs dev 模式的对照没做完。构建已成功（vite build），但在准备用 preview 测量时中止。预计 dev 模式（未压缩、无 tree-shaking）会比生产更慢，但这不足以解释 3~4 倍差距 —— 冻结克隆实验已经在同一 dev 环境下拿到 60 FPS。若需要精确数字，可重跑 probe-table-prod.mjs。
• 横向滚动与固定列 sticky 的因果未完全坐实（§3.6）。22.9 → 44~49 FPS 的差值很可能是真的，但对干净度不够，建议按 P1-4 重测后再据此决策。
• 单帧内 JS / 样式 / 布局 / 绘制的精确占比没有定论。CDP Performance 计数器、DevTools Trace 叶子事件汇总、LoAF 三种口径互相不完全吻合；LoAF 把可归因的脚本时间几乎全部指向底座一个 rAF 回调（StkTable.js，sourceCharPosition≈90337），由于是打包产物、函数名为空，该偏移只能作为线索，不能当作精确行号。本报告因此只使用那些"方向明确、且被对照实验支撑"的结论。
• 没有验证"优化后"的实际收益。§4 给出的是方向与预期量级，其中 P0-1 的量级最确定（直接对应实测的 31~434ms），P0-2 的 (c) 方案需要先做实验才能下结论。