答案是报错路径指向vendor/、composer.lock或~/.composer/cache时，需用ls -ld检查属主是否为当前用户，再执行sudo chown -r $user:$user修复所有权，禁用chmod -r 777。
直接看报错路径，查属主，用 chown 修复所有权——不是权限位（rwx）不够，而是目录“不归你管”。
报错里带 vendor/、composer.lock 或 ~/.composer 就去查它
错误信息中明确出现的路径就是问题根源。比如：
-
file_put_contents(/var/www/myapp/vendor/autoload.php): Permission denied→ 查ls -ld vendor/ -
Could not write to /var/www/myapp/composer.lock→ 查ls -ld composer.lock -
Writing cache file ~/.composer/cache/repo/https---packagist.org/ failed→ 查ls -ld $(composer config --global cache-dir)
只要任意一行输出的第三列（属主）不是当前用户名（$(whoami)），就确认是所有权错配。
用 sudo chown -R $USER:$USER 修，别碰 chmod -R 777
chmod 控制“能不能读写”，chown 才决定“这东西归不归你”。误用 chmod -R 777 会触发 CI 拒收、Git 提示 ownership changed、后续 composer dump-autoload 静默失败。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 修复项目内目录：
sudo chown -R $USER:$USER vendor/ composer.lock - 修复全局缓存：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 整个
~/.composer都是 root？直接重置：sudo chown -R $USER:$USER ~/.composer
sudo 这里只是临时提权跑 chown，不是让你去跑 sudo composer install——后者才是污染源头。
Docker、CI 和 Web 服务用户不一致时的隐性坑
本地好好的，一进容器或上线就报错，大概率是 UID 不匹配或 CLI 与 Web 用户分离：
- Docker 中宿主机 UID 是 1000，容器却以 UID 0 运行 → 启动加
user:1000，或修复时用数字：sudo chown -R 1000:1000 vendor/ - Web 服务（如 Nginx + PHP-FPM）用
www-data，而你用个人账户执行了composer update→ 修复后补一句：sudo chgrp -R www-data storage bootstrap/cache && sudo chmod -R g+w storage bootstrap/cache（仅限 Laravel 类项目） - CI 流水线（如 GitHub Actions）默认非 root 用户 → 开头加：
mkdir -p .composer-cache && chmod 700 .composer-cache，再设COMPOSER_CACHE_DIR="$PWD/.composer-cache"
最容易被忽略的是嵌套污染：一次 sudo composer install 可能让 vendor/ 下混进个别 root 所有子目录，ls -la vendor/ 才能发现；这种情况下 chown -R 仍有效，但若 autoload 已损坏，删掉 vendor/ 重来反而更快。
