这一章要解决的问题不是“Cordis 有哪些 API”，而是“为什么一个 Runtime 最后会需要 Context、Plugin、Service、Event、Lifecycle 和 inject 这些抽象”。如果一开始直接背定义，这些概念很容易显得分散；但如果从一个足够小的程序出发，让需求一步步增长，就能更自然地看到它们为什么会出现。这一章配套的示例代码仓库是 cordis-from-zero，阅读过程中如果想对照实现，可以直接配合仓库一起看。
这一章会一直围绕一个很小的“问候程序”展开。我们会先从最简单的变量切换开始，再逐步加入模块解耦、资源清理、动态依赖和多个依赖方。每往前走一步，都先看普通 TypeScript 实现遇到了什么新问题，再看 Cordis 是如何接住这个问题的。这样做的目的不是证明框架总比手写代码更好，而是把 Runtime 抽象出现的条件讲清楚。
这一章要建立什么认识
读完这一章，最重要的不是记住几个名词，而是建立下面这条判断：
Cordis 不是在解决“怎么调用一个 Service”，而是在解决“一个长期运行、能力会动态变化的系统，如何统一管理能力、依赖以及它们的生命周期”。
为了把这件事讲清楚，这一章会按下面的顺序展开：
text
一个变量
↓
多个实现
↓
Event
↓
资源清理
↓
动态依赖
↓
多个依赖方
↓
生命周期管理
↓
Runtime这一章的阅读顺序
- 1.第一篇：从一个变量开始，理解 Context、Service 和 Plugin — 先从最简单的变量切换开始，对比 Vanilla 和 Cordis 的最小实现，建立
Context、Service、Plugin的基本印象。 - 2.第二篇：从日志需求出发，理解 Event 和 Lifecycle — 在“打招呼以后还要记日志”的需求下，引出
Event，并进一步看到为什么事件系统最后会落到Lifecycle。 - 3.第三篇：从 Greeter 依赖 Clock 出发，理解 inject — 让
Greeter开始依赖一个会动态出现和消失的Clock，从而理解inject到底在管理什么。 - 4.第四篇：当多个模块共享同一依赖时，会发生什么 — 再加入第二个同样依赖
Clock的模块，观察系统规模一扩大，为什么手写同步逻辑会迅速变成胶水代码。 - 5.第五篇：回头看 Cordis 的核心概念，以及它为什么像 Agent Runtime — 最后把前面的推导统一收束起来，重新理解这些概念之间的关系，并把它映射到更真实的 Agent Runtime 场景。
这一章的读法
这一组文章适合顺着读，但每一篇也都尽量保持自成体系。也就是说，你可以把它看成一条连续的推导链，也可以在某个具体问题上单独停下来，比如只先看事件、只先看依赖，或者最后再回头统一整理概念。
下面先进入第一篇，从最简单、也最不需要框架的地方开始。