containerPort是Kubernetes中仅用于Service targetPort引用的标签，不控制容器实际监听端口；FrankenPHP监听端口由启动参数（如--fpm-port）或SERVER_NAME决定，必须与containerPort值及name字段一致，且需配合Docker -p或K8s Service配置才能对外暴露。
containerPort 是 Kubernetes 的路由标签，不是端口映射
在 Kubernetes 里，containerPort 不控制任何网络绑定，它只是给 Service 做 targetPort 引用用的“名字标签”。FrankenPHP 容器内部监听 9001（FPM）或 80（HTTP），这个事实和 containerPort 写不写、写多少，完全无关——进程该听哪个端口，只由启动参数决定。
常见错误是以为写了 containerPort: 9000 就能让 PHP-FPM 听 9000，结果 FrankenPHP 还是默认听 9001，Service 流量发过去直接 connection refused。
-
containerPort必须和实际监听端口一致：默认 FPM 是9001，HTTP 是80；若用--fpm-port 9002启动，containerPort就得同步改成9002 - 必须带
name字段（如name: fpm），否则 Service 的targetPort: fpm无法匹配 - 不写
containerPort不报错，但 Service 只能靠数字引用targetPort: 9001，失去配置校验能力，容易漏改
宿主机端口由 Docker 或 Kubernetes Service 控制，和 containerPort 无直接关系
Docker 的 -p 8080:80 和 Kubernetes Service 的 port: 80 / targetPort: 80 才真正决定外部怎么访问。它们和 containerPort 是两层事：containerPort 是“容器内谁在听”，而 -p 或 Service 是“外面连哪、转到哪”。
比如你写 containerPort: 80，却只在 Service 里配 port: 8080 → targetPort: 80，那外部访问 :8080 才能打进来；如果 Service 配成 targetPort: http，那就必须确保 containerPort 里有 name: http 对应项。
立即学习“PHP免费学习笔记（深入）”；
- 混用
--network host和-p：Docker 会忽略-p，但容易误判端口是否生效 - 宿主机防火墙、云厂商安全组（如阿里云）必须放行 Service 暴露的端口（如
80、443），containerPort写得再对也没用 - host 模式下，FrankenPHP 必须显式监听
0.0.0.0:80，不能只写:80（默认是127.0.0.1:80），否则外部请求进不来
SERVER_NAME=:80 不等于开放宿主机 80 端口
SERVER_NAME=:80 是告诉 FrankenPHP 内置 Caddy：别搞 HTTPS、别按域名路由、纯 HTTP 监听 :80。但它不改变容器网络行为——容器内监听了 :80，不代表宿主机的 80 就自动通了。
如果你用 Docker，还得加 -p 80:80；如果用 Kubernetes，Deployment 要声明 containerPort: 80，Service 要配 port: 80 和 targetPort: 80（或 targetPort: http）。
-
SERVER_NAME=:8080+-p 8080:8080是调试常用组合，避免占80端口 -
SERVER_NAME=example.com会触发 Caddy 自动申请 HTTPS，此时必须同时放行443和80（ACME 验证走80） - 别写
SERVER_NAME=localhost:8080：Caddy 不识别带端口的主机名，会 fallback 到默认行为
worker 模式下端口行为没变，但监听逻辑更敏感
启用 worker 模式后，FrankenPHP 不再自动启动 HTTP 服务，而是等你调用 frankenphp_handle_request()。这意味着：即使你设了 SERVER_NAME=:80，若入口文件没循环调用该函数，容器内就根本没进程在听 :80。
这时候 containerPort: 80 还是得写，但 Service 流量进来后会直接失败——不是配置错，是压根没人接。
- worker 模式入口必须包裹循环，例如
while (frankenphp_handle_request($handler)) {} - 不要依赖
php_server命令：它不支持 worker，也不读Caddyfile，只适合快速验证单文件 - opcache.enable_cli=1 必须禁用，否则类重定义错误会导致 worker 启动失败，看起来像端口不通
containerPort、宿主机暴露端口、Caddy 的 SERVER_NAME，这四者表面都带“端口”俩字，实际各管一段。最容易出问题的是把 containerPort 当成 Docker 的 -p，或者以为 SERVER_NAME=:80 就等于“已经开了 80 端口”。真要通，每层都得对上。 
