Vue Lynx 统一基准矩阵

同一量纲下看 IFR × VDOM/Vapor × ReactLynx。上方是结论（好消化）；下方表格与曲线用来核对数据。中位数延迟；(n.nn) = 相对该行最优的慢速倍数。生成于 2026-07-28 · git 346eccf · 4× Intel(R) Xeon(R) Processor @ 2.80GHz.

环境：lynx-web（主）阶梯：1k → 30k 数据格：764 结论：8 Engine cells：本环境 N/A（Lynx for Web 无引擎 ET PAPI），已从全部表格与图表省略

结论

标题是 takeaway；含义怎么用；核对是数字。勿跨环境比毫秒。

Vapor 点状更新 ~8.3×

含义 Select = 点状更新。交互密集列表默认 Vapor；单次点击常贴帧地板。

核对 selectStorm@10k 984→119 ms · vs RL ~22× · BG ~9.8×

ReactLynx 创建更快 ~1.05×

含义 Snapshot 擅长一次铺开大量节点。创建 ≠ 更新。

核对 create@10k RL 1659 · VDOM 1736 · Vapor 1732 ms

ReactLynx 首帧最低

含义同密度探针上 RL 最快。Vue 追首帧 → vdom +b +ifr。

核对 FCP@10k RL 241 · +b +ifr 373 · vdom 基线 452 ms

别用 +ifr 不带 +b

含义 “−19%”不是常数。中大树 vdom +ifr（无 +b）会变慢；默认 vdom +b +ifr。

核对 vs off：1k -21% · 10k +33%

+b 也加速更新 ~2%

含义模板 clone 挂载后仍有用。+ifr（无 +b）≈ 基线。

核对 selectStorm@10k 基线 984 · +ifr 995 · +b +ifr 968 ms

Vapor 稀疏命名 ×1 FCP -20%

含义 A2 稳态稀疏有同机 ×1 收益；×4 未成 hedge。Native ET 仍是大头。

核对 dense 152.9 → sparse 121.8 ms · ×4 +12%

创建→RL · 更新→Vapor · Vue 首帧→vdom +b +ifr

含义 Select=点状，Update=批量。产品选择压成这一句。

核对见下方表；跨表勿用毫秒互除。

报比率，别报绝对 ms

含义换机器中位数可差 2×+。只带同机比率。

核对例：旧机 React selectStorm@10k ≈2544 ms；本机 ≈2632 ms。

交互 Storms — IFR × 框架矩阵

黑盒协议：真实点击 → 合成 DOM 终态。单机全量测量（四轴全排列 + ReactLynx × 1k/10k/30k 一次跑完；同 key 以最新单机跑为准）。Select = 点状更新（每次只动选中态/少量 class）；Update = 批量更新（每轮改很多行）。ReactLynx (memo) = Snapshot + IFR（始终开启）+ 手动 memo/useCallback。

