Knockout性能优化方案及数据绑定机制是否存在根本性缺陷？

问题背景 #

• 技术选型：选定Knockout作为长期技术栈，基于其开发类电子表格应用，验证数据绑定机制的扩展能力
• 核心实现：
  • 每个单元格封装为可写ko.computed可观察对象，支持数值、文本、公式三类输入
  • 通过自定义range函数实现单元格/单元格区域的引用解析
  • 已开启ko.options.deferUpdates延迟更新配置
• 压测场景：20*20规模表格，设定每个单元格值为其上方单元格与左侧单元格的和
• 异常表现：修改存在多层依赖的单元格时出现超量求值，单单元格公式更新触发超140万次evaluateImmediate_CallReadWithDependencyDetection调用，更新逻辑时间复杂度达指数级O(eⁿ)，远差于预期的*O(n²)*级联更新性能，与Google Sheets同场景表现差距极大
• 排查进展：已排除依赖传递闭包被固化的猜想，确认Knockout默认依赖追踪逻辑存在严重性能问题；自行实现的替代方案在12*12规模表格下即可带来数千倍性能提升，已在Knockout官方GitHub仓库提交相关issue

根因判定 #

Knockout实现的数据绑定机制在大规模DAG（有向无环图）计算场景下存在明确的设计边界缺陷，并非配置错误或使用方式不当：

• 原生依赖追踪基于运行时属性读取自动收集，更新触发时未做全局拓扑排序与求值状态标记。级联更新过程中，同一个计算属性会被多个上游依赖重复触发求值，且不会在单次更新周期内标记已求值状态，最终导致求值次数随依赖层级呈指数级增长。
• 已开启的ko.options.deferUpdates配置仅实现了微任务维度的更新批处理，未解决更新队列内的重复入队、重复求值问题：当一个计算属性同时被多个上游依赖通知变更时，会被多次加入求值队列，框架本身没有内置判重与拓扑排序逻辑。
• Knockout的初始设计目标是支撑常规表单、中小规模列表的双向绑定需求，从架构层面就没有针对大规模依赖级联计算场景做优化，这类性能缺口不属于可通过小版本补丁修复的常规bug。

可落地优化方案 #

• 自定义计算属性更新调度逻辑
  无需修改Knockout源码，通过扩展ko.computed的配置项注入自定义调度器：在单次更新周期内给每个计算对象增加求值状态标记，已标记为待更新的对象不再重复接收入队通知；待所有上游变更通知接收完成后，按照依赖拓扑顺序从上游到下游执行单次求值，从根源上消除重复求值。
• 收窄依赖收集范围
  调整公式求值时的依赖收集逻辑：先静态解析公式实际引用的单元格范围，仅将引用到的单元格纳入依赖收集源，非引用单元格的变更完全不触发当前单元格的重算，从源头减少无效依赖通知。
• 增加分层脏值校验
  给每个单元格增加版本戳标记：上游单元格值变更时仅给下游依赖单元格打脏标记，不立刻触发求值；只有当单元格实际被读取（如进入视口触发渲染、被其他活跃公式引用）时才判断是否需要重算，跳过不可见区域、未被引用单元格的无效更新。
• 架构层兜底拆分
  若后续表格规模扩展到千行千列以上，直接将核心公式计算层从Knockout剥离，用独立的DAG计算引擎完成公式求值，Knockout仅负责视图层的绑定渲染，计算结果通过统一入口推送给视图，完全绕开Knockout的依赖追踪逻辑承载大规模计算。

内容的提问来源于stack exchange，提问作者Gunther Schadow