Composer本身不管理vendor权限，问题源于执行用户错误（如sudo），修复须先chown归还所有权，再分层chmod：文件644、目录755、bin脚本755，禁用sudo install并控制umask。
Composer 本身不分配、也不管理 vendor 目录权限，所谓“分配权限”其实是部署阶段对文件属主和访问控制的补救与加固。直接运行 composer install 不会自动设 chmod 或 chown，它只按当前用户权限写入文件——问题往往出在谁执行了命令，而不是命令本身。
为什么 vendor 下的文件权限不对？
根本原因不是 Composer 没做对，而是你（或 CI/容器）用错了用户身份：
- 用
sudo composer install或 root 用户执行过，导致vendor/及其所有子文件（包括vendor/autoload.php、vendor/composer/autoload_psr4.php）属主变成root - Web 服务器（如 PHP-FPM）以
www-data运行，但vendor/属于deploy用户且无组读权限 -
umask设置为0002或更宽松，导致新生成 PHP 文件默认是664，目录是775，存在组内可写风险
修复 vendor 权限的正确操作顺序
不能只改单个文件，也不能暴力 chmod -R 777 vendor/。必须分层处理：
- 先归还所有权：
sudo chown -R $USER:$USER vendor/（开发机）或sudo chown -R www-data:www-data vendor/（生产 Web 服务器） - 再收紧文件权限：
find vendor/ -type f -exec chmod 644 {} \;（PHP 类、配置、autoload 映射都应是 644） - 再放开目录权限：
find vendor/ -type d -exec chmod 755 {} \;（目录需可进入，但无需写权限） - 单独处理
vendor/bin/：chmod 755 vendor/bin/*（里面是可执行脚本，不能设成 644） - 验证关键文件：
ls -l vendor/autoload.php应显示-rw-r--r--，且属主是你预期的运行用户
如何避免每次 install 都要手动修？
靠环境控制，而不是事后补救：
- CI/CD 构建时，明确指定非特权用户：Dockerfile 中加
USER 1001，并前置RUN umask 0022 - 禁止在任何环节使用
sudo composer install；若提示 Permission denied，说明目录归属错了，不是权限不够 - 项目根目录下运行
composer install --no-dev -o前，确保vendor/和composer.lock都属于当前用户（ls -ld . vendor/ composer.lock） - 如果用了私有包，
auth.json必须由构建用户持有，否则拉取失败会中断流程，别指望权限修复能绕过认证
最容易被忽略的是：vendor/composer/ 下所有 autoload_*.php 文件会在每次 dump-autoload 时重写，它们的权限完全继承自当前用户的 umask 和文件系统行为——修一次没用，得从源头卡住用户和 umask。
