Composer config -g repo.packagist 命令不生效是因为键名必须为单数repo.packagist、type值必须显式写composer、URL须以https://开头且末尾带/，三者缺一即静默回退官方源，验证需输出完整JSON对象。
不配国内镜像，composer install 卡在 Loading composer repositories 或 Downloading 就是常态——不是你网络差，是根本没连上 packagist.org；配错则静默失效，命令执行完毫无提示，你以为好了其实还在直连海外。
composer config -g repo.packagist 命令为什么总不生效
它不报错，但也不写入配置：漏掉任意一个硬性条件，Composer 就自动 fallback 回 https://packagist.org，且完全不提醒。
-
repo.packagist不能写成repos.packagist（多一个s就被彻底忽略） - 中间必须显式传
composer作为 type 值：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/✅；漏掉composer就无效 ❌ - URL 必须以
https://开头，且末尾带/：https://mirrors.aliyun.com/composer/✅；https://mirrors.aliyun.com/composer❌（少斜杠会导致请求路径拼错，返回 404）
验证是否成功？只看这一行：composer config -g repo.packagist。输出必须是 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 或至少是完整 URL 字符串。空、null、Key not found 或仍显示 https://packagist.org，说明根本没写进去。
项目级配置比全局更可靠，尤其在 CI/宝塔/Docker 环境
全局配置写在当前用户的 ~/.composer/config.json，但宝塔用 www 用户、GitHub Actions 用 runner 用户、Docker 构建常以非 root 用户运行——它们根本读不到你本地配的镜像。
- 进项目根目录（有
composer.json的地方），运行：composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/（注意：不加-g） - 该命令会安全追加到
composer.json的repositories字段，不覆盖已有私有源 - 如果
composer.json里原先是"repositories": []（数组），命令会报错；得先手动改成"repositories": {}（对象）再执行 - 已有私有仓库？别手写 JSON——引号漏一个、逗号多一个就导致
composer install直接失败
改完后务必删掉 vendor/ 和 composer.lock，再跑 composer install。旧 lock 文件里的哈希是基于 packagist.org 元数据生成的，和镜像站不匹配，强行复用会报 hash 不一致错误。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
换源后仍卡在 “Resolving dependencies”？那和镜像无关
这个阶段完全不走网络，是 Composer 在本地穷举满足所有约束的版本组合。镜像再快也救不了它——90% 的“卡住”其实是求解器爆炸。
-
"minimum-stability": "dev"会让求解时间暴涨数倍；删掉它，优先用稳定版 -
"php": ">=7.4"比"php": "^8.1"多查几百个包的兼容性元数据，收紧 PHP 版本约束立竿见影 -
"monolog/monolog": "*"这类宽泛约束会触发深度回溯；改成"monolog/monolog": "^2.9.0"显式指定小版本 - Xdebug 在 CLI 下会让解析慢 5–10 倍；临时禁用：
php -d xdebug.mode=off $(which composer) install
真正有效的做法是：确保 composer.lock 已提交到 Git，并在 CI 和部署中始终用 composer install（不是 update）——锁文件存在时，依赖解析阶段几乎不耗时。
缓存路径放错位置会让 install 慢 2–5 倍
默认缓存路径 ~/.composer/cache 若落在机械硬盘、WSL2 挂载的 Windows 目录、加密卷或 NFS 上，解压 ZIP 包时 I/O 就成瓶颈。
- 查当前缓存路径：
composer config --global cache-dir - 强制迁移到 SSD：
composer config -g cache-dir /mnt/ssd/composer-cache - 临时测试新路径是否生效：
COMPOSER_CACHE_DIR=/tmp/composer-cache composer install --dry-run，再看/tmp/composer-cache下是否有新文件生成
缓存目录必须可写，且别挂到低速卷上——这点容易被忽略，但影响远超镜像切换本身。
