musl与gnu libc本质区别在于运行时兼容性：musl轻量静态友好，适用于scratch/Alpine等无glibc环境；gnu功能全但依赖多，仅适配Debian/Ubuntu等glibc发行版。选错则二进制无法运行。
musl vs gnu：底层C库差异直接决定运行兼容性
FrankenPHP 的 static-builder-musl 和 static-builder-gnu 本质区别不在 PHP 版本或功能，而在链接的 C 标准库——musl libc 是轻量、静态友好的实现，gnu libc（glibc）是 GNU/Linux 发行版默认的、功能完整但体积大、依赖多的实现。选错会导致二进制无法运行或缺失扩展。
什么时候必须用 musl 镜像
当你目标是构建最小化、无依赖的生产镜像（尤其是基于 scratch 或 alpine），musl 是唯一可行选择：
-
scratch镜像里没有 glibc，用 gnu 构建的二进制会报no such file or directory（实际是找不到ld-musl-x86_64.so.1或类似动态链接器） - musl 编译出的二进制天然静态链接，不依赖宿主机的
/lib或/usr/lib，适合嵌入式、边缘或安全敏感环境 - Alpine Linux 默认用 musl，如果你的部署环境是 Alpine（比如
alpine:latest基础镜像），musl 构建能避免 ABI 不兼容问题
gnu 镜像只在这些场景有用
gnu 构建不是“错误”，而是为特定需求服务：
- 需要某些仅支持 glibc 的 PHP 扩展（如部分企业级数据库驱动、
ldap、snmp），musl 下可能编译失败或运行时缺符号 - 目标运行环境是 Debian/Ubuntu/CentOS 等 glibc 发行版，且你愿意接受更大的镜像体积和额外依赖
- 你在本地开发机（比如 Ubuntu）上调试 FrankenPHP 二进制，想省去交叉编译烦恼，直接用 gnu 构建+本地运行
- 使用 PIE（PHP Extension Installer）安装第三方扩展时，部分扩展的预编译包只提供 glibc 版本
build-static.sh 脚本里怎么选
关键看 EMBED 环境变量指向的路径是否与构建器匹配：
立即学习“PHP免费学习笔记（深入）”；
- 用
FROM dunglas/frankenphp:static-builder-musl→ 必须确保build-static.sh中没硬编码 glibc 路径，且所有docker-php-ext-install命令在 musl 环境下通过（例如opcache可以，pgsql可能需额外apk add postgresql-dev） - 用
FROM --platform=linux/amd64 dunglas/frankenphp:static-builder-gnu→ 要注意最终二进制仍需 glibc 运行时，不能扔进scratch；若要塞进debian:slim，得确认基础镜像已装libc6 - 检查生成的二进制是否真静态：
file frankenphp输出含statically linked才算 musl 成功；若写dynamically linked，说明某步漏了 musl 工具链或用了 host 的 gcc
