根本原因是三个硬性条件缺一不可：键名必须为单数repo.packagist、type值必须显式写composer、URL必须HTTPS且末尾带/；任一缺失即静默回退官方源，返回空或null且无报错。
composer config -g repo.packagist 为什么总失效
根本原因不是网络或镜像地址错，而是三个硬性条件缺一不可：repo.packagist 键名不能多字母、type 值必须显式写 composer、url 末尾必须带 /。漏掉任意一个，Composer 2.x 就静默 fallback 到官方源，不报错也不提示。
验证是否生效，直接运行：composer config -g repo.packagist。输出必须是完整 JSON 对象，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果返回空、null、只有一串 URL 或报错，说明配置失败。
-
repos.packagist（多 s）、repositories.packagist（前缀错）→ 键名无效 -
"url": "https://mirrors.aliyun.com/composer"（缺/）→ 返回 404，Composer 自动退回到 packagist.org - Windows 用户注意配置路径在
C:\Users\用户名\AppData\Roaming\Composer\config.json，别手动编辑，用命令写入更安全
镜像同步延迟如何影响 ^ 和 ~ 的实际行为
镜像不改语义化版本规则，但会改变约束能“看到”的版本集合。比如你写了 "monolog/monolog": "^2.8.0"，本意是接受所有 2.8.x 和 2.9.x，但如果镜像还没同步 v2.9.0，Composer 就只能退回到 v2.8.4——不是它不想升，是它“看不见”。
这种延迟对 ~ 更友好：~2.8.0 只需镜像里有任意一个 2.8.x 就满足；而 ^2.8.0 在缺 2.9.0 时可能卡死在 2.8.0，哪怕你本地 composer.lock 里原本记的是 2.8.5。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 查镜像是否缺关键版本：
composer show -a vendor/package | head -10，对比 Packagist 官网 JSON 接口返回结果 - 金融类项目常用
~2.8.4+ 固定镜像，就是为规避“看似可升、实则不可达”的中间态 -
composer update --dry-run显示要升到 2.9.0，但composer install后仍是 2.8.4？八成是镜像没同步 2.9.0
装旧版依赖时，为什么 composer require vendor/package:1.2.3 是唯一可靠写法
Composer 解析版本字符串只认一种语法：冒号分隔、无空格、无前缀、不加引号（除非含破折号）。写错一个字符，就会把 1.2.3 当成分支名去查，结果报 Could not find a matching version。
常见错误写法：vendor/package@1.2.3（被当仓库地址）、vendor/package=1.2.3（非标准）、vendor/package : 1.2.3（冒号前后空格）、v1.2.3（解析为分支 dev-v1.2.3）。
- 执行后立刻检查
composer.json：对应行必须是"vendor/package": "1.2.3"，不能带^、~或多余引号 - 装完仍不是旧版？先跑
composer show -a vendor/package确认该版本是否存在；再打开 Packagist 页面看是否标abandoned或状态非stable - 已有包想降级，别用全量
composer update：先composer require vendor/package:1.2.3 --no-update，再composer update vendor/package
私有包 + 中文镜像共存时的配置陷阱
中文镜像（如阿里云）只是 packagist.org 的缓存，它不托管私有包。你配了镜像，再 composer require internal/auth-sdk，照样报 Could not find package——这不是镜像没生效，是镜像根本不管这事。
让私有包可用，必须三层齐备：源声明、认证、元数据控制。其中最容易被忽略的是 auth.json 权限和域名精确匹配。
-
auth.json权限必须是600，否则 Composer 静默忽略；Linux/macOS 下修复命令：chmod 600 auth.json - 私有源 URL 的 host 必须和
auth.json里的 key 完全一致：pkgs.example.com:8080≠pkgs.example.com，www.pkgs.example.com≠pkgs.example.com - 私有源声明必须是
"type": "composer"，且 URL 以/结尾；不能只靠--repository-url参数临时覆盖
composer.lock 里已锁定的 ZIP 或 commit。真正决定装什么的，永远是 composer.json 的约束 + composer.lock 的记录 + 当前镜像所见的可用版本三者交集。 
