为什么不用微服务、容器、Actor 或 OSGi 就好了
学完你会：理解插件化与进程隔离、服务化、Actor、OSGi、React Effect 的互补关系，避免技术宗教。
越向外，责任越具体；内层能力不能自动拥有外层权威。
Cordis 擅长同一受信宿主内的细粒度动态组合；进程、容器与服务边界擅长故障和信任隔离。企业系统需要双层甚至多层答案。
插件化与微服务在优化不同成本
插件减少同一宿主内的组合成本，服务边界减少跨团队和故障域的耦合。
微服务把能力放在独立进程与网络边界，能独立部署、扩容和隔离故障，但带来协议、运维、延迟与分布式一致性成本。插件在同一进程内组合更轻、更快、共享类型和上下文，却共享宿主权限与故障爆炸半径。
Cordis 论文批评粗粒度方案无法优雅处理大量细小动态依赖，这是合理的；但粗粒度隔离仍不可替代。让不可信客户扩展与 Core 同进程运行，只因为 disposer 很漂亮，是把生命周期问题误当成安全问题。
推荐的双层结构是：受信、同版本、低风险的细粒度能力在进程内组合；不可信、高副作用、语言异构或资源密集的 Runtime/Provider 通过进程或容器隔离，并由企业协议连接。
Actor 与 Supervisor 提供什么不同视角
Actor 更关心隔离状态和消息，Supervisor 更关心失败后谁来重启谁。
Actor 模型把状态封装在独立单元中，通过消息通信，避免共享可变状态。Supervisor tree 则把失败当作常态：子节点崩溃后由父节点决定 restart、stop 或 escalate。它们对长期运行 Agent Runtime 的故障管理很有启发。
Cordis Fiber 记录插件生命周期，但并不等同于 Erlang 式故障隔离。一个宿主插件抛出未捕获错误、耗尽内存或执行恶意代码，仍可能影响整个 Node 进程。我们可以借 Fiber 的状态解释，也借 Supervisor 的重启策略，却仍需进程所有权和资源限制。
在 Lumi 中，ExecutionSessionRef 可以表现出 supervisor 思维：平台拥有子进程、知道 termination scope、限制自动重启，并在外部副作用不明时升级为 outcome_unknown。
OSGi 的成熟与复杂度都值得学习
动态模块、服务注册和生命周期早有成熟实践，也早有复杂度教训。
OSGi 提供 bundle 生命周期、服务注册、版本与动态解析，是理解成熟插件平台的好对照。它证明动态服务不是新问题，也展示了当版本、类加载和依赖解析进入生产后，运维和调试会迅速复杂。
DeepSeek Harness/Cordis 的开发体验更现代、表达更轻，但未来同样会遇到版本范围、依赖冲突、升级兼容和可观察性。与其等生态扩大后再补，不如早期就把 exact artifact、closure digest、兼容矩阵和 deprecation window 纳入企业扩展协议。
学习前人的目的不是复制 OSGi，而是避免重复把“动态加载成功”误认为“长期演化问题已经解决”。
React Effect 是好入口，但不是同一个理论
熟悉的 cleanup 能建立直觉，不能代替对 Cordis 运行时语义的理解。
React useEffect 让 UI 组件与外部系统同步，依赖变化或卸载时执行 cleanup。它和 Cordis disposer 都强调创建与清理靠近，因此是很好的教学桥。
区别在于 React Effect 服务于渲染生命周期与依赖数组；Cordis Context 还管理服务注入、插件层级、作用域、Fiber 状态与动态依赖。把两者说成完全相同，会掩盖 Cordis 的运行时组合贡献。
真正成熟的技术学习既要会找类比，也要会及时放下类比。类比负责让你进入，边界负责防止你误用。
你真正要带走的，不只是技术解释
切换身份，看看这项技术会怎样改变战略、产品、工程和长期运营。
架构选择要看风险和组织成本，不要把开源项目的核心叙事直接变成公司的技术宗教。
四张可以带走的卡片
插件与微服务优化不同成本
Fiber 不等于故障隔离
OSGi 提醒我们版本复杂度
类比帮助入门，边界防止误用
面对不可信且有高副作用的第三方扩展，最合适的边界是什么？
把理解变成自己的语言
试着写下：这项机制能解决什么、不能解决什么，以及它会怎样影响你的产品判断。内容只保存在当前浏览器。
原文与源码放在最后，不打断学习
正文已经完成中文梳理。只有当你想核验作者原话、查看完整公式或进入代码时，才需要离开本站。