frankenphp二进制15–35mb属正常范围，因其集成php运行时、caddy协议栈及应用代码；低于12mb可能缺失关键扩展，超45mb说明未优化；体积非越小越好，需兼顾启动速度与运行性能。
FrankenPHP 打包出的二进制体积在 15–35 MB 之间属于正常水平，具体取决于 PHP 版本、启用扩展、是否压缩、目标平台和应用代码量。低于 12 MB 往往意味着关键扩展（如 opcache、mbstring）被裁剪或未启用；超过 45 MB 则大概率没做基础优化。
为什么不是越小越好？
FrankenPHP 的二进制是「PHP 解释器 + Caddy + 应用代码」三合一产物，不是纯 Go 编译的轻量 CLI 工具。它必须内嵌完整 PHP 运行时（含 Zend VM、标准扩展、opcode 缓存支持），还要带 Caddy 的 TLS/HTTP/3 协议栈。所以 frankenphp 本身静态链接后就已占 8–12 MB（Linux musl 版），再加上 Laravel 或 Webman 的 public/、vendor/ 资源和打包逻辑，撑到 20+ MB 是常态。
常见影响因素包括：
-
opcache.enable=1且预编译了脚本 → 体积略增，但启动快、内存占用低，不建议为省几 MB 关掉 - 启用了
pdo_mysql、curl、openssl等扩展 → 每个增加0.5–2 MB，musl 静态链接比 glibc 更紧凑 - 项目里有大量未压缩的 CSS/JS/图片资源被一并打包 → 这部分可单独剥离到 CDN，别塞进二进制
- 没加
-ldflags="-s -w"或CGO_ENABLED=0→ 可能多出1–3 MB的调试符号或 libc 兼容层
UPX 压缩到底值不值得开？
UPX 对 FrankenPHP 二进制的压缩率通常在 30%–50%（例如从 28 MB 压到 14–19 MB），但必须满足三个硬性前提，否则运行时直接 panic：
- 构建前已设
CGO_ENABLED=0，否则 UPX 解包后无法加载动态符号 - 使用
-ldflags="-s -w"且确认file ./frankenphp-app输出含stripped - 明确指定
-buildmode=exe（禁用 PIE），否则 UPX 解压后 mmap stack 失败
注意：UPX --ultra-brute 不推荐用于生产——它会延长启动时间，且某些含 ASN.1 解析（如 TLS 握手深度定制）的场景可能触发 NotCompressibleException。
不同打包方式的体积对比参考
以下为 2026 年实测数据（Laravel 11 + MySQL 驱动 + public/assets 全打包，Linux x64）：
- 默认打包（无压缩、含调试信息）：
38.2 MB - 加
CGO_ENABLED=0 -ldflags="-s -w"：26.7 MB - 再加 UPX（
upx -9）：15.9 MB - 若用
scratch镜像 + 多阶段构建（仅保留frankenphp二进制 +Caddyfile+public/）：12.4 MB（不含 vendor，靠 Composer autoload 机制动态加载）
真正容易被忽略的是：体积数字本身不反映性能。一个 14 MB 的 UPX 压缩版如果每次请求都要解压 PHP opcode，反而比 26 MB 的原生版慢；而 opcache.preload 开启后，哪怕体积大一点，首字节响应时间（TTFB）也能压到 3 ms 以内。别只盯着文件大小看。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
