是，vendor目录必须出现在执行composer install命令时的当前目录，即含composer.json的项目根目录；若在子目录（如public/）执行，vendor会错位导致autoload失败。
vendor目录是否真在项目根目录下
执行 composer install 后，vendor/ 必须出现在你运行命令时的当前目录——也就是含 composer.json 的那层。不是子目录（比如 src/ 或 public/），也不是家目录或 PHP 安装路径。
- 终端里先运行
pwd（macOS/Linux）或cd（Windows），确认当前路径就是项目根目录 - 检查
vendor/autoload.php是否存在且可读：它必须能被require，否则自动加载会失败 - 常见错误：在
public/里执行了composer install，结果vendor/被建在public/vendor/，导致require 'vendor/autoload.php'报错 - 如果
vendor/空或只有composer/子目录，可能是权限不足、磁盘满，或上一次安装被中断后残留了composer.lock或vendor/锁文件
composer.lock 文件是否被实际读取
composer install 的核心逻辑是照着 composer.lock 装包，而不是看 composer.json。如果 lock 文件不存在、损坏或版本不匹配，命令会退化为 update 行为（但不提示），导致版本漂移。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
ls -l composer.lock确认文件存在且非空（大小 > 0） - 对比
composer.lock中的content-hash和composer.json内容是否一致：不一致说明 json 被改过但没跑update，lock 已失效 - 若 lock 文件是空的或只有
{}，install实际会尝试解析composer.json并生成新 lock，这违背了“确定性安装”原则 - 部署环境务必禁用
--no-lock，这个参数会让install忽略 lock 文件，直接按 json 解析——只应在调试时临时使用
vendor/bin 下有没有预期的可执行文件
比“目录存在”更可靠的完成信号，是检查 vendor/bin/ 是否生成了你依赖的 CLI 工具，比如 phpunit、laravel、phinx 等。
- 运行
ls vendor/bin/（或dir vendor\bin\Windows），确认目标二进制文件在列表中 - 有些包（如
monolog/monolog）不提供 bin 文件，但像phpunit/phpunit、laravel/installer一定有；没看到就说明该包没真正装进去 - 注意 Windows 下可能生成的是
.bat文件（如phpunit.bat），而非 Unix 风格的可执行脚本 - 如果 bin 文件存在但执行报错 “command not found”，大概率是
vendor/bin/没加进 PATH，或当前 shell 没重载环境变量
autoload 是否能正常工作
最终验证不是看输出日志，而是让 PHP 真正加载一个类。哪怕 vendor 目录完整、bin 文件齐全，autoload 配置出错也会导致运行时报 Class not found。
- 写个最小测试文件：
test.php，内容仅一行：require 'vendor/autoload.php'; echo "OK\n"; - 执行
php test.php，应输出 OK；若报错，说明 autoload.php 本身加载失败（路径错）或内部 require 失败（权限/编码问题） - 再试一个具体类：
require 'vendor/autoload.php'; var_dump(class_exists('Monolog\Logger'));，返回true才算链路通 - 如果用 PSR-4 自动加载但类名与目录结构不匹配（比如命名空间
App\Controllers却把文件放在src/Controller/），autoload 会静默失败——得靠实际类加载来暴露
composer.lock 和 vendor/ 的一致性——前者可能被 git 忽略，后者可能被误删，而错误日志往往只报“类找不到”，不会告诉你根源在 autoload 或 lock 文件失效。 
