composer不使用mmap技术处理镜像源元数据，而是通过file_get_contents和json_decode在php堆内存中解析packages.json等文件，全程无mmap系统调用。
Composer 本身不使用 mmap 技术处理镜像源元数据，也不对 packages.json 或其他元数据文件做内存映射。所谓“Metadata 内存映射”是误解——Composer 的元数据加载完全基于 PHP 的标准 I/O（file_get_contents、json_decode），全程在堆内存中解析，无任何 mmap 调用。
Composer 解析 packages.json 时根本不会调用 mmap
Composer 启动后，对每个镜像源执行 GET /packages.json 请求，拿到响应体后直接交给 PHP 解析：
- HTTP 响应体写入临时内存缓冲区（非 mmap 映射）
- 调用
json_decode($content, true)构建 PHP 数组结构 - 所有包名、版本、dist.url 等信息存于 PHP 堆中，后续匹配逻辑全靠数组查找
- 没有打开文件描述符、没有
mmap()系统调用、不涉及页表或虚拟地址映射
为什么有人误以为 Composer 用了 mmap？
常见混淆点来自两方面：
- 把“内存中缓存元数据”等同于“内存映射文件”——前者是 PHP 变量，后者是 OS 层的虚拟内存机制，二者不在同一抽象层级
- 看到某些 CI/CD 工具或私有镜像服务（如 Satis、Private Packagist）内部用了 mmap 加速本地静态文件服务，误归因到 Composer 客户端
- 混淆了 Composer 的“本地缓存目录”（
~/.composer/cache/）和 mmap：该目录下只是普通 JSON 文件，Composer 读取时仍走file_get_contents
真要用 mmap 加速 Composer 元数据访问？别费劲
即使强行绕过 Composer、自己用 C 或 Rust 实现一个 mmap 加载 packages.json 的解析器，也毫无收益：
-
packages.json通常几 MB 到几十 MB，远小于典型 mmap 的收益阈值（百 MB+ 大文件随机读） - Composer 每次只顺序遍历一次元数据，mmap 的随机访问优势无处发挥
- PHP 不提供原生
mmap接口；用ext-posix+shmop或FFI实现反而引入额外开销和兼容性风险 - 实际瓶颈从来不是文件读取，而是网络请求延迟、JSON 解析、依赖图计算——这些都无法被 mmap 加速
真正影响 Composer 镜像体验的，永远是 HTTP 连接稳定性、DNS 解析速度、TLS 握手耗时，以及 repositories 数组的声明顺序——而不是某个不存在的“Metadata mmap 优化”。
