入门
欢迎使用 Caddy！本教程将介绍使用 Caddy 的基础知识，并帮助你在高层次上熟悉它。
目标：
- 🔲 运行守护进程
- 🔲 试用 API
- 🔲 给 Caddy 一个配置
- 🔲 测试配置
- 🔲 制作 Caddyfile
- 🔲 使用配置适配器
- 🔲 以初始配置启动
- 🔲 比较 JSON 与 Caddyfile
- 🔲 比较 API 与配置文件
- 🔲 在后台运行
- 🔲 零停机配置重载
先决条件：
- 基本的终端 / 命令行技能
- 基本的文本编辑器技能
caddy和curl在你的 PATH 中
如果你是通过包管理器安装了 Caddy，Caddy 可能已经作为服务在运行。如果是这样，请在开始本教程前停止该服务。
我们先启动它：
caddy哎；如果没有子命令，caddy 命令只会显示帮助文本。任何时候忘了该怎么用都可以用它来看看。
要以守护进程方式启动 Caddy，请使用 run 子命令：
caddy run这会一直阻塞，但它在做什么呢？目前……什么都没做。默认情况下，Caddy 的配置（“config”）是空的。我们可以在另一个终端使用 管理 API 来验证这一点：
curl localhost:2019/config/我们可以通过给它一个配置来让 Caddy 发挥作用。可以有多种方式做到这一点，但我们将从下一节使用 curl 向 /load 端点发送 POST 请求开始。
你的第一个配置
为准备我们的请求，我们需要制作一个配置。在其核心，Caddy 的配置就是一个 JSON 文档。
将以下内容保存到一个 JSON 文件（例如 caddy.json）：
{
"apps": {
"http": {
"servers": {
"example": {
"listen": [":2015"],
"routes": [
{
"handle": [{
"handler": "static_response",
"body": "Hello, world!"
}]
}
]
}
}
}
}
}
然后上传它：
curl localhost:2019/load \
-H "Content-Type: application/json" \
-d @caddy.json
我们可以用另一个 GET 请求验证 Caddy 是否应用了我们的新配置：
curl localhost:2019/config/通过在浏览器中访问 localhost:2015 或使用 curl 来测试它是否工作：
curl localhost:2015
Hello, world!如果你看到 Hello, world!，恭喜 —— 它正在工作！在部署到生产环境之前，确保你的配置按预期工作总是个好主意。
你的第一个 Caddyfile
光为了 Hello World 那么做显得有点麻烦。
另一种配置 Caddy 的方式是使用 Caddyfile。我们上面用 JSON 写的同样配置可以简单地表示为：
:2015
respond "Hello, world!"
将其保存为当前目录下名为 Caddyfile（无扩展名）的文件。
如果 Caddy 已在运行，请停止它（Ctrl+C），然后运行：
caddy adapt或者如果你把 Caddyfile 存在别处或命名为非 Caddyfile：
caddy adapt --config /path/to/Caddyfile你将看到 JSON 输出！发生了什么？
我们刚刚使用了一个 配置适配器 将我们的 Caddyfile 转换为 Caddy 的原生 JSON 结构。
虽然我们可以把该输出拿去再发起一次 API 请求，但我们可以跳过这些步骤，因为 caddy 命令可以为我们完成它。如果当前目录中存在名为 Caddyfile 的文件且没有指定其他配置，Caddy 会加载 Caddyfile，为我们适配，并立即运行它。
现在当前文件夹中已有 Caddyfile，让我们再次执行 caddy run：
caddy run或者如果你的 Caddyfile 在别处：
caddy run --config /path/to/Caddyfile（如果它被命名为其它不以 "Caddyfile" 开头的名字，你需要指定 --adapter caddyfile。）
现在你可以再次尝试加载你的网站，你会看到它正在工作！
如你所见，有几种方式可以用初始配置启动 Caddy：
- 当前目录下名为 Caddyfile 的文件
--config标志（可选配合--adapter标志）--resume标志（如果之前曾加载过配置）
JSON vs. Caddyfile
现在你知道 Caddyfile 只是为你转换成 JSON。
Caddyfile 看起来比 JSON 更容易，但你是否应该一直使用它？每种方法都有优缺点。答案取决于你的需求和用例。
| JSON | Caddyfile |
|---|---|
| 易于生成 | 便于手工编写 |
| 易于编程化生成 | 自动化较为困难 |
| 表达能力极强 | 表达能力中等 |
| 支持 Caddy 的全部功能范围 | 支持大部分 Caddy 功能 |
| 允许遍历配置 | 无法在 Caddyfile 内遍历 |
| 支持部分配置变更 | 仅支持整体配置变更 |
| 可以导出 | 无法导出 |
| 兼容所有 API 端点 | 兼容部分 API 端点 |
| 文档自动生成 | 文档为手工编写 |
| 普及度高 | 小众 |
| 更高效 | 更费计算资源 |
| 有点无聊 | 有点有趣 |
| 了解更多：JSON 结构 | 了解更多：Caddyfile 文档 |
你需要决定哪种方式更适合你的用例。
重要的是要注意，JSON 与 Caddyfile（以及任何其他受支持的配置适配器）都可以与 Caddy 的 API 一起使用。然而，如果使用 JSON，你可以获得 Caddy 全功能和 API 特性的全部范围。如果使用配置适配器，使用 API 加载或更改配置的唯一方法是 /load 端点。
API vs. 配置文件
你还需要决定你的工作流是基于 API 还是基于 CLI。（你可以在同一台服务器上同时使用 API 和配置文件，但我们不推荐这样做：最好只有一个事实来源。）
| API | 配置文件 |
|---|---|
| 通过 HTTP 请求进行配置更改 | 通过 shell 命令进行配置更改 |
| 易于扩展 | 难以扩展 |
| 难以手工管理 | 便于手工管理 |
| 非常有趣 | 也很有趣 |
| 了解更多：API 教程 | 了解更多：Caddyfile 教程 |
API 或配置文件工作流的选择与是否使用配置适配器无关：你可以使用 JSON 并将其存储在文件中然后使用命令行界面；相反，你也可以将 Caddyfile 与 API 一起使用。
但大多数人会使用 JSON+API 或 Caddyfile+CLI 的组合。
正如你所见，Caddy 适合各种用例和部署场景！
启动、停止、运行
因为 Caddy 是服务器，它会一直运行。这意味着在你执行 caddy run 之后，直到进程被终止（通常用 Ctrl+C），你的终端不会解除阻塞。
尽管 caddy run 是最常见并且通常推荐的（尤其是当以系统服务运行时！），你也可以选择使用 caddy start 来启动 Caddy 并让它在后台运行：
caddy start这会让你再次使用终端，在某些交互式无头环境中这很方便。
然后你需要自己停止该进程，因为 Ctrl+C 不会为你停止它：
caddy stop或者使用 API 的 /stop 端点 。
重新加载配置
你的服务器可以执行零停机的配置重载/更改。
所有加载或更改配置的 API 端点 都是优雅的、零停机的。
然而，在使用命令行时，可能会很容易想用 Ctrl+C 来停止服务器，然后再次重启以应用新配置。不要这样做：停止并启动服务器与配置更改是两回事，这样会导致停机。
相反，请使用用于优雅配置更改的 caddy reload 命令：
caddy reload这实际上在底层只是使用了 API。它会加载并在必要时将你的配置文件适配为 JSON，然后在不造成停机的情况下优雅地替换活动配置。
如果加载新配置时出现任何错误，Caddy 会回滚到上一个可用配置。