报permission denied写vendor/autoload.php，根源是vendor目录属主为root，应删vendor和composer.lock后以当前用户重装，或执行sudo chown $user:$user vendor/并chmod u+w vendor/。
composer install 报 Permission denied 写 vendor/autoload.php 怎么办
错误路径明确指向 vendor/，说明问题不在镜像配置，而在目录归属。Composer 本身不关心权限数字（如 755），只认 owner —— 如果 ls -ld vendor/ 第三列显示 root，就是之前误用 sudo composer install 污染的后果。
别跑 chmod -R 777 vendor/：这会让 vendor/bin/phpunit 等可执行文件被 CI 拒收，Git 提交时还报 ownership changed；更糟的是，部分子目录可能已混入 root 所有者，chown -R 都救不回来。
- 最稳妥：删掉整个
vendor/和composer.lock，再用当前用户重装：rm -rf vendor composer.lock && composer install - 不能删
composer.lock（如 CI 部署）：至少确保目录本身可写：sudo chown $USER:$USER vendor/+chmod u+w vendor/ - 顺手检查前几个子目录：
ls -l vendor/ | head -n 3，确认没残留 root 所有者
composer config -g repo.packagist 配了但不生效
镜像没走，根本不是网络慢或服务器挂了，而是配置命令漏了硬性条件。Composer 2.9.6+ 只认三个要素同时满足：repo.packagist（单数、小写、无 s）、中间必须带 composer 类型参数、URL 必须 HTTPS 且末尾带 /。
常见静默失败场景：
-
repos.packagist（多一个 s）→ Composer 直接忽略，不报错也不写入 -
composer config -g repo.packagist https://mirrors.aliyun.com/composer/（漏掉composer）→ 存成字符串，不是源配置，fallback 到官方源 - URL 少斜杠：
https://mirrors.aliyun.com/composer→ 请求拼成/composerpackages.json，404
验证是否真生效：composer config -g repo.packagist 输出必须是完整 JSON 对象，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null 或只返回原始 URL 字符串，都说明没配对。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
Docker 或 CI 里换镜像后仍 Permission denied
本地修好了，构建时又失败，大概率是容器内 UID 与宿主机不一致，或构建阶段用了 USER root 导致 vendor/ 归属为 root，而运行时切到非 root 用户就彻底失权。
关键检查点：
- Dockerfile 是否含
USER root？推荐显式指定普通用户，例如USER 1001 - 挂载代码目录时，宿主机文件 UID 是否与容器内一致（macOS + Docker Desktop 默认 UID 不同）
- CI 脚本里避免
sudo composer install，改用chown -R $CI_USER:$CI_USER .预处理 - 临时验证：容器内跑
whoami && id -u，再对比ls -ld vendor/属主是否匹配
全局缓存目录 ~/.composer/cache 被 root 占了怎么办
报错含 Writing cache file ~/.composer/cache/repo/https---packagist.org/，说明全局缓存目录被污染。这是误用 sudo composer global require 的典型后遗症，后续所有 composer update 都会在写缓存阶段静默卡住，日志里几乎没提示。
修复步骤：
- 查真实路径：
composer config --global cache-dir - 看归属：
ls -ld $(composer config --global cache-dir)，若第三列为root，执行sudo chown -R $USER:$USER $(composer config --global cache-dir) - 更推荐换路径：
mkdir -p ~/composer-cache && composer config --global cache-dir ~/composer-cache - 改完立刻验证：
composer clear-cache不再报错才算生效
容易被忽略的是：这个缓存目录一旦被 root 占据，composer install -vvv 日志里不会出现明显错误，只会卡在“Loading repository”之后不动——你得盯住缓存路径本身，而不是等报错才动手。