场景	vdom（基线）	vdom +b	vdom +ifr	vdom +b +ifr	vapor（基线）	vapor +b（默认）	vapor +b!（bundle 交付）	vapor +b:c（code 档）	vapor +ifr	vapor +b +ifr（默认+ifr）	rl（Snapshot+IFR+memo）
创建 · 1k 行	202.3 ms(1.13)	201.9 ms(1.13)	199.7 ms(1.12)	217.0 ms(1.21)	190.8 ms(1.07)	213.5 ms(1.19)	201.2 ms(1.12)	196.8 ms(1.10)	210.3 ms(1.18)	201.9 ms(1.13)	178.9 ms(1.00)
update storm ×50 · 1k	127.4 ms(2.06)	126.1 ms(2.04)	124.6 ms(2.02)	132.6 ms(2.15)	66.5 ms(1.08)	67.4 ms(1.09)	66.4 ms(1.08)	61.7 ms(1.00)	68.3 ms(1.11)	68.8 ms(1.12)	579.0 ms(9.38)
select storm ×30 · 1k	70.9 ms(5.37)	64.6 ms(4.89)	67.5 ms(5.12)	65.1 ms(4.94)	19.5 ms(1.48)	20.5 ms(1.56)	20.1 ms(1.52)	13.2 ms(1.00)	13.8 ms(1.05)	19.2 ms(1.45)	225.5 ms(17.08)
创建 · 10k 行	1.74 s(1.09)	1.60 s(1.00)	1.66 s(1.04)	1.68 s(1.05)	1.65 s(1.03)	1.73 s(1.08)	1.77 s(1.11)	1.76 s(1.10)	1.65 s(1.03)	1.73 s(1.08)	1.66 s(1.04)
每 10 行更新 · 10k	114.8 ms(1.31)	115.4 ms(1.32)	117.1 ms(1.34)	117.2 ms(1.34)	91.6 ms(1.05)	88.8 ms(1.02)	87.4 ms(1.00)	95.1 ms(1.09)	89.6 ms(1.03)	95.3 ms(1.09)	265.3 ms(3.04)
选中一行 · 10k	79.5 ms(1.64)	77.7 ms(1.61)	81.7 ms(1.69)	81.1 ms(1.68)	57.8 ms(1.20)	66.7 ms(1.38)	72.9 ms(1.51)	57.7 ms(1.19)	48.4 ms(1.00)	56.9 ms(1.18)	155.2 ms(3.21)
update storm ×50 · 10k	1.86 s(2.66)	1.94 s(2.78)	1.97 s(2.82)	1.89 s(2.71)	729.8 ms(1.04)	887.6 ms(1.27)	918.2 ms(1.31)	759.7 ms(1.09)	699.6 ms(1.00)	740.5 ms(1.06)	6.04 s(8.64)
select storm ×30 · 10k	984.1 ms(10.59)	1.04 s(11.19)	994.6 ms(10.70)	967.9 ms(10.41)	106.0 ms(1.14)	118.6 ms(1.28)	106.8 ms(1.15)	115.7 ms(1.24)	92.9 ms(1.00)	124.7 ms(1.34)	2.63 s(28.32)
创建 · 30k 行	5.28 s(1.13)	4.85 s(1.04)	4.83 s(1.04)	5.40 s(1.16)	5.13 s(1.10)	5.36 s(1.15)	5.05 s(1.08)	5.04 s(1.08)	5.13 s(1.10)	5.18 s(1.11)	4.66 s(1.00)
update storm ×50 · 30k	10.9 s(1.79)	7.21 s(1.18)	7.34 s(1.20)	7.51 s(1.23)	6.74 s(1.10)	7.22 s(1.18)	6.11 s(1.00)	7.29 s(1.19)	6.33 s(1.03)	7.07 s(1.16)	21.2 s(3.46)
select storm ×30 · 30k	3.57 s(12.97)	3.23 s(11.73)	3.33 s(12.10)	3.17 s(11.53)	306.1 ms(1.11)	275.2 ms(1.00)	332.6 ms(1.21)	309.7 ms(1.13)	322.3 ms(1.17)	362.9 ms(1.32)	10.3 s(37.29)
慢速几何平均	2.48	2.32	2.35	2.38	1.12	1.19	1.18	1.11	1.06	1.18	5.02

≤ 1.15× ≤ 2.5× ≤ 10× > 10×

Storm 随规模变化（1k → 30k）

线性坐标、零基线——看绝对差距，不是对数压缩后的形状。Select 曲线看点状更新；Update 曲线看批量吞吐。

Select storm（点状）vs 行数

点状更新：30 次连续选中的总墙钟。每次 tick 只改选中态。vapor 全家几乎压平；ReactLynx 陡升；vdom +b +ifr 把 vdom 往下拉。

拖框放大区域 · 滚轮缩放 · 双击复位 · hover 高亮

Update storm（批量）vs 行数

批量更新：50 轮全表/多行更新的总墙钟。创建另算——这里只看持续批量吞吐。

拖框放大区域 · 滚轮缩放 · 双击复位 · hover 高亮

Create vs 行数

ReactLynx 创建仍领先。vdom +b +ifr 靠模板 clone 略微帮助创建。

拖框放大区域 · 滚轮缩放 · 双击复位 · hover 高亮

Select storm — 对数轴（全部）

线性轴上 Vapor 家族全被压在底部；对数轴让三个数量级都能读。

拖框放大区域 · 滚轮缩放 · 双击复位 · hover 高亮

Select storm — 仅 Vapor（放大）

只画 Vapor 各变体、独立纵轴，看清基线 / +b / +ifr / +b +ifr 之间的差异（V4 记法）。

拖框放大区域 · 滚轮缩放 · 双击复位 · hover 高亮

首帧 FCP — 架构阶梯

相同卡片密度（约 1k→30k 元素）：全部四轴排列 + ReactLynx Snapshot+IFR，单机一次跑完（sfc-probe 规模阶梯）。这是首帧量纲，不能和上面的 storm 毫秒直接比。下表 CPU ×1，全部 cells 覆盖 1k→30k（×4 覆盖到 10k）。

