Composer不控制vendor权限，其文件权限由用户、umask和文件系统决定；正确做法是分层加固：chmod 755 vendor目录、确保web用户同组、设置umask 002，并通过post-autoload-dump钩子修复必要目录权限。
Composer 本身不提供批量修改依赖库文件创建权限的机制，它生成的 vendor 目录及其中文件的权限，完全由当前用户、umask 和文件系统行为决定。你无法通过 composer.json 配置或命令行参数让 Composer “自动 chmod 755 所有 .php 文件”——这不是它的职责，也从未设计为如此工作。
为什么 vendor 文件权限看起来“不对”？
常见现象是：Web 服务器（如 nginx）访问时提示 file not found 或 Permission denied，但 CLI 下 php artisan serve 正常。这通常不是 vendor 里文件权限太低，而是：
-
vendor目录本身缺少执行权限（x位）——Linux/macOS 下目录无x就无法进入或遍历 - Web 服务器用户（如
www-data）不属于当前项目所有者组，且目录未设组可读/可执行 - PHP 运行模式（如 mod_php vs PHP-FPM）对文件权限敏感度不同
真正有效的权限加固方式（非 chmod -R 777）
不要对 vendor 执行 chmod -R 777，这会破坏安全边界，且 Composer 后续操作可能覆盖权限。正确做法是分层控制：
- 确保
vendor目录有r-x给组/其他用户：chmod 755 vendor（不是递归） - 让 Web 用户和 CLI 用户同组（如都加入
www-data），再用chgrp -R www-data vendor - 设置 umask 为
002（而非默认022），使新创建文件自动带组写权限 —— 在 shell 配置中加umask 002，或在 CI 脚本开头显式设置 - 若用 Docker，直接在
Dockerfile中指定运行用户与组 ID，并用chown -R 1001:1001 /app/vendor
想让新装包自动带特定权限？只能靠 post-autoload-dump 脚本
Composer 提供 post-autoload-dump 钩子，在每次 autoload.php 重建后触发。你可以在这里统一修复关键目录权限：
"scripts": {
"post-autoload-dump": [
"@php -r \"file_exists('storage') && chmod(0775, 'storage');\"",
"@php -r \"file_exists('bootstrap/cache') && chmod(0775, 'bootstrap/cache');\""
]
}
注意：chmod() 是 PHP 函数，只改目录权限；它不会递归，也不影响 vendor 内部文件——因为那些文件本就不该被 Web 服务器直接读取，而是经由自动加载器加载。
vendor 里的文件权限真有必要管吗？
绝大多数情况下，不需要。PHP 解析器读取 .php 文件只需文件自身有 r 权限、所在目录有 r-x 权限即可。而 Composer 创建的 vendor 文件默认就是 644（文件）和 755（目录），只要你的 umask 没被改成 077，就足够安全且可用。强行递归 chmod 可能导致某些包内脚本（如 bin 文件）丢失可执行位，反而引发命令找不到错误。
