composer dump-autoload -o 仅生成类路径映射表以减少文件查找开销，并非预编译；真正的预编译需通过 opcache.preload 在 php 启动时加载并编译字节码。
Composer 本身不提供“预编译”功能，真正的预编译必须交由 PHP 的 Opcache 完成；composer dump-autoload -o 只是生成类路径映射表，减少文件查找开销，不是编译字节码。
为什么 dump-autoload --optimize 不等于预编译
很多人误以为 composer dump-autoload --optimize（或 -o）会把 PHP 类“编译”进内存，其实它只做一件事：把所有可自动加载的类路径汇总写入 vendor/composer/autoload_classmap.php。这省去了 PSR-4 命名空间拼接 + 文件 file_exists() 判断的 I/O 开销，但每个类首次加载时仍要解析、编译、执行——和没优化前一样走 PHP 解释器流程。
-
dump-autoload -o本质是“静态化路径查找”，不是字节码预编译 - 它对 CLI 脚本启动时间改善明显，但对 Web 请求的单次响应提速有限
- 若未配合
--classmap-authoritative，运行时仍会 fallback 到 PSR-4 扫描，失去优化意义
真正起效的预编译：用 opcache.preload 加载 classmap
Opcache 的 opcache.preload 配置项允许你在 PHP 启动时就 require_once 指定文件，PHP 会立即解析、编译并缓存其字节码到共享内存。这才是实打实的“预编译”。但注意：vendor/autoload.php 本身不能被 preload，因为它含动态逻辑（如 PHP_SAPI 判断、spl_autoload_register 注册），Opcache 会拒绝加载。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 正确做法是：先运行
composer dump-autoload -o -a生成权威 classmap - 再写一个独立的
preload.php，遍历autoload_classmap.php中的路径，对每个存在文件执行require_once - 在
php.ini中启用：opcache.preload=/path/to/preload.php，且确保opcache.enable=1 - preload 脚本中禁止使用
eval、function_exists、未定义函数等动态行为，否则 PHP 启动失败
--apcu-autoloader 是缓存查找结果，不是预编译
APCu 缓存的是“类名 → 文件路径”的映射查询结果，类似一个更快的 hash table。它不参与 PHP 字节码生成，也不减少解析耗时，只跳过 classmap 数组遍历。所以：
-
composer install --apcu-autoloader仅在 APCu 扩展已启用且apc.enabled=1时生效 - 它对 classmap 加载模式有效，对 PSR-4 模式无效（因为 PSR-4 是动态拼路径）
- 它和 Opcache preload 完全正交：可以同时开启，但解决的是不同层级的问题（查找 vs 编译）
- 别指望它替代
opcache.preload——缓存路径 ≠ 预编译代码
容易被忽略的关键点
很多团队配置了 opcache.preload 却没效果，根本原因是：preload 脚本里 require_once 的类文件，如果依赖尚未 preload 的其他类（比如 trait、interface 或父类），Opcache 会静默跳过该文件，不报错也不编译。这意味着你必须保证 preload 顺序，或干脆 preload 整个 classmap ——哪怕部分类暂时用不到。另外，composer.lock 更新后，必须重新运行 dump-autoload -o -a 并重启 PHP 进程，否则 preload 仍加载旧路径。
