不修改源码切换 Mock 的核心是依赖注入与接口抽象：通过构造函数注入接口而非具体实现，用工厂函数统一创建实例，运行时或构建期决定注入何种实现，Mock 必须完整遵循接口契约。
不修改源码就能切换 Mock 环境，核心在于把“谁来创建依赖”这个控制权从类内部移出去——不是 new DatabaseService()，而是让外部传进来；不是硬写 fetch('/api/user')，而是接收一个 requestFn 参数。只要接口契约不变，替换实现就是改一行注入逻辑的事。
构造函数注入是切换 Mock 最稳的起点
直接在类里 new 依赖，等于把实现锁死在编译期。测试时你没法塞进 MockDatabaseService，因为它的实例根本不在构造参数里，也不在可赋值的字段上。
- 错误写法：
private db = new PostgreSQLService();—— 测试无法干预，mock 只能打桩系统调用，脆弱且难调试 - 正确写法：
constructor(private db: DatabaseService) {}，其中DatabaseService是接口或抽象类 - 测试时直接传 mock 实例：
new UserService(mockDb)，无需任何框架支持，纯语言机制 - 避免 setter 注入：它允许对象处于半初始化状态，容易漏设、难断言，也不利于类型检查
接口抽象不是装饰，是 Mock 可行性的前提
如果注入的是具体类（比如 PostgreSQLService），那 mock 就得继承它——但很多数据库 client 是 final 类，或有复杂构造逻辑，mock 成本极高。真正能低成本替换的，只有定义清晰行为边界的接口。
- Go 中必须用
type UserProvider interface { Get(id int) (User, error) } - TypeScript 中用
interface UserProvider { get(id: number): Promise} - C++ 中用纯虚类：
class UserProvider { public: virtual User Get(int id) = 0; }; - 业务代码只依赖这个接口，不关心背后是 HTTP、DB 还是内存 map
工厂函数集中管理实例创建，避免 new 散落各处
把 new ApiClient() 写在 10 个文件里，等于把环境配置和实现细节复制了 10 遍。一旦要切 Mock、加拦截器、换 base URL，就得全局搜索替换——这不是解耦，是批量字符串替换。
- 统一导出工厂：
export const createApiClient = (options: { baseUrl: string }) => new ApiClient(options); - 入口处一次性创建：
const services = { api: createApiClient({ baseUrl: import.meta.env.VITE_API_URL }) }; - 所有模块都从
services取实例，而不是自己new - Mock 场景下，只需让
createApiClient返回mockApiClient，其余代码零改动
运行时或构建期切换，而非代码里 if-else 判断环境
在业务逻辑里写 if (process.env.NODE_ENV === 'development') return mockData，看似简单，实则污染了核心路径，且无法覆盖测试场景（比如想在 CI 中跑一遍 Mock 路径）。
- 更可靠的方式是靠启动逻辑或构建配置决定注入哪个实现
- Node.js 项目用
NODE_ENV=test加载不同 provider 注册表 - Go 主程序根据
-mockflag 创建UserService{repo: &MockUserRepo{}} - CMake 中用
option(USE_MOCK "Enable mock providers" OFF)控制是否编译 Mock 模块 - 关键点：源码不动，变的只是组装方式和注入源头
最容易被忽略的点是：Mock 实现必须完整遵循接口契约——不只是返回值类型对，还要模拟失败路径、调用次数、参数校验等。否则测试通过了，上线却因异常处理缺失而崩，这种 gap 比没有测试更危险。
