composer全局镜像配置必须执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，缺一不可：键名repo.packagist（单数）、composer为type值、url须以/结尾且用https；否则静默失效，仍连packagist.org。
不能靠“规避封禁”解决问题——Composer 官方源 packagist.org 本身没被封，真正卡住的是国内用户访问它的 TLS 握手或 DNS 解析；换镜像本质是换元数据代理，不是绕过安全机制，配置错一步就等于白换。
composer config -g repo.packagist 命令必须带三个硬参数
这条命令不是“设个 URL 就完事”，漏掉任意一个都会静默失效，且不报错：
-
repo.packagist是唯一合法键名（注意是repo单数，不是repos） - 中间的
composer是 type 值，不可省略——写成composer config -g repo.packagist https://mirrors.aliyun.com/composer/会 fallback 回https://packagist.org - URL 必须以
/结尾，且用https://开头；少斜杠会导致请求路径变成/composerpackages.json，返回 404
正确写法：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。验证是否生效：运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
项目级 repositories 会彻底屏蔽全局镜像
只要项目根目录 composer.json 里存在 repositories 字段（哪怕内容为空、只有一行 "packagist.org": false），全局配置就完全失效——这不是优先级低，而是直接跳过。
常见于 Laravel 脚手架或团队模板，默认带空 repositories 块。排查方式：
- 进项目目录后运行
composer config repo.packagist（不加-g），如果输出为空或报错，说明项目级已接管 - 运行
composer diagnose，看Repo packagist.org:后面是不是你设的镜像地址
修复建议：删掉 composer.json 中整个 repositories 块；或改用 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加 -g）覆盖写入，该命令会安全合并进 repositories，不破坏已有私有源。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
换源后不清理缓存 = 请求仍走旧地址
Composer 缓存的是元数据快照（如 p2/monolog/monolog.json），里面存的仍是旧源地址和 hash。即使镜像已生效，composer update 仍可能因校验失败报 Package not found 或卡在 Loading composer repositories。
必须执行：
composer clear-cache- 确认缓存目录清空：
ls -la ~/.composer/cache/（Linux/macOS）或dir %APPDATA%\Composer\Cache\（Windows）应为空或只剩空子目录 - 删掉项目下的
vendor/和composer.lock - 再跑
composer install -vvv，日志中看到类似GET https://mirrors.aliyun.com/composer/p2/monolog/monolog.json才算真正走镜像
别信 composer config 输出，要看真实网络请求
composer config -g repo.packagist 只告诉你字段值，不反映实际发了什么请求。很多用户看到输出正常，但 composer require monolog/monolog --no-install -vvv 日志里仍出现 Downloading https://repo.packagist.org，说明配置被项目级覆盖或缓存未清。
更隐蔽的干扰项：
- 环境变量
COMPOSER_REPO_PACKAGIST会压倒所有配置，运行env | grep COMPOSER_REPO_PACKAGIST检查是否存在 - CI/CD 或宝塔环境常因用户权限错位导致配置“写了等于没写”——比如 PHP 进程以
www用户运行，而composer config -g写的是root的~/.composer/config.json
最稳的做法是：项目级配置 + 提交 composer.json 到 Git，避免依赖全局设置；同时把 composer.lock 提交进版本库——只要它完整，composer install 就完全不发网络请求，缓存、DNS、中间人攻击全被挡在外面。