规模	vdom（基线）	vdom +b	vdom +ifr	vdom +b +ifr	vapor（基线）	vapor +b（默认）	vapor +b!（bundle 交付）	vapor +b:c（code 档）	vapor +ifr	vapor +b +ifr（默认+ifr）	vapor +b +ifr:c	rl
1k 元素	128.3 ms(1.73)	114.3 ms(1.54)	101.6 ms(1.37)	98.1 ms(1.33)	160.6 ms(2.17)	173.6 ms(2.35)	163.6 ms(2.21)	168.8 ms(2.28)	152.9 ms(2.07)	144.8 ms(1.96)	157.2 ms(2.12)	74.0 ms(1.00)
3k 元素	204.9 ms(1.86)	212.5 ms(1.93)	177.4 ms(1.61)	160.8 ms(1.46)	255.2 ms(2.32)	268.8 ms(2.45)	312.5 ms(2.84)	290.5 ms(2.64)	235.7 ms(2.14)	232.8 ms(2.12)	260.4 ms(2.37)	109.9 ms(1.00)
5k 元素	258.5 ms(1.70)	258.4 ms(1.70)	252.1 ms(1.65)	221.0 ms(1.45)	378.7 ms(2.48)	379.5 ms(2.49)	388.3 ms(2.55)	411.8 ms(2.70)	345.1 ms(2.26)	345.6 ms(2.27)	347.0 ms(2.28)	152.4 ms(1.00)
10k 元素	452.1 ms(1.87)	472.8 ms(1.96)	601.6 ms(2.49)	372.8 ms(1.54)	644.0 ms(2.67)	626.4 ms(2.60)	727.8 ms(3.02)	712.6 ms(2.95)	583.1 ms(2.42)	576.7 ms(2.39)	624.2 ms(2.59)	241.3 ms(1.00)
20k 元素	839.0 ms(1.83)	829.1 ms(1.81)	1.05 s(2.29)	708.2 ms(1.55)	1.21 s(2.65)	1.15 s(2.52)	1.26 s(2.76)	1.33 s(2.90)	1.11 s(2.42)	1.06 s(2.30)	1.16 s(2.52)	458.0 ms(1.00)
30k 元素	1.17 s(1.67)	1.21 s(1.72)	1.51 s(2.16)	1.59 s(2.26)	1.80 s(2.56)	1.73 s(2.47)	1.78 s(2.53)	2.02 s(2.88)	1.54 s(2.19)	1.66 s(2.36)	1.60 s(2.28)	702.2 ms(1.00)

CPU ×4（同矩阵，阶梯截到 10k——×4 侧只有到 10k 的完整覆盖）。

规模	vdom（基线）	vdom +b	vdom +ifr	vdom +b +ifr	vapor（基线）	vapor +b（默认）	vapor +b!（bundle 交付）	vapor +b:c（code 档）	vapor +ifr	vapor +b +ifr（默认+ifr）	vapor +b +ifr:c	rl
1k 元素	582.3 ms(1.26)	510.6 ms(1.10)	649.4 ms(1.41)	516.3 ms(1.12)	503.4 ms(1.09)	498.2 ms(1.08)	547.3 ms(1.18)	501.6 ms(1.09)	596.0 ms(1.29)	564.4 ms(1.22)	530.6 ms(1.15)	462.2 ms(1.00)
3k 元素	1.22 s(1.60)	1.01 s(1.32)	1.13 s(1.47)	926.8 ms(1.21)	923.9 ms(1.20)	837.9 ms(1.09)	973.9 ms(1.27)	944.6 ms(1.23)	1.07 s(1.40)	1.04 s(1.36)	1.14 s(1.49)	766.9 ms(1.00)
5k 元素	1.62 s(1.39)	1.42 s(1.22)	1.51 s(1.30)	1.33 s(1.15)	1.42 s(1.22)	1.26 s(1.08)	1.27 s(1.09)	1.35 s(1.16)	1.55 s(1.33)	1.49 s(1.28)	1.58 s(1.35)	1.17 s(1.00)
10k 元素	2.90 s(1.47)	2.47 s(1.25)	3.24 s(1.64)	2.36 s(1.20)	2.52 s(1.27)	2.42 s(1.22)	2.29 s(1.16)	2.32 s(1.18)	2.63 s(1.33)	2.56 s(1.29)	2.76 s(1.39)	1.98 s(1.00)

FCP vs 内容规模（CPU ×1）

ReactLynx 全程最低。Vue 侧：vdom +ifr（无 +b）在 10k 越过 vdom 基线；vdom +b +ifr 是规模对冲。

拖框放大区域 · 滚轮缩放 · 双击复位 · hover 高亮

FCP vs 内容规模（CPU ×4，至 10k）

阶梯截到 10k（×4 完整覆盖范围）。慢 CPU 放大 MT 包体解析成本。

拖框放大区域 · 滚轮缩放 · 双击复位 · hover 高亮

Graph-eng 命名单位 — node（Named Tree）vs block（Tree-Template）

同款 sfc-probe（~1004 元素）：仅切换 enableSparseNaming。Native ET 仍 stub；稀疏仍全量建 native 树。详见 ifr-bench/GRAPH-ENG-MATRIX.md。

场景	naming	web gzip	FCP ×1	Δ	FCP ×4	Δ
vapor +ifr `vapor-ifr-dense`	dense	89,720	152.9 ms	+0.0%	596.0 ms	+0.0%
vapor +b +ifr（alias） `vapor-ifr-sparse`	sparse	90,007	121.8 ms	-20.3%	670.2 ms	+12.4%
vapor +b +ifr（默认+ifr） `vapor-ifr`	sparse	90,007	144.8 ms	-5.3%	564.4 ms	-5.3%

