独立二进制并非真正免依赖，仍需 libc、libssl、libbpf 等系统库；启动失败常因 dlopen 找不到库，可用 ldd（Linux）或 otool -L（macOS）检测缺失项；frankenphp -m 仅列扩展名，不保证可用，须用测试脚本验证初始化。
确认二进制是否能真正加载系统依赖
独立二进制不是“免依赖”，而是把 PHP 和 Caddy 打包进去了，但依然要链接 libc、libssl、libbpf 等系统级共享库。启动失败常卡在 dlopen 阶段，表现为静默退出或 Operation not permitted，实际是内核拒绝加载缺失的库。
用 ldd 检查最直接：
- 先确认路径：
which frankenphp→ldd $(which frankenphp) - 重点看标为
not found的行，比如libbpf.so.1 => not found就说明 CentOS 8/AlmaLinux 9 缺少libbpf包 - macOS 不支持
ldd，改用otool -L frankenphp - 若输出中某库只有名字、没有
=>后的路径，就代表系统找不到它——别等运行时才报错
验证 PHP 扩展是否真可用，而非仅“列在清单里”
frankenphp -m 只显示模块名，不保证能初始化成功。很多扩展（如 redis、grpc）会在首次调用时才触发 zend_extension 加载逻辑，而 FrankenPHP 的嵌入式生命周期会让这类延迟失败更隐蔽。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 写一个最小测试脚本
test-ext.php： - 用
frankenphp php-server --document-root . test-ext.php直接执行，避免 Web 层干扰 - 若返回
false，再查php --ini确认extension_dir是否指向 FrankenPHP 自带目录（如/usr/lib/php/8.2/franken），不是系统默认路径 - 自定义 C 扩展必须用
frankenphp-build重编译，直接复制.so文件会报undefined symbol: zend_object_std_init
检查 $_SERVER 关键字段是否符合框架预期
Laravel、Symfony 等框架靠 $_SERVER['HTTPS']、$_SERVER['HTTP_X_FORWARDED_PROTO'] 判断协议，靠 $_SERVER['SCRIPT_NAME'] 构建 URL。FrankenPHP 默认设 SCRIPT_NAME 为 /index.php，而 Nginx+PHP-FPM 常为空，不一致会导致跳转到 http:// 或生成错误重定向。
快速验证方法：
- 在项目根目录放
server-test.php： - 启动服务：
frankenphp php-server --document-root public - 访问
curl http://localhost:8000/server-test.php，比对输出与你线上环境是否一致 - 特别注意：Caddy 默认不设
HTTP_X_FORWARDED_PROTO，若你依赖它做 HTTPS 判断，需在 Caddyfile 中显式header X-Forwarded-Proto "https"
Worker 模式下状态是否真的隔离或复用
打包交付前若启用 --worker，必须确认框架单例、静态变量、连接池是否按预期工作。很多项目在 bootstrap/app.php 里初始化数据库连接或缓存客户端，worker 进程复用后可能跨请求污染。
简单压测验证：
- 写一个接口返回
app()->isBooted()和spl_object_id(app('log')) - 用
curl连续请求 5 次，观察isBooted是否始终为true，spl_object_id是否不变 - 若日志对象 ID 变了，说明容器被重建，worker 没生效；若变了但没清空缓存，说明单例未重置，有状态残留风险
- 不要只看日志“没报错”，要验证内存行为本身
ldd 输出、$_SERVER 字段值、worker 下的内存地址一致性——这三件事不亲手跑一遍，打包出去就是赌运气。 
