刚启动就占很多内存属异常，主因是未启用worker模式、OPcache未加载或Symfony缓存路径错乱致重复加载；须确认Caddyfile含php_server { worker }、用frankenphp run启动、预热缓存并校准OPcache路径。
刚启动就占很多内存，基本不正常——除非你明确启用了 worker 模式且已预热缓存；否则大概率是配置没生效、OPcache 未加载或 Symfony 缓存路径错乱导致重复加载。
为什么刚启动就吃内存？常见错误现象
FrankenPHP 启动后 RSS 内存直接飙到 300MB+，但 memory_get_peak_usage(true) 在控制器里只报 8–12MB，说明内存不是 PHP 请求层吃掉的，而是进程初始化阶段就占了大头。典型表现包括：
- 日志里只有
Starting FrankenPHP server，没有Starting PHP worker pool with X workers - 连续发两个请求，
getmypid()返回不同值 → 根本没进 worker 模式 -
opcache_get_status()返回空或opcache.enable = 0→ OPcache 压根没启用 -
var/cache/prod下容器文件（如App_KernelProdContainer.xml）每次请求时间戳都变 → Symfony 缓存没复用
检查是否真进了 worker 模式
FrankenPHP 默认是“FPM 兼容模式”，每个请求新建 PHP 生命周期，和传统 FPM 完全一样——这种模式下刚启动就占高内存，说明框架被反复加载，属于配置失效而非行为异常。
- Caddyfile 中必须有
php_server { worker }块，不能只写php - 必须用
frankenphp run启动，frankenphp serve不支持 worker - 启动后看日志：出现
Starting PHP worker pool with 4 workers才算成功 - 在控制器里加
error_log('PID: ' . getmypid() . ', mem: ' . memory_get_peak_usage(true));，连发 3 次请求，PID 不变才可信
OPcache 和 Symfony 缓存路径必须对齐
worker 模式下，OPcache 和 Symfony 缓存都跨请求复用。如果路径不对或权限错，PHP 会不断重新编译类、Symfony 会反复重建容器，内存自然暴涨。
立即学习“PHP免费学习笔记（深入）”；
- 确认
zend_extension=opcache.so（Linux/macOS）或zend_extension=php_opcache.dll（Windows）已写入 FrankenPHP 实际加载的php.ini - 用
frankenphp info查Loaded Configuration File路径，别改错文件 -
opcache.validate_timestamps = 1必须设为 1（生产环境），否则改代码不生效；但要确保var/cache/prod目录可写、挂载方式不破坏 mtime - Symfony 启动前务必执行
bin/console cache:warmup --env=prod，否则首次请求强制编译，内存峰值翻倍
容易被忽略的隐性开销点
有些配置看似无关，实则会让 FrankenPHP 启动时多加载几十 MB 类文件或扩展：
- 开发组件没剔除：
symfony/debug-pack和symfony/profiler-pack在require-dev里，但若没从autoload-dev移除，worker 进程一启动就全加载 - PHP 扩展太多：
gd、imagick、soap等非必要扩展会增大常驻内存，1核2G 服务器建议只留opcache、pdo_mysql、mbstring -
opcache.memory_consumption设太高（如 512M）但项目文件少，OPcache 内部结构浪费大量内存，中型 Symfony 项目建议 128–256M - 没关
hot_reload = true（Caddyfile 或frankenphp.yaml），这个开发功能会在启动时监听整个src/目录，吃内存又无意义
真正健康的 FrankenPHP 启动内存应该在 80–150MB（含 Caddy 主进程 + 1 个 worker），后续请求只小幅增长。如果刚启动就逼近 300MB，优先查 php_server { worker } 是否生效、opcache 是否加载、var/cache/prod 是否预热——这三个点卡住一个，内存就稳超预期。
