答案是先验证包是否存在，再排查镜像失效、缓存残留、repositories配置错误或minimum-stability限制；composer search能搜到但require报404，说明packagist有该包，但本地元数据过期、稳定性策略过滤或项目级repositories覆盖了全局镜像。
不是网络问题，也不是镜像失效——90% 的 “Package not found” 是包名拼错、源配置被覆盖或元数据缓存过期导致的。
composer search 能搜到，但 require 就报 404
这说明 Packagist 索引里有这个包，但你本地 Composer 没拿到最新元数据，或者项目锁死了稳定性策略。
- 检查
composer.json是否含"minimum-stability": "stable"（默认值），它会过滤掉dev、beta或刚发布的RC版本；临时试：composer require vendor/name --stability=dev --no-update - 运行
composer show vendor/name，看是否已安装旧版且版本约束冲突；若已存在 v2.x，而你要装 v3.x，Composer 可能直接跳过而非升级 - 确认没在
repositories里误加了空对象或无效 URL，比如{"type": "composer", "url": ""}—— Composer 会静默忽略整个repositories数组，退回到默认源，但不报错
用了阿里云镜像，但新包或私有分支始终 404
镜像不会“创造”包，只同步官方源已有内容；新包发布后，国内镜像通常有 5–30 分钟延迟，冷门包甚至数小时未同步。
- 用
curl -I https://mirrors.aliyun.com/composer/p/vendor/name.json查响应头里的Last-Modified，如果比当前时间早 1 小时以上，说明还没同步 - 对比官方源：
curl -s https://packagist.org/packages.json | jq -r '.lastModified'和镜像源输出，差值过大就别等了 - 删元数据缓存目录（
composer clear-cache不管用）：rm -rf ~/.composer/cache/repo/https---mirrors.aliyun.com-composer（macOS/Linux）或%APPDATA%\Composer\cache\repo\https---mirrors.aliyun.com-composer（Windows） - 临时切回官方源验证：
composer config -g repo.packagist composer https://packagist.org/，再跑composer require
composer.json 里写了 repositories，结果全局镜像失效
只要 composer.json 含 "repositories" 字段，Composer 就完全忽略全局配置的镜像地址，哪怕你只加了一条私有 Git 地址。
- 执行
composer config --list | grep repositories，有输出即表示项目级源已启用 - 常见陷阱：Laravel China 镜像（
packagist.laravel-china.org）已于 2023 年底停服，但很多老项目仍保留着那段配置，导致所有包都 404 - 若需同时用私有源 + 公共镜像，必须显式把镜像也写进
repositories数组，且确保packagist.org条目排在最后，并设"packagist": false关闭默认源：
"repositories": [
{"type": "vcs", "url": "https://gitlab.internal/myorg/private-package"},
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"},
{"packagist.org": false}
]
require 加了 -w 却提示包不存在
-w（--with-dependencies）会让 Composer 强制重算整个依赖图，一旦某个已安装包锁定了无法兼容的子依赖版本，它就可能放弃安装并报 “not found”——实际是“无法满足约束”，但错误信息没说清。
- 去掉
-w重试：composer require vendor/name - 若必须带依赖更新，先用
composer update --dry-run看冲突点在哪，再针对性处理 - 旧版 Composer（如 1.x）对
-w处理更激进，建议升级到 Composer 2.5+，它会给出更明确的 why-not 提示
最常被忽略的是：删了 composer.lock 和 vendor/ 后重装，比修缓存更可靠；但前提是确认当前用户对项目根目录有完整写权限——否则 chown -R $USER:$USER . 得跟上。镜像、缓存、拼写，三者查完还找不到，大概率是包根本没发到 Packagist，或 tag 命名不合规（比如用了 v1.0_final 而非 v1.0.0）。
