Computer之Server：caddy(可扩展的服务器平台)的简介、安装和使用方法、案例应用之详细攻略
目录
[方式一：下载 GitHub Releases 中的可执行文件](#方式一：下载 GitHub Releases 中的可执行文件)
[方式三：使用 xcaddy 构建带插件的 Caddy](#方式三：使用 xcaddy 构建带插件的 Caddy)
[使用 Caddyfile](#使用 Caddyfile)
[使用 JSON API](#使用 JSON API)
[使用 Caddy 应用和模块](#使用 Caddy 应用和模块)
[案例一：使用 Caddy 作为 HTTPS 服务器](#案例一：使用 Caddy 作为 HTTPS 服务器)
[案例二：使用配置文件管理 Caddy](#案例二：使用配置文件管理 Caddy)
[案例三：通过 API 实现在线配置变更](#案例三：通过 API 实现在线配置变更)
[案例四：构建带自定义插件的 Caddy](#案例四：构建带自定义插件的 Caddy)
[案例五：将 Caddy 作为 Go 应用平台使用](#案例五：将 Caddy 作为 Go 应用平台使用)
[案例六：跨平台运行 Caddy Web 服务器](#案例六：跨平台运行 Caddy Web 服务器)
caddy的简介
Caddy 是一个可扩展的服务器平台，项目 GitHub 首页将其描述为"使用 TLS 作为默认配置的可扩展服务器平台"，并将其定位为快速、可扩展、跨平台的 HTTP/1、HTTP/2、HTTP/3 Web 服务器。项目 README 指出，Caddy 最常见的用途是 HTTPS 服务器，但它同时也是一个运行长期运行的 Go 程序的平台；Caddy 中的"apps"本质上是以 Caddy 模块形式实现的 Go 程序，目前 tls 和 http 两个应用随 Caddy 标准提供。
Caddy 的配置体系以 JSON 为原生配置语言，同时允许通过配置适配器将 Caddyfile、JSON 5、YAML、TOML、NGINX 配置等形式转换为 JSON。README 还指出，Caddy 的主要配置方式是 API；如果偏好配置文件，则可以使用命令行接口。项目将大部分配置集中在一个配置文档中，并通过模块化架构和插件系统提供扩展能力。
在安全与协议支持方面，README 将自动 HTTPS、HTTP/1.1、HTTP/2 和 HTTP/3 支持、内部名称和 IP 的本地 CA 管理、集群中的 Caddy 实例协同、多签发者回退以及 ECH 支持列为项目特性。同时，项目声称 Caddy 已经服务过数万亿次请求并管理过数百万张 TLS 证书，并指出其生产环境规模已经达到数十万个站点。
1 、特点
|----------------|----------------------------------------------------------------------------------------------------------------------|
| 特点 | 详细说明 |
| 多格式统一转换 | 支持 Word（.doc、.docx、.docm）、PowerPoint、Excel、OpenDocument、RTF、EPUB、CSV 和 PDF 等格式，并统一输出 GitHub-Flavored Markdown。 |
| 统一文档模型 | 不同格式先进入共享的 Document 模型，再交由统一 Markdown 序列化器处理，使不同输入格式在转义、表格、标题锚点和脚注等方面遵循相同输出规则。 |
| 文档结构保留 | 支持标题及锚点、粗体、斜体、删除线、行内代码、代码块、链接、内部交叉引用、项目符号列表、编号列表、嵌套列表、任务列表、表格、引用、脚注、尾注和演讲者备注等结构。 |
| 数学公式转换 | Word 和 PowerPoint 中的 OMML、OpenDocument 与 EPUB 中的 MathML，以及 RTF 公式，可转换为 GitHub-Flavored Math 的 ... 行内公式和 $$ 块级公式形式。 |
| 嵌入资源处理 | Markdown 中无法直接嵌入字节数据，因此嵌入图片和对象会以替代文本形式呈现，而原始字节继续保留在文档模型的 assets 中，并带有媒体类型信息；具有外部 URL 的图片则按普通 Markdown 图片处理。 |
| 内容驱动的格式识别 | 项目根据文件内容中的格式标记进行检测，例如 PDF 文件头、RTF 开始分组、OLE 流名称以及 ZIP 包中的 MIME 类型和内容类型；因此文件扩展名与实际内容不一致时仍可进行识别。CSV 是例外，需要通过扩展名或显式格式指定。 |
| Rust 原生实现 | 仓库将 anydoc 描述为纯 Rust 实现，不使用 ML 模型或外部服务；README 给出的中位转换时间低于 5ms。 |
| 多语言绑定 | 提供 Node.js、Python 和 WebAssembly 绑定；Node.js 转换运行于 libuv 线程池，Python 转换会释放 GIL，同时随包提供 TypeScript 类型和 Python 类型存根。 |
| PDF 本地支持 | 文本型 PDF 可通过仓库集成的 pdf-inspector 在本地处理，无需 OCR 服务；仓库同时明确指出，单纯图片型 PDF 属于不能转换的情况。 |
| Agent Skill | 仓库自带 Agent Skill，通过 npx skills add firecrawl/anydoc 安装后，可让兼容的 Agent 借助 anydoc CLI 读取和转换文档。 |
| WebAssembly 支持 | 提供 @firecrawl/anydoc-wasm，API 与 Rust 库相对应，但由于 WASM 没有文件系统，因此转换从字节开始；仓库还提供浏览器演示页面。 |
| 基准测试表现 | 仓库使用 100 份真实文档、14 种格式进行测试，anydoc 覆盖 14/14 格式，中位时间 4.4ms，综合评分 81。 |
caddy的安装和使用方法
1、安装
方式一：下载 GitHub Releases 中的可执行文件
README 给出的最简单、跨平台的安装方式，是从 GitHub Releases 下载 Caddy，然后将可执行文件放入系统的 PATH 中。项目 README 将这一方式作为最简单的跨平台入门方式。
从 GitHub Releases 下载 Caddy
↓
获得对应平台的可执行文件
↓
将可执行文件放入 PATH
↓
即可开始使用 Caddy
方式二：从源码构建
项目 README 要求从源码构建时使用 Go 1.25.0 或更高版本。用于开发时，可以直接克隆仓库并进入 cmd/caddy 目录执行构建：
git clone "https://github.com/caddyserver/caddy.git"
cd caddy/cmd/caddy/
go build
README 同时说明，这种开发构建方式不会嵌入适当的版本信息。对于需要版本信息或者插件的构建，则推荐使用项目的 xcaddy builder。
方式三：使用 xcaddy 构建带插件的 Caddy
README 给出的入口命令为：
xcaddy build
项目说明，xcaddy build 会自动完成创建目录、复制 Caddy 的 main.go、初始化 Go module、可选锁定 Caddy 版本、可选加入插件导入以及最终编译等步骤。
如果需要固定 Caddy 版本，可以使用：
go get github.com/caddyserver/caddy/v2@version
其中 version 可以替换为 git tag、commit 或 branch；加入自定义插件时，则添加相应的 import，然后执行构建：
go build -tags=nobadger,nomysql,nopgx
源码构建后的测试
README 给出了执行全部模块测试以及指定模块测试的命令：
go test ./...
go test ./modules/caddyhttp/tracing/
2、使用方法
使用 Caddyfile
Caddy 将 Caddyfile 作为一种易于配置的方式，同时其原生配置格式是 JSON。对于倾向于使用配置文件的场景，可以通过 Caddy 的命令行接口使用配置文件；而项目将 JSON API 作为主要配置方式。
使用 JSON API
Caddy 的配置模型以 JSON 为核心，并可以通过 API 进行动态配置。README 特别指出，Caddy 应用能够受益于自动生成的文档以及通过 API 进行的优雅在线配置变更。
使用配置适配器
当配置并非直接以 JSON 编写时，Caddy 可以通过配置适配器将其他配置形式转换成 JSON。项目 README 明确列出了以下形式：
Caddyfile
JSON 5
YAML
TOML
NGINX config
以及更多格式
因此，从项目自身的配置模型来看，使用流程可以概括为：外部配置格式经过适配器转换为 JSON，再由 Caddy 的模块体系加载和运行。
使用 Caddy 应用和模块
Caddy 中的应用是以 Caddy 模块实现的 Go 程序，tls 和 http 两个应用默认随 Caddy 提供。模块体系同时承担应用能力的组织与扩展，Caddy 的插件机制则允许增加自定义能力。
caddy的案例应用
案例一：使用 Caddy 作为 HTTPS 服务器
Caddy README 明确指出，Caddy 最常见的用途是 HTTPS 服务器，并且将自动 HTTPS 作为核心特性。对于公共名称，自动 HTTPS 使用 ZeroSSL 和 Let's Encrypt；对于内部名称和 IP，则可以使用完全托管的本地 CA。项目还支持多签发者回退、集群中的 Caddy 实例协同以及 ECH。
因此，按照仓库自身所描述的能力，这一应用模式主要依赖 Caddy 的 TLS 模块和自动 HTTPS 机制，而不是要求用户自行搭建一套独立的 HTTPS 证书管理流程。
案例二：使用配置文件管理 Caddy
Caddy 原生使用 JSON 作为配置语言，但 README 同时明确提供 Caddyfile 作为配置方式。当用户偏好配置文件时，可以使用 Caddy CLI；如果希望采用其他配置表达形式，则可以借助配置适配器将 Caddyfile、YAML、TOML、NGINX 配置等转换为 JSON。
这一案例体现了 Caddy 的配置层结构：不同配置来源最终可以汇聚到统一的 JSON 配置模型，并由 Caddy 的模块体系加载。
案例三：通过 API 实现在线配置变更
README 将 Caddy API 作为主要配置方式，并指出 Caddy 应用可以直接获得通过 API 进行的优雅在线配置变更能力。因此，可以将服务器配置集中到 Caddy 的配置文档，并通过 API 对运行中的配置进行管理。
项目特别强调，Caddy 的配置并非零散存在于大量命令行参数、环境变量和配置文件中，而是主要集中于单一配置文档，这也是 API 配置模型的重要组成部分。
案例四：构建带自定义插件的 Caddy
对于需要扩展服务器能力的场景，仓库 README 给出了 xcaddy 构建流程。开发者可以创建独立的构建目录，复制 Caddy 的 main.go，初始化 Go module，并添加自定义插件的 import；随后执行构建，从而得到包含所需插件的 Caddy。
仓库给出的核心流程如下：
创建构建目录
↓
复制 Caddy main.go
↓
初始化 Go module
↓
可选：锁定 Caddy 版本
↓
添加自定义插件 import
↓
go build
其中，项目提供的最终编译命令是：
go build -tags=nobadger,nomysql,nopgx
案例五：将 Caddy 作为 Go 应用平台使用
仓库 README 不仅把 Caddy 定义为 HTTPS 服务器，也明确指出它适合运行任何长期运行的 Go 程序，并将 Caddy 描述为运行 Go 应用的平台。Caddy 的"apps"就是以 Caddy 模块实现的 Go 程序，标准发行版中包含 tls 和 http 两个应用。
在这种模式下，应用可以继承 Caddy 的模块体系、自动生成文档、在线 API 配置以及与其他 Caddy 应用统一协作的能力；而插件系统进一步提供扩展空间。
案例六：跨平台运行 Caddy Web 服务器
GitHub 项目页面将 Caddy 定义为跨平台 HTTP/1-2-3 Web 服务器，README 给出的最简单安装流程也是直接从 GitHub Releases 获取对应的可执行文件并放入 PATH。同时，项目强调其运行时不依赖外部依赖，甚至不依赖 libc。
因此，仓库所展示的跨平台应用方式并不要求统一的操作系统环境，而是围绕各平台对应的 Caddy 可执行文件进行部署和运行。