根本原因是vendor/等目录属主为root而非当前用户，需用ls -ld定位路径归属，再执行sudo chown -R $USER:$USER vendor/ composer.lock修复所有权，禁用chmod 777和sudo composer install。
根本不是 autoload.php 生成失败，而是它试图写入的目录（比如 vendor/）不属于当前用户。
报 file_put_contents(./vendor/autoload.php): Permission denied 怎么定位
错误里带路径的那一行就是线索——别看“Permission denied”四个字，直接盯住括号里的完整路径：./vendor/autoload.php、vendor/composer/autoload_classmap.php 或 vendor/autoload.php 都指向同一个问题：整个 vendor/ 目录归属错了。
- 立刻执行
ls -ld vendor/，如果输出第一列是drwxr-xr-x 12 root root，说明属主是root，不是你当前用户 - 顺手查一下
whoami，确认当前用户名；再查ls -ld composer.lock，它也常被sudo composer install一并污染 - 如果
vendor/和composer.lock都显示root，基本可以排除其他干扰，就是所有权错配
为什么不能用 chmod -R 777 vendor/ 或 sudo composer install
改权限位（rwx）不解决归属问题，反而埋雷：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
chmod -R 777会让vendor/bin/phpunit这类可执行文件被 CI 工具或安全扫描器直接拒绝 -
sudo composer install是污染源头——它会以root身份创建所有子目录，后续composer update可能只失败一半，连chown -R都救不回来 - Git 提交时会提示
ownership changed，团队协作中极易引发混乱
修复只需一行 chown 命令
所有权归还才是治本操作，且必须精准：
- 只修项目内目录：
sudo chown -R $USER:$USER vendor/ composer.lock（注意末尾斜杠不能少） - 如果
composer dump-autoload还报错，再查缓存：ls -ld $(composer config --global cache-dir)，若属主是root，补上：sudo chown -R $USER:$USER $(composer config --global cache-dir) - 极端情况整个
~/.composer都被污染：sudo chown -R $USER:$USER ~/.composer
修复后先跑 composer install --no-scripts 看 vendor/autoload.php 能否生成；成功后再补 composer run-script post-install-cmd。最容易被忽略的是：Docker、CI 或 WSL 下，UID 不一致会导致同样的命令在不同环境表现迥异——别只盯着命令对不对，先 id -u 确认 UID 是否匹配挂载卷或容器用户。
