composer config -g repo.packagist 没生效大概率因键名错（如repos.packagist）、漏type值、url末尾缺/，任一出错即静默回退官方源；验证需输出完整json对象。
composer config -g repo.packagist 为什么没生效
大概率是三个硬性条件漏掉一个：repo.packagist 键名写成 repos.packagist（多了一个 s）、漏掉 composer 这个 type 值、URL 末尾没加 /。这三处任一出错，Composer 2.x 都会静默 fallback 到官方源，不报错也不提示。
验证是否写入成功，直接运行：composer config -g repo.packagist。输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON 对象。空、null、报错或只返回 URL 字符串（新版行为），都说明配置失败。
-
repo.packagist是固定键名，不能写成packagist.org或repositories.packagist -
composer是type值，不是可选参数，必须显式写出 - URL 必须是 HTTPS，且末尾带
/，例如https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌ - Windows 用户配置文件路径在
C:\Users\用户名\AppData\Roaming\Composer\config.json，别手写，用命令写入更安全
项目级配置怎么避免覆盖私有仓库
项目已有 repositories 字段时，手动编辑 composer.json 极易出错——漏方括号、引号不全、误删已有源。正确做法是让 Composer 自动合并：
进项目根目录，执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意：不加 -g）
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 如果
composer.json原本是"repositories": {}，命令会转为标准对象格式并追加packagist条目 - 如果原本是
"repositories": []（数组格式），命令会报错；需先手动改成对象再重试 - 千万别写
"packagist": false，这会导致基础包（如php、ext-json）校验失败 - 改完后运行
composer update --lock，确保composer.lock记录新源地址
宝塔/CI 环境里全局配置为啥不起作用
全局配置写在 /root/.composer/config.json，但它只对 root 用户生效。宝塔「一键部署」、PHP 管理器、计划任务默认以 www 用户运行，根本读不到 root 的配置。
解决方法很直接：先确认实际执行用户（比如 whoami 或查日志 UID），再针对性配置：
- 给
www用户配：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - GitHub Actions 等 CI 环境默认不读全局配置，需在 workflow 中显式设置
COMPOSER_HOME或改用项目级配置 - 某些 PHP 管理器（如宝塔内置 PHP）可能使用独立的
composer二进制或环境变量，建议用which composer和composer --version确认实际调用路径
换源后仍卡在 Resolving dependencies 怎么办
这个阶段不走网络，但严重受 PHP 环境和依赖结构影响。常见真实原因包括：
-
memory_limit过低（如 128M），导致依赖图解析失败重试 —— 临时加COMPOSER_MEMORY_LIMIT=-1再试 - 启用了
xdebug（运行php -v可确认），会让解析慢 5–10 倍 —— 用php -d xdebug.mode=off $(which composer) install临时禁用 -
platform配置与实际 PHP 版本不匹配（如"php": "7.4"却在 PHP 8.2 上运行），触发降级查找逻辑 -
composer.lock残留已下线包的引用，导致回退搜索 —— 删掉vendor/和composer.lock，再用composer install --no-cache - 旧版插件如
fxp/composer-asset-plugin仍在运行，它不走 Composer 镜像配置，且额外请求 Bower/NPM 源（国内无镜像）
真正容易被忽略的是：镜像只加速元数据拉取和 ZIP 包下载，但依赖解析本身完全本地进行。很多开发者以为换了镜像就万事大吉，结果卡在解析阶段才发现是 PHP 内存或 Xdebug 拖了后腿。
