项目级配置必须写入composer.json的repositories字段，且结构需为顶层对象{"packagist": {"type": "composer", "url": "https://mirrors.aliyun.com/composer"}}，URL末尾不可带/，否则配置静默失效；生效验证须通过composer install -vvv日志或composer diagnose确认。
项目级配置必须写进 composer.json 的 repositories 字段
全局配置（composer config -g）在 CI/CD、宝塔、Docker 或多用户环境下基本不可靠——因为执行命令的用户和实际运行 Composer 的用户往往不一致。项目级配置直接写入 composer.json，天然可提交 Git，团队成员拉下来就能用，行为一致。
关键点不是“加个 URL”，而是结构必须合法：repositories 必须是顶层对象（不是数组），且键名固定为 packagist，type 值必须显式写 composer，URL 末尾不能带 /（这点和全局配置相反）。
- 正确示例：执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer（注意没-g，且 URL 末尾无斜杠） - 如果项目已有
"repositories": []（数组形式），命令会报错；需先手动改成"repositories": {}（空对象）再重试 - 该命令只写
"packagist"子项，不会覆盖已有的私有源（前提是原repositories是对象） - 别手写
"packagist.org": false——这会彻底禁用兜底机制，镜像临时挂了就直接失败
为什么 composer install 还是从官方源拉包？
常见现象：明明改了 composer.json，但 composer install 日志里还是出现 packagist.org。根本原因通常是 repositories 结构不合法，或被其他配置覆盖。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
repositories字段若为数组（[]），Composer 会忽略repo.packagist写入，导致配置静默失效 - 项目中已有
"repositories": [{"type": "vcs", ...}]，而你新写的镜像没放在首位，Composer 可能优先从 vcs 源解析元数据，而非镜像源 -
composer.lock缓存了旧的包地址和 hash，即使composer.json已更新，install仍按 lock 文件执行；必须删掉vendor/和composer.lock后重新composer install - 执行
composer config repo.packagist后，检查composer.json是否真生成了类似"repositories": {"packagist": {"type": "composer", "url": "https://mirrors.aliyun.com/composer"}}的结构
验证镜像是否真正生效的可靠方式
别信 composer config repo.packagist 的输出——它只显示你“写了什么”，不等于 Composer “用了什么”。真正生效要靠网络请求路径验证。
- 加
-vvv运行一次安装：执行composer install -vvv 2>&1 | grep "Downloading"，观察日志中域名是否为mirrors.aliyun.com（或其他你设的镜像域名） - 用
composer diagnose查看 Repo.packagist.org 行，确认显示的是你的镜像地址，而不是https://packagist.org - 临时清缓存测试：
composer clear-cache && composer install --no-cache -vvv，排除本地缓存干扰 - 注意：如果
composer.json里有"packagist.org": false，且镜像又不可达，整个命令会直接报错退出，而不是 fallback
换源后卡在 Resolving dependencies？镜像不背这个锅
镜像只加速下载阶段（Downloading），对依赖解析（Resolving dependencies）完全无影响。卡在这里，99% 和网络无关，而是本地约束太宽或依赖描述不清。
-
"php": "^7.4 || ^8.0"这类宽泛版本约束会让 Composer 尝试大量组合，拖慢解析 -
require-dev里塞了未锁定版本的工具链（如"phpunit/phpunit": "^10.0"），尤其当它们自身依赖复杂时 - 用了大量
dev-main或dev-develop分支依赖，Composer 需反复探测可用版本 - 解决方法不是换镜像，而是收紧约束：
"php": "^8.1"、锁定 dev 工具版本、移除不必要的require-dev项
项目级配置写进 composer.json 看似多一步，但它把环境决策权交还给代码本身——哪天镜像站维护，你改一行 URL 就能切回官方源，不用登录每台服务器去修全局配置。
