Scalar 与 Fern 深度对比：OpenAPI 文档与 SDK 生成的技术选型指南

本指南基于开源仓库 documentation/compare/fern.md 的系统性对比，围绕"同一份 OpenAPI 文档同时产出文档与 SDK"这一核心场景，逐项拆解 Scalar 与 Fern 在文档渲染、SDK 生成、许可证、自托管、定价与 Webhook 支持上的差异。读完你将能依据自己的技术栈、部署形态与预算约束，判断哪个方案更适合作为 API 产品的基础设施。本文由 Scalar 团队撰写，文中所有关于 Fern 的论断均源自 Fern 自身的公开文档、定价页面与公开仓库；若有出入，可在仓库提交 issue 修正。

选型前必须知道的一件事： Fern 于 2026 年 1 月被 Postman 收购。Fern 官方声明产品与品牌不会改变、团队仍独立运作。但如果你正在做长达数年的平台决策，值得追问其路线图与定价将如何与 Postman 协同——这直接关系到第三方独立产品的长期承诺。

一图概览：核心差异

维度	Scalar	Fern
文档渲染器	MIT 许可，任何方案下均可自托管	非公开；自托管仅限 Enterprise
SDK 生成器	闭源	Apache-2.0
同一份规范同时产出文档 + SDK	支持	支持
独立 API 客户端	有，开源	无
框架集成	35 个（仓库文档覆盖 40+ 框架）	无（仅 iframe 嵌入）
SDK 定价	含 1 个目标语言；额外目标 $150/月起，明码标价	"按 SDK、按年计费"，需联系销售

两者本质上都在做同一件事：把 OpenAPI 文档变成可交互的文档站点与强类型的客户端 SDK。它们确实是可对等的产品——如果你在评估其中一个，就应当评估另一个。

哪里 Fern 更强：协议广度

协议覆盖是 Fern 明确的领先点。 Fern 接受 OpenAPI、AsyncAPI、OpenRPC 以及 gRPC/Protobuf 作为 SDK 输入。如果你的 API 并非纯 REST——尤其是要发布 gRPC 或 JSON-RPC 接口时——Fern 能覆盖 Scalar 目前不支持的输入格式。

这是全文对 Fern 最坦诚的让步：在纯 OpenAPI 生态之外，Fern 的输入边界更宽。选型时应先确认自己的 API 形态是否超出 REST/OpenAPI 范畴。

SDK 输出：直接读生成的代码

比较两个生成器最清晰的方式是读它们产出的代码。下文 Fern 的输出来自其 petstore TypeScript SDK（公开生成的代码），Scalar 的输出来自 Warp TypeScript SDK（同样为公开生成产物）。

实例化客户端

// Fern
import { FernApiClient } from "@fern-api/example-typescript-sdk-petstore";

const client = new FernApiClient({
  environment: "YOUR_BASE_URL",
  token: "YOUR_TOKEN",
  clientId: "YOUR_CLIENT_ID",
  clientSecret: "YOUR_CLIENT_SECRET",
});

// Scalar
import WarpAPI from "warp-hr";

const client = new WarpAPI({
  apiKey: process.env["API_KEY"], // defaults to the API_KEY env var
});

两处值得注意的差异。其一，Scalar 以你的 API 命名客户端类并以默认导出暴露，import 读起来就像产品本身；其二，Scalar 默认从约定俗成的环境变量读取凭据，happy path 甚至无需显式传入任何密钥。

方法命名

把两个生成器放在同一份 Petstore 文档上对比——同样的操作、同样的资源：

operationId	Fern	Scalar
listPets	client.pets.listPets()	client.pet.list()
getPet / getPetById	client.pets.getPet()	client.pet.retrieve()
createPet / addPet	client.pets.createPet()	client.pet.create()

Fern 几乎原样保留 operationId，导致每次调用资源名词出现两次——pets.listPets、pets.getPet、pets.createPet。Scalar 则剥离冗余名词并规范化动词，在每个资源上统一给出 list、retrieve、create。对大型 API 而言，这种一致性意味着"猜方法名"与"直接知道方法名"的差别：你只需要记住"对每个资源都有 list/retrieve/create"这一条规律。

错误处理

// Fern
import { FernApiError } from "@fern-api/example-typescript-sdk-petstore";

try {
  await client.pets.createPet(...);
} catch (err) {
  if (err instanceof FernApiError) {
    console.log(err.statusCode);
    console.log(err.message);
    console.log(err.body);
  }
}

