换阿里云镜像源本身不能自动提速，90%的“配置了但还是慢”问题出在配置未真正生效、缓存未清理或本地环境干扰；最常见的是拼写错误（repos.packagist漏s）、缺type字段、URL末尾缺/、项目级repositories覆盖全局、未执行composer clear-cache，或实际运行用户与配置用户不一致。
换阿里云镜像源本身不能自动提速，90% 的“配置了但还是慢”问题出在配置未真正生效、缓存未清理、或本地环境干扰上；网络只是表象，根因多在本地。
为什么 composer config -g repo.packagist 显示阿里云地址却仍卡在 packagist.org
最常见的是拼写错误或结构缺失：Composer 要求全局镜像配置必须是 repos.packagist（复数），不是 repo.packagist（单数）；漏掉 s 就会被完全忽略。另外，只设 URL 不够，还必须显式指定 type 字段为 "composer"，否则 Composer 会 fallback 到官方源做校验。
- 验证命令必须是：
composer config -g repos.packagist，输出应为完整 JSON：{"type":"composer","url":"https://mirrors.aliyun.com/composer/"} - URL 末尾的
/不可省略，缺它会导致部分 Composer 2.2+ 版本请求packages.json时 404，静默回退 - 项目级
composer.json中若已有repositories字段，会直接覆盖全局配置；用composer config --list对比全局和项目配置是否冲突
composer install -vvv 日志里仍出现 packagist.org 或大量 connect timeout
说明 Composer 正在尝试连接旧源，不是镜像没配好，就是缓存还在用旧元数据。Composer 优先读缓存，哪怕你刚改了镜像，只要缓存里还存着从 packagist.org 拉下来的 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/才算真正生效
换了镜像、清了缓存，Resolving dependencies 还卡住几分钟
这不是网络问题，是 Composer 在本地暴力穷举版本组合。尤其当 composer.json 里写了宽泛约束（如 "*"、"dev-main"、"^1.0 || ^2.0"）或 PHP 版本声明太松（如 "php": ">=7.4"），求解器要查几百个包的兼容性元数据，CPU 占满也卡。
- 收紧约束：
"php": "^8.1"比"php": ">=7.4"少查 80% 以上候选包 - 删掉
"minimum-stability": "dev"，dev 版本极大增加求解空间 - 避免全量
update：用composer update monolog/monolog精确更新，而不是composer update - 检查是否启用了
xdebug：php -v输出含xdebug就禁用，否则解析慢 5–10 倍
并发下载没提速甚至报 file_put_contents(/tmp/): failed to open stream
高并发依赖 Composer 2.2+，但提速效果受 DNS/TLS 延迟、文件系统 I/O、防病毒软件拦截等制约；过高并发反而触发临时文件竞争，尤其在 WSL、Docker 或杀软开启的 Windows 上。
- 确认 Composer 版本：
composer --version，低于 2.2 不支持parallel-downloads - 别盲目设
--concurrency=16，先试--concurrency=4；多数场景 4–6 最稳 - 检查
sys_temp_dir是否可写且不被杀软扫描；WSL 下建议把cache-dir迁到 Linux 原生路径，避开 Windows 挂载卷 - 已知冲突插件如
hirak/prestissimo在 Composer 2.2+ 中不仅无效，还会干扰并发逻辑，应卸载
最容易被忽略的点：全局配置在宝塔、Jenkins、systemd 等环境下可能不生效——因为 composer config -g 写的是当前 shell 用户的 ~/.composer/config.json，而实际执行命令的可能是 www、jenkins 或 root 用户。CI 脚本里别信全局配置，直接用 --repository-url=https://mirrors.aliyun.com/composer/ 更可靠。
