95%的Permission denied报错是目录属主错配而非权限不足，vendor/、composer.lock或~/.composer被sudo污染为root所有，应删掉vendor/和composer.lock后以当前用户重装，或用chown修复归属并chmod u+w vendor/。
95% 的 Permission denied 报错不是权限不够，而是目录属主错配——vendor/、composer.lock 或 ~/.composer 被 sudo 污染成了 root 所有，而你正以普通用户运行命令。
vendor/ 目录报 Permission denied 怎么修
终端错误里出现 vendor/autoload.php 或 vendor/composer/installed.json？问题就锁死在 vendor/ 目录。
- 先看归属：
ls -ld vendor/，如果第一列是drwxr-xr-x 3 root root，说明它被sudo composer install创建过 - 别用
chmod -R 777，这不解决问题还破坏安全边界 - 正确做法：删掉整个
vendor/和composer.lock（开发环境可接受），再用当前用户重跑composer install - 若不能删
composer.lock（如 CI 部署），至少确保目录本身归属是你自己：chown $USER:$USER vendor/，再加写权限：chmod u+w vendor/
~/.composer 缓存或全局 bin 目录找不到命令
composer global require laravel/installer 成功但输 laravel 提示 command not found？问题常出在两处：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 查全局 bin 路径：
composer config -g bin-dir，默认是~/.composer/vendor/bin - 检查该路径归属：
ls -ld $(composer config -g bin-dir)，若属主不是你，执行：sudo chown -R $USER:$USER $(composer config -g bin-dir) - 确认它已加入
$PATH：在~/.zshrc或~/.bashrc加export PATH="$HOME/.composer/vendor/bin:$PATH"，然后source ~/.zshrc - 更稳妥做法：把 bin-dir 改到你完全可控的路径：
mkdir -p ~/bin && composer config -g bin-dir ~/bin && export PATH="$HOME/bin:$PATH"
Docker 或 CI 环境里反复 Permission denied
本地好好的，一进容器就报错？本质是 UID 不一致：宿主机用户 UID 是 1001，容器内默认用的是 0（root）或另一个 UID，挂载卷后文件不可写。
- 不要在容器里用
sudo composer install，改用匹配 UID 的用户启动：docker run -u $(id -u):$(id -g) ... - CI 脚本中，避免 cache: composer 后直接跑 install；加一步清理：
rm -rf vendor/ composer.lock && composer install，或强制修复：sudo chown -R $USER:$USER vendor/ - 构建镜像时，显式设置工作目录归属：
RUN chown -R www-data:www-data /app（按你实际 Web 用户名调整）
最易被忽略的一点：所有修复都必须在删掉污染产物（vendor/、composer.lock、缓存目录）之后再重装；只改归属不清理，残留的 root-owned 文件仍可能在 autoload 或插件加载阶段触发静默失败。