优化 flag 矩阵 — 全排列 create/update 与因子归因

统一 table app（真实点击、双线程），全部合法优化组合（cell 名 = 基线 × +b[:t|c|e] × +ifr[:c|e]，见下方图例；因子 = 单个 flag 的 marginal Δ%）各测 create / update10th / updateStorm / select / selectStorm（1k/10k，reps=2 — ±10% 内视为噪声）。因子 = 单轴 marginal Δ%。engine cells 在本环境（Lynx for Web，无引擎 ET PAPI）数据记为 N/A，默认从表格滤除（顶部开关可显示）；其解释回退的对照原始样本仍在 results JSON 中。详见 ifr-bench/GRAPH-ENG-REPORT.md §3.3。

优化 flag 图例（cell 名 = 基线 × flag 堆叠，与因子归因一一对应）

标记	含义
`基线`	per-node addressing —— 最朴素、最安全：每个节点独立命名，无需元数据、无需校验。`vdom` = op stream；`vapor` = named tree。
`+b`	block templates：用模板块的 parts 信息做块式命名（`base+offset`）并物化模板。staging 参数缺省为该 render model 的自然档位 —— `vdom +b` ≡ `+b:c`（code，baked `create()`）；`vapor +b` ≡ `+b:d`（data：序列化树在运行期作为数据过线——REGISTER_TREE 每模板一次——由 MT 解释；Split 拓扑所致）。注意：两个 render model 的 `+b` 因子因此不可互比。信息来源也不同：vdom 是 intrinsic（Vue Block 声明），vapor 是 recovered（编译期恢复，带指纹 fail-safe）。
`+b:c`	vapor 的 staging 升到 code 档（#337）：构建期解析 `template()` HTML，直线 PAPI `create()` 编进 MT bundle，实例化只过一条 `INSTANTIATE_TEMPLATE(id)`——residual 运行期完全不过线。命名沿用 `base+offset` 前序，update 路径零改动；构建期解析与运行期解析的结构指纹不合时静默回退 REGISTER_TREE 数据路径。
`+b!`	delivery 列单独翻转（#338）：staging 仍为 data，但序列化树在构建期烧进 MT bundle（`registerVaporStructure(hash, ast)`）；BG 只发指纹哈希（REGISTER_TREE_BUNDLE），结构字节 0 过线。解释、命名、update 路径与 `vapor +b` 逐字节一致；哈希不合时静默回退完整 REGISTER_TREE。
`+b:e`	staging 升到 engine 档：模板常驻引擎（`__CreateElementTemplate` 家族），native clone。作用于 persistent 本体树。本环境（Lynx for Web）无该 PAPI → N/A。
delivery	（第六列性质）residual 何时到 MT：`runtime` = 运行期过线（vapor +b 的 data 现状与 native）；`bundle` = 构建期编进 MT bundle（vdom 的 code、RL Snapshot、vapor 的 `+b!` 与 `+b:c`）。`+b!` 是唯一在其他五列全部不动的前提下单独翻转 delivery 的格——纯 delivery 因子的单列读数。
`+ifr`	IFR：MTS 抢跑 ephemeral 首帧副本，BG 启动后 hydration 采纳或整体重放。paint 参数缺省 = 首帧继承本体 staging。
`+ifr:e`	仅首帧副本用 engine 档画（旧名 engine-et）；本体树照常。区别于 `+b:e`（全程）。本环境 N/A。
`+ifr:c`	仅首帧副本用 code 档画（#340）：ephemeral 首帧跑运行期编译的 Code-Template `create()` executor，本体树仍是 data/block（旧名 disposable-et）。区别于 `+b:c`（全程、构建期烘焙）。与 `+ifr:e` 不同，本环境可测真值（不再 N/A）——读数见 `+ifr:c paint effect` 行与对应结论卡。

数据文件仍使用 legacy key（映射：vdom-et=vdom +b、vapor=vapor +b（默认）、vapor-dense=vapor 基线、vapor-bang=vapor +b!、vapor-code=vapor +b:c、vapor-ifr-dense=vapor +ifr、vapor-engine=+b:e、vapor-ifr-engine-et=+ifr:e、vapor-ifr-code-paint=+ifr:c）。vapor-ifr-sparse 是 vapor +b +ifr 的同坐标复测样本，已从显示中省略（数据保留在 JSON）。机制层术语（Named Tree / Tree-Template / Code-Template / Engine-Template）与五轴坐标见 GRAPH-ENG-REPORT.md。

