composer中文镜像不影响runtime，只加速元数据和zip包下载；它不修改php代码、不干预autoloader逻辑、不改变autoload.php生成方式，仅替换p2目录json和zip源地址，所有依赖解析、版本计算、自动加载规则均由composer自身完成。
Composer中文镜像不影响 runtime，只加速元数据和 ZIP 包下载
中文镜像对 composer install 或 composer update 过程中的 runtime（运行时）行为完全无影响——它不修改任何 PHP 代码、不干预 autoloader 加载逻辑、不改变 vendor/autoload.php 的生成方式。镜像只替换 Packagist 元数据（p2/ 目录下的 JSON）和 ZIP 包的 HTTP 源地址，其余所有依赖解析、版本约束计算、自动加载规则生成均由 Composer 自身完成。
为什么“安装慢”常被误认为是 runtime 问题
实际卡顿几乎都发生在「下载阶段」，而非 runtime 执行阶段。典型现象包括：
-
Loading composer repositories with package information卡住超过 1 分钟 —— 这是 Composer 在拉取packages.json，走的是镜像源，不是 runtime -
Installing dependencies from lock file后长时间不动 —— 多数是某个包 ZIP 下载慢或失败，仍属镜像层问题 -
Generating autoload files耗时几秒到几十秒 —— 这才是真正的 runtime 阶段，但它的耗时与镜像无关，取决于composer.json中的autoload规则复杂度和文件数量
哪些操作看似“runtime 相关”，实则受镜像配置牵连
以下场景容易混淆，需注意区分：
-
composer dump-autoload：纯本地操作，不联网，镜像完全不参与 -
composer require foo/bar：先联网查版本（走镜像），再下载 ZIP（走镜像），最后才执行本地 autoload 生成 —— 前两步快了，整体才显得“安装快” - CI 构建中
composer install --no-scripts仍卡住：说明卡在下载环节，不是脚本执行慢，应优先检查镜像是否生效、缓存是否清空 - 本地
vendor/autoload.php加载报错（如 Class not found）：和镜像无关，是 autoloader 规则写错、命名空间不匹配或未执行dump-autoload
真正影响 runtime 的配置项有哪些
这些和镜像无关，但常被一起调整，需单独关注：
-
optimize-autoloader：设为true会生成 classmap，提升生产环境加载速度，但增加install时间 -
classmap-authoritative：强制只从 classmap 加载，跳过 PSR-4/PSR-0 动态查找，需配合optimize-autoloader -
apcu扩展启用：Composer 2.2+ 支持 APCu 缓存 autoloader 查找结果，需 PHP 配置启用，非镜像功能
镜像配置再完美，如果 autoload 块里漏写了目录、用了错误的命名空间前缀，runtime 就照样找不到类——这是最常被忽略的边界。
