设想你正在查看图上的一个节点，想判断它与某个问题有什么关系。后台解析又完成了一批资料，页面收到新结果，重新处理节点与关系，画面开始移动。你要等的不只是页面恢复响应，还要重新找到刚才的位置。
这个场景来自 TraceWise 持续展示抽取候选的工作方式。节点与关系随任务增长，用户需要在变化中保持视角、选择对象并打开依据。“图一大就卡”因此包含两类问题：计算与绘制阻塞操作，以及更新打断观察。更快的渲染器能否同时解决它们，需要先看开销来自哪里。
我的判断是，先确认哪些工作没有必要重复发生，再决定剩余计算应该放在哪里，以及哪些显示细节可以简化。 这是一种排查顺序，不是所有大图都必须采用的实现路线。以下案例使用 2026 年 9 月 11 日的固定回放与加载阶段采样；它们支持诊断和原型选择，还没有优化前后的收益对照。
用户看到一张图，系统却在做几种工作
TraceWise 的正式项目图与抽取中的候选预览来自不同路径。进入项目时可以请求正式图；解析过程中，任务详情还会携带累计候选，让用户在正式审核之前观察结果。正式图为空时，候选画布也可能已经出现上万个节点。
所以，正式图接口返回快，并不能解释候选页面是否流畅。要沿实际任务拆开几个问题：任务详情传回多少内容，前端怎样合并候选，布局需要多少计算，每次又画了什么。它们可以相互触发，单看某个接口或某次绘制容易遗漏成本。
前端预览构造源码从基础图生成节点集合，并逐条搜索关系列表来处理变更。不断加入尚未存在的关系时，线性搜索会扫描越来越长的列表，比较工作可能接近平方级。重新创建候选节点对象，也使布局状态的保留成为需要检查的问题；仅凭节点数量相同，无法说明用户仍然看到同一个位置。
这里先得到的是一个具体排查目标：内容没有变化时，是否仍然重做了这条处理链？
一份固定快照告诉了我们什么
我们从正在运行的任务读取一份快照，在独立的无头 Edge 浏览器里拦截该任务的详情 GET 请求并返回同一快照。真实解析任务继续运行。这个设置刻意保持候选不变，用来观察现有页面在重复响应下的行为，不用于测量自然网络流量。
样本为第469个已完成分片的累计候选，包含11,389个节点变更和10,333条关系变更。浏览器版本为152.0.4191.66，视口1440×1000，设备像素比1。
| 观测项 | 结果 | 含义 |
|---|---|---|
| 任务详情正文 | 14,926,309字节，约14.93 MB | 未压缩正文大小，不是网络线路流量 |
| 固定详情响应 | 14次，候选内容哈希相同 | 回放条件下的请求次数，不是自然运行中的重复比例 |
| 当前预览构造函数中位耗时 | 266.04 ms | Node中3次预热后执行20次；不包含布局、React或网络 |
| 同一函数P95耗时 | 376.75 ms | 20个样本按最近秩取第19个，样本规模有限 |
| 未操作观察窗口 | 约8.29秒，81个长任务 | 页面仍在布局、轮询与更新，不是稳定静态图 |
| 拖拽、缩放及等待窗口 | 约18.99秒，174个长任务 | 自动化操作受卡顿影响，两个窗口不作直接优劣对照 |
未操作窗口的requestAnimationFrame间隔P95约462.5 ms，交互窗口约408.4 ms。这是浏览器回调调度间隔，不是实际绘制帧率；不能取倒数写成产品FPS。无头浏览器、后台解析、自动化和响应回放也会影响结果。
图为现有版本的固定快照回放。左侧记录候选变更数，画布中的关系数经过现有预览处理，两者并非同一计数口径；此处不能根据数量差直接认定丢失了有效关系。
这些数据说明，重复传递和构造累计预览值得优先处理。第一轮还不能分解布局、绘制与React更新的耗时占比。首次实时响应抓取曾因浏览器调试缓存淘汰失败，该轮未进入以上统计。
布局和绘制各占多少，需要另一次观察
随后对已安装页面做了一次约10.03秒的主线程CPU采样，采样间隔设为1 ms。采样开始时候选仍在获取，结束时页面显示494/514分片、11,936个节点候选和10,782条关系候选。因此，这次捕捉的是候选出现与布局阶段，不是稳定静态图，也不是上一份469分片快照的同条件重测。
通过安装包中压缩函数的位置与函数正文核对调用栈，将每个样本只归入一个类别，得到以下估计。占比以全部已记录采样时间为分母，包含空闲时间。
| 调用栈范围 | 采样时间 | 占比 |
|---|---|---|
| 力导向模拟tick子树 | 3,940.89 ms | 39.31% |
| 节点与边绘制子树，含命中检测Canvas | 2,736.14 ms | 27.29% |
| 预览状态更新子树 | 920.91 ms | 9.19% |
| 垃圾回收 | 291.34 ms | 2.91% |
| 其他index包调用，不能当成纯React耗时 | 162.40 ms | 1.62% |
| 其他未归因 | 640.65 ms | 6.39% |
| 空闲 | 1,332.60 ms | 13.29% |
在布局分支中，多体力计算与四叉树遍历是明显热点。绘制分支包含自定义节点绘制、类别颜色计算，以及用于鼠标命中判断的隐藏画布。这里的Canvas耗时是主线程调用栈中的采样，不包含完整GPU、合成或像素呈现成本。
预览更新发生在React状态更新路径中；压缩与内联会影响函数边界，因此不能把表中9.19%说成预览纯函数的独占耗时，也不能把剩余index包时间说成React的全部成本。这些子树采用互斥归类，没有再次叠加父子函数耗时。
这改变了方案优先级：Worker布局从只有文档依据的候选，升级为有本地加载阶段热点支持的原型候选。同时，重复预览更新与重建仍应先处理，因为它可能反复触发布局。单独把计算搬到Worker，并不会消除这些重复计算。
绘制同样值得优化，但27.29%不能直接换算成更换WebGL后的收益。类别颜色计算可以缓存，绘制细节可以调整；隐藏命中画布关系到点击准确性，不能简单关掉。不同措施的收益必须通过后续对照分别确认。
先减少重复工作，但不能漏掉真实变化
收到相同候选时，最直接的设想是跳过预览重建。但“相同”的定义不能只是节点数和关系数：同样是两个节点、一条边，摘要、方向或证据引用都可能改变。内容版本或可靠的变更标识应该覆盖会影响显示与操作的字段；如果计算这个标识本身要每次遍历巨大正文，它也有成本。
若服务只返回变化部分，还要约定缺口与重连怎样恢复。客户端错过一次删除事件，可能长期保留已经不该显示的对象。因此，增量传输应该能检测版本不连续，并在必要时重新取得完整状态。它减少常态工作，同时增加协议和恢复逻辑；本文尚未实施这项改动。
对象复用也需要稳定身份。Force Graph 的动态更新示例追加节点时沿用已有对象；但示例删除后重新编号，不适合直接用于具有固定实体身份的知识图谱。可以借鉴对象复用，不能连身份策略一起照搬。
对关系建立索引时，还要先确定关系究竟由什么标识。同一对节点之间可能存在独立的平行关系，简单按端点合并会改变图的含义。当前预览处理使用端点与关系类型匹配，新增预览边也未携带独立关系 ID；这需要在优化之前核对业务契约，不能把合并后的边变少当成性能收益。
保持位置，为什么不等于把布局冻结
回到用户正在查看的节点：若新数据只是更新摘要，没有必要因为对象重建让它重新寻找位置；若新增关系连接了两个原本分开的群组，适当移动又有助于表达新的结构。
D3 模拟器文档说明，节点位置与速度保存在被模拟器修改的对象上，设置新的节点集合会重新初始化相关力。由此可以检查对象与坐标是否被无谓丢弃，但不能推导“保留对象后引擎只计算新增节点”。TraceWise 的依赖链实际使用 d3-force-3d，具体适配仍须核对锁定版本。
我的选择标准是把观察连续性作为约束：选中对象仍是同一个实体，视角不会被无关更新重置，新结构需要变化时允许布局调整。至于采用局部固定、渐进移动还是更新后重新布局，需要由实际任务比较；位移更小不自动等于图更容易理解。
什么时候值得把计算搬到 Worker
加载阶段约39.31%的采样时间落在模拟tick子树，让布局线程化成为有依据的原型候选。D3 文档针对大图静态布局建议使用 Web Worker，以避免冻结界面；它支持计算与交互分离的方向，不承诺总计算时间一定缩短。simulation.tick
持续更新的图还要多考虑一步：Worker算到一半时又来了新候选，旧坐标还能否回写？用户刚拖动的节点，应该采用用户的位置还是迟到的布局结果？原型至少需要绑定输入版本、丢弃过期结果，并约定拖拽状态怎样同步。
这些通信与协调都有代价。减少无变化时的重建之后，应再次测量布局是否仍占用主要时间；如果开销已经足够小，维护一套跨线程协议可能不值得。Worker的价值主要要看交互能否及时响应，同时核算复制、通信和布局质量。
绘制占比能否支持换 WebGL
约27.29%的采样时间落在绘制子树，说明这里值得继续分解，但其中包含颜色计算与鼠标命中画布。缓存样式计算、调整细节和替换渲染器，是不同的措施。隐藏命中检测虽然可能少做工作，却会损害点击，不能当作等价优化。
Sigma 的生命周期说明区分数据处理和渲染，并通过调度合并重复刷新。这个对照说明，即便使用 WebGL，仍然需要处理数据和管理更新。换渲染器之前，应明确它将替代哪部分开销，以及剩余工作是否还会阻塞交互。
只有在剔除明显重复更新之后，绘制仍然是主要限制，并且新渲染器保留所需功能，替换才更有说服力。当前记录没有测量替代实现，因此尚不能依据这一个百分比估算收益。
“少画一点”会改变用户能理解什么
Cytoscape.js 的性能指南讨论标签、复杂边、动画和像素密度的开销，并建议在细节不可读时减少显示。它也指出，无语义意义的箭头可以考虑省略。把这些建议用于 TraceWise，关键在于判断细节是否承载任务所需信息。
例如，缩小到整图概览时，所有标签可能已无法辨认；进入选中节点的邻域后，名称与关系方向却是理解原因和后果的依据。可以考虑按缩放与选择状态恢复细节，而不是永久移除它们。聚合也类似：它可以帮助观察群组，但应该允许回到需要核对的对象。
还应把显示范围与检索范围说明白。画布为了交互只展示一部分，不意味着检索只能访问这一部分；反过来，如果数据尚未全部加载，也不能让用户以为已经看到了完整关系。减少可见对象涉及产品语义，需要单独验收。
把方案放回同一张决策表
| 方案 | 当前判断 | 正面作用与主要代价 |
|---|---|---|
| 候选版本未变化时不重建预览 | 优先进入后续验证 | 减少无效工作；不能只比较数量，否则属性变化会漏掉 |
| ID索引与批量应用变更 | 优先进入后续验证 | 减少关系扫描；必须保留平行关系的独立身份 |
| 复用节点与坐标 | 优先进入后续验证 | 稳定视角；新关系出现时仍需允许布局调整 |
| 缩略图底图缓存 | 适合局部验证 | 移动视口框时复用底图；坐标变化后需要失效重绘 |
| 标签、箭头和动画简化 | 保留现有做法，按任务评估追加 | 减少绘制；可能损害方向辨认与关键节点发现 |
| Worker布局 | 有本地热点支持的原型候选 | 加载阶段布局分支显著；仍需验证通信成本、更新取消和拖拽兼容 |
| 图版本缓存与渐进加载 | 独立的加载设计项 | 改善等待；需处理范围完整性与当前有效性 |
| WebGL渲染器替换 | 暂不选为默认路线 | 可能提升绘制能力；数据构造与布局问题仍在 |
| 聚合与展开 | 独立产品选择 | 有利于理解结构；不能用聚合后的显示数量代替完整数据范围 |
这张表是我依据该次诊断整理的采用判断。前三项有代码与样本依据，因此值得先验证。CPU采样进一步支持Worker原型评估；WebGL尚需绘制细分和功能对照。两者均未作最终采用决定。上述判断不是产品实现清单，也不表示其收益已经得到测量。
如何证明优化以后，用户真的更容易继续工作
对照首先需要同一份图、同一组变更和同一套操作。固定输入后，分别观察首次加载、无变化轮询、真实内容更新、拖拽与缩放。无变化时不应反复重建；真实变化时又必须完整应用。把不同阶段混在一起取一个平均耗时，很难知道方案解决了什么。
我会用下面这张表安排后续验证。它是实验设计，尚未产生优化后结果。
| 场景 | 性能观察 | 不能被牺牲的结果 |
|---|---|---|
| 首次加载同一张图 | 数据处理、布局、首次可交互时间、内存 | 完整范围被准确说明，节点与边身份一致 |
| 重复返回相同版本 | 重建次数、主线程长任务 | 不漏掉同数量但内容不同的更新 |
| 更新与删除一批对象 | 应用变更与重新布局耗时 | 方向、平行关系与删除结果正确 |
| 查看节点时接收新结果 | 响应时间、位移与视角变化 | 选择连续，依据入口仍指向同一对象 |
| 拖拽时布局异步返回 | 输入响应与通信开销 | 过期结果不覆盖当前拖拽状态 |
| 概览切换到局部调查 | 绘制耗时与标签呈现 | 所需名称、方向和来源能够恢复查看 |
当前记录尚未形成有效的堆内存、完整GPU开销或代表性设备对照。requestAnimationFrame间隔也不是实际呈现帧率。后续测量应同时保留交互结果与成本，不能仅凭某个函数更快宣布整个页面改善。
什么情况下，我会改变优化顺序
对于小图、低频更新和简单交互，全量重建可能更容易维护。若采样已经确认主要成本在复杂边与标签绘制，而数据处理很小，就应该直接试验绘制策略，不必先建设一套复杂增量协议。若用户只需要一次静态展示，持续增量布局也可能没有必要。
这次万级候选图的材料，使我优先考虑变化识别、批量处理与对象状态保留，再验证Worker布局，暂不把WebGL替换选为默认路线。这个顺序依赖当前负载与观察；重复工作减少后，新的采样结果应当有权改变它。
下一次遇到“图一大就卡”，先沿一次用户操作找到数据处理、布局与绘制实际发生的位置，区分必要变化与重复计算，再决定在哪一层投入。最终要保留下来的优化，应当让用户更及时地操作，也能持续认出对象、看清关系并回到依据。