Cordis Proxy反射系统如何完整揭秘上下文自动回收原理

Cordis Proxy反射系统如何完整揭秘上下文自动回收原理

【免费下载链接】cordisMeta-Framework of Spatiotemporal Composability项目地址: https://gitcode.com/GitHub_Trending/co/cordis

写一次ctx.provide('database')，之后任何插件都能直接ctx.database拿到服务，不用传参。更微妙的是：提供该服务的插件被卸载后，引用它的代码会被自动拆掉再重装。这不是通灵术，而是 Cordis 的 Proxy 反射系统——你手里的每个 Context 都是代理对象，每次属性读写都要多走一道拦截。

架构鸟瞰：Proxy反射系统的三个主角

把整个反射系统摊到白板上，只有三块：

• Context（context.ts）：门面。构造函数结尾把this包进 Proxy 再返回，外部永远拿不到"素颜"对象。
• ReflectService.handler（reflect.ts）：守门员。get/set/has三个陷阱决定每次属性读写流向哪里。
• Fiber（fiber.ts）：户口本。每个插件对应一个 Fiber，记录它提供了哪些服务、注入了哪些依赖，也是卸载与重装的最小单位。

一句话版本：Context 是门，ReflectService 是门卫，Fiber 是楼里的住户名册。

一次ctx.database属性访问的完整拦截链路

现在跟着一次属性读取走完全程。

第一步：new Context()时门就换过了

构造函数最后几行就是全部玄机：

