如果你还在使用 Swagger UI 展示 OpenAPI 文档，最近值得关注的一个项目是 Scalar。它并不是微软推出的产品，而是一个独立的开源 OpenAPI 文档工具。不过，微软已经在 ASP.NET Core 官方文档和新教程中提供了 Scalar 集成，并将其作为 OpenAPI 交互式文档 UI 的选择之一。
先厘清一个概念：Scalar 并不是 OpenAPI 的替代品，而是 OpenAPI 文档的展示和交互层。 OpenAPI 负责描述 API，生成 openapi.json 或 YAML；Swagger UI、Scalar、ReDoc 等工具负责读取这个规范并呈现给开发者。因此，从 Swagger UI 迁移到 Scalar，通常不需要修改 API 规范本身。Scalar 官方也提供了专门的 Swagger UI 迁移指南。
Scalar 与主要竞品
| 特性 | Scalar | Swagger UI | ReDoc | Postman |
|---|---|---|---|---|
| 核心定位 | OpenAPI 文档 + API Client | OpenAPI 文档 + 调试 | OpenAPI 文档 | API Client + 协作平台 |
| OpenAPI | ✅ | ✅ | ✅ | ✅ |
| 在线接口测试 | ✅ | ✅ | 社区版有限 | ✅ |
| 搜索 | 内置 | 相对基础 | ✅ | ✅ |
| Code Snippets | 丰富 | 有限 | 有限 | 丰富 |
| UI/UX | 现代化 | 经典 | 文档化风格 | 工作台风格 |
| Dark Mode | ✅ | 部分支持 | ✅ | ✅ |
| 自托管 | ✅ | ✅ | ✅ | 部分能力 |
| 开源 | ✅ | ✅ | ✅ | 核心产品不是 |
| API Governance | 基础 | ❌ | Redocly 生态较强 | 较强 |
| SDK / MCP 生态 | 持续扩展 | ❌ | Redocly 生态 | ❌ |
Scalar 官方的定位已经明显超出传统“文档渲染器”：除了 API Reference，还提供集成式 API Client，并围绕同一份 OpenAPI 文档继续扩展 SDK、MCP 等能力。
- Swagger UI 的优势仍然是成熟、简单和生态广。 它存在时间很长，集成方式成熟，尤其适合开发阶段快速查看和调用接口。微软目前的 ASP.NET Core 文档仍然把 Swagger UI 定位为本地临时测试的选择。
- ReDoc 更偏向“漂亮的 API 文档”。 如果重点是把 OpenAPI 规范整理成结构清晰、适合阅读的参考文档，ReDoc 依然有价值。不过其开源版本与商业 Redocly 平台之间存在能力差异，例如 Try-it Console 等高级能力属于商业产品体系。
- Scalar 的方向则更接近“OpenAPI Developer Experience”。 它不仅希望替代 Swagger UI 的展示界面，还希望把 API 文档、接口调试、代码示例以及后续 SDK/MCP 工具链串起来。
那么，应该换吗？
如果项目只是内部 API，Swagger UI 已经稳定运行，没有必要为了换 UI 而换 UI。
但如果正在搭建新的 API 平台，或者希望把 OpenAPI 作为 API 的核心契约，并进一步连接自动化测试、SDK 生成、API Client 和 MCP，那么 Scalar 的产品方向更值得关注。
另外，ASP.NET Core 从 .NET 9 开始已经内置 OpenAPI 支持，Swashbuckle 不再是项目模板中的默认方案；交互式 UI 仍需要额外选择 Swagger UI、Scalar 等工具。微软当前教程甚至直接使用 Scalar 展示生成的 OpenAPI 文档。
因此，Scalar 更准确的定义不是“新的 Swagger”，而是“面向现代 API 工作流的 OpenAPI UI 和工具链”。 如果只需要 Swagger UI 的替代品，它已经足够；如果希望进一步围绕 OpenAPI 构建完整的 API Developer Experience，它的价值会更明显。
