docker compose up service_name 是最简启动方式，前台运行并自动拉起依赖服务；加 -d 后台运行，加 --no-deps 可忽略依赖单独启动指定服务。
直接用 docker compose up [服务名] 就行，不需要额外配置 Docker Desktop —— 它只是宿主环境，真正执行命令的是 CLI。
docker compose up service_name 是最简方式
只要当前目录下有 docker-compose.yml（或 compose.yaml），运行命令就能只启动那个服务：
-
docker compose up web：前台启动web服务，同时自动拉起它依赖的db（如果web的depends_on里写了） -
docker compose up -d redis：后台启动redis，适合长期运行 - 不加
-d时，Ctrl+C 可退出前台模式，容器也会停止
--no-deps 防止意外连带启动依赖服务
默认行为是“启动目标服务 + 它声明的依赖”，但很多场景你只想单独验证某个服务（比如调试 worker 而不想碰 db），这时必须加 --no-deps：
-
docker compose up --no-deps worker：只启动worker容器，哪怕它depends_on: db也忽略 - 注意：如果
worker实际连接db但db没运行，它会报连接拒绝（Connection refused），这是预期行为，不是命令失败 -
--no-deps不影响网络连通性——只要容器在同一个默认网络里，手动docker exec进去还是能 ping 通其他服务名
docker compose start 和 docker compose run 的区别
这三个命令看起来都“启动服务”，但语义完全不同，容易混用出错：
-
docker compose start service_name：只适用于已存在且已停止的容器；如果容器被删过或没 build 过，会报No such service -
docker compose run --rm service_name command：临时跑一次命令就退出，不会保持运行状态；常用于迁移脚本、一次性任务，比如docker compose run --rm web python manage.py migrate -
docker compose up service_name：创建+启动+保持运行，是日常开发中最该用的命令
Windows 上路径和换行符可能干扰服务启动
Docker Desktop for Windows 默认使用 WSL2 后端，但如果你在 PowerShell/CMD 中操作，要注意：
-
docker-compose.yml文件必须用 LF（Unix）换行符，CRLF 容易导致解析失败，报错类似yaml: line X: did not find expected key - 挂载本地路径时，
./src在 Windows 下会被自动转成C:\path\to\src，但 WSL2 内部看到的是/mnt/c/path/to/src；多数情况自动转换没问题，但若服务内硬编码了路径逻辑，可能读不到文件 - 权限问题较少见，但若服务以非 root 用户运行（如
user: "1001:1001"），而挂载的 Windows 目录实际属主是 Windows 用户，WSL2 会映射为 UID 1000+，可能触发 permission denied
真正麻烦的不是命令本身，而是服务之间隐式依赖的判断——比如你以为 api 不依赖 cache，但它启动时主动连接 redis://cache:6379，而你又忘了加 --no-deps，结果 cache 被拉起来了，日志里还看不出哪来的。这种链式启动得靠 docker compose ps 和 docker compose logs api 交叉验证。
