加载失败
讨论源自一篇比较“推（push）、拉（pull）、混合”三类反应性算法的文章，评论集中在实现细节与开发者期望如何影响选择。评论以前端生态为例：Vue（一个 JavaScript 运行时 reactivity API，使用 ref/computed）通常在第一次读取时动态记录依赖，而 Svelte（一个以编译期静态分析著称的前端框架）倾向于在编译阶段生成依赖图，但有人指出 Svelte 5 也引入了运行时接线。有人分享了 Rust 项目 hornpipe（GitLab 上的 reactivity 实验），提出用事务性内存与 CRDT 处理并发与撤销/重做问题；另有读者推荐了 lord.io/spreadsheets 这类更深入的比较文章并讨论了 glitch hazards（更新中间不一致）等工程挑战。整体讨论在理论（图论、拓扑排序）与工程实现（数组 vs 指针、脏位掩码、缓存）之间来回权衡，提出了若干未决的运行时一致性问题。
评论指出开发者期望的语法/体验会直接决定采用的反应性算法。以 Vue 的 ref/computed 为例（const input = ref(1); const output = computed(() => ref.value + 1);），在不执行 computed 的闭包前无法静态得知依赖，因此多数 signals 类库在第一次读取时执行计算并记录依赖（pull），随后输入变更时用已记录的图来推送更新（push）。这种运行时接线允许任意 JS 控制流和复杂表达式，而唯一的替代是像 Svelte 那样通过源码静态分析在编译期生成依赖图。评论里还有补充指出 Svelte 5 在某些场景下也提供运行时接线的能力，模糊了纯粹“静态”与“运行时”界限。
有评论以编译与运行期实现细节展开，强调要把抽象的图论属性与实际的运行时数据结构区分开来。讨论区分 dataflow graph（数据流图，边从源指向汇）与 dependency graph（依赖图，边方向相反），并指出遍历方向决定高效遍历策略：如后序遍历（children-first）、sense-reversing 访问标志以及缓存拓扑排序以稳定次序。提出工程优化：用数组替代指针链表以提高迭代速度、为节点分配连续整数 id 并维护每个源的下游位掩码，然后通过位或更新全局 dirty_nodes，再按拓扑序仅处理脏节点；同时提醒在节点规模或更新模式不同情况下可能存在“遍历整个数组比有选择更新更快”的临界点。评论还把惰性求值和在节点评估期间的动态重配置列为需要特别设计的复杂场景。
多人分享了现成实现与延伸阅读：有人维护的 Rust 反应性工程 hornpipe（托管在 GitLab）尝试用事务性内存和 CRDT 来缓解并发修改并提供撤销/重做功能。作者与读者推荐了更深入的比较文章（lord.io/spreadsheets）和 lobste.rs 的讨论，后者细致比较了多种库的实现细节并分析了 glitch hazards（更新中间不一致或闪烁问题）。评论区对文章的图示风格也有讨论——作者把手绘草图转为 SVG 并有人建议用 tldraw 等工具快速制作近手绘风格的技术图。社区既关注理论差异，也在交换可复用的工程实践和代码仓库链接以便进一步探索。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
评论提出若干开放问题：当图在评估期间发生动态重配置（例如删除尚未计算的节点或插入新子图）时，系统应如何保证遍历一致性与正确的更新顺序。有人建议用事务性内存或 CRDT 处理并发与分布式场景，但也指出这些方案会引入额外复杂性与同步开销。与此相关的“glitch hazards”分析提示，在异步或惰性求值模型下避免临时不一致需要精心设计的调度与同步策略，读者期待作者或实现者给出更具体的收敛/修复机制与边界条件处理方案。
Pull（拉/请求式）与 Push（推/主动传播）: Pull 在读取某个输出时触发评估并在评估过程中记录依赖，适合按需（惰性）求值；Push 在源变化时把变更沿已知依赖图主动传播到下游节点，适合即时更新。许多现代 JS signals 库采用 Pull-on-read + Push-on-change 的混合策略。
dataflow graph（数据流图） / dependency graph（依赖图）: dataflow graph 的边从数据源指向使用者（sources→sinks），dependency graph 常把边指向依赖的源（sinks→sources）；两者连通性相同但遍历方向不同，影响高效更新与遍历实现。
拓扑排序（topological sort）: 对有向无环图按依赖关系线性排列的算法，缓存拓扑序可在更新时保证稳定的处理次序并避免重复排序。
脏节点位掩码（dirty bitmask）: 为每个节点或源维护位掩码表示其下游受影响集合，源变化时用位或把这些掩码合并到全局 dirty_nodes，然后按拓扑序只处理标记为脏的节点以加速更新。
CRDT（Conflict-free Replicated Data Type）: 一种用于分布式系统的无冲突复制数据类型，设计能在不同副本并发更新时自动合并并保持最终一致性，评论中被提作处理并发修改与撤销/重做的一种手段。
glitch hazard（闪烁/中间不一致）: 在异步或部分更新场景中可能出现的暂态不一致状态（例如部分下游尚未收到更新），会导致 UI 短暂闪烁或错误中间值，是反应性调度需要避免的情形。