5个免费的浏览器端开发工具：GraphQL格式化器、Docker Compose验证器、Dockerfile检查器，还有更多

最近我往 DevNestio 又塞了 5 个新工具——这玩意儿现在已经攒了 172 个免费、纯浏览器端运行的开发小工具了。所有工具都不用注册、不用上传任何东西到服务器，甚至离线也能用。听起来挺酷的对吧？下面我就一个一个拆开聊，顺便说说它们到底能帮你解决什么实际问题。

---

1. GraphQL 查询格式化器 & 压缩器

地址： https://devnestio.pages.dev/graphql-formatter/

如果你写过 GraphQL，肯定遇到过这种情况：从某个地方复制了一段查询，结果缩进乱七八糟，注释和空格混在一起，想粘贴到代码评审或者 API 文档里都没眼看。这个工具就是干这个的。

它能做什么？

• 美化输出（Pretty-print）：自动给你加上一致的缩进，让查询结构一目了然。
• 压缩（Minify）：去掉所有注释和多余空格，生成一个更小的请求体。这个对减少网络传输量挺有用，尤其是你在写移动端或低带宽场景下的 GraphQL 客户端时。
• 验证：检查花括号和圆括号是否成对匹配。别小看这个，GraphQL 的嵌套层级一深，少写一个花括号就能让你 debug 半天。
• 操作检测：自动列出所有命名的 query、mutation、subscription 和 fragment。比如你贴了一段复杂的查询，它会把每个操作的名字都提取出来，方便你快速了解这段代码里到底定义了什么。

实际场景

比如你在代码评审里看到一个同事写的 GraphQL 查询，乱七八糟的，你不想手动去整理。直接复制粘贴到这个工具里，点一下美化，然后复制回去，干净利落。或者你正在写 API 文档，需要展示一段规范的查询示例，这个工具也能帮你省时间。

原理简述

它本质上是一个纯前端的解析器，基于正则和状态机来识别 GraphQL 语法结构。因为 GraphQL 的语法是标准化的，所以不需要引入任何外部依赖，一个 HTML 文件就能搞定。这也是 DevNestio 所有工具的共同特点——vanilla JS，单文件，离线可用。

---

2. Protobuf (.proto) 格式化器 & 验证器

地址： https://devnestio.pages.dev/protobuf-formatter/

Protocol Buffers 是 gRPC 和很多微服务通信的核心。但 .proto 文件写起来容易，维护起来却有不少坑。这个工具就是帮你踩坑前先扫一遍雷。

它能做什么？

• 重复字段编号检测：Protocol Buffers 里每个字段必须有唯一的编号。如果你不小心把两个字段设成了同一个编号，序列化/反序列化就会出问题。这个工具会直接标红告诉你。
• 消息和枚举结构验证：检查你的 message 和 enum 定义是否符合语法规范，比如字段类型是否正确、枚举值是否重复等。
• 语法高亮输出：格式化后的代码带颜色，看着舒服。
• 一键复制：格式化完直接复制走，不用手动选中。

实际场景

你在改一个 gRPC 服务的 .proto 文件，加了一个新字段，改了一个枚举值。在提交之前，先贴到这个工具里跑一遍，确保没有重复编号、没有语法错误。这比等到 CI 跑挂了再回头改要快得多。

原理简述

Protocol Buffers 的语法比 GraphQL 复杂一些，有嵌套的消息、枚举、oneof、map 等等。这个工具用的是自定义的解析器，逐行扫描，根据缩进和关键字来构建语法树。它不依赖任何外部的 protobuf 库，所以完全在浏览器里跑，不会把你的文件内容传到任何服务器上。

---

3. Docker Compose 验证器

地址： https://devnestio.pages.dev/docker-compose-validator/

Docker Compose 文件写起来挺容易犯错的，尤其是当你用了复杂的网络配置、卷挂载或者依赖关系时。这个工具能帮你提前发现一堆问题。

它能检查什么？

