根本原因是宿主机挂载目录属主与容器用户UID/GID不匹配，导致vendor/权限错误；应通过composer install --uid=U --gid=G指定用户ID，配合docker --user或docker-compose环境变量注入实现跨平台一致。
为什么composer install在Docker里总报“Permission denied”？
根本原因是宿主机挂载的代码目录（如./src）以非root用户身份写入，而容器内默认用root或其它UID运行PHP进程，导致vendor/目录属主混乱、缓存文件不可写。尤其当宿主机是macOS或Windows时，文件系统元数据丢失，chown在容器内失效。
用--uid和--gid让Composer主动适配宿主机用户
Composer 2.2+ 支持直接指定执行用户ID，绕过容器用户与宿主机权限错位问题。这比改Dockerfile里的USER更轻量、更可靠。
- 先查宿主机当前UID/GID：
id -u和id -g（例如输出1001和1001） - 运行时显式传参：
composer install --uid=1001 --gid=1001 - 若用
docker run，建议结合-v挂载+--user保持一致：docker run --user 1001:1001 -v $(pwd):/app php:8.3-cli composer install --uid=1001 --gid=1001 - 注意：该参数只影响
vendor/和composer.lock等生成文件的属主，不改变PHP进程本身UID
docker-compose.yml中避免硬编码UID，用user: "${UID:-1001}:${GID:-1001}"
硬写user: "1001:1001"会导致团队协作时其他人构建失败。环境变量注入才是可持续做法。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 启动前导出变量：
export UID=$(id -u) GID=$(id -g)（可加到.bashrc或Makefile） -
docker-compose.yml里这样写：services: app: user: "${UID:-1001}:${GID:-1001}" volumes: - .:/app working_dir: /app command: composer install --uid=${UID:-1001} --gid=${GID:-1001} - Mac上Docker Desktop默认不传递
UID，需在Docker Desktop → Settings → General → “Use the Docker CLI from the terminal” 确保勾选
别碰chmod -R 777 vendor/，临时解法反而埋雷
这类操作看似“解决”了权限错误，实则破坏Composer自身校验逻辑——下次composer update可能因文件时间戳或权限异常拒绝覆盖，且会污染git状态（尤其是vendor/意外被提交）。
- 真正要修复的是“谁创建了
vendor/”，而不是“怎么让谁都写得进去” - 如果已有损坏的
vendor/，先rm -rf vendor/ composer.lock，再用正确UID重装 - CI环境（如GitHub Actions）无需处理UID，因为runner是干净容器，直接用
root跑即可
最常被忽略的一点：.dockerignore里漏掉vendor/，导致每次build都把宿主机的vendor/复制进镜像，UID冲突直接带进最终镜像层——这个坑比权限报错更难排查。
