报错路径直接定位问题：vendor/或全局缓存目录权限归属错误；用ls -ld检查属主是否为当前用户；禁用sudo composer install以防root污染；确认项目目录下composer.json存在且属主正确。

看报错路径，立刻锁定问题位置

错误信息里带完整路径的那一行，就是 Composer 实际卡住的地方。别猜，直接盯：file_put_contents(/var/www/myapp/vendor/autoload.php): Permission denied → 问题在 vendor/；Writing cache file ~/.composer/cache/repo/https---packagist.org/packages.json → 问题在全局缓存目录。路径明确，就不用试错。

用 ls -ld 验证当前用户是否真正拥有写权

ls -ld 输出的第一列是权限位（如 drwxr-xr-x），第三列才是属主——这才是关键。执行这三行，看第三列是不是你的用户名（$(whoami)）：

• ls -ld vendor/
• ls -ld composer.lock
• ls -ld $(composer config --global cache-dir)

任意一行显示 root root 或 www-data www-data，而你是 alex，那就坐实了：不是“不能写”，是“不归你管”。权限位再全也没用，操作系统只认属主。

别用 sudo composer install，它会污染整个 vendor/

看似能跑通，实则埋雷：sudo composer install 会让 vendor/ 下所有文件都变成 root 所有。后续你用普通用户运行 composer update 或 php artisan，就会卡在一半、autoload.php 写失败却不报错——这种嵌套污染，chown -R 都不一定能彻底清理干净，最后往往得删掉 vendor/ 重来。

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

确认当前用户对项目目录有完整控制权

进到项目根目录后，执行这两步才叫真正“检查完权限”：

• pwd —— 确认你在对的路径下（composer.json 必须存在且可读）
• ls -l composer.json —— 看权限是否至少为 -rw-r--r--，且属主是你自己

如果属主不是你，直接 sudo chown -R $USER:$USER .（注意结尾的 .）；如果连 composer.json 都不存在，pwd 和 ls 就比任何配置检查都管用——路径错了，其他全是白忙。