答案：Composer报“Package not found”主因是Packagist索引同步延迟（1–15分钟），非本地配置或网络问题；应先访问https://www.php.cn/link/5d2e892c81e5fafc51ab0973879563a0packages/vendor/package确认发布状态，再通过curl验证API响应，最后执行composer clear-cache与composer show强制重载元数据。
Composer install 或 require 报 Package not found 但包明明已发布
这是 Composer 的包索引没同步到 Packagist 的最新状态，不是你本地配置或网络问题。Packagist 默认有缓存（通常 1–15 分钟），新包或新版本发布后不会实时生效。
实操建议：
- 确认包已在 Packagist 上成功提交：访问
https://www.php.cn/link/5d2e892c81e5fafc51ab0973879563a0packages/{vendor}/{package}，看是否能打开且显示正确版本 - 如果页面 404，说明提交失败或未审核——检查 GitHub/GitLab 仓库是否公开、
composer.json是否合法、是否点击了 Packagist 页面上的 “Update” 按钮手动触发同步 - 如果页面存在但 Composer 仍找不到，大概率是本地缓存或 Packagist CDN 延迟；此时不用“刷新索引”，而应绕过缓存验证
强制让 Composer 重新拉取最新元数据
Composer 不提供“刷新索引”命令，但可通过清空缓存 + 强制更新元数据来逼近最新状态：
执行以下两步（顺序不能反）：
- 运行
composer clear-cache—— 清掉本地~/.composer/cache/下的 dist 和 metadata 缓存 - 再运行
composer update --dry-run或composer show {vendor}/{package}—— 这会触发 Composer 重新请求 Packagist API，拿到当前最新响应
注意：composer update 本身不保证拉新索引，它只基于本地已有 metadata 做依赖计算；真正触发元数据重载的是首次需要该包信息的操作（如 show、require、update --dry-run）。
为什么 composer require 有时“突然又能装了”
这不是魔法，是 Packagist 的最终一致性在起作用：
- 新包发布后，Packagist 需要时间抓取 Git tag、验证
composer.json、生成 JSON 元数据并推送到全球 CDN 节点 - 不同地区用户请求的 CDN 节点可能缓存不同步，导致有人能装、有人报错
- 如果你刚提交完就立刻 require，大概率撞上窗口期；等 5 分钟再试，成功率大幅上升
若等不及，可临时用 VCS 方式直连源码（仅开发阶段）：
composer require "vendor/package:dev-main" --repository='{"type":"vcs","url":"https://github.com/vendor/package"}'
检查 Packagist 同步状态的最快方式
别刷网页，直接查 API：
- 打开终端，运行：
curl -I https://www.php.cn/link/5d2e892c81e5fafc51ab0973879563a0p/vendor/package.json - 看返回的
HTTP/2 200和cache-control头；若返回 404，说明 Packagist 根本没收录 - 若返回 200，再用
curl https://www.php.cn/link/5d2e892c81e5fafc51ab0973879563a0p/vendor/package.json | jq '.packages."vendor/package"'看是否有你发布的版本号
Packagist 不支持手动“刷新”，也不开放索引重建接口；所谓“刷新”，本质是等待同步完成 + 清除本地干扰缓存。最常被忽略的是：你以为包发布了，其实 GitHub token 权限不足或 webhook 没配好，Packagist 根本没收到推送。
