第 6 卷

stateVersion 对不上，那一行就被直接丢弃、整份重算，而不是拿旧规则去接着算新事件 ——那只会把缓存喂成一堆垃圾。

顺带划清一个容易混的东⻄：它跟崩溃恢复用的持久化检查点不是一回事。后者管的是日志本身接不接得上（那是第 09 讲的事），前者只是投影的加速手段，丢了不过是下次多翻几行账

本。

本讲小结

今天这一讲，我们回到了会话这条主线，把状态存哪儿这件事讲清楚了。

我们看清了：一次会话就是一份只能追加的事件日志，seq 连号、进日志即冻结、非无损 JSON 在入口被拒，读不懂的事件也默认拒绝重建；只有三种事件进 surface 并算成消息——

8 条事件最终只算出 3 条消息；而投影把这套“从日志算东⻄”的做法通用化了：交出 init/apply/view 三个纯函数，驱动、缓存与通知全由框架接管。

这背后真正的变化是，你不再把消息历史当成一份需要单独维护的数据，而是把它看成一份从日志算出来的投影；历史根本改不动，能做的只有“再追加一条”。

这，就是会话日志的本质：只追加的日志保证只有一份说了算的历史，谁都改不了；投影保证任何人想要任何一种视图，都能从这份历史里算出来，不必另存一份可能与真相打架的副本。

两者合起来的效果是——不管你想看模型眼里的会话、想数这一轮跑了多少步，还是要在中断之后完整重放，答案永远只能来自同一个地方：那本谁都改不了的流水账。

有了这份日志，很多事情才有了着落：它怎么落盘、断了怎么接上、太长怎么压缩、跨会话怎么检索——这些我们接下来一讲一讲拆开看。下一讲先聊最实际的一个：会话续接——fork、

resume 与崩溃修复。

注：本讲 GitHub 链接

（user/message 别漏了 surfaceOp，对这个类型是必填的），重新跑 npm run start:ch08。观察三个数字：事件总数、deriveMessages() 的条数、

surface.nodes。想一下为什么消息只多了 1 条而事件多了 3 条，多出来的那两条属于哪一类？提示：它们是本节说的记账事件。

小改动：在 projection-demo.ts 里，把 apply 最后那句 return state 改成 return { ...state }（也就是无论什么事件都返回一个新对象），重新跑 npm run

start:ch08:projection。变更通知次数变成了多少？和原来的 3 次差在哪儿？这印证了本讲的哪条约定？

欢迎把你的运行结果分享出来。如果你觉得这节课对你有帮助，也欢迎分享给其他朋友，我们下节课再见！

© 版权归极客邦科技所有，未经许可不得传播售卖。页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。

精选留言

由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。