第 5 卷
复制代码 1[logger] 启动（level=debug）
- 改代码：把 plugins/chat.ts 里的 [chat] 收到：改成 [chat] 收到【改代码】：
存盘。这条链路清掉模块缓存、重新 import，让两个 chat 一起换成新代码（它们共用同一个插件），而 shell、logger 全程无感。
实测（Node 24.20.0；临时挂上 console logger 就能看到 HMR 自己的日志）：
复制代码
| 1 | [D]hmr change detected at plugins/chat.ts |
|---|---|
| 2 | [I]hmr reload plugin at plugins/chat.ts |
| 3 | [chat]收到【改代码】：[mock/mock-chat]回复：你好 |
| 4 | [chat]收到【改代码】：[b-provider/b-model]回复：你好（我看到shell配置：{"model":"int |
两个 chat 同步换装，shell 与 logger 一行没动，正是“共用同一份插件代码”的样子。
这就是 HMR 的两条链路：一条改配置、一条改代码，目标都是不重启进程就让改动生效。两条路的机制其实是同一件事，旧实例干净卸载、新实例按依赖重新就绪（这正是第一讲的
effect 回收 + 第二讲的依赖编排）。
改 cordis.yml 时，include 靠 id 对账找出“哪个条目变了”，只重挂那一个：
fiber.restart() 先停后走，停是回收它的全部 effect，走是用新配置重新 apply。所以没写 id 的条目，每次重读都会生成新随机 ID、被当成删旧加新，整棵子树重挂，精准热更
新失效——写 id 是热更新能精确到单个插件的前提。
改插件代码则绕过配置树：清掉模块缓存、重新 import 拿到新代码， registry.plugin(新代码, 旧配置) 原地换新，配置原样保留。所以改代码是按模块换的
——共用这份代码的所有实例一起换装；改配置是按条目换的——只重挂变了的那一个（如果是组，则连坐它的子树）。这正是上面两个实测的区别。
本讲小结
今天这一讲，我们补齐了基础篇的最后一块拼图——装配。
我们学会了用一份 cordis.yml 长出一棵树：id 认人、disabled 留枝、!!js 取活值、 group 分组、isolate 分世界、intercept 叠配置；config 进 apply 之前先过
schema 安检；改完想立刻生效，就交给 HMR——改配置走 fiber.restart 先停后走，改
而这一切换汤不换药，配置只是换了个说法，跑的还是前三讲那套 Context / Fiber / Effect / Service。
这，就是插件树的本质——用一份声明，让框架把整棵插件树给你长出来。
到这里，基础篇四讲的拼图拼完了：第一讲给了你时间上的可逆（插件可挂载，也能干净卸载），第二讲给了你空间上的协同，第三讲给了你通信，这一讲则回答了最后一个问题，这棵
树该怎么装配。从“一步步指挥框架干活”到“只描述想要什么”，你已经走完了 Cordis 的运行机制；下一讲开始的核心篇，将在这套机制之上长出真正的 Agent 能力。
注：本讲 GitHub 链接
思考题
动手实操：给 cordis.yml 里的 tenant-a 组也加一段 intercept（就放在它已有的 isolate: 下面、config: 上面，字段写法照抄 tenant-b 那段），重新跑 main.ts，观
察 a-chat 那行的输出有什么变化。再想一想：它注入的 shell 实例，还是原来那个 mock 吗？
小改动：把 spare 条目的 disabled: true 改成 false，重新跑 main.ts，看它这次是否启动、注入的是哪个 shell。
欢迎把你的运行结果分享出来。如果你觉得这节课对你有帮助，也欢迎分享给其他朋友，我们下节课再见！
© 版权归极客邦科技所有，未经许可不得传播售卖。页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。