01
从路径和行列回到输入
语法错误保留物理行列并高亮；配置验证错误指出字段路径。先修复结构错误，再使用服务和资源关系视图。version 只是兼容字段，不会把引擎切换成旧版规范。
Docker / 容器
Docker Compose 检查
检查一份 Compose YAML，联动查看声明关系、端口映射与变量引用。
Docker Compose 检查
Compose YAML 输入
分析结果
YAML 仅在当前浏览器处理，不执行 Docker，不读取环境文件，不发送网络请求。
审阅选项
输入原文可见。显示输出后允许导出保留真实值的 YAML，其中可能包含密钥。
静态范围：Compose 规范 fee041b（2026-09-01）。不插值、不读取文件、不启用 profile、不执行容器。
最多 200,000 个 UTF-16 代码单元、100 个服务、500 条关系记录；视图每次显示 50 条。
输入或选项已改变，请重新分析后导出。
代码审查时，缩进正确并不代表服务可以一起启动。Docker Compose 检查把同一宿主端口的争用、未声明的命名卷和依赖循环放到具体路径旁，便于回到原文确认。输入不会被自动改写，格式化结果另行展示；通过检查说明所检范围内没有发现问题，不代表容器已经就绪。
为什么使用 Docker Compose 检查
沿着声明找到关联服务
Docker Compose 检查将服务依赖、卷挂载和宿主端口放进同一份报告。箭头从依赖方指向被依赖服务，长语法保留 condition 声明。图中也展示命名空间和链接关系，不需要在几个很长的服务块之间反复搜索，但箭头并不表示数据库已经健康。
把确定冲突与待确认情况分开
两个服务的容器端口不同，也可能争用同一个宿主端口。检查按 TCP、UDP 和宿主地址分别比较；范围分配、跨协议族通配地址及带 profile 的服务重叠只给出保守警告，避免把未确定的运行条件说成必然失败。
先定位错误，再判断能否导出
02
比较宿主映射而不是容器监听端口
两个容器都使用 80 端口本身没有问题。看宿主地址、published 端口和协议是否重叠；变量映射与自动分配会标记为未确定，不会替换成虚构的端口号。
03
确认显露范围再下载
原输入始终可见，完整输出默认隐藏。勾选显示配置值才开放 YAML 复制和下载，文件保留真实值。ENV 模板始终为空值；关闭自动分析可用主按钮或 Ctrl/Cmd + Enter，任何修改都会先禁用旧结果导出。
将语法、关系和引用一起审阅
固定规范的配置验证
Docker Compose 配置验证使用 2026-09-01 官方规范快照，并补充服务来源、资源引用、循环和端口语法检查。未知字段会报告，不会被悄悄删掉。YAML 格式化保留注释和锚点，不排序服务，也不覆盖编辑器里的内容。
可核对的依赖与挂载关系
支持 depends_on 的长短语法，以及服务命名空间、链接和卷继承关系。命名卷对照顶层声明检查；bind 挂载只展示路径，不打开主机文件。匿名卷与命名卷分开表示，未解析路径不会冒充已验证路径。
环境变量只收集引用名称
识别字符串值里的 $VAR、花括号表达式和嵌套替代值，遵守 $$ 转义。裸环境变量项及值为空的映射记为 shell 透传。普通环境变量声明不等同于外部引用；模板去重排序后输出 NAME=，不复制默认值或密码。
报告与配置分别导出
配置下载保留原有值和插值文本；JSON 报告不包含完整 YAML 或变量默认值，只保留诊断、路径和关系。每次展示 50 条，可逐批展开，导出包括限制范围内的完整结果。错误报告仍可下载，便于复核问题。
静态检查的实际边界
- 不执行容器或探测真实端口
- 不拉取镜像、不启动服务、不验证健康检查，也不查询其他程序占用了哪些端口。文件权限、网络可达性和运行版本兼容性需在自己的 Docker 环境确认。结构通过不能作为部署成功的证明。
- 单文档，不读取外部上下文
- 拒绝多文档、重复键、不支持的标签和循环别名。include、extends 会阻止配置导出；不合并覆盖文件，不读取 .env 或 env_file。需要跨文件结果时，先在本地解析项目，再粘贴得到的单份配置。
- 所有 profile 一起参与检查
- 不会模拟哪些服务在当前命令下启用。因此涉及 profile、范围分配或混合通配地址的端口冲突只提示可能重叠。动态分配及含变量的映射保持未解析状态，不据此推断实际运行占用。
- 隐藏不是脱敏处理
- 输入仍然显示原文。开启显示配置值后导出的文件可能包含凭证，只有没有错误时才允许导出 YAML。ENV 模板的值一律留空，诊断报告可以包含错误；下载报告不表示配置获得通过。
- 展开有界，规范固定
- 支持 YAML 1.2、锚点和合并键，最多 200,000 个 UTF-16 代码单元、100 个服务及 500 条关系记录。展开上限为 20,000 个节点、40 层深度。规范提交以 fee041b 开头，未来字段需要更新快照才能纳入。
- 只核对声明能说明的部分
- 重点检查 bind、命名卷和 tmpfs 挂载；其他规范允许的挂载类型提示人工确认，不检查主机路径存在性。服务依赖展示声明及循环，不计算真正的启动时间，也不能证明应用已准备好接受请求。
Docker Compose 检查常见问题
如何验证和排查 Compose 配置？
先查看 YAML 语法与规范字段诊断，再检查服务、卷和端口关系。修复后重新分析，确认结果已更新。最后还应在目标环境执行自己的配置检查和启动验证，本页无法读取部署机器的文件与运行状态。
启动时端口冲突怎么处理？
先确认冲突的是宿主 published 端口，而不是不同容器内部的 target。可在配置中调整宿主绑定，再重新分析。本页能发现同一文档的固定绑定冲突，但不会检查其他程序、其他项目或当前系统实际占用。
为什么 .env 里的变量没有被识别？
本页不读取 .env，只列出配置中的引用名称，不判断真实环境是否赋值。请在本地核对文件位置、命令参数和变量优先级。下载的模板只有空值，需要按目标环境填写，不能直接当作完整凭证文件。
为什么 depends_on 不等待服务就绪？
短语法描述服务启动依赖，并不等于应用已经可以处理请求。长语法可声明 service_healthy 等条件，但本页只显示条件文本，不运行 healthcheck，也不会通过依赖图推断数据库已经可连接。
环境变量和密钥应该怎样管理？
将真实密钥放在适合部署环境的安全配置来源中，并避免把凭证提交到仓库。本工具只生成引用名称清单，不能代替密钥管理系统。输出默认隐藏，显露后下载的 YAML 仍保留原值，发送前需自行审阅。
有需要更准确定位的 Compose 声明？