构造函数注入比 new 更适合 Mock 切换，因它显式化依赖、避免编译期锁死实现、支持类型安全替换，且配合接口抽象与构建时切换可保障 Mock 可靠性与生命周期一致性。

能不改业务代码就切 Mock，前提是依赖创建必须移出类/函数内部，且所有实现都通过同一接口契约通信。

为什么构造函数注入比 new 更适合 Mock 切换

硬编码 new DatabaseRepo() 或 axios.create() 会把实现锁死在编译期；测试时无法替换，只能打桩全局函数（如 jest.mock('axios')），但这种方案脆弱、影响范围大、难以控制粒度。

• 构造注入让依赖关系显式化：UserService 的实例必须由外部提供 UserProvider，测试时直接传 new MockUserProvider() 即可
• 避免 setter 注入：setter 允许对象处于未初始化状态，测试易漏设，且无法在编译/类型检查阶段暴露缺失依赖
• 接口抽象是前提：如果注入的是具体类（如 PostgreSQLClient），Mock 就得继承它——而很多数据库客户端是 final 或含私有字段，mock 成本极高

前端 Hook 中如何安全注入请求函数而非硬绑 fetch

写 useEffect(() => { fetch('/api/user') }) 等于放弃控制权；fetch 是全局绑定，无法按模块隔离 mock 行为。

• 把请求函数作为参数传入：const useUser = (requestFn = fetch) => { ... }，生产用默认 fetch，测试传 mockFetch
• 若用 axios 或自定义 client，同样适用：useUser(axios.get) 或 useUser(apiClient.getUser)
• 注意：不要在 Hook 内部再封装一层“API 工具函数”，那只是把 new 换成 import，本质仍是硬依赖

Go/TS/PHP 中接口定义与 Mock 实现的关键约束

Mock 能否无缝替换，取决于接口是否真正覆盖了所有调用路径和错误分支。一个只定义 Get(id int) User 的接口，在真实场景中几乎必然失败。

• 必须包含 error 返回：Get(id int) (User, error)（Go）、get(id: number): Promise（TS）、public function get(int $id): User + 异常声明（PHP）
• Mock 实现要支持边界行为：比如 Get(0) 返回 nil, errors.New("invalid id")，Get(-1) 模拟网络超时
• 记录调用痕迹用于断言：mock.Calls.Count("Get") == 2，而不是只看返回值
• Mock 类应仅存在于 test/ 或 __mocks__/ 目录，构建脚本需确保其不进入生产包

构建时切换 vs 运行时切换：哪个更可靠

运行时靠 NODE_ENV=test 或 -mock 参数动态选服务，看似灵活，实则容易因环境变量拼写错误、加载顺序错乱导致 Mock 失效且无提示。

• 构建时切换更可控：CMake 用 option(USE_MOCK OFF) 控制源文件是否参与编译；Go 用 //go:build mock tag 分离实现；TS 用 tsconfig.json 的 paths 映射 mock 版本
• 关键点在于：Mock 实现和真实实现必须共用同一接口文件，不能各自定义一套，否则类型系统无法校验兼容性
• 最易被忽略的是生命周期一致性：Mock 实例不能在每次 provide 时新建（如 provide('api', new ApiClient())），而应提前构造好，再统一 provide('services', services)