企业官网建设流程全解析

• 前端
• UI库/组件

CanJS 是一个"用更少代码构建 CRUD 应用"的客户端 JavaScript 框架，而它最让人印象深刻的技术，就是 Observation 观察者机制：数据一变，只有页面上真正受影响的 DOM 节点被精准更新，而不是像传统做法那样重新渲染整棵组件树。本文将带你快速看懂 CanJS 的这套细粒度 DOM 更新机制是如何实现的。

为什么需要"细粒度"的 DOM 更新 🎯

大多数框架在数据变化时会重新执行组件渲染，再对比新旧虚拟 DOM 来决定改哪些节点。而 CanJS 走的是另一条路：在数据被读取的那一刻就建立好依赖关系，数据变化时直接定位到需要更新的 DOM 节点。

CanJS 技术文档中是这样描述这一点的：CanJS 直接观察模板中每个魔法标签（如{{ name }}）内部发生了什么，从而"尽可能将变更局部化"——当某个 todo 的名字改变时，只有对应的文本节点会被更新，没有对整个模板的 diff 过程。

官方文档 technical.md 的 "Observation" 小节完整演示了这个行为，是理解本文最佳入口。

上图展示了 CanJS 的整体数据流：Model 层（绿色）与视图组件（橙色）之间，正是靠观察机制实现双向联动。

核心原理：ObservationRecorder 记录"谁读了数据"

细粒度更新的起点，是一个朴素的思路：如果一个值被某个函数读取过，那么它的变化就应该通知这个函数。

can-observation包提供了两套 API：

• ObservationRecorder.add(target, key)—— 在可观察值被读取时"打点"。比如给Person的getName()方法里加一行记录，之后任何时候this.name发生变化，都能追溯到"刚才谁读过它"。
• Observation—— 类似一个可观察的"推导值"，你传入一个函数，它会在执行期间追踪函数体内所有被记录下来的读取，之后自动监听这些依赖的变化。

这个机制有两个关键特性：

1. 依赖自动推断：不需要像传统框架那样声明computed("firstName", "lastName")，你在函数体里读了什么，依赖就自动是什么——哪怕依赖是动态的（比如遍历列表时读取了每个元素）。
2. 值缓存：Observation一旦被绑定，就会立即计算并缓存结果，之后只有依赖真正变化时才会重新计算，重复读取几乎零成本。

这两点在 can-infrastructure.md 的 "can-observation" 章节有完整的代码示例，对应的导出文件是 es/can-observation.js。

💡 可以这样理解：Observation就是 CanJS 里"智能缓存 + 自动订阅依赖"的合体，它是 can-compute 一切推导能力的地基。

数据一变，DOM 如何精准更新？——四层队列系统

知道"依赖被记录了"之后，下一个问题是：变化发生后，通知、重算、改 DOM 这三步怎么安排，才能保证既同步、又不重复更新？

CanJS 的答案是 can-queues 提供的四条流水线，任务按顺序逐级传递：

这套设计的妙处在于批量（batching）：一次事件循环里无论多少数据变化，同一段 UI 最多只更新一次。官方文档举了个经典例子——"一键完成所有 todo"这种循环里逐条改数据的场景，如果没有批量机制，派生值会被重复计算 O(n²) 次；有了队列，整个循环结束后 DOM 只更新一次，复杂度降为 O(n)。

这是官方 benchmark 的结果：同样的更新操作，CanJS（以 DoneJS 形态测量）每次更新耗时约 3.29ms，略优于 React 的 3.42ms 和 Angular 的 4.25ms。细粒度观察 + 队列批量的组合，是它能在更小组件粒度下保持高性能的关键。

列表变更怎么办？——can-diff 数据差异计算

细粒度更新还有一个难题：列表。当你往可观察数组里 push 一个新元素，模板里的{{#for}}渲染的是一组重复结构，直接"全部重绘"显然不划算。

CanJS 的方案是：for助手函数拿到新旧两个数组后，用 can-diff 计算出一组最小变更操作（增、删、移动），只对新元素创建新的 DOM 节点，已存在的节点原样保留（连同输入框焦点、展开状态这些副作用）。所以往列表追加一项，页面上只多出一个<div>，其余节点纹丝不动。

上图是 todomvc 实验示例的界面，它的列表增删改正是通过 Observation + can-diff 协同工作的。

实战调试：亲眼看到 Observation 的调用链 🔍

理解机制最有力的方式，是亲眼看到它运行。CanJS DevTools 提供了两个神器：

1. Bindings Graph（绑定关系图）：在 Elements 面板选中任意 DOM 节点，右侧会画出这个节点背后的完整依赖链——从DefineMap的属性，到Observation的读取，再到 DOM 更新任务，一目了然。

图中可以看到一个<span>节点背后挂着的Observation节点——这就是"这个 DOM 节点是谁在观察、观察了哪个数据"的可视化证明。

2. Queues Stack（队列栈）：在断点处暂停，侧边栏会展示当前排入队列的任务链，例如"属性 getter 更新 → Observation 依赖变更回调 → DOM 节点更新"，完整还原一次细粒度更新的全过程。

更多调试技巧（包括queues.logStack()、DOM 断点、表达式观察断点）可参考官方文档 debugging.md。

总结：CanJS 细粒度更新的三块拼图 🧩

三者配合，让 CanJS 做到了"改一个值，页面只动该动的地方"——没有全模板 diff，没有冗余重渲染。这也正是它"用更少代码构建 CRUD 应用"背后真正的工程含金量。

想动手验证？可以从 todomvc 实验 和 技术特性总览 读起，再配合 DevTools 的 Bindings Graph 边看边调，Observation 的运行轨迹会变得异常清晰。

• 前端
• UI库/组件