expose仅声明镜像预期监听端口，不绑定、不映射、不触发网络规则；实际访问必须依赖docker run -p或-p，且-p/-p需配合expose元数据才能生效。
不会。 Docker Desktop 中的 EXPOSE 指令和所有 Docker 环境一样，只是镜像元数据声明，不监听、不绑定、不映射、不触发任何网络规则——它连宿主机的 iptables 或 Windows 的防火墙策略都不会碰一下。
EXPOSE 在 Docker Desktop 里到底做了什么
它只把端口信息写进镜像配置（Config.ExposedPorts），可通过 docker inspect 镜像名 查看。Docker Desktop 的图形界面、CLI、甚至 Compose 都会读这个字段，但仅用于提示或辅助生成配置，不会因此打开任何端口。
常见误解场景：
- 你在 Docker Desktop 的 Dashboard 里看到镜像写了
EXPOSE 8080，就以为点“Run”后能直接访问http://localhost:8080→ 实际 404 或连接拒绝 - 用 Docker Desktop 自带的 “Quick Start” 启动一个 FrankenPHP 镜像，没加
-p，却期待 Caddy 的 HTTP 服务可用 → 它确实监听了0.0.0.0:80，但宿主机根本收不到包
为什么 Docker Desktop 里 -P 映射有时“看起来自动生效”
这是因为 docker run -P（大写 P）的行为：它会扫描镜像中所有 EXPOSE 声明的端口，并为每个端口随机分配一个宿主机高位端口（如 32768 → 80）。Docker Desktop 的 CLI 和 Dashboard 调用的正是这个逻辑。
但注意几个关键点：
-
EXPOSE 9001≠ 应用真在监听9001；FrankenPHP 默认监听9001（PHP-FPM）和80（Caddy），若你误写EXPOSE 9000，-P会映射9000，但请求全丢给黑洞 - Docker Desktop 的 GUI 启动容器时，默认不启用
-P；你必须手动勾选“Publish all exposed ports”或在命令行显式加-P - Windows 上若启用了 WSL2 后端，
-P分配的端口需通过localhost访问，但某些旧版 WSL2 存在 DNS 解析延迟，导致刚启动时 curl 失败（不是 EXPOSE 问题，是 WSL2 网络初始化时序）
Docker Desktop 中正确暴露端口的实操路径
别依赖 EXPOSE 做任何实际网络打通。真正起作用的是运行时参数或 Compose 配置：
- 命令行：
docker run -p 8080:80 frankenphp—— 把宿主机8080映射到容器80，无论 Dockerfile 有没有写EXPOSE 80都有效 - Docker Desktop Dashboard：点击镜像 → “Run” → 展开 “Optional settings” → 在 “Publish ports” 手动填
8080:80（不能只填左边或右边） - Docker Compose：
ports:下必须显式写- "8080:80"；EXPOSE在docker-compose.yml里完全被忽略，即使写了也不会触发映射 - 验证是否成功：用
docker port 容器名查看实际映射关系，而不是看docker inspect里的ExposedPorts
容易被忽略的 FrankenPHP 特殊情况
FrankenPHP 官方镜像 Dockerfile 里没写任何 EXPOSE。但它实际监听两个端口：
- Caddy HTTP 入口：
0.0.0.0:80（TCP） - PHP-FPM socket 接口：
0.0.0.0:9001（TCP，供反向代理调用）
这意味着：
- 如果你基于官方镜像自定义构建，又忘了加
EXPOSE 80，docker run -P就不会映射80，哪怕服务跑着也白搭 - 想让 PHP-FPM 被外部调用（比如本地 Nginx 反代），必须显式
-p 9001:9001，且确保宿主机防火墙放行该端口（macOS/Windows 默认拦截） - Docker Desktop 的资源限制（如内存设太低）可能导致 Caddy 启动失败，表现为端口看似映射成功但无响应——这时
docker logs比检查EXPOSE有用得多
