composer config -g repo.packagist 不生效的根本原因是键名写错（如repos.packagist）、缺type值“composer”、url未以/结尾，三者任一缺失均静默回退官方源，且不报错。
composer config -g repo.packagist 命令为什么总不生效
它不报错，但也不起作用——这是最让人抓狂的情况。根本原因就三点：键名写错、type 缺失、URL 格式不对。
-
repo.packagist不能写成repos.packagist（多一个s就完全被忽略） - 中间的
composer是type值，不是可选参数，漏掉就会 fallback 到官方源 -
url必须是 HTTPS，且末尾带/，比如https://mirrors.aliyun.com/composer/；缺斜杠会导致路径拼成/composerpackages.json直接 404 - 验证是否写入成功，只看这一条：
composer config -g repo.packagist，输出应为{"type": "composer", "url": "..."}；空、null或报错说明没写对
全局配置在宝塔、Docker、CI 中为何经常失效
不是镜像不行，是配置没落到真正执行命令的用户身上。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 宝塔后台「一键部署」默认以
www用户运行，而composer config -g默认写的是/root/.composer/config.json，www根本读不到 - Docker 构建时，基础镜像（如
php:8.2-cli）往往没有~/.composer目录，composer config -g会静默失败 - CI 流水线（如 GitHub Actions）用的是
runner用户，你本地root配的全局配置对它完全无效 - 解决方法很直接：改用项目级配置，在项目根目录执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g），它会安全合并进composer.json的repositories字段
换镜像后依然卡在 Resolving dependencies 怎么办
镜像只加速元数据拉取和 ZIP 包下载，不参与依赖解析。卡在这里，问题一定出在本地环境或 composer.json 本身。
- 检查 PHP 扩展是否启用：
php -m | grep -E 'openssl|curl|zlib'，缺任意一个都可能导致 TLS 握手失败或压缩解包异常 - 确认
disable_functions没禁用proc_open或putenv，否则composer config -g会报错或静默失败 - 如果
composer.json里写了过于宽泛的版本约束（如"^1.0 || ^2.0"），Composer 解析器可能陷入组合爆炸，耗时几十秒甚至超时 - 升级到
Composer 2.9.6+能显著改善大型项目依赖解析性能，旧版本在复杂约束下容易卡死
项目级配置怎么写才安全可靠
手动编辑 composer.json 容易格式出错或覆盖已有源，推荐用命令自动注入。
- 先确保
composer.json顶层的repositories是对象（{}），不是数组（[]）；如果是数组，命令会报错，需先手动改成"repositories": {} - 执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/，它会自动 merge 进去，不破坏原有私有源 - 切勿写
"packagist": false—— 这会彻底关掉官方源，一旦镜像临时不可用，composer install直接失败 - 改完必须删掉
vendor/和composer.lock，再跑composer install；否则旧 lock 文件里的 hash 可能和镜像元数据不匹配，导致校验失败
composer.json 的约束合理性。很多“换源没用”的问题，其实根本不在源本身。
