内容摘要是对图书或文章主要内容的简要介绍，需客观精炼地概括研究目的、方法、结果及结论，具有独立性与自明性，便于读者快速把握核心信息。
别用 sudo composer install，也别 chmod -R 777，95% 的权限问题只是文件属主错了——修对 owner 就行，不是加权限。
ls -ld 看清谁在拦你
报错里带路径就直接查它：file_put_contents(/home/alex/myapp/vendor/autoload.php): Permission denied → 查 vendor/；Writing cache file ~/.composer/cache/repo/... → 查 ~/.composer/cache。
- 运行
ls -ld vendor/、ls -ld composer.lock、ls -ld $(composer config --global cache-dir) - 输出第一列是权限，第二列是 owner，第三列是 group；只要 owner 不是
$(whoami)（比如显示root root），就是它了 - 如果
ls -ld ~/.composer也显示root，说明全局配置全被锁死，得一并修
chown -R $USER:$USER 是标准解法
修复目标明确：把目录所有权还给当前用户，不是开放所有权限。
- 项目目录全修：
sudo chown -R $USER:$USER ./（注意结尾的./，别漏） - 只修 vendor 和 lock：
sudo chown -R $USER:$USER vendor/ composer.lock - 修全局缓存：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 修 ~/.composer 整个目录：
sudo chown -R $USER:$USER ~/.composer，再补一句chmod -R u+rw ~/.composer防 umask 导致子目录不可写
Docker 和 CI 环境要对齐 UID
容器里报 Permission denied，大概率是宿主机文件属主 UID=1000，但容器以 UID=0（root）或 UID=1001 启动，系统直接拒绝写入。
- Docker 运行时加
-u $(id -u):$(id -g)，让容器内用户和宿主机一致 - GitHub Actions 中，cache 解压后权限继承自缓存创建者，加一步
chown -R $USER:$USER vendor/或直接rm -rf vendor/ composer.lock再装 - Dockerfile 里别用
USER root跑composer install；改用多阶段构建，或显式创建 UID 匹配的非 root 用户 - Mac 上挂载
/Volumes/或虚拟机共享盘，先touch test && rm test验证底层是否支持 Unix 权限；不支持就挪到~/Sites再试
composer global require 找不到命令？PATH 和 bin-dir 权限都得看
装完 laravel/installer 却提示 command not found，不是没装成，而是 ~/.composer/vendor/bin 没进 PATH，或该目录本身属主不对。
- 查 bin 目录在哪：
composer config -g bin-dir，默认是~/.composer/vendor/bin - 确认该路径属主是当前用户：
ls -ld $(composer config -g bin-dir) - 把它加进 shell 配置：
echo 'export PATH="$HOME/.composer/vendor/bin:$PATH"' >> ~/.zshrc && source ~/.zshrc - 更稳做法：换到用户级 bin 目录，避开权限纠缠：
mkdir -p ~/bin && composer config -g bin-dir ~/bin，再加~/bin到 PATH
真正麻烦的不是修权限，而是修完立刻又被污染——只要有一次 sudo composer install，vendor 就又归 root；只要 COMPOSER_HOME 指向 /root/.composer，global 命令就永远跟你无关。盯住 owner，而不是 chmod。
