微服务拆分部署
后端团队把单体应用拆成 5 个微服务，每个服务依赖 Redis、MySQL 和消息队列。手动写 docker-compose.yml 时，网络别名写错两次，导致服务间调用超时。用本工具可视化拖拽服务节点和依赖关系，自动生成正确的网络别名和卷挂载路径，部署一次通过，省去半小时排错。
项目设置project
快速模板一键添加服务
服务services
docker-compose.yml实时生成
第一节
关于本工具
About在 docker-compose.yml 里写 volumes 和 networks 时，缩进错一位或路径写错，容器启动就报错。这个工具把服务、网络、卷的依赖关系画成可视拓扑，输入 YAML 后高亮标出未定义的卷和网络引用。解析全在浏览器进行，YAML 内容不会离开本机。
使用场景
CI/CD 环境复现
QA 在测试环境发现一个 Bug，但开发本地跑不起来——因为测试环境用了 3 个自定义网络和 2 个命名卷。用本工具把测试环境的 docker-compose.yml 可视化后，发现卷路径写反了。直接导出修正后的配置，开发拉下来就能复现，不再需要手动比对 200 行 YAML。
新人接手遗留项目
实习生接手一个 4 年前的 Node.js 项目，docker-compose.yml 里定义了 8 个容器、4 个网络、6 个卷，但注释全无。用本工具导入 YAML 后，拓扑图清晰显示前端容器挂载了后端卷，后端容器却连不上数据库——原来网络名写错了。改完网络名，项目 10 分钟跑通。
多环境配置对比
生产环境用 3 个副本的 Nginx，开发环境只跑 1 个，但卷和网络配置一样。手动维护两份 docker-compose.yml 经常漏改。用本工具同时打开两个版本，可视化对比发现开发环境漏了日志卷挂载。统一配置后，用模板变量生成差异部分，避免上线后日志丢失。
本地开发环境搭建
前端同事需要本地跑后端全套依赖：PostgreSQL、Redis、Elasticsearch 和 3 个 Go 服务。手动写 docker-compose.yml 时，端口冲突两次，网络别名也写错。用本工具把服务节点拖拽排布，自动分配端口和网络别名，生成后直接 `docker-compose up`，5 分钟启动全部服务。
第二节
使用指南
Getting Started使用步骤
- 1在左侧编辑器中编写或粘贴 docker-compose.yml 内容，右侧画布同步渲染服务/网络/卷的拓扑图
- 2点击画布中的任意服务节点，高亮显示其依赖的卷和网络连线，便于排查配置错误
- 3拖动画布空白区域平移视图，滚动鼠标滚轮缩放，检查复杂拓扑的细节
- 4确认拓扑无误后，点击「导出」按钮下载生成的 docker-compose.yml 文件
输入输出示例
| 输入 | 输出 | 说明 |
|---|---|---|
| version: '3.8' services: web: image: nginx:alpine ports: - "80:80" db: image: postgres:13 environment: POSTGRES_PASSWORD: example networks: frontend: backend: volumes: pgdata: | 拓扑图显示：两个服务（web、db）通过 frontend 和 backend 网络连接；web 暴露端口 80；db 挂载卷 pgdata。 | 常规：典型多服务 + 网络 + 卷组合，验证工具能否正确解析 YAML 结构并生成可视化关系图。 |
| version: '3' services: app: image: myapp:latest depends_on: - redis redis: image: redis:alpine volumes: - redis-data:/data volumes: redis-data: | 拓扑图显示：app 依赖 redis（虚线箭头）；redis 挂载卷 redis-data；无显式网络定义时，默认使用 bridge 网络。 | 常规：depends_on 依赖关系 + 默认网络场景，验证工具是否处理隐式网络和依赖箭头。 |
| version: '3' services: single: image: alpine:latest command: sleep infinity | 拓扑图显示：单一服务节点 single，无网络连接、无端口映射、无卷挂载。 | 边界：最小化配置（仅一个服务无任何连接），验证工具对极简 YAML 的容错和渲染能力。 |
| version: '3' services: web: image: nginx ports: - "8080" networks: - net1 - net2 networks: net1: net2: | 拓扑图显示：web 连接两个网络 net1 和 net2；端口 8080 映射到随机主机端口（标注为 8080→?）。 | 边界：服务同时加入多个网络 + 端口仅指定容器端口（无主机端口），验证多网络连接和端口简写处理。 |
| version: '3' services: worker: image: busybox volumes: - /host/path:/container/path | 拓扑图显示：worker 服务挂载主机路径 /host/path 到容器路径 /container/path，无命名卷或网络定义。 | 边界：使用绝对路径绑定挂载而非命名卷，验证工具能否区分绑定挂载与命名卷并正确显示。 |
| version: '3' services: api: image: node:14 ports: - "3000:3000" environment: - NODE_ENV=production - DB_HOST=db depends_on: - db db: image: mysql:5.7 environment: MYSQL_ROOT_PASSWORD: rootpass volumes: - dbdata:/var/lib/mysql volumes: dbdata: | 拓扑图显示：api 依赖 db（虚线箭头），api 暴露端口 3000，db 挂载卷 dbdata；未定义网络时默认 bridge 网络连接两个服务。 | 易错：环境变量中包含引用其他服务名（DB_HOST=db），但工具不应将其解析为网络连接；验证工具不误将环境变量值当依赖关系。 |
| version: '3.8' services: front: image: nginx networks: - public back: image: flask networks: - internal networks: public: internal: | 拓扑图显示：front 在 public 网络，back 在 internal 网络，两个网络之间无连接，服务彼此隔离。 | 易错：两个服务分别在不同网络且无共享网络，验证工具能否正确展示网络隔离（无连线），而非错误连接。 |
常见错误对照
1.服务名包含下划线，导致容器名生成异常
✗ 错误
services:
my_app:
image: nginx✓ 修复
services:
myapp:
image: nginxDocker Compose 规范要求服务名只能包含字母、数字和连字符（-），下划线会导致容器名自动替换为连字符，造成命名不一致或引用错误。
2.卷挂载路径使用反斜杠，在 Linux 环境失效
✗ 错误
volumes:
- ./data:C:\app\data✓ 修复
volumes:
- ./data:/app/dataDocker 容器内路径统一使用正斜杠（/），反斜杠在 Linux 容器中被视为转义字符或非法字符，导致挂载失败。
3.端口映射遗漏协议，默认 TCP 导致 UDP 服务不可用
✗ 错误
ports:
- "53:53"✓ 修复
ports:
- "53:53/udp"端口映射默认协议为 TCP，若服务需要 UDP（如 DNS），必须显式指定 /udp，否则 UDP 流量无法进入容器。
4.depends_on 只控制启动顺序，不等待服务就绪
✗ 错误
depends_on:
- db
# 直接在 web 里连接 db，启动就报错✓ 修复
depends_on:
db:
condition: service_healthydepends_on 默认只保证容器启动顺序，不等待服务内部就绪。需配合 healthcheck 和 condition: service_healthy 实现真正依赖。
5.网络别名写错位置，导致服务间无法通过别名访问
✗ 错误
services:
web:
networks:
frontend:
aliases: app
# 别名写在 service 级别✓ 修复
services:
web:
networks:
frontend:
aliases:
- app
# 别名写在 networks 下的网络对象内网络别名必须定义在 networks 下的具体网络对象中，而非 service 顶层。错误位置会导致 DNS 解析不到别名。
6.环境变量值包含特殊字符未加引号，YAML 解析失败
✗ 错误
environment:
PASSWORD: Pa$$word!✓ 修复
environment:
PASSWORD: "Pa$$word!"YAML 中 $ 和 ! 等字符有特殊含义，不加引号会导致解析为变量替换或类型转换错误。
7.构建上下文路径错误，导致 Dockerfile 找不到依赖文件
✗ 错误
build:
context: ./backend
dockerfile: Dockerfile
# 实际 Dockerfile 在 ./backend/docker/prod/Dockerfile✓ 修复
build:
context: ./backend
dockerfile: docker/prod/Dockerfilecontext 指定构建上下文根目录，dockerfile 路径是相对于 context 的。若 Dockerfile 在子目录，必须写相对路径。
8.容器名重复，多个 compose 文件冲突
✗ 错误
services:
redis:
container_name: my-redis
# 另一个 compose 也定义同名容器✓ 修复
services:
redis:
# 不指定 container_name，由 compose 自动生成带项目前缀的容器名显式指定 container_name 会覆盖自动命名，多个 compose 项目若使用相同容器名会导致启动失败。建议仅单项目使用或加项目前缀。
第三节
工作原理
How It Works核心公式
服务依赖关系 = 服务A → 服务B (depends_on: 服务B 在 服务A 之前启动)
变量说明
服务A依赖其他服务的服务服务B被依赖的服务，需先启动
示例
web 服务依赖 db 服务：depends_on: db → 启动顺序为 db → web，确保数据库就绪后 web 才连接。
用户输入 / 错误反馈
解析与校验
映射与输出
第五节
常见问题
Q & A问我复制了一个别人的 docker-compose.yml 进去，它怎么只画了服务，网络和卷都没显示？＋
答
本工具只从你输入的 YAML 内容中提取已定义的网络和卷。如果原文件中没有显式声明 `networks:` 或 `volumes:` 顶层字段，或者服务没有通过 `networks:` 和 `volumes:` 挂载，那么可视化结果中自然就不会出现对应的节点。检查一下原始文件，确保网络和卷的声明和挂载写法完整。
问生成的图能导出成图片或者 PDF 吗？＋
答
工具当前是纯前端实现，可视化结果展示在页面内，不提供一键导出图片或 PDF 的功能。如果需要保存，可以直接使用浏览器自带的截图功能（如 Windows 的截图工具、Mac 的 Shift+Command+4），或者右键点击画布区域，看是否有浏览器右键菜单中的“另存为图片”选项（取决于你使用的图表库）。未来是否会加入导出功能，可以关注工具更新日志。
问为什么我写的环境变量 `ENV_VAR=value` 在可视化里没有单独显示出来？＋
答
本工具关注的是服务、网络、卷这三类基础设施的拓扑关系，属于架构层面的可视化。环境变量属于服务内部的配置细节，不在拓扑图的展示范围内。如果你需要检查环境变量，建议直接查看原始 YAML 文件，或者使用专门的 YAML 校验工具。
问我输入了很长一段 docker-compose.yml，加载后页面卡住了，是不是有文件大小限制？＋
答
工具没有显式设定文件大小上限，但因为是纯前端运行，所有解析和渲染都在浏览器内存中完成。如果文件非常大（例如超过几百行，或者包含大量重复的服务定义），浏览器的渲染性能会下降，导致卡顿甚至无响应。建议拆分大型项目为多个独立的 Compose 文件分别可视化，或者精简 YAML 内容后再粘贴。
问这个工具和直接在 IDE 里看 YAML 文件有什么区别？＋
答
IDE 只能展示代码结构，而本工具用图形化方式呈现服务之间的网络连接和卷挂载关系。对于多人协作的项目，或者需要向非开发人员（如运维、产品经理）解释架构时，一张拓扑图比满屏的 YAML 缩进直观得多。IDE 适合写代码时逐行检查，本工具适合快速理解整体架构和依赖关系。
问我把 YAML 粘贴进去，结果提示解析错误，但我的文件在本地 docker-compose up 是能正常运行的，为什么？＋
答
本工具的 YAML 解析器遵循的是标准 YAML 规范，而 docker-compose 在运行时对某些非标准写法（比如使用锚点、别名、合并标签，或者某些扩展字段）有更宽松的容忍度。常见问题包括：缩进使用了 Tab 而非空格、键值对冒号后缺少空格、或者使用了 Docker Compose 特有的 `x-` 扩展语法。建议用 YAML 校验工具（如 yamllint）先检查语法，再粘贴到本工具。
问这个工具会上传我的 YAML 内容到服务器吗？＋
答
不会。工具标注的实现方式为 FE（纯前端），所有 YAML 解析、拓扑计算和图形渲染都在你的浏览器本地完成，没有任何数据离开你的设备。可以放心粘贴包含敏感服务名、内部 IP 或端口信息的 Compose 文件。如果对隐私有更高要求，也可以断网使用。
问生成的图里，同一个网络被画了好几条线连到不同服务，线太多看不清，能调整布局吗？＋
答
当前版本使用自动布局算法，不支持手动拖拽调整节点位置或连线走向。如果连线过于密集，可以尝试在输入 YAML 时减少不必要的网络定义（例如将多个服务放在同一个默认网络中），这样可视化结果会更简洁。自动布局会尽量让节点分散，但复杂拓扑图难免会有交叉线。
隐私保证所有计算与处理均在你的浏览器本地完成，输入数据不会上传服务器，也不会保存或共享。