场景 @1k	coordinate	create	update10th	updateStorm	select	selectStorm
vdom `vdom`	ops/node/random-access/BTS/persistent/—	202.3 ms	24.7 ms	127.4 ms	26.6 ms	70.9 ms
vdom +b `vdom-et`	code/block/random-access/BTS/persistent/bundle	201.9 ms	24.8 ms	126.1 ms	26.1 ms	64.6 ms
vdom +ifr `vdom-ifr`	ops/node/random-access/BTS+MTS/persistent+ephemeral/—	199.7 ms	23.2 ms	124.6 ms	26.5 ms	67.5 ms
vdom +b +ifr `vdom-ifr-et`	code/block/random-access/BTS+MTS/persistent+ephemeral/bundle	217.0 ms	26.9 ms	132.6 ms	26.0 ms	65.1 ms
vapor `vapor-dense`	data/node/traversal/BTS/persistent/runtime	190.8 ms	26.3 ms	66.5 ms	27.0 ms	19.5 ms
vapor +b `vapor`	data/block/traversal+recover/BTS/persistent/runtime	213.5 ms	26.9 ms	67.4 ms	27.0 ms	20.5 ms
vapor +b! `vapor-bang`	data/block/traversal+recover/BTS/persistent/bundle	201.2 ms	24.5 ms	66.4 ms	26.1 ms	20.1 ms
vapor +b:c `vapor-code`	code/block/traversal+recover/BTS/persistent/bundle	196.8 ms	25.5 ms	61.7 ms	27.1 ms	13.2 ms
vapor +ifr `vapor-ifr-dense`	data/node/traversal/BTS+MTS/persistent+ephemeral/runtime	210.3 ms	21.3 ms	68.3 ms	25.8 ms	13.8 ms
vapor +b +ifr `vapor-ifr`	data/block/traversal+recover/BTS+MTS/persistent+ephemeral/runtime	201.9 ms	27.0 ms	68.8 ms	17.0 ms	19.2 ms

场景 @10k	coordinate	create	update10th	updateStorm	select	selectStorm
vdom `vdom`	ops/node/random-access/BTS/persistent/—	1.74 s	114.8 ms	1.86 s	79.5 ms	984.1 ms
vdom +b `vdom-et`	code/block/random-access/BTS/persistent/bundle	1.60 s	115.4 ms	1.94 s	77.7 ms	1.04 s
vdom +ifr `vdom-ifr`	ops/node/random-access/BTS+MTS/persistent+ephemeral/—	1.66 s	117.1 ms	1.97 s	81.7 ms	994.6 ms
vdom +b +ifr `vdom-ifr-et`	code/block/random-access/BTS+MTS/persistent+ephemeral/bundle	1.68 s	117.2 ms	1.89 s	81.1 ms	967.9 ms
vapor `vapor-dense`	data/node/traversal/BTS/persistent/runtime	1.65 s	91.6 ms	729.8 ms	57.8 ms	106.0 ms
vapor +b `vapor`	data/block/traversal+recover/BTS/persistent/runtime	1.73 s	88.8 ms	887.6 ms	66.7 ms	118.6 ms
vapor +b! `vapor-bang`	data/block/traversal+recover/BTS/persistent/bundle	1.77 s	87.4 ms	918.2 ms	72.9 ms	106.8 ms
vapor +b:c `vapor-code`	code/block/traversal+recover/BTS/persistent/bundle	1.76 s	95.1 ms	759.7 ms	57.7 ms	115.7 ms
vapor +ifr `vapor-ifr-dense`	data/node/traversal/BTS+MTS/persistent+ephemeral/runtime	1.65 s	89.6 ms	699.6 ms	48.4 ms	92.9 ms
vapor +b +ifr `vapor-ifr`	data/block/traversal+recover/BTS+MTS/persistent+ephemeral/runtime	1.73 s	95.3 ms	740.5 ms	56.9 ms	124.7 ms

场景 @30k	coordinate	create	update10th	updateStorm	select	selectStorm
vdom `vdom`	ops/node/random-access/BTS/persistent/—	5.28 s	478.3 ms	10.9 s	308.4 ms	3.57 s
vdom +b `vdom-et`	code/block/random-access/BTS/persistent/bundle	4.85 s	355.9 ms	7.21 s	248.6 ms	3.23 s
vdom +ifr `vdom-ifr`	ops/node/random-access/BTS+MTS/persistent+ephemeral/—	4.83 s	370.0 ms	7.34 s	306.8 ms	3.33 s
vdom +b +ifr `vdom-ifr-et`	code/block/random-access/BTS+MTS/persistent+ephemeral/bundle	5.40 s	369.9 ms	7.51 s	242.3 ms	3.17 s
vapor `vapor-dense`	data/node/traversal/BTS/persistent/runtime	5.13 s	253.8 ms	6.74 s	268.7 ms	306.1 ms
vapor +b `vapor`	data/block/traversal+recover/BTS/persistent/runtime	5.36 s	266.2 ms	7.22 s	236.8 ms	275.2 ms
vapor +b! `vapor-bang`	data/block/traversal+recover/BTS/persistent/bundle	5.05 s	250.4 ms	6.11 s	275.4 ms	332.6 ms
vapor +b:c `vapor-code`	code/block/traversal+recover/BTS/persistent/bundle	5.04 s	257.2 ms	7.29 s	291.3 ms	309.7 ms
vapor +ifr `vapor-ifr-dense`	data/node/traversal/BTS+MTS/persistent+ephemeral/runtime	5.13 s	242.9 ms	6.33 s	272.1 ms	322.3 ms
vapor +b +ifr `vapor-ifr`	data/block/traversal+recover/BTS+MTS/persistent+ephemeral/runtime	5.18 s	250.6 ms	7.07 s	288.9 ms	362.9 ms

