依赖注入重构业务逻辑，轻松切换数据 Mock

本文深入剖析了如何通过依赖注入（DI）实现业务逻辑与数据源的彻底解耦，让 Mock 切换真正“零侵入”——只要将 new 操作移出业务类、严格采用构造函数注入与接口/纯虚类契约、确保 Mock 精准镜像真实接口的所有行为（包括字段结构、错误路径、边界值和调用痕迹），并把切换逻辑统一收口至应用组装入口，就能在不修改任何业务代码的前提下，一键启用 Mock 进行高效测试；而真正考验工程能力的，恰恰是维护接口契约的一致性——Mock 不是摆设，而是契约的活文档，一旦脱节，集成时的隐性崩塌远比写不出 Mock 更致命。

能不改业务代码就切 Mock，前提是依赖创建逻辑必须外移、注入点必须可控——不是“能不能”，而是“你有没有把 new 从类里抠出来”。

构造函数注入是底线，别在类里 new 任何依赖

硬编码 new DatabaseRepo() 或 new ApiClient() 的类，等于把实现焊死在编译期。测试时你连实例都拿不到，更别说替换成 Mock。

• 错误写法：class OrderService { private repo = new DatabaseRepo(); } —— 测试无法接管 repo
• 正确写法：class OrderService { constructor(private repo: UserRepository) {} } —— 测试可传入 new MockUserRepository()
• Go 必须用接口类型（如 UserRepository）作参数；C++ 必须用纯虚类（class IUserProvider { virtual User Get(int) = 0; }），否则 mock 失去多态基础

Mock 实现不是占位符，是接口契约的镜像

只返回固定数据但忽略参数校验、错误路径、空值处理的 Mock，上线前不会报错，集成时才爆雷。

• MockUserProvider.Get(123) 必须返回符合 User 类型的结构：字段名、嵌套层级、null/undefined 处理都要一致
• 边界场景必须覆盖：Get(0) 或 Get(-1) 应返回 error("invalid id")，而不是 panic 或静默跳过
• 记录调用痕迹是验证逻辑的关键：mock.Calls.Count("Get") 和 mock.Calls.Args("Get", 0) 要能查到真实调用次数与参数
• TypeScript 中用 jest.fn() 时，必须用 mockImplementationOnce 控制不同调用返回不同结果，否则重试、降级逻辑测不出来

切换入口必须统一前置，不能藏在业务逻辑里分支判断

靠 if (process.env.NODE_ENV === 'test') 在业务方法里加载模块，等于又把环境耦合回去了。切换点必须唯一、不可绕过、发生在组装阶段。

• Go 主程序中：if mockFlag { svc = NewUserService(&MockRepo{}) } else { svc = NewUserService(NewDBRepo()) }
• CMake 中：option(USE_MOCK "Enable mock providers" OFF)，仅开启时才 add_subdirectory(test/mocks)
• TypeScript：bind(UserProvider).to(MockUserProvider) 或 .to(HttpUserProvider) 的决策，只出现在 DI 容器注册表或 main.ts 入口处
• 切忌在组件或 Hook 内部做 import.meta.env.MODE === 'mock' 判断并条件导入 —— 那不是解耦，是分散污染

真正难的不是写 Mock，而是让所有注入点暴露且稳定。一旦接口演化，Mock 必须同步更新字段和错误行为，否则契约就断了。这点常被忽略，直到联调时发现字段名对不上、空值处理不一致、或者某个 404 场景根本没模拟。

本篇关于《依赖注入重构业务逻辑，轻松切换数据 Mock》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！