波仔
🐳 第五章 Cordis让插件能够动态组合
📄 一句话概括

Fiber ＝ 插件实例一段生命周期的账本：谁装的、依赖谁、声明了什么、何时结束、跟谁一起结束——5.1 的【能撤下】全靠这本账落地。

📝 本节和前面几节的关系

前面四节讲了规矩，这一节讲记账的载体——没有账本，所有规矩都是口号。

一、账本上记什么

四条对应四件事：来源可查、顺序可定、恢复可依、边界可判。

二、为什么记【实例】而不是【类】

同一个插件装两次，就是两段独立的生命周期、两本账。

如果账记在【类】上，撤 A 就会把 B 一起带走——粒度错了，一切白搭。

这也是 3.2.1 那句【能力跟会话生灭】的记账版：每个会话一份实例，每个实例一本账。

三、账本让规矩可执行

回头看前三节的规矩，全靠这本账：

规矩负责说清该怎样，账本负责证明做到了。

四、账本思想的通用性

这套思路哪里都在用：

能记账的系统才敢做动态的事——静态系统靠小心，动态系统靠账本。

五、动手 Demo：Fiber——插件实例的账本

账本四栏，各自回答什么问题：

book = [
    ("谁装的、何时装", "这件东西是哪来的"),
    ("依赖了谁、被谁依赖", "撤它之前要先动谁"),
    ("声明了哪些 Effect", "撤下时要恢复哪些现场"),
    ("何时结束、跟谁一起", "清理的边界到哪儿"),
]
for a, b in book:
    print("  %-16s -> %s" % (a, b))
print()
print("  记实例不记类: 同一插件装两次 = 两本账")

实跑输出：

--------------------------------------------------------------------
Fiber——插件实例的账本
--------------------------------------------------------------------
  Fiber ＝ 记录插件实例**一段生命周期**的账本。

  账上记什么                 回答什么问题
  ------------------------------------------------
  谁装的、什么时候装的       这件东西是哪来的
  依赖了谁、被谁依赖         撤它之前要先动谁
  声明了哪些 Effect          撤下时要恢复哪些现场
  何时结束、跟谁一起结束     清理的边界到哪儿
  ------------------------------------------------

  有了这本账，5.1 的【能撤下】才从口号变成可执行的动作：
  **照着账本逆序恢复，一件不漏。**

  注意 Fiber 记的是【实例】不是【类】——同一个插件装两次，
  就是两段独立的生命周期、两本账。

记实例不记类是粒度的关键——撤 A 不带走 B。 四栏账让前三节的规矩全部可执行——规矩说清该怎样，账本证明做到了。 账本思想在数据库事务、Trajectory、出处注释里反复出现——动态系统的通用底座。

30 秒实验

  1. 把账本四栏背下来，各配一个【没有它会怎样】。
  2. 解释：为什么撤实例 A 不能影响实例 B？
  3. 找一个你熟悉的【记账系统】（Git？账本 App？），说说它和 Fiber 的共同点。

常见误区

  1. 错误：Fiber 是性能优化用的轻量线程。——纠正：这里的 Fiber 是插件实例的生命周期账本——跟并发模型里的 Fiber 只是重名。
  2. 错误：账记在插件（类）上一份就够。——纠正：必须记到实例——同一插件装两次就是两段独立生命周期。
  3. 错误：有账本太啰嗦，直接删就行。——纠正：没有账的删除就是脏撤下——悬空引用从这儿来。
自测三问（点开对答案） 1. Fiber 的账本记哪四栏？ —— 来源（谁装何时装）、依赖关系、Effect 声明、结束边界（何时跟谁一起结束）。 2. 为什么按实例记账？ —— 同一插件装两次是**两段独立生命周期**——按类记账会让撤 A 带走 B。 3. 账本和前三节的规矩什么关系？ —— **规矩说清该怎样，账本证明做到了**——5.1~5.3 全靠它落地。

相关笔记