答案是90%因vendor/、composer.lock或~/.composer归属root而非当前用户，应先用ls -ld定位属主，再执行sudo chown -r $user:$user修复所有权。

非 root 用户运行 Composer 时的权限问题，90% 不是缺权限，而是所有权错配 —— vendor/、composer.lock 或 ~/.composer 被 root 占了，普通用户自然被拦在门外。

为什么 composer install 报 Permission denied 却不是 chmod 的事

错误信息里带路径的那行（比如 file_put_contents(./vendor/autoload.php)）就是关键线索。它不是说“你没写权限”，而是“这扇门不归你管”。ls -ld vendor/ 一看，如果第一列是 drwxr-xr-x 2 root root，那就坐实了：目录属主是 root，当前用户只是访客。

常见误操作包括：

• 用 sudo composer install 一次，vendor/ 就全变成 root 所有，后续所有命令都卡住
• CI/CD 流水线里没指定用户，容器默认以 root 启动，挂载的宿主机代码目录一写就崩
• ~/.composer 整个目录被 sudo curl | php 污染过，导致 composer global require 失败

修复 vendor/ 和 composer.lock 的归属权

别碰 chmod -R 777，它临时放行但破坏安全策略，还可能让 Git 忽略混乱或 autoload 静默失败。

只做一件事：sudo chown -R $USER:$USER vendor/ composer.lock（注意末尾斜杠不能少，否则子目录可能漏掉）。

验证是否修好：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• ls -ld vendor/ 输出第一列应含当前用户名，比如 drwxr-xr-x 12 yourname yourname
• 跑 composer install --no-scripts 看能否生成基础结构；成功后再补 composer run-script post-install-cmd

全局缓存和 ~/.composer 归属被锁死怎么办

如果 composer global require laravel/installer 失败，或 laravel 命令提示 command not found，大概率是 ~/.composer 被 root 占了。

分步检查与修复：

• 查缓存路径：composer config --global cache-dir（通常是 ~/.composer/cache）
• 看归属：ls -ld ~/.composer，若输出含 root root，立刻执行：sudo chown -R $USER:$USER ~/.composer
• 顺手加固：chmod -R u+rw ~/.composer，避免系统 umask 导致子目录默认无写权限
• 确保 bin 目录可访问：composer config -g bin-dir 默认是 ~/.composer/vendor/bin，把它加进 $PATH（如 export PATH="$HOME/.composer/vendor/bin:$PATH"），或更稳妥地改用用户级 bin：mkdir -p ~/bin && composer config -g bin-dir ~/bin

Docker 或 CI 环境中 UID/GID 错位怎么绕开

宿主机用户 UID 是 1001，容器里却用 root（UID 0）跑 PHP 进程，挂载进来的 vendor/ 自然不可写 —— chown 在容器内常失效，尤其 macOS/Windows 下文件系统元数据丢失。

务实解法不是硬改 Dockerfile，而是让 Composer 主动适配：

• Composer 2.2+ 支持 --uid 和 --gid 参数：composer install --uid=1001 --gid=1001
• CI 脚本开头加：mkdir -p .composer-cache && chmod 700 .composer-cache，再通过环境变量指定：COMPOSER_CACHE_DIR="$PWD/.composer-cache"
• 降低权限敏感度：composer install --no-plugins --no-scripts --no-autoloader
• Alpine 镜像若卡在 Extracting archive，加 -v 看是否 musl libc 解包静默失败

真正难处理的从来不是报错本身，而是第一次误用 sudo composer install 后，整个 vendor/ 目录树的所有权就脱离了你的控制 —— 它不会自动恢复，必须手动归还，而且得一次清干净，漏一个子目录都可能在几小时后某个 dump-autoload 里突然爆发。