docker compose 适用于开发与轻量部署，但服务超10–15个时易出现启动慢、资源争抢等问题；通过健康检查、资源限制、命名卷、镜像优化等配置可支撑20–30服务稳定运行。
Docker Compose 本身不是为大规模生产编排设计的工具，它本质是面向开发、测试和轻量级部署的本地编排器。当服务数量超过 10–15 个、容器频繁启停、卷/网络规模扩大时，性能损耗会明显暴露——启动变慢、资源争抢加剧、状态同步延迟、磁盘空间不可控。但通过针对性配置和架构调整，仍可显著缓解，支撑中等规模（20–30 服务）稳定运行。
避免默认并行启动引发的“启动风暴”
Compose 默认并发启动所有服务，若依赖链未显式收敛，会导致大量无效重试和资源抢占。- 使用
depends_on+condition: service_healthy替代简单顺序依赖 - 为每个关键服务添加合理
healthcheck，例如数据库用pg_isready、Redis 用redis-cli ping - 设置
start_period避免过早检测：start_period: 40s给初始化留出缓冲 - 不要依赖
depends_on控制业务逻辑就绪，它只管容器进程存活；健康检查才是真实服务可用信号
精准限制资源，阻断单点拖垮全局
无约束的容器会抢占 CPU、内存甚至 I/O 带宽，尤其在 M1/M2 Mac 或低配云主机上表现更剧烈。- 在
deploy.resources中同时设置limits和reservations：-
limits.memory: 768M防止 OOM 杀死或内存溢出 -
reservations.memory: 256M保证最低可用资源，避免调度饥饿
-
- 对数据库类 I/O 密集服务，额外配置
blkio_weight: 800提升磁盘优先级 - 用
docker stats实时观察瓶颈服务，而非凭经验猜测
用命名卷替代匿名卷，终结磁盘碎片化假象
所谓“磁盘碎片化”，实际是 `/var/lib/docker/volumes/` 下堆积的匿名卷目录（如 `a7f3b5e8c9d/_data`）导致 inode 耗尽或 `df -h` 显示异常。- 所有需要持久化的路径必须声明为命名卷：
volumes: - db-data:/var/lib/postgresql/data volumes: db-data: {} - 彻底禁用形如
- /app/cache的隐式挂载（它会生成匿名卷） - 定期执行
docker volume prune -f清理闲置卷，建议加入 CI 后置脚本或本地make clean
优化镜像与构建，减少启动延迟源头
每次 `up --build` 重新拉取或构建，都是性能隐形杀手。- 固定基础镜像标签：用
nginx:1.25-alpine而非latest - 启用 BuildKit 加速多阶段构建：在
.env中设DOCKER_BUILDKIT=1 - 开发环境用
override文件分离构建逻辑，生产用预构建镜像 - 对 ARM 设备（如 M1 Mac），显式指定
platforms: linux/arm64，避免 Rosetta 2 翻译开销
不复杂但容易忽略。
