Composer install慢90%非VS Code问题，而是镜像未生效：必须严格满足repo.packagist单数键名、显式type composer、URL以/结尾三条件，且需执行composer clear-cache并验证config输出为完整JSON。
VS Code 里 composer install 慢，90% 不是 VS Code 的问题，而是 Composer 根本没走国内镜像 —— 配置写错了、缓存没清、或项目级配置覆盖了全局。
为什么 composer config -g repo.packagist 总不生效
这条命令必须同时满足三个硬条件，缺一即静默失败（不报错，但也不起作用）：
-
repo.packagist必须是单数repo，写成repos.packagist或repositories都无效 - 命令末尾必须显式带上
composer这个 type 值，不能省略；否则 Composer 2.0+ 会 fallback 到https://packagist.org - URL 必须是 HTTPS 且末尾带
/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会导致请求/composerpackages.json而 404）
验证是否真正写入：运行 composer config -g repo.packagist，输出必须是完整 JSON，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、或含 packagist.org，说明没配对。
VS Code 终端里执行仍卡在 packagist.org？先清缓存
Composer 优先读本地缓存，哪怕你刚改完镜像，只要 ~/.composer/cache/repo/ 里还存着旧的 packages.json，它就会继续往海外源发请求——直到超时才 fallback，这个过程极耗时。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须执行
composer clear-cache，不是可选项 - 清完后手动检查缓存目录是否真空：
ls ~/.composer/cache/repo/应无内容 - 临时验证是否走新源：加
--no-cache再跑一次composer install -vvv，如果变快，就坐实是缓存问题 - 日志末尾出现
Reading packages.json from cache at /https---mirrors-aliyun-com-composer/才算真正生效
项目根目录有 composer.json 就可能绕过全局镜像
Composer 的配置优先级是：项目级 repositories > 临时 --repository > 全局 repo.packagist。只要项目 composer.json 里存在 "repositories" 字段（哪怕只是空对象 {} 或空数组 []），全局镜像就会被跳过。
- 检查命令：
composer config --list和composer config --list --global对比，确认实际生效的是哪个 - 若项目已有私有源，别用
composer config repo.packagist ...（它会全量替换repositories），应手动编辑composer.json，确保结构类似：
"repositories": {
"packagist": {
"type": "composer",
"url": "https://mirrors.aliyun.com/composer/"
},
"my-private": {
"type": "vcs",
"url": "https://git.example.com/pkg"
}
}
注意：键名必须是 "packagist"（小写，单数），且不能和已有私有源同名冲突。
换源后 Resolving dependencies 还卡几分钟？这不是镜像的事
镜像只加速下载，不解决依赖求解慢的问题。如果卡在 Resolving dependencies through SAT，大概率是本地约束太宽：
-
"*"、"dev-main"、"^1.0 || ^2.0"这类版本约束会让 Composer 穷举数百个包的兼容性元数据 -
"php": ">=7.4"这类松散 PHP 版本声明也会显著拖慢求解器 -
composer update仍需串行算依赖图，parallel-downloads对它无效（只对install生效） - 若已用
composer.lock，可先试composer install --no-suggest跳过提示环节，看是否提速
真正容易被忽略的是：VS Code 启动方式影响环境变量。如果你用桌面图标打开 VS Code，它可能没加载用户级 shell 配置（比如 zshrc 里的 PATH），导致终端里 which composer 找不到，或用了旧版 Composer。务必先在系统终端确认 composer --version 输出是 2.2+，再进 VS Code 验证。
