composer config -g repo.packagist 没生效是因为键名必须为单数repo.packagist、type值必须显式写composer、url必须https且末尾带/，三者缺一即静默回退官方源，验证需输出完整json对象。
全新系统装完 Composer 后，composer install 还是慢得像卡在“Loading composer repositories”，不是镜像没配，而是配置根本没写进去——90% 的人第一次都漏了 repo.packagist 的单数形式、composer 类型值、末尾斜杠这三处硬性要求，命令静默失败，自己却完全不知道。
为什么 composer config -g repo.packagist 看似执行成功却没生效
这条命令不报错 ≠ 配置写进去了。Composer 2.0+ 对键名和结构校验极严，缺一不可：
-
repo.packagist必须是单数，写成repos.packagist或repositories.packagist会静默写入无效字段 - 中间的
composer是type值，不是注释或可选项，漏掉就直接 fallback 到packagist.org - URL 必须以
https://开头，且末尾必须带/：比如https://mirrors.aliyun.com/composer/✅，少斜杠就是404（请求路径变成/composerpackages.json） - 必须加
-g，否则只改当前目录下的composer.json，换项目即失效
验证是否真写进去了，别信终端输出，直接跑：composer config -g repo.packagist。正确结果必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、或提示 Key "repo.packagist" does not exist，说明全白配了。
Windows 下 PATH 和用户权限双重陷阱
全新 Windows 系统常卡在这两步，不是镜像问题，是环境没对齐：
- 安装 Composer 时没勾选
Add to PATH（新版默认不勾），导致composer --version找不到命令；手动把C:\ProgramData\ComposerSetup\bin加进系统环境变量后，必须新开 CMD/PowerShell 才生效 - 全局配置写在
%USERPROFILE%\AppData\Roaming\Composer\config.json，但宝塔、计划任务、Docker 容器里跑的composer很可能用的是www或runner用户，根本读不到你的配置 - 用管理员 CMD 执行
composer config -g，但日常开发是普通用户，配置写到了 root 的路径下，普通用户运行时完全不可见
最稳的做法：进项目根目录，运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉 -g）。它会自动向 composer.json 的 repositories 字段安全追加，Git 可提交，所有环境行为一致。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
群晖 NAS 上最容易被忽略的 PHP 路径绑定
在 DSM 里配 WebStation，PHP 版本（比如 PHP 8.2）实际路径是 /volume1/@appstore/PHP82/usr/bin/php，但终端默认走的是系统旧版 PHP（如 /usr/bin/php）。你用 composer config -g 配的镜像，只对调用它的那个 PHP 解释器生效。
- 先查 WebStation 绑定的 PHP Path：DSM → WebStation → PHP 设置 → 找到启用版本 → 记下完整路径
- 确认该 PHP 能调用 composer：
/volume1/@appstore/PHP82/usr/bin/php /usr/local/bin/composer --version - 用同一路径执行配置：
/volume1/@appstore/PHP82/usr/bin/php /usr/local/bin/composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 同步检查该 PHP 的
php.ini：确保phar.readonly = Off，否则 composer 缓存写入失败，配置也白搭
换源后仍卡住？不是镜像没生效，是 Composer 还在读旧缓存和 composer.lock 里记的老地址。必须清三样：composer clear-cache、删 vendor/、删 composer.lock，再跑 composer install -vvv 看日志第一行下载域名是否已变成 mirrors.aliyun.com。
项目级配置比全局更可靠，但要注意 repositories 结构
团队协作或 CI 场景下，全局配置几乎必然失效。项目级配置写进 composer.json，天然可 Git 跟踪、行为确定：
- 进项目根目录后执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/ - 如果
composer.json里已有"repositories": []（数组），该命令会报错；需先手动改成"repositories": {}（空对象）再重试 - 它只追加
"packagist"子项，不会覆盖已有的私有源（前提是原repositories是对象） - 千万别手写
"packagist.org": false—— 这会彻底关掉回退机制，镜像临时挂了整个install就失败
真正容易被忽略的点：项目级配置优先级高于全局。哪怕你刚配好全局镜像，只要 composer.json 里有 repositories 字段（哪怕为空），Composer 就会优先读它，而不会 fallback 到全局配置。所以验证时，一定要看 composer show -p 输出里的 repositories 实际指向哪。
