optimize-autoloader 对 alias 无效，因其仅优化 psr-4、psr-0 和 classmap 中的类加载，而 alias 是运行时通过 class_alias() 建立的符号映射，不对应物理文件，也不被 classmap 扫描。
别名类（Alias）本身不参与 Composer 自动加载优化，composer install --optimize-autoloader 对它完全无效——因为 alias 是运行时通过 class_alias() 注册的，不是由 autoloader 加载的类。
为什么 optimize-autoloader 对 alias 没用
Composer 的 --optimize-autoloader 只处理三类声明：PSR-4、PSR-0 和 classmap 中明确列出的类文件。alias 是 PHP 运行时行为，比如 class_alias('OriginalClass', 'AliasName')，它不对应任何物理文件路径，autoloader 根本不会“加载”它，只是建立一个符号映射。
- 你在
autoload.files里 require 了一个定义class_alias()的 PHP 文件？那这个文件会被加载，但 alias 本身不进 classmap - 你指望
autoload.classmap扫描出 alias？不可能——classmap 只解析class、interface、trait声明，不解析class_alias()调用 - 执行
composer dump-autoload --optimize后检查vendor/composer/autoload_classmap.php，里面绝不会出现 alias 类名
alias 类怎么才能被“优化”地使用
真正影响 alias 性能的，是它所指向的原始类能否被快速加载。所以优化重点不在 alias，而在它的目标类：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 确保原始类（如
OriginalClass）本身在 PSR-4 或 classmap 中被正确声明——这样new OriginalClass才能走优化路径 - 如果原始类靠
autoload.files加载（比如一个全局函数文件里定义了 class + alias），那--optimize-autoloader不加速它，但你可以把该文件加进apcu缓存（需启用"apcu-autoloader": true） - 避免在热路径中反复调用
class_alias()：它本身开销小，但重复注册会触发警告；应在autoload.files文件或框架启动阶段一次性完成 - Laravel 等框架的 alias（如
App\Facades\Cache）本质是 Facade，底层仍依赖真实类加载——优化这些 facade 对应的真实类（如Illuminate\Cache\CacheManager）才有效
alias 导致 Class not found 的常见坑
开了 --classmap-authoritative 后突然报错 Class 'AliasName' not found，不是 alias 失效，而是 autoloader 被强制“只信 classmap”：
- alias 名字没在 classmap 里 → autoloader 直接放弃，连
autoload.files都不查 - 解决方案：要么关掉
--classmap-authoritative，要么确保定义 alias 的那个.php文件被列为autoload.files条目（它仍会被加载，只是不进 classmap） - 验证方式：查看
vendor/composer/autoload_files.php是否包含该文件路径；若没有，说明它没被声明或被--no-dev过滤掉了
alias 是语法糖，不是加载单元。想让它快，先让它的本体快；想让它稳，就别把它和权威 classmap 绑死——这两点最容易被忽略。
