观看 Eelco Dolstra 这场 26 分钟的 NixCon 演讲 《Scaling Up Flakes》，最有效的入口，不在把 flakes 当成 default.nix 与 shell.nix 的一层漂亮包装，而在把它当成一次对工程代价的拆解。[1] Dolstra 在开场不到一分钟的地方就把核心问题点破了：妨碍 flakes 走向稳定化的一条重要障碍，是大型仓库在求值阶段会被整棵复制进 Nix store，这让普通开发动作也变得非常昂贵。[1]
这层判断放到 2026 年 仍然成立，因为官方文档并没有把这个议题写成“已经结束”。nix.dev 目前仍把 flakes 称作带有未决问题的 experimental extension format，参考手册则把 flake 定义成一个以 flake.nix 为根的 filesystem tree，并通过 flake.lock 的依赖图去固定输入版本。[2][3] NixOS Wiki 也继续沿用 experimental 的表述，并把这条功能线索追溯到 Nix 2.4。[5] 因而这场演讲真正值得看的地方，并非它宣布 flakes 已经成熟，而是它把其中一条最关键的工程边界讲得很清楚。
这篇文章的主判断也由此收紧。真正值得记住的，并非“flakes 好不好”，而是 当 hermetic evaluation 不再要求先把整棵 source tree 物化到 store 里时，flakes 才开始显得可信。[1][3] 若 purity 的代价，是每改一个字符就多出一份巨大的 store copy，那么 purity 会变成税；若 source tree 可以一直保持 lazy，直到某条路径真的被索取，purity 才会变得可操作。
配图说明：封面使用的是 OST 在 NixCon 2025 回顾页发布的真实会场照片，并非 Dolstra 2022 年那场演讲的现场图。它依然贴合本文，因为文章讨论的是 Nix 会议体系里反复公开争论的主题：flake ergonomics、stabilization blockers 与 scale bug 究竟该在哪里被修正。[6]
开场四分钟里，问题被写成了一条 scaling bug，而并非一条 usability complaint
Dolstra 在前段几乎没有花时间推销 outputs、templates 或 developer shell 的便利性。[1] 他先定义失败模式。大约在 0:40 左右，他直说 flakes 在大型仓库上“并不好用”，原因在于 Nix 会倾向于把整个仓库复制进 store，而这件事根本无法扩展。[1] 到 3:00 到 4:15 一段，这个代价被进一步压成具体数字：一个字符的改动，就足以生成另一份 multi-gigabyte 级别的复制；在 nixpkgs 上跑 nix build .#hello 会多出数秒等待；他本地一个例子已经吃掉了大约 93 gigabytes 的压缩后 ZFS 空间。[1]
这也是这场演讲在几年后仍然比许多生态演示更有价值的原因。它并不主要负责介绍功能，而是在追问抽象代价究竟落在了哪里。flakes 承诺了 pinned inputs，也承诺了一条更标准化的 project boundary，但支撑这些承诺的底层实现，却把大型 source tree 的本地迭代变成了笨重动作。[1][3] 这一段几乎就是对“naive purity”做的一次现场反驳。
到第六分钟左右，Dolstra 把整棵复制的理由也交代清楚了
演讲到了中段，力道反而更强，因为他开始解释机制。大约 6:10 到 7:25，Dolstra 说 Nix 过去在 reproducible builds 这件事上做得很好，在 reproducible evaluation 上却没那么强。[1] flakes 之前，两位开发者即便看的是同一个仓库，也或许因为 NIX_PATH 指向不同而得到不同求值结果；工作树里的未跟踪文件，或者 ../ 这样的外部引用，也会把环境污染带进 evaluation。[1] 把所有东西先复制进 store，是隔离这些污染的一条简单做法，只是代价过高。
这一层和今天的参考手册是能接上的。nix flake 文档写得很明确：lock file 是一个 UTF-8 JSON graph，结构与 root flake 的依赖图同构，作用就是把输入钉到准确 revision 上。[3] nix flake lock 一页又把这条承诺推到操作层面：输入更新是显式动作，某条依赖边可以用 --override-input 有针对性改写，而并非让机器上的偶然状态替你决定结果。[4]
因此这场演讲真正提出的，并非“因为大仓库麻烦，所以把 purity 放松一点”，而是“在不放弃 hermetic evaluation 的前提下，把原来那张存储账单重新分配”。[1][3][4]
大约从 9:30 开始，lazy trees 改写的是 materialization 的时机
最值得重看的部分从 9:26 左右开始。Dolstra 演示 fetchTree 不再需要返回一个 outPath 已经落在 Nix store 里的 attribute set。[1] 它可以返回一种他口中的 “magic value”，这东西仍然带着 provenance，打印出来时也还能说明源头，却不要求整个仓库立刻被复制进 store。[1]
这件事听上去细，但后果很大。到了 10:13 一带，他直接说出一句最关键的话：nothing gets copied to the Nix store unless you ask for it。[1] 你可以继续沿着 tree 走到某个 README.md，这个状态依然是 lazy 的；真正的 materialization，要等到那条路径必须变成 derivation input，或者必须被强制转成 store-facing 表示时才发生。[1] 后面 13:15 到 14:25 一段，他又把 patched source tree 与 accessor 的做法摆出来，说明 patch 甚至可以沿着 access path 在内存里生效，而不需要先把整棵树急着复制出来。[1]
这一段正是本文判断的中心。很多人讨论 flakes 时，把重点放在用户界面层的标准化上；这场演讲提醒你，flakes 能不能站住，取决于更底层的一条 storage 与 evaluation contract。参考手册今天仍把 flake 写成 filesystem tree，并强调它可以来自 Git 仓库或 tarball。[3] Dolstra 这一讲真正改写的，并非“tree 是什么”，而是“tree 何时才需要成为 store data”。答案从“立刻”改成了“按需”。
最后一段真正讨论的是代价，而并非 triumph
若演讲在 lazy-tree demo 结束处收尾，它会弱很多。Dolstra 没有那样做。他在后段把兼容性代价讲得很直接。大约从 17:20 开始，他解释 flake lock files 不再为所有 inputs 都保留 narHash，因为要计算这个值，就必须把整棵 source tree 读完，而那恰恰是新设计想避开的工作。[1] 旧版本 Nix 因而会抱怨缺少 narHash；一些把 path 当成本地文件系统表示或 store-path 类型检查的习惯，也会因此失效。[1]
也正因为这一层还在，今天 nix.dev 对 flakes 的措辞才依然重要。截至 2026 年 3 月 28 日，概念页仍然把 flakes 归在 experimental 下。[2] NixOS Wiki 也维持同样的边界，并没有把它写成已经尘埃落定的基础设施。[5] 把这些材料与演讲并读，会得到一个更扎实的结论：lazy trees 处理掉了一条很大的 scaling blocker，但它没有自动替 flakes 完成全部 stabilisation 工作。
如果今天重看这支视频，最值得数一数的是 Dolstra 把时间花在了哪里。关于 flakes 是什么，他只做了很短的回顾；真正的大块篇幅，放在 evaluation pollution、store-path 时机、provenance，以及 lock-file semantics 变化之后会坏掉什么。[1] 这正是最耐看的地方。让 flakes 变得可用，真正困难的部分，从来不只是 inputs 与 outputs 的语法，而是 hermeticity 究竟在哪一层被强制执行，以及团队要为这件事支付多少存储与迭代代价。
来源
- NixCon，《Scaling Up Flakes》，YouTube 视频，发布于 2022 年 11 月 10 日。
- nix.dev，《Flakes》概念指南——当前 experimental 状态、依赖模型与
follows语义。 - Nix Reference Manual，
nix flake——filesystem tree 定义、依赖图与flake.lock结构。 - Nix Reference Manual，
nix flake lock——lock file 更新方式与--override-input行为。 - NixOS Wiki，《Flakes》——功能背景、Nix 2.4 起点与当前 experimental 定位。
- OST Eastern Switzerland University of Applied Sciences，《OST hosts NixCon 2025》——会议回顾与配图来源。