95%的“Permission denied”是vendor/或composer.lock被sudo污染为root所有，须用sudo chown -R $USER:$USER vendor/ composer.lock修复所有权，禁用chmod -R 777。
“Permission denied”在 Composer path 依赖场景下，95% 是 vendor/ 或 composer.lock 所有者被 sudo 污染为 root，不是 chmod 能解决的——必须用 chown 归还所有权，再确保 PHP 进程用户（CLI 或 Web）有读权限。
vendor/ 目录报 Permission denied 怎么快速确认和修复
错误常出现在 composer install、composer update 或运行 vendor/bin/phpunit 时，终端明确提示 file_put_contents(/path/to/vendor/autoload.php) 或类似路径失败。
- 立刻执行
ls -ld vendor/：若第三列显示root，说明被sudo composer install污染过 - 同理检查
ls -ld composer.lock，它常和vendor/一起被设为 root 所有 - 修复命令（仅此处该用 sudo）：
sudo chown -R $USER:$USER vendor/ composer.lock（注意末尾没斜杠，否则composer.lock文件本身可能被忽略） - 别用
chmod -R 777 vendor/：它不解决属主问题，还会触发 CI 拒绝、安全扫描告警、Git 提示 ownership changed
vendor/bin 下脚本执行 Permission denied 怎么办
Linux/macOS 下运行 vendor/bin/phpunit 报错，大概率不是目录权限问题，而是 ZIP 解压丢失了可执行位——Git 不跟踪 Unix 权限，每次 composer install 都会重置。
- 临时解法：
chmod +x vendor/bin/phpunit（或批量：chmod +x vendor/bin/*） - 一劳永逸：在
composer.json的scripts区加钩子："post-install-cmd": "chmod +x vendor/bin/*", "post-update-cmd": "chmod +x vendor/bin/*"（仅对 POSIX 系统生效） - Windows 用户无需处理可执行位，但需确认没在 PowerShell 或 CMD 中以“管理员身份运行”执行过 Composer
PHP 进程读不到 vendor/autoload.php 怎么排查
Web 请求或 CLI 脚本报 failed to open stream: Permission denied，指向 vendor/autoload.php，说明 PHP 进程用户（如 www-data、nginx 或你当前 shell 用户）无权读取该文件。
- 先查 PHP 运行用户：
php -r "echo posix_getpwuid(posix_geteuid())['name'];" - 再查文件归属：
ls -l vendor/autoload.php；若属主不是 PHP 用户，且不是同组，就可能读失败 - 安全做法：把 PHP 用户加入你的用户组（如
usermod -a -G $USER www-data），并确保vendor/目录组权限可读（find vendor -type d -exec chmod 755 {} \;，find vendor -type f -exec chmod 644 {} \;） - 更稳妥的是统一用同一用户操作项目（开发时用你自己的账号，部署时用
www-data并chown -R www-data:www-data vendor/）
Docker 或 CI 场景下反复 Permission denied 怎么防
本地好好的，进容器就报错？根本原因是 UID 不一致：宿主机用户 UID 是 1001，容器内默认是 root（0）或 www-data（33），导致挂载的 vendor/ 目录对容器内 PHP 进程不可读写。
- 构建镜像时，显式设置工作目录归属：
RUN chown -R 1001:1001 /app（按你实际 UID/GID 调整） - 运行容器时指定 UID：
docker run -u $(id -u):$(id -g) -v $(pwd):/app php:8.3-cli composer install - GitHub Actions 中，避免 cache: composer 后直接跑 install；加一步清理：
rm -rf vendor/ composer.lock，或强制修复：sudo chown -R $GITHUB_ACTOR /github/workspace/vendor/ - CI 脚本里禁用
sudo composer install——它只会让问题更隐蔽，而不是更干净
最容易被忽略的一点：所有 chown 修复都必须在删掉污染产物（vendor/、composer.lock、缓存目录）之后再重装；只改归属不清理，残留的 root-owned 文件仍可能在 autoload 或插件加载阶段触发静默失败。