// Scalar
import { APIError } from "warp-hr";

try {
  const list = await client.customWorkerFields.list();
} catch (err) {
  if (err instanceof APIError) {
    console.log(err.status, err.name, err.headers);
  }
  throw err;
}

两者都暴露了状态码、响应体与原始响应。Scalar 的额外能力是：从规范生成并精确记录该 API 可能返回的错误状态集合——例如上述客户端记录了 400、401、403、404、409、422、429 和 500 八种错误，错误处理代码可以直接围绕这份清单编写。

依赖

两个生成器都产出零依赖 TypeScript：Fern 的 petstore SDK 与 Warp SDK 的 package.json 均为 "dependencies": {}。Scalar 只在启用特定功能时才引入运行时库——例如开启 webhook 验签时会引入 standardwebhooks。这意味着生成的 SDK 默认体积干净、供应链面小，额外依赖按需增长。

文档能力：从渲染器到部署形态

两个产品都能把 OpenAPI 渲染成带交互式调试器的文档站点，都支持 Markdown 与 MDX，都能生成 llms.txt，并且都提供 MCP 服务器。差异集中在可定制性与文档能部署在哪里。

Scalar 更可定制，因为渲染器归你

Scalar 的 API Reference 采用 MIT 许可，整个渲染层属于你：你可以使用 主题与 CSS 变量（仓库 packages/themes 中内置了多套预设主题），可以在任意页面插入自定义 HTML、CSS 与 JavaScript，甚至可以直接 fork 渲染器实现 Scalar 未预料的任何行为。仓库根目录的 LICENSE 明确为 MIT License，这与"文档栈完全开源"的定位一致。

Fern 提供 27 个内置组件与自定义 React 组件，覆盖面已经很广——但渲染器本身不公开，能力的上限就是 Fern 暴露给你的一切。

文档可以长在你的应用里

Scalar 提供 35 个框架集成（仓库 documentation/integrations 下覆盖 40+ 框架的接入文档）：Express、Fastify、Hono、NestJS、Next.js、Nuxt、Laravel、Django、Rails、Go、Rust、ASP.NET Core、Spring Boot 等。你在自己正在运行的应用中挂载 API Reference，路由由你决定。仓库 integrations 目录还维护着 16 个官方集成包（如 integrations/express、integrations/fastify、integrations/hono、integrations/nestjs、integrations/dotnet、integrations/java 等），每个包都有 playground 与测试验证接入流程。

Fern 是托管式文档平台，没有中间件。唯一的嵌入机制是 embedded mode：剥掉页面外壳，把托管站点塞进 <iframe>。Fern 自己的文章也承认了这一差异，指出 Scalar 可以"与 Express、FastAPI、Hono、NestJS 等框架集成"。

自托管：双方都有，但条款不同

Scalar 的渲染器是 MIT 许可，任何付费方案下都能自托管，无账号也能离线运行。Fern 的自托管文档仅限 Enterprise：以闭源的 fernenterprise Docker 镜像交付，且 Fern 官方公布了一份自托管模式下不可用的功能清单——Ask Fern、AI 示例、分析、编辑器、SSO、RBAC 与 OAuth 在自托管时全部不可用。

你所阅读的这个站点本身就是产品

scalar.com——包括本文、定价页、指南、API Reference 与博客——全部由 Scalar Docs 基于单个 scalar.config.json 构建与托管，不维护独立的营销技术栈。仓库根目录的这份配置文件（含站点元信息、重定向规则、导航、脚本与样式清单）就是整个文档站点的唯一配置源，直观印证了"配置驱动、单文件管理"的产品哲学。

"单一事实来源"是字面意义的

两个产品都宣称文档与 SDK 出自同一份规范。在 Scalar 的生成器中，这不是宣传话术——docs 本身就是与各语言目标并列的一个构建目标。一次生成运行会同时产出：SDK、静态 API Reference，以及 openapi.augmented.json——即 SDK 实际由之生成的精确产物，外加一份用于覆盖率检查的共享 manifest。

其含义是：你的 API Reference 与客户端库不可能描述两个不同的 API，因为它们来自同一次运行中编译后的同一份文档。这从机制上消除了"文档与 SDK 漂移"这类常见的 API 工程问题。

在你联系销售之前能得到什么

Fern 的免费 SDK 档位上限为 50 个端点，且以下能力全部仅限 Enterprise：

