preload 必须在 config/octane.php 中显式启用并配置路径列表，它与 Composer 类映射优化互不感知；仅启用 dump-autoload 无效，需重启 Octane 生效，且 preload 文件应无状态、无外部依赖、不调用 env()。
preload 配置必须在 octane.php 里显式启用，否则不生效
Octane 默认不会自动预加载 Composer 类映射，即使你用了 composer dump-autoload --optimize 或 --apcu。关键点在于：preload 是 Octane 的独立机制，和 Composer 的 autoloader 优化互不感知。
实操上，得手动打开 config/octane.php 中的 preload 开关，并指定要提前加载的文件列表：
return [
'preload' => [
'app/Providers/*.php',
'app/Http/Controllers/*.php',
'app/Models/*.php',
],
];
常见错误是只改了 composer.json 的 autoload.classmap，却没配 preload —— 这样 worker 启动时仍会按需加载，冷启动延迟照旧。
-
preload路径支持 glob，但不支持递归（**无效），子目录得单独列 - 别把
vendor/autoload.php加进去，Octane 已内置处理，重复加载会报Cannot redeclare class - 修改后必须重启 Octane（
php artisan octane:restart），热重载不触发 preload 重建
worker 启动时类加载顺序：preload → Laravel boot → 请求处理
每个 Octane worker 生命周期分三阶段：初始化 preload 文件 → 执行 Laravel 服务提供者 boot() → 接收 HTTP 请求。preload 阶段加载的类，在整个 worker 生命周期内驻留内存，但它们的静态属性、单例实例并不会自动跨 worker 共享。
这意味着：
- 你在 preload 文件里执行
new MyClass()或赋值MyClass::$cache = []，只对当前 worker 生效，下次请求若落到别的 worker，缓存是空的 - 依赖
AppServiceProvider::boot()初始化的绑定（如$this->app->singleton(...)）仍要走 Laravel 容器流程，preload 不跳过它 - 如果某个类在 preload 里被 require，但它的 trait 或父类没被包含，运行时仍可能抛
Class not found—— preload 不自动解析依赖
避免 preload 引发内存泄漏或配置错乱
preload 是“一次性加载 + 长期驻留”，所以任何带状态的代码都容易出问题。最典型的是数据库连接、Redis 实例、全局变量、日志 handler。
比如这样写就危险：
// ❌ 错误示例：preload 中直接 new Redis()
use Predis\Client;
return new Client('tcp://127.0.0.1');
这个 Redis 实例会在 worker 整个生命周期持有连接，且无法被 Laravel 的连接池管理，超时、断连后不会自动重连。
- 所有外部连接、资源句柄（
fopen、curl_init）、闭包绑定都该放在boot()或请求生命周期内，而非 preload - 配置类（如
config/app.php）可以 preload，但别在里面调用env()—— 环境变量在 preload 阶段尚未被 Laravel 注入，会返回false或空字符串 - 测试是否真被预加载：在 preload 文件末尾加
file_put_contents('/tmp/preload.log', "loaded\n", FILE_APPEND);，看日志只写一次还是每次请求都写
composer dump-autoload 和 preload 的关系不是叠加而是分工
composer dump-autoload --optimize 生成的是 classmap，加快 PSR-4 查找速度；而 preload 是让 PHP 引擎在 worker 启动时就把这些文件 parse+compile 进内存。两者能共存，但目标不同：前者减查找开销，后者减加载+编译开销。
实际效果差异明显：
- 没 preload：首次请求需加载、parse、compile、执行类定义，耗时几十 ms
- 有 preload：首次请求只需执行逻辑，类定义已就绪，可省下 10–30ms（视项目规模）
- 但若 preload 列表过大（比如含全部
app/），worker 启动变慢，内存占用上升，反而影响扩容响应速度
真正该进 preload 的，是高频使用、无副作用、无环境依赖的核心类，比如 Eloquent 模型基类、常用 Service、Value Object —— 不是越多越好。
复杂点在于：preload 文件里的 require 或 include 会立即执行，而类定义语句只是注册，不触发构造函数。但一旦你写了 new、static:: 调用或 trait 中的静态初始化，行为就不可控了。这点很容易被忽略。
