Composer config -g repo.packagist 总不生效是因为四个硬性条件缺一不可：键名必须为单数repo.packagist、第二个参数必须显式写composer、URL须HTTPS且末尾带/、命令必须加-g；任一不满足即静默回退官方源，验证需输出完整JSON对象。
composer config -g repo.packagist 为什么总不生效
不是网络卡，也不是镜像地址错，而是四个硬性条件缺一不可：键名必须是 repo.packagist（单数，多一个 s 就静默失效），第二个参数必须显式写 composer（这是 type 值，不是可选），URL 必须以 https:// 开头且末尾带 /，命令还必须加 -g。任一不满足，Composer 就自动 fallback 到官方源，且不报错、不提示。
验证是否真写进去了，别信“命令没报错”——运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，比如：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果返回空、null、或只有一行 URL 字符串，说明根本没写成功。
项目级镜像配置比全局更可靠
CI/CD 流水线、宝塔面板、GitHub Actions 默认用的是 runner 用户或 www 用户，它们的 ~/.composer/config.json 往往为空，全局配置根本读不到。项目级配置直接写进 composer.json 的 repositories 字段，路径明确、作用域清晰。
进项目根目录后执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意去掉 -g）。它会自动在 composer.json 顶层追加 "repositories" 字段，key 固定为 "packagist"，不会覆盖已有私有源。
改完必须删掉 vendor/ 和 composer.lock，再跑 composer install（不是 update），否则旧 lock 文件仍指向海外源，镜像形同虚设。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
换源后还卡在 “Resolving dependencies” 怎么办
镜像只加速包下载，不解决依赖解析慢的问题。“Resolving dependencies” 是本地 CPU 在暴力穷举满足所有约束的版本组合，和镜像源完全无关。
常见提速手段包括：
- 删掉
"minimum-stability": "dev"—— 稳定版能直接砍掉 80% 的求解时间 - 收紧 PHP 版本约束：
"php": "^8.1"比"php": ">=7.4"少查几百个包的兼容性元数据 - 确保
composer.lock已提交进 Git，并在部署中始终用composer install - 临时禁用 xdebug：
php -d xdebug.mode=off $(which composer) install，它会让解析慢 5–10 倍
镜像源和自动加载机制有关系吗
没有直接关系。镜像源（如阿里云、腾讯云）只影响 composer install 或 update 时下载包的速度和稳定性，不影响 vendor/autoload.php 的注册逻辑、PSR-4 映射生成、或类文件查找流程。
但间接影响很大：
- 镜像配置错误或失效 →
composer install失败 →vendor/目录缺失或不全 →vendor/autoload.php不存在或损坏 - 私有包未正确配置镜像或认证 → 包没拉下来 → 对应的 PSR-4 映射不会写入
vendor/composer/autoload_psr4.php
真正决定类能否加载的，永远是 require 'vendor/autoload.php' 是否执行、composer dump-autoload 是否重生成映射、以及命名空间与路径是否严格匹配反斜杠和正斜杠 —— 这些环节，镜像源一个都插不上手。
