离线环境还原 vendor 目录必须在联网机器上用 composer install --no-dev --prefer-dist --optimize-autoloader 生成完整快照，仅靠 composer.lock 不足；拷贝后需执行 composer dump-autoload -o 并校验命令与扩展。
离线环境还原 vendor 目录的核心前提
必须提前在联网机器上生成完整、可复现的 vendor 快照，仅靠 composer.lock 文件本身不够——它不包含二进制依赖（如 phpunit/phpunit 的 PHAR、laravel/pint 的可执行文件）或某些通过 install 脚本动态生成的资源。
用 composer install --no-dev --prefer-dist --optimize-autoloader 打包才可靠
这是离线部署前唯一推荐的安装命令。不加这些参数，会导致：本地 composer.json 里没声明但被 autoload-dev 引入的类仍被加载；源码模式（--prefer-source）会拉 Git 仓库，无法离线复现；未启用 --optimize-autoloader 时，vendor/composer/autoload_classmap.php 缺失，某些框架（如 Laravel）启动直接报错。
-
--no-dev：排除开发依赖，减小体积，避免离线机器缺失 dev-only 扩展（如xdebug）导致安装失败 -
--prefer-dist：强制用 ZIP 包而非 Git 克隆，确保所有文件可打包迁移 -
--optimize-autoloader：生成扁平 classmap，绕过 PSR-4 动态查找，对无 OPcache 环境更稳定
离线替换时必须校验 vendor 完整性
直接拷贝 vendor 目录到目标机后，常见错误是 Class not found 或 Command "xxx" is not defined，原因通常是：vendor/bin 下的软链接失效（Linux/macOS）、Windows 上符号链接变成普通文件、或某些包的 post-install-cmd 脚本（如 symfony/flex）根本没运行。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 务必在目标机执行
composer dump-autoload -o，强制重建 autoloader（尤其 Windows 离线环境） - 检查
vendor/bin中关键命令是否可执行：php -d extension=phar.so vendor/bin/phpunit --version（注意部分 PHAR 需要phar扩展） - 若项目含
scripts（如post-autoload-dump），需手动补跑：composer run-script post-autoload-dump
长期维护离线环境的隐藏成本
每次升级依赖都得回联网机器重新 composer install → 打包 → 同步 → 校验，比在线 composer update 多出至少三倍操作量。更麻烦的是：某些包（如 spatie/laravel-ray）会在安装时调用外部 API 获取配置，或依赖 git 命令生成版本号——这类包在纯离线环境即使有完整 vendor 也会运行时报错，只能提前在联网机上运行一遍再打包整个运行时状态。
真正安全的离线交付，不是“复制 vendor”，而是把 composer install 过程固化为 CI 构建步骤，产出带全部依赖的 tar.gz + 校验脚本，否则总有一处 autoload、link、extension 或 runtime call 会漏掉。