• 缺少 services 部分：整个文件没有 services 字段？那跑不起来，直接报错。
• 服务没有 image 或 build：每个服务要么指定一个镜像，要么指定一个构建上下文。如果两个都没写，Docker 不知道从哪启动容器。
• 无效的端口映射：比如 "abc:xyz" 这种明显不对的，或者 80:80、127.0.0.1:8080:80、53:53/udp 这些格式是否正确。它甚至能检测端口范围映射（比如 8000-8010:8000-8010）是否合法。
• depends_on 引用不存在的服务：你写了一个 depends_on: - database，但整个文件里根本没有 database 这个服务？它会告诉你。
• 循环依赖检测：比如 A 依赖 B，B 依赖 C，C 又依赖 A。这种循环依赖 Docker Compose 启动时会卡死，工具能直接识别出来。
• 未知的重启策略：restart 字段只能取 no、always、on-failure、unless-stopped 这几个值，写个 restart: forever 就是错的。

示例代码

services:
  web:
    ports:
      - "abc:xyz"  # 这行会报错：无效端口映射
    depends_on:
      - missing_service  # 这行也会报错：不存在的服务

实际场景

你在一个微服务项目里改了 docker-compose.yml，加了一个新服务，改了几个端口映射。提交之前，把整个文件粘贴到这个工具里，一键验证。它会把所有错误列出来，你改完了再提交，省得 CI 跑一半报错。

原理简述

这个工具没有用任何外部的 YAML 解析库（比如 js-yaml），而是自己写了一个基于缩进的行解析器。为什么这么做？因为 YAML 的解析本身就很复杂，而且很多 YAML 解析器在遇到格式不规范的输入时，要么报错不够详细，要么直接崩溃。自定义解析器可以精确控制错误信息的输出，告诉用户具体是哪一行、哪个字段出了问题。当然，这也意味着它只处理 Docker Compose 常用的那部分 YAML 子集，但已经足够覆盖 99% 的实际场景了。

---

4. Dockerfile 分析器 & 检查器

地址： https://devnestio.pages.dev/dockerfile-analyzer/

Dockerfile 写得好不好，直接影响到镜像的安全性、大小和构建速度。这个工具会从三个维度给你打分和提建议。

检查类别

安全（Security）

• 在 RUN 里使用 sudo：在容器里用 sudo 通常意味着你在用 root 用户运行某些命令，但更好的做法是直接用 root 或者用 USER 切换到普通用户。sudo 在容器里是多余且不安全的。
• 容器以 root 运行（没有 USER 指令）：默认情况下 Docker 容器以 root 运行，这有安全风险。工具会建议你加上 USER 指令。
• 在 ENV 或 ARG 中硬编码密钥：如果你在 Dockerfile 里写了 ENV PASSWORD=123456 或者 ARG SECRET_KEY=xxx，工具会检测到并警告。这些值会被留在镜像层里，别人拉取镜像就能看到。

镜像大小（Image Size）