主效应（每次只翻一个 flag）。每个 flag 会同时挪动几根坐标轴（见下方「flag ↔ 坐标轴」表），所以这些数字归因到 flag 粒度、不能再往单轴拆。图：柱向左（负）= 该 flag 让该操作更快;±10% 内视为噪声（reps=2）。engine 因子在 web 上是 stub 探测开销。

主效应 @1k（Δ% — 左/负 = 更快）

create update10th updateStorm select selectStorm

主效应 @10k（Δ% — 左/负 = 更快）

create update10th updateStorm select selectStorm

主效应 @30k（Δ% — 左/负 = 更快）

create update10th updateStorm select selectStorm

主效应结论（take away）

Update / select 对模板机制是盲的。+b 因子（vdom 与 vapor 两行）在 update10th / select / updateStorm / selectStorm 上各规模都落在 ±10% 噪声带内 — 与 ops 级 factorial（所有 cell 的 update 帧数、native 调用完全相同）互证。模板只改变首帧由谁构建，不改变洞怎么写。

模板的 create 收益只在静态重的屏上出现。「负 = 更快」。table app 的 create 被动态 v-for 行主导，模板化只覆盖那一小块静态骨架，所以 staging 因子在 create 上 -0.2%~-8.1% ≈ 噪声；换到静态重内容（sfc-probe FCP 阶梯），block/code 模板就成了唯一在所有规模都为负（更快）的因子。规则：先量你首屏的静态占比，再决定要不要上模板。

render 轴（vdom→vapor）才是 update 的大杠杆：updateStorm -47.8% / -60.7% / -38.4%（1k→30k），远超任何模板轴。交互性能选 render model，别指望模板。

IFR 是首帧杠杆，不是交互杠杆：ifr 因子只在 create/FCP 显著，update 因子在噪声内；×4 下 vapor 的 IFR 首帧代价由 +b 收回（基线 +12% → +b +2%）。

那 vapor +b 到底做了什么？在动态表格上它对 create / update / select / storm 延迟几乎没影响（各规模都在 ±10% 噪声内）。它真正可测的收益有两处：(1) 内存 / 簿记 — BG shells −94%、MT 表项 −92%（精确计数）;(2) 静态重首屏 — block 化让首帧构建更省，收益随子树静态占比上升。一句话：+b 是内存 + 静态首帧优化，不是动态延迟杠杆。我们在 +b / +ifr 上花的功夫，产出的是这两样，而不是表格交互延迟。

+b:e 与 +ifr:e 在本环境记为 N/A（Lynx for Web 无引擎 ET PAPI；__VUE_LYNX_ENGINE_ET_STATUS__ = stub）。它们的解释回退对照样本仅用作 fail-safe 成本与噪声尺，不作为 engine 结论；这条轴已端到端可跑，等引擎 PAPI 落地即测真值。

+b!（delivery 单列翻转，#338）与 +b:c（code 档，#337）已实测——收益是「小模板 × 多实例」条件收益，不是普适收益。storms table app（小行模板 × 上万实例）：+b! create -5.8% / +2.1% / -5.8%、+b:c create -7.8% / +1.5% / -6%（1k/10k/30k），update/select 因子在 reps=2 噪声包络内（对照解释路径完全相同的 +b:e stub 行在 30k 同样摆动 ±20%——模板盲性再次验证）；结构字节按设计 0 过线（table app 注册线路 1165 B → 99 B 指纹帧；+b:c 连注册都不发，wire-bytes 计数内嵌在 factor JSON）。但 content 首屏探针（一整张 mega 静态模板 × 单实例）方向相反：×1 下两格 FCP 随规模变慢（最高 ~+16%），机制 = bundle 内驻的 residual 在 MT 启动关键路径上被解析——30k 时 MT 段 gzip 从 8 kB 涨到 +b! 14 kB / +b:c 487 kB（raw 24 kB → 1.1 MB / 3.5 MB）。原猜测 +b:c create −5…−17%（随静态占比）来自 vdom ET「每卡片一个小 create()」的先例，不迁移到 vapor 的单一 mega-template 形态；+b! 的 structure wire −100% 逐字节成立。资格规则：烘焙只在 residual 小且实例多（列表行）时净赚；单实例大模板应留在 data 线路——按模板尺寸门控。update 路径与 vapor +b 逐字节相同（指纹 fail-safe + mutated-hash 测试兜底）。

