应优先选择Debian系基础镜像，因其glibc生态完善、PHP扩展开箱即用且FrankenPHP官方包原生适配；Alpine虽体积小但musl libc导致多数扩展兼容性差，仅适用于明确需轻量化的边缘场景。
Alpine版体积小但扩展兼容性差
Alpine镜像确实精简——优化后仅传统LAMP栈1/3大小，适合CI/CD或边缘部署。但它用的是musl libc，而绝大多数PHP扩展（尤其是含C模块的pdo_pgsql、redis、grpc）默认编译依赖glibc，直接apk add装不上或运行报Symbol not found错误。
常见踩坑点：
- 试图用
pecl install在Alpine上编译扩展，失败率高，需手动指定--with-libdir=lib等参数 -
php-zts扩展包在Alpine仓库里极不全，php-zts-opcache有，php-zts-amqp基本没有 - 某些调试工具（如
xdebug）官方预编译so只提供glibc版本，musl下必须源码重编
Debian版启动慢但扩展开箱即用
Debian（或Ubuntu）基础镜像虽大，但用glibc + apt管理PHP扩展非常稳定。FrankenPHP官方rpm/deb包都基于此生态，sudo apt install php-zts-redis就能装好ZTS线程安全版redis扩展，无需编译。
适用场景明确：
立即学习“PHP免费学习笔记（深入）”；
- 项目依赖
pgsql、amqp、protobuf等非轻量扩展 - 团队里有人要本地复现Docker环境，避免“在我机器上能跑”问题
- 用
frankenphp worker模式跑Laravel/Symfony，需要完整pcntl和posix支持（Alpine默认阉割部分posix函数）
别只看基础镜像，重点看FrankenPHP发行版是否匹配
FrankenPHP官方提供的二进制包本身已静态链接PHP 8.5，Linux版是glibc编译的。这意味着：即使你用Alpine容器，只要用的是官方frankenphp二进制（而非从源码编译），它仍会动态加载系统PHP扩展——而Alpine没这些扩展，就只能靠pie-zts这类第三方方案补漏，稳定性存疑。
更稳妥的做法：
- 选Debian系基础镜像（如
debian:bookworm-slim），再curl -sSL https://frankenphp.dev/install.sh | sh装官方二进制 - 若坚持Alpine，必须用
alpine:edge+apk add php85-zts（来自henderkes的static-php仓库），而不是默认Alpine PHP包 - 生产环境禁用
pecl install动态装扩展，所有扩展必须进镜像层，避免启动时IO阻塞
小公司/个人项目建议直接上Debian
现在FrankenPHP deb包已支持php-zts:static-8.5模块，sudo apt install frankenphp一行搞定，连PHP主二进制、ZTS运行时、常用扩展全打包好了。Alpine省下的那几十MB，在现代云主机带宽和磁盘成本下几乎无感，反而为排查undefined symbol类错误多花半天——这种权衡实际意义不大。
真正需要Alpine的场景极少：比如嵌入式网关、K3s边缘节点，且确认整个应用栈（含所有PHP扩展）都有musl兼容版本。其他情况，Debian就是更少意外的选择。
