FrankenPHP高并发部署时，glibc与musl影响启动成功率而非性能：官方二进制默认依赖glibc，在Alpine等musl环境直接运行会因找不到动态链接器而报“No such file or directory”，导致K8s反复CrashLoopBackOff；必须用file和readelf确认二进制实际链接的C库，且musl环境下所有PHP扩展也需统一musl编译，否则扩展加载失败或运行时崩溃。
FrankenPHP高并发部署时，glibc vs musl 影响的是启动成功率，不是性能参数
FrankenPHP 官方二进制默认依赖 glibc，在 Alpine、Buildroot、OpenWrt 等 musl 环境里直接运行会报 No such file or directory——这不是权限或路径问题，而是动态链接器根本找不到：/lib/ld-musl-x86_64.so.1 vs /lib64/ld-linux-x86-64.so.2。高并发场景下，容器启动失败一次，K8s 就可能触发反复 CrashLoopBackOff，比慢还致命。
常见误判是以为“只要镜像小就适合高并发”，但实际是：没跑起来，压根谈不上并发。
用 file 和 readelf 两步确认你的 FrankenPHP 二进制链了哪个 C 库
别靠镜像名或文档猜，直接查二进制本身：
-
file vendor/bin/frankenphp→ 看输出是否含dynamic linked -
readelf -d vendor/bin/frankenphp | grep 'program interpreter'→ 输出是/lib64/ld-linux-x86-64.so.2就是 glibc；/lib/ld-musl-x86_64.so.1才是 musl
注意：readelf 在 Alpine 上需先 apk add binutils；Debian/Ubuntu 默认自带。
立即学习“PHP免费学习笔记（深入）”；
Alpine 镜像体积小，但 PHP 扩展链断裂会让高并发直接退化为 500 错误
很多团队选 Alpine 是为了轻量，结果上线后发现 grpc、sqlsrv、rdkafka 这些扩展加载失败，错误里常带：
-
undefined reference to 'clock_gettime'（musl 缺失该符号） -
libgssapi_krb5.so.2: cannot open shared object file（Kerberos 依赖未打包） -
extension=xxx.so行在php.ini里被静默跳过，php -m不显示
这些不是配置问题，是 musl 下预编译扩展缺失或 ABI 不兼容。一旦请求走到依赖这些扩展的逻辑（比如数据库连接、gRPC 调用），就必然 500，且无法通过增加 Worker 数缓解。
真正容易被忽略的点：FrankenPHP 的“静态构建”不等于“C 库静态链接”
官方说的 “static binary” 指把 Go runtime、Caddy、PHP 引擎打包进一个文件，但 C 库仍默认动态链接。musl 支持必须显式启用构建流程（如用 dunglas/frankenphp:static-builder 镜像），且所有 PHP 扩展也得统一用 musl 工具链编译——否则主二进制能跑，extension= 一行照样崩。
尤其要注意 pdo_sqlite 这类看似基础的扩展，在 musl 下若用了 glibc 编译的 .so，加载时不会报错，但首次调用 PDO::query() 才 panic。
