composer本身不提供离线自动补全依赖功能，该能力实际由ide（如phpstorm、vs code插件）基于vendor目录实现；离线时composer install仍会强制联网校验，需设composer_disable_network=1并清理镜像配置，且vendor完整性与autoload优化决定补全实效性。
Composer 本身不提供“离线自动补全依赖”功能——它没有本地符号索引、不解析 PHP 类名、也不像 IDE 那样做静态分析。所谓“自动补全依赖”，实际是 IDE（如 PHPStorm、VS Code + PHP Intelephense）基于 vendor/ 目录里的已安装代码做的语义补全，不是 Composer 的能力。
为什么 composer install 在离线时仍会报错或卡住
即使 vendor/ 已存在、composer.lock 完整，composer install 默认仍会尝试访问 https://repo.packagist.org/packages.json 做元数据校验。这不是“可选检查”，而是强制行为。
-
COMPOSER_DISABLE_NETWORK=1是硬性前提，不设它，所有--no-xxx参数都无效 - 全局配置里残留
repo.packagist（比如用过阿里云镜像）会导致 fallback 请求，必须运行composer config --global repo.packagist false -
composer.lock中若有"source"类型条目（如 Git URL、"dev-master"），离线时无法校验，直接失败 - 项目
composer.json里写了"repositories": [{"type": "packagist", "url": false}]，在COMPOSER_DISABLE_NETWORK=1下也会退出，不是静默忽略
离线环境下让 IDE 正确补全的实操要点
补全是否可用，取决于 IDE 能否准确加载 vendor/ 中的类定义。这和 Composer 是否联网无关，但和 vendor/ 的完整性、autoload 生成方式强相关。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 源机打包前必须执行
composer install --no-dev --optimize-autoloader，确保vendor/autoload.php是扁平化、无 symlink、无冗余路径的版本 - 目标机解压后优先运行
composer dump-autoload -o，修复因路径差异导致的 PSR-4 映射失效 - 若项目含
ext-redis或ext-gd等扩展依赖，目标机必须已安装对应扩展，否则部分包的 autoloader 可能跳过注册 - IDE 需配置为使用项目级
vendor/，而非全局缓存；VS Code 中确认intelephense.environment.includePaths包含./vendor
哪些情况会导致补全“看起来正常但实际失效”
常见假象：IDE 显示类名、方法名可补全，但运行时报 Class not found 或 Call to undefined method。
-
vendor/是从不同 PHP 小版本（如 8.2.10 → 8.2.12）迁移来的，某些包的composer.json含"php": "^8.2.10"约束，install 时被跳过，但 IDE 仍索引了残留文件 - 用了
path仓库类型依赖，其代码不在vendor/内，而是在项目外某路径；离线迁移时漏掉该路径，补全存在但运行时找不到 -
composer.json中"autoload"和"autoload-dev"混用，且未在离线机执行composer dump-autoload --optimize，导致 dev 类未注册 - 某些包（如
phpunit/phpunit）带 bin 脚本，依赖php在$PATH中且路径与源机一致；路径不一致时，vendor/bin/phpunit符号链接失效，IDE 补全指向错误位置
真正决定补全质量的，从来不是 Composer 是否联网，而是 vendor/ 是否干净、autoload.php 是否准确、以及 IDE 是否读到了真实可用的类结构。离线场景下，任何“看起来能用”的补全，都得用 require 'vendor/autoload.php'; var_dump(class_exists('Some\Class')); 实测验证一次。
