composer dump-autoload 离线失败是因为默认检查 composer.lock 是否过期需访问 packagist.org；正确命令是 composer dump-autoload --classmap-authoritative --no-dev --optimize-autoloader，全程不联网，生成纯本地可用的静态类映射。
composer dump-autoload 为什么在离线时会失败
因为默认执行 composer dump-autoload 时，Composer 会尝试检查 composer.lock 是否过期——这需要访问 packagist.org。即使你没改依赖，它也会发起 HTTP 请求，离线即报错：Could not fetch packages information, package information was not updated.
关键不是“生成映射”，而是“跳过网络校验”。只要告诉 Composer 别联网查版本，它就能纯本地干活。
- 加
--no-plugins不够，插件不是主因 - 必须加
--no-update（但注意：这不是指不更新依赖，而是禁用所有远程同步逻辑） - 真正起效的是
--classmap-authoritative+--no-dev组合，它们不触发网络，且直接产出最简、最快的类加载路径
离线生成权威类映射的正确命令
运行这条命令即可，全程不碰网络：
composer dump-autoload --classmap-authoritative --no-dev --optimize-autoloader
--classmap-authoritative 表示“类只可能在 classmap 里，找不到就别去 PSR-4/PSR-0 猜了”，这既提速又避免运行时扫描；--no-dev 排除开发依赖（通常含测试工具、PHPStan 等），减少 classmap 体积和扫描风险；--optimize-autoloader 把 PSR-4 映射也转成静态数组，和 classmap 一起固化。
- 如果项目用了
autoload.files，它仍会被包含，无需额外操作 - 生成的
vendor/composer/autoload_classmap.php是纯 PHP 数组，可直接部署到无网环境 - 别用
--apcu-autoloader：它依赖 APCu 扩展且需运行时注册，离线部署时扩展未必存在
为什么 vendor/autoload.php 在离线后仍能工作
因为 vendor/autoload.php 本身只是引导文件，它加载的是 vendor/composer/autoload_real.php，而后者根据 autoload_files.php、autoload_classmap.php 等静态文件构建加载器——这些全是本地 PHP 文件，不联网。
- 只要
vendor/目录完整（含composer/子目录），autoload 就不依赖网络 - 常见误操作：只复制
vendor/autoload.php，漏掉vendor/composer/下的映射文件 → 必然失败 - 验证方式：删掉
vendor/composer/autoload_psr4.php，保留autoload_classmap.php，再跑php -r "require 'vendor/autoload.php';"—— 若不报错，说明 classmap 模式已生效
CI/CD 或容器中离线构建的实操要点
在构建镜像或离线 CI 节点上，不能依赖 “先联网 install 再 dump”，得把 classmap 生成步骤压进构建流程里，且确保输入稳定。
- 先用有网机器执行
composer install --no-dev --optimize-autoloader，再立刻跑composer dump-autoload --classmap-authoritative --no-dev --optimize-autoloader - 把整个
vendor/打包带走，而不是只传composer.lock后在目标机 run install - 若用 Docker，
COPY vendor/ /app/vendor/必须在RUN composer ...之后，且禁止在 FROM 镜像里预装 vendor（不同 PHP 版本下 classmap 可能不兼容）
classmap 的生成结果和 PHP 版本强相关——同一份代码，在 PHP 8.1 和 8.2 下生成的 autoload_classmap.php 不能混用，这点很容易被忽略。
