Composer元数据缓存默认使用JSON文件而非SQLite，官方从未提供SQLite缓存开关或配置项；所谓SQLite改造实为误读或第三方非默认方案，实际收益有限且引入额外运维复杂度。
Composer元数据缓存默认用JSON，不是SQLite
Composer 2.2+ 默认把 repo/ 下的包元数据（如 packages.json 快照）存为 JSON 文件，不是 SQLite 数据库。所谓“SQLite 缓存改造”，其实是社区对官方行为的误读或第三方插件的非默认方案。官方至今未将 SQLite 作为元数据缓存后端，composer clear-cache 清的仍是 ~/.composer/cache/repo/ 下的 JSON 文件。
为什么有人想改用SQLite？
主要动机是解决高并发场景下文件锁争用、元数据解析慢、或想做自定义查询（比如查某包所有历史版本）。但现实是：
- Composer 自身不提供 SQLite 缓存开关，也没有
cache-driver=sqlite这类配置项 - 元数据缓存体积通常很小（几十 MB），JSON 文件读取在 SSD 上已足够快，SQLite 带来的收益极有限
- 一旦引入 SQLite，就要自己维护 schema、事务、vacuum、文件权限，反而增加故障面
- CI/CD 环境中，多个 job 并发写同一个 SQLite 文件极易触发
database is locked
真要上SQLite，只能绕过Composer原生机制
目前没有稳定、被广泛采纳的 Composer 插件能透明替换元数据存储为 SQLite。可行但需自行承担风险的路径只有两条：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 写自定义
RepositoryInterface实现，把findPackage()等方法重定向到本地 SQLite 查询——但这要求你完全理解 Composer 的依赖解析流程，且每次 Composer 升级都可能破坏兼容性 - 用
COMPOSER_CACHE_DIR指向一个挂载了 SQLite 文件系统的目录，并在外部用脚本定期把repo/*.json导入 SQLite 表——这纯属事后分析，不影响 Composer 运行时行为
别指望 composer config --global repo.packages 或修改 config.json 能启用 SQLite；那些字段只控制镜像源地址，不涉及缓存后端。
真正影响元数据加载速度的，是镜像源和TTL
如果你遇到 composer update 卡在 “Loading composer repositories” 阶段，问题大概率不在缓存格式，而在：
- 镜像源响应慢或返回 404（比如私有 Packagist 配置错误）
- 元数据缓存过期后，Composer 会强制重新 fetch 远程
packages.json，而该文件 TTL 默认 24 小时 - 网络 DNS 或 TLS 握手延迟，尤其在 CI 中使用 Alpine 镜像时常见
验证方式：运行 composer update -vvv，看日志里卡在哪一行；再手动 curl -I https://packagist.org/packages.json 测速。换国内镜像源（如阿里云、腾讯云）或调大 repositories.packagist.org.cache-ttl 值，比折腾 SQLite 实在得多。