+ifr:c（code-paint，#340）首帧在噪声内打平。用运行期编译的 Code-Template create() executor 画 ephemeral 首帧（本体树仍 data/block）。content-probe FCP 相对 plain vapor +b +ifr：×1 -3.3%…+11.9%，×4 -6%…+9.5%，均值 +5.2%——见 +ifr:c paint effect 行。机理与 +b:c 的 storms 结论一致：单次 ephemeral 物化由 PAPI 建元素主导（两种 paint 完全相同），code 档只省掉 data 档每节点的解释走查，占首帧成本很小。与 +ifr:e 不同，这是真值（Code-Template 在 web 上真的会跑）。

flag ↔ 坐标轴映射（哪些轴被这个 flag 一起挪动）

flag	staging 阶段	naming 命名	access 访问	thread 线程	lifetime 生命期	origin 来源	同时挪动
render	ops→data	·	random-access→traversal	·	·	—→runtime	3
+b (vdom)	ops→code	node→block	·	·	·	—→bundle	3
+b (vapor)	·	node→block	traversal→traversal+recover	·	·	·	2
+ifr	·	·	·	BTS→BTS+MTS	persistent→persistent+ephemeral	·	2
+b:e （web 上 N/A）	data→native	·	·	BTS→Engine	·	·	2
+ifr:e （web 上 N/A）	·	·	·	·	·	runtime→runtime(native-paint)	1

每一行是一次 cell→cell 的移动，亮起的列 = 该 flag 同时挪动的坐标轴，直接从 6 槽 coord 串 diff 得出（不是编造）。因为这些轴共线——例如 +ifr 永远同时挪 thread 与 lifetime、render 一次挪 3 根——所以上面因子表里的 Δ% 只能归因到 flag 粒度，无法再拆成单轴数字。native/engine 轴在本机记为 N/A（只作 fail-safe 成本尺）。

factor (marginal Δ%) @1k	create	update10th	updateStorm	select	selectStorm
render effect (vdom → vapor, baselines)	-5.7%	+6.5%	-47.8%	+1.5%	-72.5%
+b effect (vdom, no ifr)	-0.2%	+0.4%	-1%	-1.9%	-8.9%
+b effect (vdom, with +ifr)	+8.7%	+15.9%	+6.4%	-1.9%	-3.6%
+b effect (vapor, no ifr)	+11.9%	+2.3%	+1.4%	+0%	+5.1%
+b effect (vapor, with +ifr)	-4%	+26.8%	+0.7%	-34.1%	+39.1%
+b! delivery effect (vapor)	-5.8%	-8.9%	-1.5%	-3.3%	-2%
+b:d→c effect (vapor)	-7.8%	-5.2%	-8.5%	+0.4%	-35.6%
+ifr effect (vdom)	-1.3%	-6.1%	-2.2%	-0.4%	-4.8%
+ifr effect (vapor +b)	-5.4%	+0.4%	+2.1%	-37%	-6.3%

factor (marginal Δ%) @10k	create	update10th	updateStorm	select	selectStorm
render effect (vdom → vapor, baselines)	-5.2%	-20.2%	-60.7%	-27.3%	-89.2%
+b effect (vdom, no ifr)	-7.9%	+0.5%	+4.5%	-2.3%	+5.7%
+b effect (vdom, with +ifr)	+1.3%	+0.1%	-3.9%	-0.7%	-2.7%
+b effect (vapor, no ifr)	+5.3%	-3.1%	+21.6%	+15.4%	+11.9%
+b effect (vapor, with +ifr)	+4.5%	+6.4%	+5.8%	+17.6%	+34.2%
+b! delivery effect (vapor)	+2.1%	-1.6%	+3.4%	+9.3%	-9.9%
+b:d→c effect (vapor)	+1.5%	+7.1%	-14.4%	-13.5%	-2.4%
+ifr effect (vdom)	-4.3%	+2%	+6.1%	+2.8%	+1.1%
+ifr effect (vapor +b)	-0.3%	+7.3%	-16.6%	-14.7%	+5.1%

factor (marginal Δ%) @30k	create	update10th	updateStorm	select	selectStorm
render effect (vdom → vapor, baselines)	-2.8%	-46.9%	-38.4%	-12.9%	-91.4%
+b effect (vdom, no ifr)	-8.1%	-25.6%	-34.1%	-19.4%	-9.6%
+b effect (vdom, with +ifr)	+11.7%	+0%	+2.4%	-21%	-4.7%
+b effect (vapor, no ifr)	+4.5%	+4.9%	+7.2%	-11.9%	-10.1%
+b effect (vapor, with +ifr)	+0.9%	+3.2%	+11.8%	+6.2%	+12.6%
+b! delivery effect (vapor)	-5.8%	-5.9%	-15.3%	+16.3%	+20.9%
+b:d→c effect (vapor)	-6%	-3.4%	+1%	+23%	+12.5%
+ifr effect (vdom)	-8.4%	-22.6%	-32.9%	-0.5%	-6.7%
+ifr effect (vapor +b)	-3.4%	-5.9%	-2.1%	+22%	+31.9%

