开发环境隔离需四层协同：网络（显式项目名+专属网络）、存储（命名卷+自动清理）、配置（.env/.env.dev/override分层）、资源与健康检查（限值+依赖就绪），辅以一键脚本闭环管理。
开发环境隔离不是“跑起来就行”，而是要确保每次启动都干净、可复现、不污染、不冲突。核心在于网络、存储、配置、命名空间四层隔离的协同控制，而非单点配置。
独立网络 + 显式项目名，杜绝跨项目通信
默认情况下，docker-compose up 会基于当前目录名生成项目名（如 myapp），并创建同名网络（如 myapp_default）。但若多个项目目录名相同，或未指定项目名，极易导致网络混用、DNS 解析错乱。
- 始终用
-p显式声明唯一项目名：docker-compose -p myapp-dev up -d - 禁用默认网络，在
compose.yaml中定义专属网络，并设name避免动态生成：networks:<br> app-net:<br> name: myapp-dev-network<br> driver: bridge
- 服务间仅通过该网络通信，宿主机无法直连容器 IP，除非显式映射端口
数据卷命名固化 + 自动清理策略
开发中频繁启停容易残留匿名卷，尤其数据库数据卷若未命名，下次 up 可能挂载旧数据，造成状态污染。
- 所有
volumes块必须显式命名，避免使用./data:/data这类绑定挂载替代命名卷（除非明确需要源码热重载） - 为开发环境单独定义命名卷：
volumes:<br> dev-db-data:<br> name: myapp-dev-db-data
- 配合脚本一键清理：
docker volume ls -q --filter "name=myapp-dev-.*" | xargs -r docker volume rm
配置分层加载：.env + env_file + override 文件三重保障
单一 .env 文件无法满足多角色（前端/后端/DBA）或不同本地调试需求。应建立三层配置加载链：
-
.env：存放项目级默认值（如PROJECT_NAME=myapp），被所有环境共享 -
.env.dev：存放开发专用敏感变量（如API_KEY=dev-fake-key），通过env_file: .env.dev加载到对应服务 -
docker-compose.override.yml：覆盖开发特有行为（如构建本地镜像、挂载源码、启用 debug 日志），不提交至 Git
注意：Compose 按 docker-compose.yml → docker-compose.override.yml → env_file → Shell 环境变量顺序合并，后加载者优先级更高。
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
资源限制 + 启动健康检查，模拟真实约束
开发环境放任资源使用，会导致上线后突发 OOM 或超时，而问题在本地无法复现。
- 为每个服务设置基础资源上限：
mem_limit: 512m，cpus: "0.5"，restart: "no"（避免无限重启掩盖问题） - 添加健康检查，防止服务“假启动”：
healthcheck:<br> test: ["CMD", "curl", "-f", "http://localhost:8080/health"]<br> interval: 30s<br> timeout: 5s<br> retries: 3
- 搭配
depends_on: { service: db, condition: service_healthy }，确保依赖真正就绪再启动
一键维护脚本：启动、验证、清理全闭环
避免手动执行零散命令出错，建议封装为可复用脚本（如 dev.sh）：
-
./dev.sh up：带项目名启动 + 等待健康检查通过 + 打印服务地址 -
./dev.sh logs -f app：自动过滤当前项目日志（用--project-name限定） -
./dev.sh down --volumes：彻底清除容器、网络、命名卷 -
./dev.sh reset：down + 清理 dev 数据卷 + 重建（适合重置数据库状态）
脚本内统一使用 docker-compose -p myapp-dev 前缀，避免环境变量或当前路径干扰。
