想让Composer search响应更快？配置本地缓存镜像！

Composer search 响应慢的根本原因是每次执行都强制远程拉取 packages.json 和 provider 索引，国内直连 packagist.org 的 TLS 握手与 DNS 解析耗时严重；必须正确配置全局镜像源（repo.packagist）、清空缓存并确保执行用户匹配，才能实现秒级响应。

先说个常见误区：不少人以为 composer search 慢是因为搜索算法效率低，其实问题出在每次执行都强制去远程拉最新的 packages.json 和 provider 索引。国内直连 packagist.org，光 TLS 握手和 DNS 解析就能卡掉好几秒，搜个关键词等 10 秒以上一点不稀奇。配镜像源只是基础，不配上本地缓存的镜像，search 永远快不起来。

为什么 composer search 特别慢？

它和 install、update 不一样——后面几个好歹有本地 lock 文件或 vendor 缓存可以复用，search 默认强制刷新元数据。流程是这样的：先 GET 请求 https://repo.packagist.org/packages.json，再逐个请求 provider-lara vel~10.0.json 这类分片索引，一次搜索就可能触发上百次 HTTP 请求。没有镜像的话，95% 的时间都耗在超时重试上。

• 即便开了 parallel-downloads，也只会加速 tarball 下载，对 search 毫无帮助
• --repository 参数在 Composer 2.2+ 已经明确限制，对 search 不生效
• 全局 repo.packagist 配置必须准确无误，否则请求会静默 fallback 到官方源，而且没有任何提示

composer config -g repo.packagist 必须写对三处

这是 search 能走镜像的唯一前提。错一处，就无声无息地回退到 packagist.org，你完全看不到报错。

• 键名必须是 repo.packagist（不是 repos.packagist、packagist 或 mirror）
• 中间的 composer 是 type 值，不能省；漏了就等于没配
• URL 必须是 HTTPS 且末尾带 /，例如 https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会 404）

验证方法：执行 composer config -g repo.packagist，输出必须是完整的 JSON 对象，类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果输出空值、null、报错，或者只返回 URL 字符串（新版有时会简化），都说明配置没生效。

换源后必须清缓存，否则旧元数据还在偷偷用

镜像配置写对了，但 ~/.composer/cache/repo/https---repo.packagist.org/ 里还躺着旧的 packages.json 和 provider 文件。这时候 search 会优先读这些过期内容，结果要么搜不到，要么漏包，甚至触发 fallback。

• 直接跑 composer clear-cache，清掉所有缓存目录
• 别手动删 ~/.composer/cache，容易搞乱权限；用命令最稳妥
• 第一次 composer search lara vel 还是会稍慢（因为要重建缓存），但之后再搜就快了——新缓存里存的是镜像源的元数据

CI/宝塔等环境要确认执行用户

composer config -g 写的是当前用户的 ~/.composer/config.json。但在宝塔面板、Jenkins 或 systemd 服务中，composer search 很可能以 www、jenkins 或 root 用户运行，而不是你 SSH 登录的那个用户。

• 在宝塔终端里先跑 whoami，看看实际执行用户是谁
• 用对应用户身份重新配置：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
• CI 脚本里最好不要依赖全局配置，改用临时方式：composer search lara vel -vvv --repository-url=https://mirrors.aliyun.com/composer/（注意要加 -vvv 才能看到真实请求的域名）

说到底，卡点从来不在搜索算法本身，而在于元数据是否从本地缓存镜像加载。只要缓存路径里存的是镜像源的 packages.json，search 就能秒出结果。其他所有优化都只是锦上添花，这一步才是刚需。