应通过umask控制初始权限（如umask 002使目录775、文件664），再配合chmod -r u+rwx,g+rwx vendor/加固，禁用post-install-cmd自动chmod，docker中用--chown或-u参数对齐uid/gid。
Composer install 后 vendor 目录权限不对怎么办
默认情况下，composer install 创建的 vendor/ 目录权限取决于当前用户 umask 和文件系统挂载选项，常导致 Web 服务器（如 nginx、Apache）无法读取，或 PHP 进程因缺少执行权限而报 Class not found 错误。
用 chmod + umask 控制 vendor 权限最直接
不依赖插件或钩子，靠系统级权限控制更稳定。关键不是“给 vendor 赋权”，而是让 composer install 生成的文件从一开始就有合适权限。
-
umask 002（组可写）再运行composer install，能让新创建目录默认为775、文件为664，适合开发机或共享组环境 - 若需所有文件可执行（比如某些 bin 脚本），用
umask 000，但注意安全风险 - 在 CI/CD 或容器中，建议显式加一步：
chmod -R u+rwX,g+rwX vendor/（X只对目录和已有执行位的文件生效，比x更安全）
避免用 post-install-cmd 自动 chmod 的坑
有人在 composer.json 里写 "post-install-cmd": ["chmod -R 755 vendor/"]，这看似省事，实际埋雷：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Linux/macOS 有效，Windows 下直接失败（
chmod不可用） - 755 给所有文件加执行位，可能触发 PHP opcache 或安全扫描告警
- 如果
vendor/是符号链接（如 Docker 挂载），chmod -R会穿透到源目录，改错地方 - CI 环境通常以非 root 用户运行，
chmod可能被拒绝，且错误容易被忽略
Docker 环境下 vendor 权限问题怎么解
宿主机和容器 UID/GID 不一致是常见根源，composer install 在容器内跑完，生成的 vendor/ 文件属主是容器内 UID，宿主机用户无法读写。
- 构建阶段用多阶段 Dockerfile：在 builder 阶段装依赖，
COPY --chown=www-data:www-data复制到运行镜像，绕过权限继承问题 - 本地开发用
docker run -u $(id -u):$(id -g)启动容器，让 composer 生成的文件属主匹配宿主机 - 不要在 volume 挂载点上直接
composer install—— 容器内用户写入的文件，在宿主机看到的 UID 常是随机数
真正麻烦的从来不是 chmod 命令本身，而是没想清楚权限该由谁在哪个环节设定：是安装时、复制时，还是运行时？搞错这一层，后面全在补洞。
