FrankenPHP v1.2.0静态二进制硬编码配置，不加载任何外部php.ini；扩展在构建时固化，解决冲突需重建二进制或使用Docker镜像动态安装。
macOS上FrankenPHP v1.2.0启动时无法跳过硬编码的php.ini，因为其静态二进制在编译时已将配置嵌入，运行时不读取、不加载、不覆盖任何外部php.ini文件——你试图“跳过”的那个文件，系统根本不会打开它。
确认当前php.ini是否真的被加载
执行./frankenphp php-cli -r "echo 'Loaded: ', php_ini_loaded_file() ?: 'none';"，输出一定是Loaded: none或空字符串。这不是bug，是embed SAPI的设计结果。
若看到路径输出，说明你运行的不是官方v1.2.0静态二进制，而是本地编译版或Docker内PHP CLI，需立即停止并验证二进制来源。
解决扩展冲突的唯一有效路径
FrankenPHP的扩展列表在构建阶段固化，运行时无法启用/禁用扩展。所谓“扩展冲突”，本质是两个扩展注册了同名函数（如mbstring和xml同时定义utf8_encode）、或共享内存段地址重叠（常见于opcache + xdebug组合）。
立即学习“PHP免费学习笔记（深入）”；
方法一：用frankenphp build重建无冲突二进制
第一步：准备一个干净的extensions.ini，只保留必需项：
extension=opcache.so<br>extension=pdo.so<br>extension=mbstring.so
第二步：执行构建命令，显式排除冲突扩展：frankenphp build --php-ini php.ini --extensions extensions.ini --output frankenphp-clean
【extensions.ini必须放在当前目录，且不能含xdebug、blackfire、pcov等调试类扩展】这些扩展与embed SAPI存在符号解析冲突，v1.2.0中会导致进程启动即崩溃。
方法二：改用Docker官方镜像绕过本地二进制限制
拉取dunglas/frankenphp:1.2.0镜像后，进入容器执行：install-php-extensions opcache pdo_mysql mbstring
该命令会从源码重新编译扩展并注入到运行时，自动处理符号冲突逻辑——这是目前唯一支持运行时动态裁剪扩展的合法路径。
验证扩展是否真正生效
对生成的frankenphp-clean二进制执行：./frankenphp-clean php-cli -m | grep -E "(mbstring|opcache|pdo)"
只应输出三行，且无xdebug、apcu、igbinary等非常规项。若有额外输出，说明extensions.ini未被正确读取，需检查文件权限及路径拼写。
运行./frankenphp-clean php-server前，务必删除项目根目录下所有*-dev.ini或docker-php-ext-类文件——它们会被frankenphp build误识别为扩展配置源，引发重复加载错误。
