离线环境下执行 composer dump-autoload 必须满足 vendor/ 存在且非空、composer.lock 与 composer.json 一致、无未提交 git 更改；正确命令为 composer dump-autoload --no-plugins --optimize。
离线环境下 composer dump-autoload 失败的典型表现
执行 composer dump-autoload 时卡住、报错 Could not fetch packages from repository，或提示 Package operations: 0 installs, 0 updates, 0 removals 却没生成新 vendor/autoload.php——说明 Composer 尝试联网校验依赖或重载配置，而你没断开网络却误以为“已离线”。真正的离线重建前提是：所有依赖包的代码已完整存在于 vendor/ 目录中，且 composer.lock 和 composer.json 未被修改。
确认离线状态后必须做的三件事
别急着敲命令，先检查这三项是否满足，否则任何操作都白搭：
-
vendor/目录存在且非空，所有包目录（如vendor/symfony/console）可正常访问 -
composer.lock文件存在且与composer.json版本一致（即没手动改过require或autoload段） - 当前目录下没有未提交的
git更改影响composer.json或autoload配置（比如新加了psr-4映射但没提交）
dump-autoload 的离线安全模式
默认 composer dump-autoload 会尝试读取 composer.lock 并验证包完整性，某些版本还会触发插件钩子导致联网。要彻底离线运行，必须加两个关键参数：
-
--no-plugins：禁用所有插件（如hirak/prestissimo或自定义 autoload 插件），避免它们偷偷发起 HTTP 请求 -
--optimize（可选但推荐）：生成优化后的autoload_classmap.php，跳过动态扫描，纯靠静态映射，既快又不依赖文件系统实时遍历
正确命令是：composer dump-autoload --no-plugins --optimize。如果项目用了 classmap 或 files 自动加载类型，这个命令能 100% 离线完成；若只用 psr-4 且路径没变，也完全没问题。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
autoload 配置变更后离线重建的限制
一旦你改过 composer.json 中的 "autoload" 或 "autoload-dev"，比如新增一个 psr-4 命名空间映射，dump-autoload 就必须重新扫描对应目录下的 PHP 文件——这时它不联网，但会依赖本地文件结构。容易踩的坑有：
- 目标目录（如
src/MyLib/）在离线机器上不存在或为空 → 报错Class not found或映射失效 - 目录权限不对（尤其 Windows + WSL 混合环境），
composer无法读取文件 → 静默跳过该映射，不报错也不警告 - 用了
exclude-from-classmap但对应文件在离线机上路径不同 → 排除规则失效，类被错误加载
这种情况下，别指望一条命令解决。得先同步好代码目录结构，再运行 composer dump-autoload --no-plugins（去掉 --optimize，因为 classmap 重建需要扫描）。
离线重建最脆弱的环节不是命令本身，而是对 vendor/ 和源码目录状态的误判——很多人以为“只要没改 composer.json 就能直接跑”，结果 vendor/ 是从另一台机器 rsync 过来的，少了 .git 或权限位，dump-autoload 就会漏掉某些文件扫描。
