composer config -g repo.packagist 命令总不生效是因为必须同时满足三个硬性条件：键名严格为单数 repo.packagist、type 值显式指定为 composer、url 为 https 且末尾带 /，缺一即静默失败；验证需输出完整 json 对象如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
composer config -g repo.packagist 命令为什么总不生效
根本不是网络或权限问题，而是三个硬性条件缺一不可，错一个就静默失败——不报错、不提示、配置也不写入。
-
repo.packagist是唯一合法键名：写成repos.packagist（多 s）、packagist.org或大小写混用（如Repo.Packagist）都会被完全忽略 - 中间的
composer是强制type值：不能省略，也不能替换成vcs、package或空字符串 - 镜像 URL 必须是 HTTPS 且以
/结尾：https://mirrors.aliyun.com/composer/✅，少斜杠会拼出/composerpackages.json导致 404
验证是否真写进去了？直接运行 composer config -g repo.packagist。输出必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果为空、null 或报 Key does not exist，说明没写对。
全局配置和项目级配置到底该用哪个
全局配置写进 ~/.composer/config.json，影响所有项目；项目级写进当前目录的 composer.json 的 repositories 字段，只作用于本项目。选哪个取决于你跑在哪、跟谁协作。
- 个人开发用全局最省事：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 团队协作或 CI/CD（GitHub Actions、Docker、宝塔）必须用项目级：避免成员本地配置不一致，也防止 Web 服务以
www用户运行时读不到你的$HOME - 项目级命令是去掉
-g：composer config repo.packagist composer https://mirrors.aliyun.com/composer/，但它会**完全覆盖**整个repositories字段——已有私有仓库配置会被清空
安全做法：手动编辑 composer.json，确保 repositories 是数组，首位放 {"packagist.org": false}，第二位才是镜像对象，并保留其他自定义源。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
换镜像后还是卡在 “Loading composer repositories” 怎么办
镜像只改下载路径，不解决缓存、旧锁文件或底层环境问题。卡住大概率不是源的问题，而是 Composer 还在读旧数据。
- 先执行
composer clear-cache - 删掉项目下的
vendor/和composer.lock - 再跑
composer install（不是update），让 Composer 重新解析并生成新锁文件 - 检查 PHP 环境：
proc_open和putenv不能被禁用；openssl和zlib扩展必须加载
验证实际走哪个源：运行 composer diagnose 看 “Repo” 行，或加 --no-cache 跑一次 composer update --no-cache，观察日志里是否出现 mirrors.aliyun.com。
换源后 composer install 报 hash 不匹配
这不是镜像故障，是旧 composer.lock 里记录的 dist URL 和哈希值来自官方源，切换镜像后路径映射不一致，校验必然失败。
- 必须删掉
vendor/和composer.lock - 不能只跑
composer update—— 它会复用旧 lock 文件里的元数据，继续往错误地址找包 - 要跑
composer install，让 Composer 从头拉取元数据、重新计算依赖图、生成新 lock 文件 - 如果项目已有
repositories数组，确认镜像对象排在首位，且{"packagist.org": false}与之并列，不是嵌套在内部
真正容易被忽略的是：哪怕 "repositories": {} 这种空对象，也会触发“禁用默认源”，全局镜像彻底失效——它不是 bug，是 Composer 的设计逻辑。
