导出覆盖是轻量精准的依赖替换技术，用于测试中隔离支付、认证等真实模块，仅拦截显式导出项（如module.exports或export声明），不修改源码、不影响内部调用，需按语言生态选用proxyquire/vi.mock/patch等工具。
导出覆盖是一种轻量、精准的依赖替换技术，适用于测试中隔离真实业务模块（如支付、用户认证、数据库连接等），无需修改源码或重构模块结构。它的核心是“按需拦截并重写模块导出行为”，让测试代码能控制运行时实际使用的实现。
明确导出覆盖的作用边界
导出覆盖不是全局替换，也不影响模块内部逻辑调用。它只在模块被其他代码 require 或 import 时生效，且仅作用于被显式导出的函数/类/对象。例如：
- Node.js 中用
module.exports = { sendEmail }导出的函数，才能被 Proxyquire 或类似工具覆盖；未导出的helper()不可见、不可替 - ES6 模块中只有
export function fetchUser()才可被 Vitest 的vi.mock()拦截；const internal = () => {}属于私有实现，无法覆盖 - Python 的
from module import func可被patch替换；但若模块内直接调用func()而非通过导入引用，则 patch 失效
选择匹配环境的覆盖工具
不同语言生态提供成熟、语义清晰的导出覆盖方案，应按项目技术栈选用：
-
Node.js（CommonJS）：用
proxyquire替换require()返回值
→ 示例：proxyquire('./order', { './payment': { process: mockPay } }) -
Node.js（ESM） + Vitest：用
vi.mock()声明模拟模块
→ 示例：vi.mock('./auth', () => ({ verifyToken: () => ({ id: 123 }) })) -
Python：用
unittest.mock.patch修饰导入路径
→ 示例：@patch('myapp.services.db.get_connection') -
Java（Guice）：用
Modules.override()合并模块，后加载的绑定优先生效
→ 示例：Modules.override(new ProdModule()).with(new TestDbModule())
覆盖真实模块的典型操作步骤
以替换生产环境的「订单通知服务」为例，目标是让所有调用 notifyOrder() 的地方返回固定成功响应：
- 确认该服务被导出：检查
notifications.js是否含module.exports = { notifyOrder }或export function notifyOrder() - 编写模拟实现：
const mockNotify = jest.fn().mockResolvedValue({ ok: true }) - 在测试前激活覆盖：
jest.mock('./notifications', () => ({ notifyOrder: mockNotify })) - 触发业务逻辑（如调用
createOrder()），验证mockNotify是否被调用且参数符合预期 - 测试结束后自动恢复（Jest/Vitest 默认清理；手动使用 Proxyquire 需注意缓存）
避免常见陷阱
导出覆盖失效往往源于对模块加载机制的理解偏差：
- 不要覆盖未导出的内部函数——它们不属于模块接口，覆盖无意义
- 避免循环依赖场景下覆盖：若 A → B → A，B 中对 A 的引用可能绕过覆盖逻辑
- ESM 中动态
import()需单独vi.importActual()处理，否则模拟不生效 - 同一模块被多个测试文件加载时，确保覆盖逻辑执行顺序正确（如 Jest 中
beforeAll优于setupFilesAfterEnv）
