vendor/autoload.php“存在却失效”是因为其内部命名空间哈希与vendor/composer/下生成文件（如autoload_psr4.php）不匹配，常见于手动修改、CI中复制、composer.lock与composer.json不同步或中文命名空间配置错误（双反斜杠、路径/namespace不一致），导致getLoader()返回空加载器。
vendor/autoload.php 为什么“存在却失效”
它存在，但类加载全挂——不是报 autoload.php not found，而是直接 Fatal error: Class 'XXX' not found。这是 vendor 注入失败最典型的静默现象。根本原因不是文件丢了，而是它的内容和 vendor/composer/ 下其他生成文件（尤其是 autoload_psr4.php）不匹配。
常见诱因包括：
- 手动改过
vendor/autoload.php，下次composer install被覆盖后，命名空间哈希（如ComposerAutoloaderInit8a7f）变了，但你硬编码的调用仍指向旧签名 - CI/CD 流程里用
cp复制了别人项目的vendor/autoload.php，哈希不一致导致getLoader()返回 null 或空加载器 -
composer.lock和composer.json不同步，autoload_psr4.php里压根没写入你的中文命名空间映射，但autoload.php还在试图加载它
中文命名空间加载失败，先查 autoload_psr4.php
别急着重装 vendor，直接打开 vendor/composer/autoload_psr4.php，搜索你的命名空间前缀（比如 "中文"）。如果没出现，问题不在加载阶段，而在配置或解析环节。
必须核对三处：
-
composer.json里"autoload": {"psr-4": {"中文\": "中文/"}}—— 注意双反斜杠转义和末尾反斜杠，"中文": "中文/"✅，"中文": "中文/"❌ - 文件系统中真实路径是
中文/支付/Alipay.php，且该目录名 UTF-8 编码正确（Git 提交时未被转成%E4%B8%AD%E6%96%87或大小写混用） - PHP 文件内
namespace 中文支付;和文件路径严格对应，不能是namespace zhongwenzhifu;
dump-autoload -v 不输出扫描日志？说明配置没生效
运行 composer dump-autoload -v 后，终端没出现类似 Scanning /path/to/中文/支付 for namespace 中文支付 的行，意味着 Composer 根本没读到你的 PSR-4 配置。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
可能卡点：
-
composer.json有 BOM 头或中文逗号（，），导致 JSON 解析失败，autoload字段被忽略 - 配置写在
autoload-dev里，但你在非 dev 环境下跑composer install（默认不加载 dev autoload） - 项目根目录下有
composer.lock，但它的packages段里没包含你刚加的包，dump-autoload只处理 lock 文件里已确认的包
CI/CD 中 vendor/autoload.php 被 cp 复制后报错
这是线上构建最隐蔽的坑：文件存在、语法合法、甚至能 require_once 成功，但所有类都找不到。因为 autoload.php 里的命名空间后缀（如 ComposerAutoloaderInit8a7f）和当前 vendor/composer/autoload_real.php 生成的类名不一致。
解决方式只有一条：禁止复制 vendor/autoload.php。它必须由当前环境下的 composer install 命令自动生成。CI 脚本里应确保：
- 先
rm -rf vendor，再composer install --no-cache --no-dev - 不保留任何
vendor/目录快照，尤其不能从缓存或 artifact 中提取autoload.php - 若用 Docker 构建，
COPY . .后必须触发完整安装，不能跳过composer install
哈希不匹配的问题不会报错，只会让 getLoader() 返回一个无法注册映射的空实例——这正是“Panic 异常”难定位的根源。