• 使用 :latest 标签：FROM node:latest 这种写法不推荐，因为 latest 标签会变化，导致构建不可重复。最好指定具体版本。
• apt-get update 和 apt-get install 分开写在不同的 RUN 里：如果 apt-get update 在一个单独的 RUN 里，而 apt-get install 在另一个 RUN 里，那么 apt-get update 产生的缓存可能会过期，导致安装失败或者安装到旧版本。正确做法是把它们链在一起：RUN apt-get update && apt-get install -y ...
• 没有使用 --no-install-recommends：apt-get install 默认会安装推荐的包，很多你并不需要。加上 --no-install-recommends 可以减小镜像体积。
• 没有清理 apt 缓存：apt-get install 之后应该执行 rm -rf /var/lib/apt/lists/* 来删除下载的包列表，否则这些文件会被留在镜像层里。
• 使用 ADD 而不是 COPY 来添加本地文件：ADD 比 COPY 功能更多（比如自动解压 tar 文件），但如果你只是复制本地文件，用 COPY 更清晰、更安全。工具会建议你改用 COPY。

层优化（Layer Optimization）

• 连续的 RUN 指令：如果多个 RUN 指令可以合并成一个（用 && 连接），工具会建议你这样做。因为每个 RUN 都会创建一个新层，层数太多会影响构建和推送性能。
• 总层数过高：虽然没有硬性限制，但层数太多通常意味着 Dockerfile 写得不够优化。工具会给出一个警告。

其他检查

• 缺少 WORKDIR：没有设置工作目录，所有命令都在根目录下执行，容易导致混乱。
• 多阶段构建（Multi-stage builds）：如果检测到多阶段构建，工具会给予正面评价。
• HEALTHCHECK：如果 Dockerfile 里有 HEALTHCHECK 指令，工具也会点个赞。

实际场景

你在优化一个生产环境的 Dockerfile，想看看有没有安全漏洞或者可以减小镜像体积的地方。把 Dockerfile 贴进去，它会列出所有违反最佳实践的地方，并给出具体建议。比如它会告诉你：“第 12 行的 RUN apt-get update 应该和后面的 RUN apt-get install 合并。” 或者 “第 5 行的 ENV 可能包含密钥，请考虑使用 Docker secrets 或环境变量注入。”

---

5. 邮件头分析器

地址： https://devnestio.pages.dev/email-header-analyzer/

这个工具是给安全团队或者运维同学用的。当你收到一封可疑邮件时，最快速的办法就是查看原始邮件头，看看有没有异常。但这个原始头信息又长又乱，人工看很费劲。这个工具帮你解析好，按类别展示。

它能做什么？

• 认证结果（Authentication Results）：直接告诉你 SPF、DKIM、DMARC 是 pass 还是 fail。如果任何一个 fail，这封邮件就很有可能是伪造的。
• 钓鱼信号（Phishing Signals）：
  • Reply-To 域名与 From 域名不一致：这是最常见的冒充手法。发件人显示是 support@bank.com，但回复地址却是 attacker@evil.com。工具会高亮这个差异。
  • Return-Path 域名不匹配：同样可能是伪造的迹象。
  • Spam Score / X-Spam-Flag 检测：如果邮件头里有垃圾邮件评分或标记，工具会提取出来。
• 路由追踪（Routing Trace）：解析所有 Received: 头，展示每跳的路径，包括发件服务器的 IP 地址。你可以看到邮件从哪台服务器发出，经过了哪些中继，最终到达你的邮箱。
• 三个标签页展示：
  • Summary：显示 From、To、Subject、Date、Message-ID，以及认证状态。
  • Routing：逐跳展示路由信息，每个 IP 地址都列出来。
  • All Headers：原始邮件头的完整转储，方便你查看所有字段。

实际场景

你的安全团队收到用户举报，说收到了一封冒充公司 IT 部门的邮件。你把原始邮件头复制出来，粘贴到这个工具里。三秒钟后，你看到 SPF 和 DKIM 都是 fail，Reply-To 域名和 From 域名不一致，而且路由信息显示邮件来自一个从未见过的 IP。基本可以断定是钓鱼邮件，直接封掉这个域名和 IP 就行。

原理简述

邮件头是纯文本，每一行是一个键值对，但有些字段（比如 Received:）可以出现多次，而且内容里可能包含换行（用空格或制表符续行）。这个工具用正则表达式逐行解析，把每个字段提取出来，再根据字段名分类展示。它完全在浏览器里运行，邮件头不会离开你的电脑。

---

实现细节

这 5 个工具都遵循相同的设计原则：

• Vanilla JS，单个 HTML 文件：没有用任何框架（React、Vue 都没有），也没有用打包工具（Webpack、Vite 都不用）。每个工具就是一个独立的 HTML 文件，里面包含了所有 CSS 和 JavaScript。这意味着你甚至可以把它下载到本地，离线打开也能用。
• 80+ 个 Node.js assert 测试：核心逻辑被提取出来，独立于浏览器环境进行测试。这保证了工具在浏览器里的行为是可靠的。
• 没有外部 YAML/解析库：Docker Compose 验证器用的是自定义的逐行缩进解析器。这听起来有点原始，但好处是完全可控，而且可以给出更精确的错误信息。

---

DevNestio 现在总共有 172 个工具了。如果你有什么想要的工具，在评论区留言，我看看能不能把它加到列表里。毕竟，自己写工具虽然爽，但能帮到别人更爽。