单元测试必须彻底隔离敏感数据：禁用env_file、用模拟服务替代真实依赖、显式声明独立测试网络、硬编码最小配置、利用网络命名空间隔离，并验证无敏感连接。
在单元测试中直接暴露核心敏感数据，本质上是环境失控的信号。Docker Compose 的网络隔离本身不参与单元测试执行过程（测试通常运行在宿主机或测试容器内，不依赖服务编排网络），但可以通过构建“测试专用隔离上下文”来切断敏感数据流向测试环节——关键不是让网络隔离“保护测试”，而是让测试“无法触达敏感数据”。
避免测试容器访问真实敏感服务
单元测试应始终与生产级数据库、密钥管理服务、内部API等保持逻辑断连。不要在 docker-compose.test.yml 中引入真实后端服务：
- 用轻量模拟服务替代，例如
testcontainers启动临时 PostgreSQL 实例，或用WireMock模拟 HTTP 依赖，确保测试数据完全可控 - 若必须复用部分服务配置，显式将测试网络与生产/开发网络分离：
networks: test-isolated: driver: bridge ipam: config: - subnet: 172.30.5.0/24 - 禁止测试服务加入
frontend或backend等承载真实数据的网络，防止 DNS 解析误连
敏感配置彻底脱离测试上下文
环境变量是敏感数据泄露高发区。单元测试不应加载任何含密码、令牌、连接串的配置文件：
- 测试启动时禁用
env_file，改用硬编码最小化配置（如DB_URL: jdbc:h2:mem:testdb）或通过 JVM 参数传入 - 确保
.env.production、.env.secrets等文件被.gitignore排除，且不在 CI 测试镜像中打包 - 使用
environment块覆盖敏感字段，例如：environment:<br> - DATABASE_URL=jdbc:h2:mem:unit-test<br> - API_KEY=mock-key-for-test
利用网络命名空间强化进程级隔离
即使不跑 Docker，本地运行单元测试时也可借助系统级隔离减少风险：
- 在 Linux 上用
unshare --net启动测试进程，使其无权访问宿主机网络栈，自然无法连接真实数据库或密钥服务 - CI 环境中默认启用容器化测试（如 GitHub Actions 的
ubuntu-latestrunner），天然具备网络命名空间隔离，无需额外配置 - 避免在测试代码中调用
System.getenv("DB_PASSWORD")等直取方式；统一通过注入的配置对象访问，便于测试时替换为 stub 实现
验证隔离是否生效的简单检查项
每次更新测试配置后，快速确认以下几点：
- 运行
docker-compose -f docker-compose.test.yml config，检查输出中无env_file指向敏感文件，且所有environment值均为测试专用 - 查看服务网络声明，确认没有
- default或共享网络名，只出现- test-isolated类独立网络 - 在测试容器内执行
ping -c1 production-db或nc -zv vault.internal 8200，应全部失败
