应避免用root执行composer命令，已发生则用chown -R $USER:$USER vendor/修复所有权，禁用discard-changes=true，Windows下启用symlink或改用bin-dir配置。
composer install 后 vendor 目录被 root 占用怎么办
直接改权限不是最优解，根本原因是 composer install 在 root 下执行过，导致整个 vendor/ 目录所有者变成 root，普通用户后续运行 composer update 或 PHP 脚本时会因无写权限报错，比如 file_put_contents(/path/vendor/autoload.php): failed to open stream: Permission denied。
实操建议：
- 永远避免用
sudo composer install或在 root 用户下运行 composer 命令；CI/CD 中也应指定非 root 用户执行 - 如果已经发生，先确认当前用户（如
www-data或你的普通用户名），再用chown -R $USER:$USER vendor/递归修复所有权（别只改权限chmod，那治标不治本） - 检查
composer.json是否含"scripts"调用了 shell 命令——某些自定义脚本若用sudo或写死路径，也会悄悄提权
vendor 目录权限设成 755 还是 775
取决于部署环境的用户组模型：本地开发一般用 755（所有者可读写、组和其他人仅读+执行），但生产环境常需多进程协作（如 web server 和 CLI 用户不同但同属一个组），这时 775 更稳妥。
实操建议：
-
755是 Composer 默认行为，安全保守，适合单用户开发机 -
775需确保 web server 用户（如www-data）和部署用户同属一个组（如www-data组），否则仍会权限拒绝 - 别设
777——哪怕临时调试也不行，vendor/里可能有缓存文件或生成的类映射，写入任意内容等于开放服务器后门 - 权限命令用
find vendor -type d -exec chmod 775 {} \;（目录） +find vendor -type f -exec chmod 664 {} \;（文件），避免误给 .php 文件执行位
composer config --global discard-changes true 的副作用
这个配置看似能绕过“本地修改被覆盖”的提示，实际会让 composer update 强制丢弃所有对 vendor/ 内文件的手动改动（包括你改过的权限、符号链接、甚至 patch 补丁），属于高风险操作。
实操建议：
- 仅在 CI 环境中全局启用，开发机上应禁用，改用
--no-interaction+ 显式git stash流程管理变更 - 如果你曾手动修改过
vendor/monolog/monolog/src/Monolog/Handler/StreamHandler.php来调路径权限，开启该配置后下次update就直接回滚，且无日志提示 - 替代方案：用
composer-patches插件管理定制化修改，它会在每次 install/update 时自动重打 patch，比手动改 vendor 可靠得多
Windows 下 vendor 符号链接失效怎么处理
Composer 在 Windows 上默认不创建符号链接（symlink），而是复制文件，导致 vendor/bin 下的可执行文件（如 phpunit）其实是硬拷贝，升级后不会自动更新，还可能因路径硬编码出错。
实操建议：
- 启用 symlink 支持：以管理员身份运行 PowerShell，执行
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser，再在项目根目录运行composer install --prefer-source - 检查是否生效：进
vendor/bin/，用ls -la phpunit（WSL）或dir /a:L（CMD）看是否显示为链接；不是则说明 Git for Windows 没开 core.symlinks - 更稳的路：改用
composer config --global bin-dir 'bin'把二进制文件统一放项目内bin/，再用composer run-script调度，避开 symlink 兼容性问题
composer.json scripts 里的静默提权操作。 
