vendor目录不能设777，因composer不控制权限，高权限用户执行install/update会导致php文件、autoload映射及bin脚本全局可写，易被攻击者篡改；须通过umask、dockerfile、ci非特权用户及安装后chmod加固权限。
vendor 目录为什么不能 777？
因为 composer install 或 composer update 默认不会改文件权限，而很多部署脚本或 CI 环境会用 root 或高权限用户执行，导致 vendor/ 下的 PHP 文件、autoload 类映射、甚至第三方包里的 shell 脚本（比如 bin/ 下的）被设成全局可写。攻击者一旦通过某处代码执行漏洞进入，就能直接篡改 vendor/autoload.php 或注入恶意扩展类——这不是理论风险，真实入侵案例里常有。
Composer 本身不控制权限，得靠系统层干预
Composer 没有 --chmod 参数，也不读取 composer.json 里的权限配置。它只管下载和 autoload 生成。真正起作用的是：你运行命令时的 umask、宿主文件系统挂载选项（如 noexec）、以及后续是否手动加固。
- 检查当前 umask：
umask，若输出是0002，新建文件默认就是664（组可写），不安全 - 临时收紧：执行前设
umask 0022（文件 644，目录 755） - Docker 部署时，在
Dockerfile中加RUN umask 0022 && composer install --no-dev --optimize-autoloader - CI 脚本里避免用
sudo composer install，改用非特权用户 + 正确 umask
安装后必须手动修复 vendor 权限
哪怕 umask 设对了，某些包自带的 post-install-cmd 脚本（比如 Laravel 的 php artisan storage:link）仍可能创建可写 symlink 或目录。所以安装完要立即清理：
- 禁止写入：
find vendor/ -type f -exec chmod 644 {} \; - 仅目录可执行：
find vendor/ -type d -exec chmod 755 {} \; - 特别处理
vendor/bin/：里面脚本需可执行，但不应可写，单独跑chmod 755 vendor/bin/* - 如果用了
composer install --no-dev，确认vendor/composer/installed.json是 644，不是 666
Web 服务器能否直接读 vendor？
不能。PHP-FPM 或 Apache 若以 web 用户身份运行，且 vendor/ 和项目根目录同属一个用户组，那 644/755 就够；但如果 web 用户和部署用户不同（比如部署用 deploy，PHP-FPM 用 www-data），就得加组权限或 ACL，而不是放宽文件权限。
- 推荐做法：把
www-data加入部署用户组，再设chmod -R g+rX vendor/ - 绝对不要用
chmod -R 775 vendor/—— 组内任意成员都能改代码 - 禁用 PHP 的
allow_url_include和auto_prepend_file，防止绕过权限加载恶意文件
vendor/composer/ 子目录下的权限是否一致。每次部署完，花十秒跑一遍 ls -l vendor/composer/ 看看 autoload_classmap.php 是不是 644，比事后排查入侵快得多。 
