根本原因是显式声明repositories会完全忽略packagist.org及所有镜像，Composer仅从所列源中查找包；若私有源或path仓库未正确配置（如name不匹配、路径错误、缺composer.json），则报“no matching package found”。
中文镜像本身不会导致包名或路径不匹配——问题出在你手动加的 repositories 配置和本地路径仓库（path repository）的写法上。
为什么换镜像后突然找不到包了
不是镜像“改了包名”，而是你在 composer.json 里写了自定义 repositories，比如：
"repositories": [
{"type": "vcs", "url": "https://github.com/yourname/monolog"},
{"type": "path", "url": "../my-utils"}
]
一旦这么写，Composer 就会忽略 packagist.org（包括所有镜像），只从你列的源里找包。如果 monolog/monolog 没出现在你的 GitHub 仓库里，或者 ../my-utils 目录下没有合法 composer.json，就会报 no matching package found。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查命令：
composer config --list | grep repositories，确认是否项目级配置覆盖了全局镜像 - 临时禁用自定义源：
composer config --unset repositories，再跑composer show monolog/monolog看是否恢复 - 若必须保留私有源，记得显式启用官方源：
"packagist.org": true或把packagist.org显式加进repositories数组
path 类型仓库 require 失败的硬性条件
90% 的失败是因为 name 字段和路径没对齐，Composer 不做任何容错：
-
name必须全小写、仅含短横线-，且与require中字符串逐字一致："acme/utils"≠"Acme/utils"≠"acme_utils" -
url必须指向**含composer.json的目录**，且是相对于主项目composer.json的路径，末尾不能带/（"../my-pkg/"会被静默忽略） - Windows 下还需：启用开发者模式 + 管理员权限终端 +
"symlinks": true写在该 path 仓库对象内，不能写在根config
镜像同步延迟 vs 真实路径错误怎么区分
两者现象相似（都报“找不到”），但排查路径完全不同：
- 如果是镜像延迟：访问
https://mirrors.aliyun.com/composer/p/vendor/package-name.json返回 404 或旧版本；而https://packagist.org/packages/vendor/package-name页面已存在——说明只是元数据没同步完 - 如果是路径错误：运行
composer show -a vendor/package-name完全无输出，且手动打开 Packagist 页面也是 404 → 包根本不存在或名字拼错了 - 关键验证命令：
composer show --tree，如果连包名都没出现在树里，基本可排除镜像问题，直接查repositories和本地路径
真正容易被忽略的是：repositories 一旦存在，就彻底接管包发现逻辑，镜像配置形同虚设。很多人以为“开了镜像就万事大吉”，结果在 composer.json 里随手粘了个 fork 地址，却忘了它会让整个依赖解析绕过所有镜像和 Packagist。
