单元测试中多环境配置的核心是参数化注入环境上下文并验证契约：用 setupFilesAfterEnv 统一管理 process.env，loadConfig 接收显式环境对象，describe 按环境分组断言，避免硬编码分支与跨环境混验。
在单元测试中组织多环境配置，核心是让测试逻辑不依赖真实环境变量，又能准确模拟 dev / staging / prod 等不同场景下的行为。关键不是“写多个 config 文件”，而是用可控方式注入环境上下文，并验证配置加载函数在各环境输入下的输出是否符合契约。
用参数化测试覆盖不同环境标识
避免为每个环境写一个 test() 块。改用数据驱动方式，把环境名、租户 ID、预期配置特征打包成测试用例数组：
- 传入 process.env.NODE_ENV = 'production' 和 tenantId = 'acme'，断言 config.cdn.url 以 https://prod-cdn 开头
- 传入 NODE_ENV = 'development' 且无租户标识时，检查是否回退到本地 mock 配置（如 config.api.base = 'http://localhost:3001'）
- 传入 NODE_ENV = 'test' 时，确认日志级别被强制设为 'silent'，且所有外部 API 被自动 mock
通过 setupFilesAfterEnv 统一注入环境状态
在 Jest 的 setupFilesAfterEnv（如 jest.setup.js）中集中管理测试环境的初始状态，而不是每个 test 里重复设置：
- 重置 process.env 为干净副本：const originalEnv = { ...process.env }; beforeEach(() => Object.assign(process.env, originalEnv));
- 根据当前运行的测试文件名或描述，自动设置典型环境组合：比如匹配 /staging\.test\.js$/ 就设 process.env.DEPLOY_ENV = 'staging'
- 对需要全局生效的 mock（如 fetch、localStorage），也在该文件中统一注册，避免跨测试污染
按环境分组配置加载逻辑，而非硬编码分支
配置加载函数本身应接收明确的“环境上下文”对象，而不是直接读取 process.env。这样测试时可自由传入任意组合：
立即学习“Java免费学习笔记（深入）”；
- 函数签名改为 loadConfig({ env, tenantId, featureFlags })，不再内部调用 process.env.NODE_ENV
- 测试中直接调用 loadConfig({ env: 'production', tenantId: 'shopify' })，无需启动真实环境
- 环境特有逻辑（如 prod 下禁用调试面板）封装进独立策略函数，单独测试，不混在主加载流程里
用 describe 隔离环境行为断言，不混合校验
每个 describe 块只聚焦一个环境的行为契约，避免“这个测试既验 dev 又验 prod”：
- describe('in production environment', () => { ... }) 内只断言 CDN 域名、错误上报开关、缓存策略等 prod 特征
- describe('in development environment', () => { ... }) 专注热重载支持、source map 路径、mock 数据开关等 dev 行为
- 同一配置项（如 api.timeout）在不同环境下的值差异，用 toEqual 或 toMatchObject 显式比对，不靠注释推测