constructor() { this[symbols.isolate] = Object.create(null) this[symbols.intercept] = Object.create(null) const self = new Proxy<this>(this, ReflectService.handler) this.root = self this.fiber = new Fiber(self, {}, Object.create(null), null, () => []) // ... 挂载 reflect/registry/events/logger return self // 外部拿到的永远是代理 }

从这一刻起，任何读写都会先进陷阱。

第二步：get 陷阱对三类请求的处理

执行ctx.database时命中 reflect.ts 的 get 陷阱：

get: (target, prop, ctx) => { if (isSpecialProperty(prop)) return Reflect.get(target, prop, ctx) if (Reflect.has(target, prop)) { return getTraceable(ctx, Reflect.get(target, prop, ctx)) } const error = new Error(`cannot get property "${prop}" without inject`) return ctx.events.waterfall('internal/get', ctx, prop, error, () => { /* 沿 fiber 链向上找 impl，见下 */ }) }

分支顺序很直白：

1. 特殊属性放行——Symbol、then、prototype、数字串、下划线开头直接透传。不放行then的话，谁await ctx都会把它误判成 Promise。
2. 真实存在的属性放行——如果对象上真有这个属性，返回值前还要过一遍"可追踪化"包装，后文细说。
3. 服务查找兜底——两者都不命中，才进入服务查找流程。

第三步：服务查找用"门牌符号"而非字符串

查找用的 key 不是字符串database，而是一个 Symbol：ctx[symbols.isolate]['database']。每个上下文有自己的一套符号表（isolate 表），服务实现存在ReflectService.store里，以符号为键。因此同一个服务名在不同上下文分支可以指向不同实现——你用ctx.isolate('database')就能给某个分支单独换一套实现，互不污染。这正是 Cordis 所谓"空间隔离"的地基。

拿到 key 后沿 Fiber 链向上找：当前 fiber 的 store 里有实现就返回；没有则查父 fiber，直到根部。途中有两个判断：

• 如果该属性在inject列表里却找不到，抛cannot get required service ... in inactive context——声明过的必需依赖缺失，比随便找个可选属性缺失更严重，必须单独报出来；
• 如果父层的 isolate key 对不上，也直接中止，确保只能借用"同名同牌"祖先的服务。

找到实现后并不裸奔返回，还要经过getTraceable（utils.ts）：

export function getTraceable<T>(ctx: Context, value: T): T { if (!isObject(value)) return value if (Object.hasOwn(value, symbols.shadow)) { return Object.getPrototypeOf(value) } const tracker = value[symbols.tracker] if (!tracker) return value return createTraceable(ctx, value, tracker) }

🔍 这里才是真正转折：带tracker标记的服务对象会被再包一层 Proxy。服务内部写this.ctx时拿到的是调用方所在的上下文，而不是它被注册时的上下文。

为什么多包一层而不是直接返回原对象？这是一个刻意的取舍。若服务绑定注册时的 ctx，那插件在隔离上下文里用它时，intercept 配置覆盖、isolate 边界统统失效——这些都挂在调用侧上下文上。代价是每次访问多一层 Proxy 开销，换来的是"谁调用，服务就活在谁的环境里"。

第四步：为什么查找要经过internal/get事件流

你可能会问：查表而已，为什么还要走events.waterfall('internal/get', ...)？

看 waterfall 的签名：error 对象会被传给每个监听器，监听器可以直接替换实现并短路默认行为。这给"热替换"留了口子——hmr 包就是靠这个机制在开发时原地换服务实现的。直查表只需一行store[key]，走事件流则意味着系统里任何人都能中途改答案——Cordis 选了慢而开放，没选快而封闭。

provide 的真身：绑定插件生命周期的服务登记

ctx.provide('database', db)并不是把db塞进一个 map。reflect.ts 里它实际登记的是：

return this.ctx.fiber.effect(() => { this.ctx.root[symbols.isolate][name] ??= Symbol(name) const key = this.ctx[symbols.isolate][name] const impl: Impl = { name, value, fiber: this.ctx.fiber, check } if (this.store[key]) { throw new Error(`service "${name}" has been registered at ...`) } this.store[key] = impl }, `ctx.provide(${JSON.stringify(name)})`)

📌 注意最外层的this.ctx.fiber.effect(...)：整个登记动作本身被注册为当前 Fiber 的一个"effect"。这意味着：

• 插件卸载时，store[key]先被删除，接着notify([name])遍历所有注入该服务的 Fiber，逐个触发_refresh()；
• 返回的 disposable 也可以手动调用，效果相同——同一服务能反复登记、注销、再登记，每次都有明确的开头和结尾。

check参数也值得记住：它是一个可选谓词，刷新时若check()返回 false，该实现视为不存在，依赖方随之卸载。服务不只是值，还是一份"我可能随时消失"的契约。

依赖变更时插件为什么能自动重装

最后一块拼图在 fiber.ts。每个 Fiber 持有一个epoch，_refresh()的算法极其朴素：

for (const name of Object.keys(this.inject)) { const impl = this._store[name] if (!impl) { epoch = INACTIVE break } epoch += ':' + impl.fiber.uid } this._setEpoch(epoch)

epoch 就是把每个依赖的提供方插件 uid 拼成一个字符串。插件实例每次重装，uid 都会变；于是上游服务只要重装过一次，下游 Fiber 的 epoch 字符串就对不上了。_setEpoch检测到差异后触发_unload()——按创建逆序跑完所有 disposer——再跑_reload()重新执行插件函数。

这就是"自动重装"的全部：没人手动调用重装，只是版本号变了，旧的必须死、新的必须生。它同时解释了 Cordis 为何敢宣称不泄漏：定时器、监听器、服务登记全部 push 进fiber._disposables，卸载时严格倒序清理，任何副作用都有销户登记。

Cordis 反射系统三个易踩的失败模式

1. 未声明就访问。服务没注册时执行ctx.database，get 陷阱直接抛cannot get property "database" without inject（reflect.ts）。想先声明后赋值，正确顺序是provide()再set()。

2. 未声明就写入。set 陷阱（reflect.ts）与 get 对称：属性没声明就抛cannot set property "foo" without provide。这套"先声明、后使用"的约束，从源头掐掉了插件系统最常见的冲突来源——两个插件写到同一个 key 上互相覆盖。

3. 重复注册与跨 fiber 写。同一分支内同名服务只允许登记一次，第二次provide抛service "foo" has been registered at <root>，错误信息直接告诉你是谁先占的坑。反过来，服务实现的fiber在登记时就锁死了，别的 Fiber 想改它的值，cannot set property "foo" in multiple fibers立刻拦下。

这三道防御的共同思路：在陷阱层、在访问发生的那一刻把错误抛出来，而不是等运行时悄悄返回 undefined。Cordis 甚至专门写了enhanceError重写堆栈，让报错直接指向最外层调用点。🧩

可迁移的设计启示

1. 访问即拦截：把"属性访问"本身当成 API 钩子。设计 DI 容器时，ctx.service比container.get('service')更直接，Proxy 就是你的拦截点。
2. 生命周期即清单：副作用不要散装。定时器、监听器全部登记为 disposer，卸载时按创建逆序清空，资源才能反复加载而不泄漏。
3. 版本号驱动更新：需要"依赖变更自动重启"时，试试 epoch 技巧——把依赖方 uid 拼成版本号，号一变就先卸后装。

Proxy 本身没有魔法，它只是让每一次访问可被检查、每一次登记可被撤销、每一次变更可被追踪。

【免费下载链接】cordisMeta-Framework of Spatiotemporal Composability项目地址: https://gitcode.com/GitHub_Trending/co/cordis