docker compose可作为严格遵循12要素原则的本地微服务基座，通过统一代码库、环境变量注入配置、无状态服务设计及stdout日志输出实现开发与生产一致性。
用 Docker Compose 搭建本地微服务基座，本身不是云原生的最终形态（生产环境应上 Kubernetes），但它完全可以作为**严格遵循 12 要素原则的本地开发与验证基座**。关键不在于工具，而在于设计方式是否对齐要素逻辑。下面从落地角度分四块说明怎么做。
一、代码与构建：一份代码库 + 显式依赖 + 环境隔离
所有微服务（如 user-service、order-service）放在同一个 Git 仓库下，按目录结构组织：
- 根目录放 docker-compose.yml 和统一的 .env（仅存默认值，如
COMPOSE_PROJECT_NAME=myapp） - 每个服务子目录含：
Dockerfile、package.json或pom.xml、src/，不放任何配置文件（如application-prod.yml） - 依赖全部显式声明：Node.js 用
package.json，Java 用pom.xml，Python 用requirements.txt—— 构建时只靠这些还原环境，不依赖宿主机全局安装
二、配置与运行：全靠环境变量注入，零硬编码
在 docker-compose.yml 中禁用任何形式的配置文件挂载（如 volumes: ./config:/app/config），改用 environment 或 env_file：
- 数据库连接、API 密钥、开关参数等，全部通过
environment字段传入容器，例如：DATABASE_URL=postgresql://user:pass@postgres:5432/mydb - 不同环境用不同
.env文件控制：本地开发用.env.local，测试用.env.test，启动时指定：docker-compose --env-file .env.local up - 服务内部不读取
config/目录，只读process.env.DATABASE_URL或 Spring Boot 的${DATABASE_URL}
三、服务与进程：无状态、端口绑定、附加资源化
每个服务定义必须体现“可插拔”和“无状态”特性：
- 数据库、Redis、消息队列等后端服务单独定义为
services，不嵌入应用镜像；应用只通过服务名（如redis）+ 环境变量访问，更换云托管 Redis 只需改 URL，代码零改动 - 所有应用服务不挂载本地磁盘存储（禁用
volumes到/app/data类路径），会话、缓存、上传文件全部走外部服务（如 Redis、MinIO） - 每个服务用
EXPOSE和ports显式暴露端口（如8080:8080），不依赖 Nginx 反向代理做路由 —— 符合“端口绑定”要素，也方便本地直连调试
四、日志、管理与生命周期：面向云原生运维习惯设计
即使本地运行，也要模拟生产级可观测性和操作方式：
- 所有服务禁止写本地日志文件（如
logs/app.log），统一输出到 stdout/stderr；docker-compose logs -f即可查看聚合流，后续可对接 Loki 或 ELK - 管理任务（如数据库迁移、数据初始化）定义为一次性服务，用
docker-compose run --rm db-migrate python manage.py migrate执行，不混入主应用进程 - 服务必须支持快速启动（spring.lifecycle.timeout-per-shutdown-phase），在
docker-compose down时不会丢数据或中断请求
