composer config -g repo.packagist 失效主因是键名错（应为单数repo）、缺type值“composer”、url末尾无/，三者任一出错均静默回退官方源，且项目级repositories字段会完全屏蔽该配置。
composer config -g repo.packagist 命令总不生效？检查拼写和权限
最常见失效原因是键名写错：repo.packagist（正确） vs repos.packagist（多一个 s，Composer 2.x 会静默忽略）。执行后必须验证输出是否为完整镜像配置，而不是空或 https://packagist.org。
其他关键点：
- Composer 1.x 不支持该语法，需改用
composer config -g repos.packagist '{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}' - WSL 或 Docker 容器中，
~/.composer/目录可能不可写，检查权限并手动修复 - 宝塔等面板环境里，
root用户配了，但 PHP 进程实际以www用户运行，需额外给www用户也执行一次
为什么 composer install -vvv 还在请求 packagist.org？优先级和 fallback 规则
Composer 的源选择不是“全局覆盖”，而是有明确优先级：项目级 repositories > 临时 --repository > 全局 repo.packagist。只要项目根目录的 composer.json 含 "repositories" 字段（哪怕只是空数组），全局配置就完全失效。
排查要点：
- 运行
cat composer.json | grep repositories，确认是否意外存在该字段 - 若存在，检查其中是否显式禁用了 packagist：
"packagist": false；否则 Composer 会 fallback 回官方源 - 私有包、
path类型仓库、标记为abandoned的包，也会绕过镜像直接回源拉取元数据 - 镜像同步有 5–30 分钟延迟，新发布包（如
laravel/framework v11.0.0）可能尚未同步，可用composer show vendor/package -vvv观察真实请求域名
parallel-downloads 和 classmap-authoritative 怎么关才真提速
parallel-downloads 只对 composer install 有效，对 composer update 几乎无加速作用——因为依赖图求解（SAT）本身是串行的。而 classmap-authoritative 模式（Composer 2.x+ 默认开启）会导致每次 update 都强制重扫整个 vendor/ 目录，I/O 开销极大，和网络快慢无关。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
实操建议：
- 关闭权威类映射：
composer config authorative false（注意拼写是authorative，不是authoritative） - 删掉
composer.json中的"optimize-autoloader": true，改用composer dump-autoload --optimize手动触发 - 在
composer.json的"config"段加"parallel-downloads": 10，仅对install生效 - 禁用 Xdebug：
php -d xdebug.mode=off composer install，否则依赖解析慢 5–10 倍
换源后首次 install 报 hash 不匹配？别硬扛，重来更稳
镜像源切换后，旧 composer.lock 文件里的 dist.url 和 dist.shasum 仍指向官方源路径，校验必然失败。这不是配置错误，而是锁文件与镜像不一致的必然结果。
安全做法是清干净再重装：
- 删掉
vendor/和composer.lock - 执行
composer clear-cache - 运行
composer install --no-cache，强制从镜像站重新拉取并生成新 lock - 如果 CI 流水线卡住，可临时加
--repository=https://mirrors.aliyun.com/composer/确保当次命令走镜像
真正容易被忽略的是：镜像同步延迟 + 项目级 repositories 覆盖 + classmap-authoritative 引发的本地扫描开销，这三者叠加时，即使 URL 显示走的是 aliyun，实际耗时也几乎全花在本地而非下载上。
