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 绑死——这两点最容易被忽略。