90%的“Permission denied”是目录属主为root而非当前用户所致，需定位报错路径→用ls -ld查归属→执行sudo chown -R $USER:$USER修复，禁用chmod 777和sudo composer install。
composer install 报 Permission denied 本质是属主错配，不是权限数字问题
错误信息里带的完整路径就是线索。比如报 file_put_contents(/var/www/myapp/vendor/autoload.php): failed to open stream: Permission denied，那问题就在 vendor/；如果报 Writing cache file ~/.composer/cache/repo/https---packagist.org/packages.json: failed to open stream，就盯 $(composer config --global cache-dir) 这个路径。
立刻检查三处：
-
ls -ld vendor/—— 看属主是不是当前用户（$(whoami)） ls -ld composer.lockls -ld $(composer config --global cache-dir)
只要任一输出里第一列显示 root root 或其他非当前用户，就确认是所有权问题。别急着 chmod -R 777，那会触发 CI 拒绝、Git 警告、安全扫描器标高危。
修复动作必须用 chown -R $USER:$USER，不是 chmod
最小必要动作只改属主，不碰权限位：
- 项目内修复：
sudo chown -R $USER:$USER vendor/ composer.lock - 全局缓存修复：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 若 Web 服务器（如 PHP-FPM）以
www-data运行，且需运行时写入（如生成 autoload），则还需确保该用户能读取vendor/：把当前用户加进www-data组，或反向chown -R www-data:www-data vendor/（仅限生产部署且明确需要）
注意：sudo composer install 是污染源头——它会让 vendor/ 下混入 root 所有文件，后续 update 可能卡在中间、autoload.php 生成失败却不报错，这种嵌套污染 chown -R 都不一定能彻底清理干净，最后往往得删掉 vendor/ 重来。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
CentOS 上 Composer 二进制本身也要检查属主
如果连 composer --version 都报权限错，问题可能出在 Composer 可执行文件上：
- 查位置：
which composer（常见为/usr/local/bin/composer） - 看属主：
ls -l $(which composer) - 若属
root:root但你不是 root，又不想总加sudo，可改属主：sudo chown $USER:$USER $(which composer) - 更推荐做法：把 Composer 装到用户目录下，避免系统级路径权限纠缠（例如
curl -sS https://getcomposer.org/installer | php -- --install-dir=$HOME/bin --filename=composer，再加$HOME/bin到$PATH）
CentOS 默认 umask 常为 0022，新生成文件无组写权限，若团队协作部署，建议设为 0002 并统一用户组，否则 composer install 后其他人可能无法继续操作 vendor/。
自动化部署时怎么避免每次手动 chown
CI/CD 流水线或 Ansible 部署脚本中，不能依赖人工干预。关键点是：在 composer install 之后、服务启动之前，插入属主修复步骤：
- Ansible 示例：
- name: Fix vendor ownership shell: chown -R {{ ansible_user }}:{{ ansible_user }} /var/www/myapp/vendor - GitHub Actions：
run: sudo chown -R ${{ github.actor }}:$GITHUB_ACTOR ./vendor（注意 runner 用户名可能非$USER） - Docker 构建中：在
RUN composer install后加RUN chown -R www-data:www-data /app/vendor，并确保容器以该用户运行
真正容易被忽略的是：Web 服务器进程用户（如 www-data）、CLI 当前用户、Git 部署用户三者不一致时，chown 只修了一半——比如 CLI 用 alice 装包，Nginx 用 www-data 读，但 alice 没加进 www-data 组，chown alice:alice vendor/ 后，Nginx 仍读不了。这时候得同步处理组权限或用户归属，而不是反复调 chmod。
