IoC 在复杂业务中生效的前提是主动将“谁创建、用哪个实现、何时初始化”三件事移出模块内部；否则即使使用 @Autowired 或 import，硬编码 new 仍导致测试困难、替换成本高、演进受阻等现实问题。
直接说结论：在复杂业务中，IoC 不是靠加个注解或引入 Spring 容器就自动生效的；它生效的前提是你主动把“谁创建、用哪个实现、何时初始化”这三件事从模块内部移出去。否则，哪怕用了 @Autowired，只要组件里还藏着 new UserService() 或硬编码 import { RealPayment } from './payment'，耦合就还在。
为什么“组件里 new 依赖”是耦合的硬伤
这不是风格问题，而是测试、替换、演进的现实障碍：
- 单元测试时无法注入
MockPaymentService，只能走真实支付通道，要么失败，要么污染环境 - 业务要求灰度切到新风控策略时，得全局搜索
new RiskCheckerV1()，逐个替换成RiskCheckerV2()，漏一处就出线上问题 - 某个服务初始化需要 token 或配置上下文，但组件构造函数没留参数入口，只能改源码、发版、等发布窗口
这些不是理论风险——它们每天发生在订单履约、营销活动、多租户权限切换等真实场景里。
手动装配 + 接口契约比框架自动注入更可控
尤其在前端或轻量后端（如 NestJS 小模块、Midway 微服务），过早依赖容器反射会掩盖设计缺陷。推荐分两步落地：
- 先定义清晰接口：
interface PaymentService { charge(order: Order): Promise<receipt> }</receipt> - 再集中工厂封装：
const createPaymentService = (env: 'prod' | 'staging') => env === 'staging' ? new MockPaymentService() : new AlipayService(config) - 启动时统一注入：
const app = new OrderProcessor({ payment: createPaymentService('prod'), logger: new SentryLogger() })
这样，所有环境切换、降级开关、A/B 实验都收口在工厂函数里，不侵入业务类，也不依赖容器扫描逻辑。
跨层依赖必须通过抽象层传递，不能跳层引用
常见错误是 Controller 直接 import Service 层的具体实现，或者 ViewModel 拿着 DAO 实例做缓存判断。这会导致：
- UI 层被数据库事务生命周期绑架（比如 DAO 需要
await db.transaction()，但 ViewModel 不该管这个） - 更换 ORM（如从 TypeORM 切到 Drizzle）时，UI 层也要跟着改类型定义和调用方式
- 无法在 Service 层统一加熔断、重试、日志埋点
正确做法是：Controller 只接收一个 OrderService 接口，而 OrderService 内部才决定用 PrismaOrderRepo 还是 InMemoryOrderRepo —— 上层永远不知道下层怎么存的，只关心“能不能下单”。
真正难的从来不是写个容器或配个 @Injectable()，而是每次想 new 一个对象前，多问一句：这个实例的生命周期、配置来源、替换成本，是不是该由调用方或启动入口来定？一旦开始这么问，IoC 就不再是框架特性，而是你写代码时的肌肉记忆。
