请解释在 Koa 框架中，如何实现针对中间件的依赖注入？请描述具体的实现方式或设计模式。
考察说明
考查对 Koa 中间件机制的理解，以及如何通过设计模式实现依赖注入，提升应用的可测试性和可维护性。
回答思路
- 【回答框架 1】Koa 中间件是异步函数，接收 ctx 和 next 参数，通过组合形成洋葱模型。依赖注入的核心是将中间件依赖的组件（如数据库连接、配置、服务实例）从外部传入，而非在中间件内部自行创建。
- 【回答框架 2】常见的实现方式有三种。第一种是工厂函数：定义一个接收依赖参数的函数，返回中间件函数，例如 const middleware = (db) => async (ctx, next) => { ctx.db = db; await next(); }。这种方式简单直观，在应用启动时组合依赖。
- 【回答框架 3】第二种是利用 Koa 的 context 对象：在应用初始化时，将共享依赖挂载到 app.context 上，如 app.context.db = db，然后中间件中通过 ctx.db 访问。这种方式方便，但需要注意命名冲突和模块化。
- 【回答框架 4】第三种是使用 IoC 容器（如 inversify）或依赖注入库：通过装饰器或注册表管理依赖，在中间件中通过容器解析依赖。这种方式适合大型应用，但会增加复杂性和学习成本。
- 【回答框架 5】实际项目中，我倾向使用工厂函数方式，因为它显式、易测试，且与 Koa 的轻量特性契合。同时，结合模块化设计，将依赖的创建集中在入口文件或配置模块中。
- 【关键点 1】依赖注入的核心是将依赖从内部创建改为外部传入，提高可测试性和可替换性。
- 【关键点 2】Koa 中间件本质是函数，可通过高阶函数（工厂函数）注入依赖。
- 【关键点 3】利用 app.context 挂载共享依赖是一种简单有效的方式。
- 【关键点 4】使用 IoC 容器适合大型项目，但需权衡复杂度。
- 【易错点 1】将依赖直接写死在中间件内部，导致难以测试和替换。
- 【易错点 2】滥用 context 挂载导致命名冲突或内存泄漏。
- 【易错点 3】过度设计，引入复杂容器反而增加维护成本。