frankenphp高并发下响应压缩必须由caddy层统一接管，禁用php层ob_gzhandler和zlib.output_compression；推荐在caddyfile中配置encode gzip {level 6 threshold 1024}并慎用streamedresponse。
FrankenPHP 高并发下开启响应压缩不能只加个 gzip on 就完事——它会显著放大线程阻塞、内存抖动和 CPU 争抢，尤其在 worker 模式下，压缩逻辑若没隔离到 Go 层或没限流，极易让整个线程池卡在 zlib 压缩上。
压缩必须由 Caddy 层统一接管，禁用 PHP 层的 ob_gzhandler
FrankenPHP 的 worker 模式下，PHP 进程常驻，ob_gzhandler 或 zlib.output_compression = On 会导致：多个请求复用同一 zlib 上下文、内存未及时释放、压缩缓冲区堆积。Caddy 自带的 encode 指令才是安全出口。
- 在 Caddyfile 的
php_server或路由块中显式启用：encode gzip zstd（推荐双编码，客户端自动协商） - 务必关闭 PHP 层所有压缩开关：
zlib.output_compression = Off、output_handler = ""、移除所有ob_start('ob_gzhandler') - 验证是否生效：curl -H "Accept-Encoding: gzip" -I http://127.0.0.1 | grep Content-Encoding，应看到
gzip，且响应头不含X-Powered-By: PHP类压缩标识
高并发时 gzip 压缩要设硬性限流，避免线程卡死
Caddy 默认对每个响应做全量 gzip，但 zlib 压缩是同步阻塞操作。当 num_threads = 8 且大量 50KB+ JSON 响应同时抵达，8 个线程可能全陷在 deflate() 调用里，frankenphp_queue_depth 立刻飙升，CPU 却不高。
- 加
encode子指令限流：encode gzip { level 6 threshold 1024 }，表示只压缩 ≥1KB 的响应，且压缩等级压到 6（默认 9），降低 CPU 占用 40%+ - 对已知大响应接口（如报表导出），用 Caddy 的
handle+header显式禁用：header -Content-Encoding+encode不匹配该路径 - 不要依赖
gzip_min_length这类 Nginx 风格参数——Caddy 的threshold是唯一有效控制点
worker 模式下必须检查 OPcache 与压缩的内存叠加效应
开启压缩后，PHP 响应体在进入 Caddy encode 流程前，仍需完整构造在内存里。若你同时开了 OPcache + 大量 include_once，单请求峰值内存可能比不压缩时高 20%～30%，极易触发 OOM。
- 实测单请求峰值内存必须包含压缩预备空间：用
memory_get_peak_usage(true)在public/index.php末尾打点，压测时对比开启/关闭encode的差值 - 如果差值 >1MB，说明压缩缓冲区开销过大，应降级为
encode zstd { level 1 }（zstd 压缩比接近 gzip，但 CPU 和内存开销低 60%） - 禁用
opcache.save_comments = 1和opcache.enable_file_override = 1，这两项在压缩场景下会额外增加字符串复制压力
最易被忽略的一点：Caddy 的 encode 不处理 chunked transfer encoding 的流式响应。如果你的 Laravel/Symfony 接口用了 yield 或 StreamedResponse，压缩会失效且可能截断数据——这种场景必须改用 application/json+stream 并在客户端自行解压，或者干脆关掉该路由的 encode。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
