确认当前生效源需用composer diagnose查Repo packagist.org行，而非仅信config输出；项目级repositories优先级最高，会屏蔽全局配置；验证须结合diagnose结果与curl -I镜像URL，缺一不可。
“Package not found”不是网络问题，而是 Composer 根本没去你期望的地方找——配置、缓存、拼写三者中只要一个错，它就静默跳过，直接报错。
怎么确认当前生效的源是不是你想要的
别信 composer config -g repo.packagist 的输出，它只显示“写了什么”，不等于“正在用什么”。真正起作用的是三层优先级：
- 项目
composer.json顶层repositories字段（最高，写了就屏蔽全局） - 全局配置
~/.composer/config.json中的repo.packagist（需含"type": "composer"和结尾/） - 默认
https://packagist.org/（兜底，但国内常超时伪装成 404）
验证方式：运行 composer diagnose，找到 Repo packagist.org: 这一行，后面 URL 必须是你设的镜像地址（如 https://mirrors.aliyun.com/composer/），且结尾有斜杠；如果是 https://packagist.org/，说明配置没生效或被项目 repositories 覆盖了。
为什么加了私有仓库，连 monolog/monolog 都装不上
只要 repositories 数组里有一条记录，Composer 就默认关闭 packagist.org 自动注入——结果是私有包没拉到，公共包也全挂了。
修复必须显式补上官方源，并关闭自动注入：
- 第一项必须是
{"packagist": false}，且必须是数组第一条 - 第二项起手动加
{"type": "composer", "url": "https://packagist.org"}（国内镜像换为https://mirrors.aliyun.com/composer） - 私有 Git 仓库单独加一条，如
{"type": "vcs", "url": "https://gitlab.internal.company.com/group/pkg"} - 改完立刻执行
composer clear-cache，否则旧缓存仍用“无 packagist”的配置
镜像同步延迟导致新包找不到怎么办
阿里云等镜像同步有 5–30 分钟延迟，新发布的包或 dev 分支不会立刻出现。不能只清缓存，得验证镜像是否已同步：
- 执行
curl -I https://mirrors.aliyun.com/composer/p2/vendor/name.json（把vendor/name换成实际包名） - 返回 HTTP 200 且
Last-Modified接近当前时间才算同步完成 - 返回 404？坐实是镜像延迟，临时切回官方源：
composer config -g repo.packagist composer https://packagist.org - 同步完成后，再删元数据缓存目录：
rm -rf ~/.composer/cache/repo/https---mirrors-aliyun-com-composer（路径按镜像 URL 转义）
包名拼错、大小写混入、全角字符这些隐形坑
Composer 不做模糊匹配，也不自动纠正。输错一个字符、斜杠方向反了、漏 vendor 名，或者命令行里混入全角空格，都会直接报 Could not find package，错误提示却未必指向拼写问题。
- 包名必须全小写，
vendor名、package名严格按 Packagist 上注册的来（如spatie/laravel-backup不能简写成spatie/backup） - 别从网页或聊天记录复制包名——里面可能藏不可见空格或全角字符，建议在纯文本编辑器重打一遍再粘贴
- 访问
https://packagist.org/packages/vendor/name确认包是否存在、是否有可用版本 - 若包只有
dev-main版本，确保minimum-stability没设成stable（否则直接过滤掉）
最麻烦的其实是 repositories 配错一个字段——Composer 会静默忽略整条配置，继续查默认源，而你完全看不到任何警告。所以每次改完，务必跑一次 composer diagnose 看 Repo packagist.org: 行，再 curl -I 验证目标 URL 是否可访问，缺一不可。
