根本原因是宿主机与容器UID/GID不匹配导致vendor/写入失败；应使用composer install --uid=U --gid=G指定宿主机用户ID，并在docker-compose.yml中显式传参，或运行容器时用--user U:G同步映射。
docker-compose 挂载后 vendor/ 写入失败，根本不是路径错，是 UID 错配
宿主机目录（如 ./src）挂进容器后，composer install 报 Permission denied，90% 不是因为路径不存在或没写权限，而是容器内运行用户（UID）和宿主机文件属主 UID 不一致。比如你在 macOS 上 UID 是 501，但容器默认用 root（UID 0）执行命令，它对挂载进来的 ./src 只有读权限——尤其当该目录是普通用户创建时，Linux/macOS 的挂载行为会保留属主元数据，但容器内没有对应 UID 的用户，就变成“不可写”。
- 先查宿主机 UID/GID：
id -u和id -g（常见值如1001、501） - 进容器确认实际运行用户：
docker compose exec php id，看输出是否匹配 - 别依赖
USER指令硬改 Dockerfile——它不解决挂载卷的属主映射问题
用 composer install --uid=U --gid=G 主动适配宿主机用户
Composer 2.2+ 原生支持 --uid 和 --gid 参数，让生成的 vendor/、composer.lock 等文件直接以指定 UID/GID 创建，绕过容器用户与宿主机权限错位。这是目前最轻量、跨平台最稳的解法。
- 在
docker-compose.yml的 service 中，把 composer 命令显式带上参数：command: ["composer", "install", "--no-scripts", "--no-autoloader", "--uid=1001", "--gid=1001"] - 如果用
docker run临时调试，加--user 1001:1001并同步传参：docker run --user 1001:1001 -v $(pwd):/app php:8.3-cli composer install --uid=1001 --gid=1001 - 注意：该参数只影响 Composer 创建的文件属主，不影响 PHP 进程本身的 UID；若还需 Web 请求可写
storage/，仍需额外配置容器用户或组权限
挂载路径本身不存在？Compose 不会自动创建，得自己铺路
docker compose up 报 invalid mount config for type "bind": bind source path does not exist，不是权限问题，是宿主机上那个 ./data 或 ./config 目录压根没建。Compose 解析相对路径时，始终以 docker-compose.yml 所在目录为基准，但它不会帮你 mkdir -p。
- 别指望
docker-compose.yml里写./logs:/app/logs就能自动生成./logs - 启动前手动创建：
mkdir -p ./data ./logs ./config - 或写个轻量 wrapper 脚本（如
start.sh）：#!/bin/sh<br>mkdir -p ./data ./logs ./config<br>docker compose up -d
- 若用 Makefile，加 target：
setup:<br>\t@mkdir -p ./data ./logs
为什么 sudo chown -R $USER:$USER vendor/ 在容器里无效
在容器内执行 chown 修复 vendor/ 权限，基本没用——因为挂载的是宿主机目录，它的属主信息来自宿主机，容器内 chown 改的只是挂载视图下的 inode 映射，宿主机上文件实际 UID/GID 并未变，下次重启容器或重挂载，问题照旧。更糟的是，某些文件系统（如 macOS 的 APFS + gRPC-FUSE）根本不支持容器内 chown。
- 真正有效的修复点永远在宿主机：运行
sudo chown -R $(id -u):$(id -g) ./src（假设挂载的是./src） - 如果已用
sudo composer install污染过，先清理：rm -rf vendor/ composer.lock，再确保宿主机目录归属正确，最后重新composer install - Docker Desktop for Mac/Windows 用户注意：WSL2 或 Hyper-V 后端下，挂载卷的 UID 映射可能被二次转换，此时必须用
--uid/--gid参数，而非依赖chown
复杂点在于：UID/GID 错配是静默发生的，错误日志从不提示“你 UID 不对”，只报“Permission denied”。一旦忽略这点，所有 chmod、chown、USER 指令都像在给影子治病。
