核心是“定义即隔离”——每个业务用独立Dockerfile和docker-compose.yml声明环境，通过专属网络、资源限制、非root运行及构建隔离实现完全独立。
用 Docker 在 CI/CD 流水线中构建多业务并行测试环境，核心不是“一键”，而是“定义即隔离”——只要每个业务的测试环境由独立 Dockerfile 或 docker-compose.yml 描述，并在流水线中按需启动互不共享资源的容器实例，就能天然实现完全独立、互相隔离。
每个业务配专属 Dockerfile 或 Compose 文件
避免所有业务共用一个镜像或一个 compose 配置。应为每个业务（如 payment-service、user-service、notification-api）维护自己的构建和测试声明：
- 每个业务目录下放 Dockerfile.test：基于最小运行镜像（如 alpine 或 distroless），只装本业务测试所需工具（curl、jq、httpie）和依赖服务客户端
- 配套 docker-compose.test.yml：明确定义该业务所需的依赖服务（如 PostgreSQL、Redis、Mock Server），全部使用官方镜像 + 固定 tag，并通过
networks隔离专属网络，不复用默认 bridge - 示例片段（payment-service/docker-compose.test.yml）：
version: '3.8' services: app: build: context: . dockerfile: Dockerfile.test depends_on: [db, mock-gateway] db: image: postgres:15-alpine environment: {POSTGRES_DB: testdb, POSTGRES_PASSWORD: test} mock-gateway: image: wiremock/wiremock:1.6.0 ports: ["8080"] networks: isolated: {driver: bridge}
流水线中按业务并发启动隔离网络栈
CI 工具（如 GitHub Actions / GitLab CI）支持并行 job；关键是在每个 job 中启用独立网络命名空间，防止端口冲突和服务误连：
- 在 job 脚本开头运行
docker network create test-net-$CI_JOB_ID，并在 compose 中指定该网络 - 测试完成后强制清理：
docker-compose -f docker-compose.test.yml down -v && docker network rm test-net-$CI_JOB_ID - 禁用 host 网络模式，不挂载宿主机目录（如 /tmp、/var/run），杜绝跨容器文件泄露
- 若用 GitHub Actions，可配合
services块启动临时依赖，但仅限单 job 内部可见，天然隔离
构建阶段也做业务级隔离
测试环境的干净，始于构建产物的纯净。不要让多个业务共享同一构建镜像：
- 每个业务用多阶段构建，且 builder 阶段仅 COPY 本业务源码（
COPY ./payment-service/ .），避免误带其他业务配置或密钥 - 镜像 tag 加业务前缀：
docker build -t myorg/payment-service:test-$CI_COMMIT_SHA . - 构建缓存按业务分离：GitHub Actions 可用
cache-key: ${{ runner.os }}-build-payment-${{ hashFiles('payment-service/**') }}
运行时加硬性资源与权限限制
容器默认仍可争抢 CPU 和内存，需显式约束才能保障并行稳定性：
- 在 docker-compose.test.yml 的 service 下添加：
deploy:<br> resources:<br> limits:<br> cpus: '0.5'<br> memory: 512M
- 以非 root 用户运行测试容器（Dockerfile.test 中加
USER 1001） - 禁用特权模式：
privileged: false，不挂载/proc或/sys
