能，docker compose config 输出的是合并展开后的最终生效配置，包括端口是否解析为纯数字（如 "8080:80"），是验证端口映射是否正确的唯一可信方式。
docker compose config 能看到最终生效的端口吗
能，而且这是唯一可信的方式。Docker Compose 启动前会把 .env、docker-compose.yml、覆盖文件（如 docker-compose.override.yml）全部合并展开，docker compose config 输出的就是这个“运行时真实配置”。如果端口没展开成数字，比如还留着 ${HTTP_PORT}，说明变量根本没被读取或定义错位置。
常见错误包括：
-
.env文件没放在docker compose执行目录下（必须同级） - 变量名拼错，比如写成
HTTP_PORTT或大小写不一致（http_port≠HTTP_PORT） - 在
ports字段里用了未声明的变量，例如ports: - "${MISSING_VAR}:80"，Compass 会静默替换为空字符串，变成"":80，导致启动失败
执行后检查输出中 ports: 下的值是否为纯数字格式，例如 - "8080:80" —— 这才是最终会绑定的映射。
为什么 docker port 比 docker ps 更准
docker ps 只显示容器创建时声明的端口字段，而 docker port 读的是运行时实际建立的网络绑定关系。两者不一致，说明配置改了但没重建容器。
立即学习“PHP免费学习笔记（深入）”；
典型现象：
-
docker ps显示0.0.0.0:443->443/tcp，但你刚把ports改成了- "8443:443" -
docker port却只输出443/tcp -> 0.0.0.0:443，没有8443行 —— 证明新端口根本没生效
此时必须用 docker compose up -d 重建，restart 无效。
环境变量没进 Caddy 怎么验证
FrankenPHP 自身不读 HTTP_PORT 这类变量，它们是给 Caddy 用的。要确认变量是否真正注入到容器环境并被 Caddy 加载，分两步查：
- 进容器：
docker exec -it frankenphp sh -c 'printenv | grep HTTP_PORT'，应输出HTTP_PORT=8080 - 看 Caddy 日志：
docker logs frankenphp 2>&1 | grep "listening on"，若看到listening on :8080，说明 Caddyfile 正确引用了变量；若仍是:80，大概率是 Caddyfile 里没写import env或模板语法有误
Caddy 默认不自动加载环境变量，必须显式声明，比如在 Caddyfile 开头加 { env } 或用 http://${HTTP_HOST}:${HTTP_PORT} 这类插值语法（取决于 Caddy 版本）。
多个 Compose 文件合并时端口怎么优先级
Compose 按加载顺序合并：基础文件（docker-compose.yml）→ 覆盖文件（docker-compose.override.yml）→ 命令行传入的 -f 文件（后加载的覆盖先加载的）。端口字段是 list 类型，不是简单覆盖，而是追加合并。
这意味着：
- 如果基础文件写了
- "80:80"，覆盖文件写了- "8080:80"，最终会同时暴露两个端口 - 想“替换”而非“追加”，必须在同一个文件里统一管理，或用
docker compose config --no-interpolate查看原始结构，避免意外叠加 - 别依赖 override 文件“悄悄改端口”，它可能只是多加了一条映射，而不是替换
最稳妥的做法是所有端口只在一个地方声明，比如全收在 docker-compose.prod.yml 里，开发环境用单独的 docker-compose.dev.yml，不混用 override。
