根本原因是 Composer 依赖运行时 umask 和文件系统挂载选项，umask 决定新文件权限（如 umask 0022 → 目录 755、文件 644），Composer 本身不提供权限控制参数，须从环境层统一配置 umask 并确保属主正确。
为什么composer install生成的文件权限总不对
根本原因不是 Composer 本身没控制权，而是它完全依赖运行时的 umask 和文件系统挂载选项。你执行 composer install 时当前 shell 的 umask 值（比如 0022 或 0002）会直接决定新创建文件的默认权限：目录是 777 & ~umask，文件是 666 & ~umask。所以 umask 0022 → 目录 755、文件 644；umask 0002 → 目录 775、文件 664。Composer 不提供 --chmod 参数，也不读取 composer.json 里的权限配置。
如何在 Linux/macOS 上稳定控制生成文件权限
必须从环境层入手，而不是事后 chmod -R —— 那只能修“旧”，不能保“新”。
- 检查当前
umask：umask命令输出应为0022（推荐）或0002（需组写权限时）；若显示0077，则所有新文件默认无组/其他用户读权限，会导致 Web 服务器无法读vendor/autoload.php - 临时生效：
umask 0022 && composer install - 永久生效：把
umask 0022加到~/.bashrc或/etc/profile（后者影响所有用户，慎用） - Docker 构建中务必显式设置：
RUN umask 0022 && composer install --no-dev --optimize-autoloader，避免继承 base image 的 root 用户umask
vendor/autoload.php 权限出错，别只改它一个文件
单独 chmod 644 vendor/autoload.php 是无效操作。因为 composer dump-autoload 或下次 install 会重写它，还会覆盖 vendor/composer/autoload_psr4.php、autoload_classmap.php 等动态生成文件——它们全受同一 umask 控制。更糟的是，如果这些文件属主是 root（比如你曾 sudo composer install），那改权限也没用，PHP-FPM 进程仍会报 Permission denied。
- 先确认归属：
ls -l vendor/autoload.php，看第一列是否为当前用户 - 属主错误？立刻修复整个
vendor/：sudo chown -R $USER:$USER vendor/ - 属主正确但权限异常？说明
umask不对，回上一节调整 - CI/CD 中验证是否生效：
php -r "require 'vendor/autoload.php'; echo 'OK\n';"，用实际运行用户执行
Windows 和 WSL 用户特别注意
WSL 下行为和原生 Linux 一致，umask 有效；但纯 Windows 不走 Unix 权限模型，vendor/bin/*.bat 脚本才是关键路径。如果你在 WSL 里看到 vendor/bin/phpunit 没有 x 位，不是 bug，是 ZIP 解压机制丢失了可执行位——这和 autoload.php 权限问题无关，属于另一类问题，需用 post-install-cmd 钩子补 chmod +x。
- 别在 Windows 上尝试
chmod或chown，无效且误导 - 跨平台项目建议统一用
php vendor/bin/phpunit显式调用，绕过 shebang 和权限问题 - WSL 用户若用
sudo启动 shell，整个 session 的umask和文件归属都会被污染，退出后重新登录普通用户即可
vendor/composer/ 下所有 autoload_*.php 文件都由 Composer 动态重写，它们的权限和属主完全同步于你执行命令时的环境上下文——不是 Composer 的缺陷，是你运行它的那一刻，就已经决定了整棵树的命运。 