自动分页 · 带退避的重试 · OAuth 2.0 · 幂等头 · Webhook 验签 · WebSockets · Server-sent events · gRPC · OpenRPC · HMAC 认证 · Mock 服务测试 · 自定义代码维护

而 Enterprise 定价为"按 SDK、按年计费"且不公布费率——这意味着 Fern 宣传的大部分 SDK 能力都藏在需要打电话询价的年度合约之后。

Scalar 明码标价：每个方案都包含 1 个 SDK 目标语言，额外目标每项 $150/月起。价格随 OpenAPI 文档中的端点数量分档——Free 覆盖 25 个端点以内的 SDK，Pro 含 100 个，Business 含 250 个——你可以不联系销售就自己算出成本。

Webhooks：验签与事件模型的工程细节

Fern 的 webhook 签名验证设计良好——通过 OpenAPI 扩展声明 HMAC 与非对称 RSA/ECDSA/Ed25519，并带重放保护。但其实现目前仅限 TypeScript。

Scalar 在多个目标语言中生成类型化入站事件模型与验签辅助函数，能力包括：HMAC SHA-256、多密钥轮换、provider 风格签名头、时间戳容差与重放存储钩子。支持平台原生密码学的目标语言直接暴露 RSA、ECDSA 与 Ed25519；标准库缺乏 Ed25519 的目标语言则接受验签回调，从而保持生成运行时依赖轻量。

精确地说开源：两半恰好相反

两个产品都不是端到端开源，且开源的部分正好互成镜像。

• Scalar 的文档栈是开源的。 API Reference（packages/api-reference）与 API 客户端（packages/api-client）均为 MIT 许可，可离线、免账号运行并可 fork。GitBook 的交互式 API 浏览器正是由 Scalar 驱动的——这个组件开源到另一家文档公司把它嵌进自己的产品。Scalar 的 SDK 生成器不是开源的（本仓库的 packages 目录也未托管 SDK 生成器源码）。
• Fern 的 SDK 生成器是开源的。 fern-api/fern 采用 Apache-2.0，各语言生成器全部公开。但有两个前提：fern generate --local 仍需要 FERN_TOKEN 与一次组织校验调用，否则只能得到部分输出——核心代码而不含包元数据。Fern 的文档渲染器则未见公开：monorepo 中找不到对应仓库，CLI 本地预览下载的是预构建产物而非从源码构建，自托管文档以闭源镜像交付。

所以结论很直接：如果你在意的是拥有并修改文档层，Scalar 是开源的那个；如果你在意的是自己阅读与运行 SDK 生成器，Fern 是开源的那个。

API 客户端：文档之外的独立产品

Scalar 附带一个独立的开源 API 客户端——桌面端与 Web 端、离线优先，支持环境变量、兼容 Postman 的脚本能力，并为 40+ 种 HTTP 客户端生成代码。Fern 没有对应产品，其调试器只存在于文档站内部。

Fern 的对比内容曾把 Scalar 描述为"仅 REST、不支持 server-sent events、缺少 OAuth 令牌处理"。这三点均已过时：Scalar 客户端能处理 text/event-stream 响应并提供专门的流式响应渲染，能识别 AsyncAPI 文档，并且实现了 OAuth 2.0 的授权码、密码与客户端凭证三种授权模式，在 provider 返回刷新令牌时予以捕获。

如何选择

选择 Fern，如果：你的 API 依赖 gRPC 或 OpenRPC，或者你希望亲自阅读并运行 SDK 生成器的源码。

选择 Scalar，如果：你希望在 MIT 许可下完全拥有文档层；希望自托管而不签企业合同；希望文档挂载在现有应用内部而非独立的托管站点；希望文档之外还有一个真正的 API 客户端；或者希望在联系销售之前就知道 SDK 的成本。

结语

这是一份以事实为基础的对比：本指南基于 Fern 截至 2026 年 7 月的公开文档、定价页面与公开仓库，以及 Scalar 自身的源码与生成产物；Fern 于 2026 年 1 月被 Postman 收购，产品未来可能变化。我们在 Fern 更强的协议广度上做了明确让步，所有对 Fern 的论断均可溯源到其自身公开资料。若发现错误或过时信息，欢迎在仓库提交 issue 修正。同系列的其他选型参考可继续阅读 对比索引 下的 Mintlify 对比、Speakeasy 对比 与 Stainless 对比；若已决定迁移，可查看 迁移指南。