FCP 主效应（content-probe 首帧量纲，与上面 storm 毫秒是两套仪器，不可互比）：

FCP 主效应 ×1（Δ% — 左/负 = 首帧更快）

@1k @3k @5k @10k @20k @30k

FCP 主效应 ×4（Δ% — 左/负 = 首帧更快）

@1k @3k @5k @10k

factor (FCP Δ%)	×1 @1k	×1 @3k	×1 @5k	×1 @10k	×1 @20k	×1 @30k	×4 @1k	×4 @3k	×4 @5k	×4 @10k
render effect (vdom → vapor, baselines)	+25.2%	+24.5%	+46.5%	+42.4%	+44.5%	+53.8%	-13.5%	-24.5%	-12.1%	-13.2%
+b effect (vdom, no ifr)	-10.9%	+3.7%	0%	+4.6%	-1.2%	+3%	-12.3%	-17.1%	-12.1%	-15%
+b effect (vdom, with +ifr)	-3.4%	-9.4%	-12.3%	-38%	-32.6%	+4.9%	-20.5%	-17.9%	-11.8%	-27.1%
+b effect (vapor, no ifr)	+8.1%	+5.3%	+0.2%	-2.7%	-4.9%	-3.7%	-1%	-9.3%	-11.4%	-4.1%
+b effect (vapor, with +ifr)	-5.3%	-1.2%	+0.1%	-1.1%	-4.8%	+7.5%	-5.3%	-2.3%	-3.6%	-2.6%
+b! delivery effect (vapor)	-5.8%	+16.3%	+2.3%	+16.2%	+9.6%	+2.3%	+9.9%	+16.2%	+0.7%	-5.2%
+b:d→c effect (vapor)	-2.8%	+8.1%	+8.5%	+13.8%	+15.1%	+16.6%	+0.7%	+12.7%	+7.3%	-3.8%
+b:d→e effect (vapor, N/A)	-14.6%	-13.2%	-16.6%	-12.8%	-13.3%	-13.4%	+22.6%	+44.4%	+33.7%	+23.2%
+ifr effect (vdom)	-20.8%	-13.4%	-2.5%	+33.1%	+25.2%	+29.4%	+11.5%	-7.7%	-6.4%	+11.7%
+ifr effect (vapor +b)	-16.6%	-13.4%	-8.9%	-7.9%	-8.4%	-4.5%	+13.3%	+24.7%	+18.5%	+6%
+ifr:e paint effect (N/A)	-9.1%	-13.2%	-19.7%	-14.3%	-14.1%	-22.5%	+16.2%	+26.4%	+28.6%	+33.1%
+ifr:c paint effect	+8.6%	+11.9%	+0.4%	+8.2%	+9.6%	-3.3%	-6%	+9.5%	+5.7%	+7.7%

覆盖面

每种架构在统一 schema 里量过什么。

架构	交互 storms	首帧 FCP	instrumented BG/e2e
vdom（基线） `vdom`	✓	✓	✓
vdom +ifr `vdom-ifr`	✓	✓	—
vdom +b +ifr `vdom-ifr-et`	✓	✓	—
vapor +b（默认） `vapor`	✓	✓	✓
vapor +b +ifr（默认+ifr） `vapor-ifr`	✓	✓	—
vapor +ifr `vapor-ifr-dense`	✓	✓	—
vdom +b `vdom-et`	✓	✓	—
vapor（基线） `vapor-dense`	✓	✓	—
vapor +b:c（code 档） `vapor-code`	✓	✓	—
vapor +b!（bundle 交付） `vapor-bang`	✓	✓	—
vapor +b +ifr:c `vapor-ifr-code-paint`	—	✓	—
rl（Snapshot+IFR+memo） `react`	✓	✓	—
ReactLynx (naive) `react-naive`	✓	—	—
ReactLynx (compiler) `react-compiler`	✓	—	—

量纲不能混。 Instrumented BG/e2e、黑盒 click→DOM、lynx-web FCP、node --jitless 暖渲染共用 1k→30k 标签，但不是同一把尺子。
着色怎么读：与 playground 相同——颜色是相对该行最优的慢速倍数；数字本身才是权威。
CPU ×4 展示：阶梯截到 10k（该 throttle 下完整覆盖范围）。
复现：pnpm --filter vue-lynx-benchmark bench:unified && bench:synthesize && bench:report