命令总不生效是因为三个硬性条件未满足：repo.packagist必须单数、中间参数composer是必填type值、URL须以https://开头且结尾带/，任一错误均静默回退官方源；验证需输出完整JSON对象{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
composer config -g repo.packagist 命令为什么总不生效
不是网络问题，是命令写错三个硬性条件导致静默 fallback 到官方源，且完全不报错。
-
repo.packagist必须是单数，写成repos.packagist（多一个 s）就失效 - 中间那个
composer是 type 值，不是可选参数——漏掉它，Composer 2.x 直接忽略整条配置 -
https://mirrors.aliyun.com/composer/必须带 HTTPS + 末尾斜杠，缺斜杠会拼出/composerpackages.json导致 404
验证方式只有一种：composer config -g repo.packagist。输出必须是完整 JSON 对象，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。返回空、null、报错或纯字符串，都说明没写进去。
项目级配置怎么避免覆盖私有仓库
手动编辑 composer.json 的 repositories 字段极易出错：引号漏写、方括号不闭合、误删已有源。正确做法是让 Composer 自动合并。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 进项目根目录，执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加-g） - 如果原
repositories是对象结构（如"repositories": {}），命令会转为标准数组并插入packagist条目 - 如果原
repositories已是数组（如"repositories": [ ... ]），命令会在末尾追加新项，不破坏私有源 - 千万别手动写
"packagist": false，这会导致基础扩展（如ext-json）校验失败
宝塔、Docker 或 CI 环境里全局配置为啥读不到
全局配置写在 ~/.config/composer/config.json，但只对当前用户生效。宝塔默认用 www 用户运行 PHP，CI 流水线常用 runner 或 www-data，它们根本读不到 root 或你个人用户的配置。
- 先确认实际执行用户：查日志 UID、跑
whoami，或看宝塔 PHP 管理器里“运行用户”字段 - 针对性配置：比如宝塔用
www用户，就执行sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - Docker 中若用非 root 用户启动容器，也要在 Dockerfile 或 entrypoint 里用对应用户执行配置命令
换源后还卡在 “Resolving dependencies” 怎么办
镜像只加速下载，不解决依赖解析慢的问题。这个阶段完全本地计算，和网络无关。
- 检查
composer.json里的 PHP 版本约束是否太宽，例如"php": "^7.4 || ^8.0"会让 Composer 尝试数百种组合 - 删掉所有
dev-main、dev-develop这类未锁定分支的 require，换成具体版本号 -
require-dev里塞太多工具（如phpunit、phpstan、friendsofphp/php-cs-fixer）也会显著拖慢解析速度 - 升级到
Composer 2.9.6+，它优化了依赖解析算法，对大型项目提升明显
真正容易被忽略的是：镜像源配置成功 ≠ 依赖安装一定快。元数据加载快了，但解析逻辑仍卡在本地 CPU 和内存上，尤其当 composer.json 写法不够收敛时，再快的镜像也救不了。
