composer config -g repo.packagist 命令不生效是因为三要素缺一不可：键名必须为单数repo.packagist、第二参数必须显式写composer、URL必须以https://开头且末尾带/，任一缺失均静默回退官方源且不报错。
composer config -g repo.packagist 命令为什么总不生效
不是网络慢，是这条命令根本没写对，还静默失败——不报错、不提示、配置为空。它必须同时满足三个硬条件：
-
repo.packagist是唯一合法键名，写成repos.packagist（多一个 s）或Repo.Packagist（大小写混用）全无效 - 中间的
composer是type值，不是可选参数，漏掉就 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、报错或只返回 URL 字符串（新版行为），都说明没写进去。
宝塔/CI 环境里全局镜像为啥不起作用
全局配置默认写在 /root/.composer/config.json，但它只对 root 用户生效。而宝塔后台、计划任务、GitHub Actions 构建容器，往往用的是 www、runner 或其他非 root 用户，根本读不到这个文件。
- 先确认实际执行用户：在宝塔终端运行
whoami，或查日志里的 UID - 给对应用户单独配：比如是
www，就执行sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 脚本里别用
sudo composer config -g，否则写进的是root配置，而 runner 用户运行时完全无视
Composer 不做跨用户配置共享，这点容易被忽略。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
项目级配置怎么安全追加而不覆盖私有源
全局配置省事但不可靠，尤其在团队协作或 CI 场景下。项目级配置写进 composer.json 的 repositories 字段，能随代码一起提交，行为一致。
- 进入项目根目录，执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加-g） - 如果原
composer.json中"repositories": {}是空对象，命令会自动 merge 进去；如果是数组格式（"repositories": []），命令会报错，需先手动改为对象 - 千万别手写
"packagist.org": false——这会彻底关掉基础包校验，镜像一挂，composer install直接失败 - 改完后建议删掉
vendor和composer.lock，再跑一次composer install，避免旧 lock 文件里的 hash 与镜像元数据不匹配
换源后依然卡在 Resolving dependencies 怎么办
镜像只加速下载（Downloading...）和元数据加载（Loading composer repositories），但 Resolving dependencies 阶段完全不走网络，是 Composer 在本地穷举满足所有约束的版本组合。卡在这里，和镜像无关。
- 检查
composer.json里有没有宽泛约束，比如"php": "^7.4 || ^8.0"、"*"或"minimum-stability": "dev" -
require-dev里是否塞了太多未锁定版本的工具链，如"phpunit/phpunit": "^9" - 是否存在大量
dev-分支依赖，或composer.lock没提交、没固定 - 临时解法：删掉
vendor和composer.lock，再composer install；长期解法：收紧版本约束，禁用xdebug，设parallel-downloads=10
最常被跳过的一步是 composer clear-cache——缓存里还存着旧的 packages.json，Composer 会优先读缓存，哪怕配置已改，它仍试图从旧地址拉校验信息，结果卡在 DNS 或 TLS 握手。
