客户接受度取决于交付场景和运维能力：单二进制适合无容器环境或快速验证，docker镜像适合已有k8s/ci/cd体系的客户；核心诉求是“开箱即用”，即一键运行、问题可追溯、升级便捷。
客户接受度不取决于“单文件”或“Docker镜像”本身，而取决于交付场景和运维能力。能直接运行的单二进制文件（frankenphp）更适合交付给无容器基础设施、无运维团队或需快速验证的客户；Docker镜像则更适合已有K8s/CI/CD体系、重视环境隔离与配置可追溯性的客户。
客户要的是“开箱即用”，不是“技术选型”
很多客户根本不在乎你用没用Docker，只关心三件事：能不能一键跑起来、出问题找谁、升级方不方便。FrankenPHP的frankenphp二进制本身就能监听端口、自动配HTTPS、服务静态资源、执行PHP——这意味着你可以打包成myapp-linux-amd64丢过去，对方双击（或./myapp）就起服务。
但前提是：客户机器装了glibc（或musl）、有权限绑定80/443、不介意进程常驻。我们遇到过政府单位客户连systemctl都不让用，但允许放一个可执行文件在指定目录下由他们自己的守护脚本拉起——这种场景下，单二进制比Docker更轻量、更可控。
- 单二进制交付典型路径：
curl -L https://example.com/myapp-v1.2.0→chmod +x myapp→./myapp --config caddyfile - Docker交付典型路径：
docker pull example.com/myapp:v1.2.0→docker run -p 80:80 -v ./config:/etc/caddy myapp
运维团队有Docker经验？那镜像才是标准件
如果你的客户是中大型企业、SaaS服务商或云原生团队，他们大概率已有镜像仓库、K8s集群、安全扫描流程。这时候交一个scratch基础的FrankenPHP镜像（比如FROM scratch + COPY frankenphp /usr/local/bin/），比交一个二进制更符合他们的交付规范。
原因很实际：
- 镜像层可扫描漏洞（Trivy、Clair），单二进制没法做SBOM生成和依赖溯源
- 他们能统一管理镜像生命周期（tag策略、GC策略、回滚机制）
- 多环境部署时，
docker run -e ENV=prod比改Caddyfile里的env块更易集成到现有发布平台 - 日志、健康检查、资源限制都走标准Docker接口，不用额外适配
注意：别用docker run --privileged或--cap-add=SYS_PTRACE交付生产镜像。FrankenPHP在worker模式下确实需要ptrace调试能力，但生产环境应改用--cap-add=SYS_PTRACE仅限构建阶段，运行时用FROM dunglas/frankenphp:1.2.0官方镜像更稳妥。
别忽略“交付物归属权”这个隐形门槛
有些客户合同明确要求“所有交付物必须可审计、可重建”。这时交一个frankenphp二进制，他们会立刻问：“这个二进制怎么编译出来的？Go版本？PHP补丁？Caddy插件列表？”——你得提供完整的build.sh、go.mod、patch清单，否则他们无法通过内部合规审查。
而Docker镜像天然带构建上下文：Dockerfile里写清楚FROM、COPY、RUN每一步，配合docker build --progress=plain日志，就是一份可复现的构建说明书。
我们吃过亏：某金融客户拒收单二进制，理由是“无法验证是否含后门”，最后我们把FrankenPHP源码+交叉编译脚本+SHA256校验值全部打包交付，才通过安全评审。
所以真正决定交付形式的，往往不是技术先进性，而是客户法务和安全部门的checklist。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
