发布与恢复 · XB 现场笔记

小系统的优势

Mon, 27 Jul 2026 00:00:00 +0000

小不等于未完成。它意味着每个组件职责清晰、依赖经过斟酌，并且从请求到结果之间始终可见。

明确每个请求边界、相关证据与负责人。组件更少只会减少需要理解的路径；恢复承诺仍靠备份与恢复演练支撑。

可见性是一种特性

当运维人员能说出每个边界时，他们也能指出缺少哪份证据。日志变得更有用，告警更具体，例行维护风险更低。

对静态网站而言，重要的边界通常很容易列出：

DNS 把主机名指向预期的边缘。
TLS 在预期的代理处终结。
代理只服务一个已知的输出目录。
输出只包含站点需要的文件。
404 响应由站点本身处理，而不是意外的上游。

把这些写下来，比加上一块回答不了任何上述问题的仪表盘更有价值。

复杂性要用实力取得位置

当新的一层消除的不确定性多于它引入的，它才值得。缓存重要时，给资源加指纹的构建步骤会有用；内容需要事务时，数据库才有用。但对一个小而多为静态的站点，这两者都不必然是改进。

对客户端 JavaScript 也适用同一规则。如果页面确实需要客户端脚本，应选择满足需求的最小实现，并有意识地审查内容安全策略。对本站而言，这首先需要重新评估已接受的零脚本架构及其验证契约，并不是当前策略的例外。如果页面是一份文档，纯 HTML 往往更容易检视、更有韧性。

让所有权明确

每个文件都应有存在的理由与明确的更新方式。vendored 主题应记录其上游版本与许可。生成目录应标记为生成物。资源下载应说明它包含什么、何时更新、校验和如何产生。

这些简短声明能防止未来的运维者把偶然产生的制品当作受支持的接口。

为下一次变更留出空间

最好的小系统不是行数最少的那个，而是下一次变更看得见去处的那一个。笔记站可以从 Markdown、静态生成器与一个 Web 服务器起步；如果以后需要搜索或评论，可以独立评估这个新需求，而不是一开始就假设它存在。

规模小并不自动带来容错。一个边缘、磁盘或运维者仍可能成为单点故障。明确可接受的恢复时间与数据损失，保留独立备份并演练恢复。组件更少的好处是需要理解的故障路径更少，而不是不会停机。

来源

Hugo directory structure，内容与资源的目录约定，已核验 2026-07-27。
Caddy file_server 指令，设计中引用的静态文件服务默认值，已核验 2026-07-27。

静态服务器应有一个明确的根目录

Thu, 04 Jun 2026 00:00:00 +0000

静态部署最有用的属性是：运维人员不用读应用代码，就能回答"这条响应是哪个目录提供的？"。Caddy 的 root 与 file_server 指令直接提供了这个边界。

明确提供响应的目录。检查符号链接及读取和目录穿越权限，再验证边缘的真实响应。

让根目录明确

一个最小的站点块可以贴近制品布局：

www.example.test {
 root * /srv/example-site
 encode zstd gzip

 header {
 -Server
 X-Content-Type-Options nosniff
 X-Frame-Options DENY
 Referrer-Policy strict-origin-when-cross-origin
 }

 file_server
}

主机名与路径都是占位值；www.example.test 不是可签发公开可信证书的生产名称。生产环境应使用自己控制且可解析的主机名，测试环境的本地 TLS 信任则另行安排。发布命令应发布一个完整目录、核验它，然后才把这个目录设为配置里的根。在新目录通过冒烟测试之前，保留旧的已知良好目录。

检查边缘，而不只是文件树

请求一个 HTML 页面、一个可下载的文本文件和一个缺失路径。把内容类型与状态码与本地制品比较。即使 404 页看起来很精致，若返回 200 仍是部署缺陷。

当 Caddy 管理 HTTPS 时，证书签发与 HTTP 到 HTTPS 的重定向都属于边缘行为。请从裸的 HTTP 监听器测试重定向，并从公共主机名读取证书名称。不要只凭进程健康就推断成功。

根目录是发布边界，不是沙箱

把版本控制元数据、备份、凭据与私有配置留在发布树之外。Caddy 会跟随根目录中的符号链接，因此链接可能暴露根目录外的文件。既要检查制品内容，也要检查服务用户的读取与目录穿越权限。此外，仅把 404.html 放进目录并不会配置自定义错误处理；应核验缺失路由的状态码与预期错误页行为。

来源

Caddy file_server 指令，静态文件服务与根目录选择，已核验 2026-10-15。
Caddy header 指令，响应头配置，已核验 2026-10-15。
Caddy Automatic HTTPS，证书签发与 HTTPS 重定向，已核验 2026-10-15。
MDN: X-Frame-Options，防止被嵌套的选项，已核验 2026-10-15。
RFC 7034 — X-Frame-Options，DENY 嵌入策略，已核验 2026-10-15。
静态网站发布检查清单，本地配套资源。
RFC 6761 — Special-Use Domain Names，保留的 .test 名称，已核验 2026-10-15。

静态网站的发布检查清单

Thu, 30 Jul 2026 00:00:00 +0000

静态网站发布很简单，但简单并不免除发布检查的需要。有用的检查足够小，能在每次发布运行，也足够具体，能为真实的理由而失败。

检查对象应是生成制品。干净输出不等于可复现；占位符搜索只是复核线索，真正的链接门禁应基于解析器。发布前服务确切制品，发布后比较两种语言的公共 GET 正文，并保存提交、生成器版本和下载校验和。

构建干净的制品

使用固定版本的生成器，构建到一次性的输出目录：

set -eu
hugo version
hugo --cleanDestinationDir --gc --minify --destination public

--gc 回收未使用的构建缓存资源，不会清理陈旧的已发布页面。--cleanDestinationDir 会移除目标目录中的陈旧文件，因此只能用于一次性制品目录，不能指向源码或其他数据所在的目录。把打印出的版本与项目固定版本比较；打印版本本身不会强制版本一致。记录构建输入并验证生成的制品。干净的目标目录不能证明逐字节可复现：时间戳与其他非确定性输入需要单独控制和比较。不要在构建之后手改生成的 HTML。

检查制品，而不只是源码

检视生成的树，确认期望的入口点存在。把下面的断言块作为独立 shell 脚本运行；任何必需文件缺失或为空时，都应在打印清单之前停止：

set -eu
test -s public/index.html
test -s public/404.html
test -s public/robots.txt
test -s public/sitemap.xml
find public -type f -print | sort

然后搜索意外的占位符、本地路径与仅开发用的主机：

rg -l 'localhost|127\.0\.0\.1|TODO|example\.com|/Users/' public --glob '*.html'

这只是复核线索，不是自动发布门禁：本清单这类示例本来就会命中，翻译页中也一样。这项仅检查 HTML 的扫描不会覆盖 XML 订阅或 JSON 搜索输出。rg 无匹配时退出 1，发生错误时退出 2。逐个复核列出的文件，区分围栏示例与有效链接或属性，并用基于解析器的链接检查作为真正门禁。公开链接中的私有路径属于发布错误。

验证公共路由

让隔离的类生产服务器直接指向这份制品，才能进行更可靠的发布前路由检查。Hugo 开发服务器会重新构建内容；下面是独立的源码预览，不能证明它服务的就是已经检查过的 public/ 字节。第一条命令在一个终端运行，其余请求在另一个终端运行：

hugo server --bind 127.0.0.1 --port 1313 --baseURL http://127.0.0.1:1313/ \
 --disableFastRender --disableLiveReload --renderToMemory
curl -I http://127.0.0.1:1313/
curl -I http://127.0.0.1:1313/notes/
curl -I http://127.0.0.1:1313/resources/
curl -I http://127.0.0.1:1313/missing-page/

HEAD 检查不比较正文。对待发布服务器再运行 GET，发布后将公共正文与制品比较，并检查两种语言。确认缺失路由在生产服务器上返回 404 状态。一个外观精美但状态 200 的错误页，仍然会破坏监控与缓存。

记录结果

在发布记录中保留源码提交、生成器版本与每个可下载资源的校验和。这样无需依赖记忆，就能把线上文件与产生它的源码进行比较。

这份检查清单的可下载版本在资源一节中。

来源

Hugo command reference，干净生产构建的生成器标志，已核验 2026-07-30。
curl manual，HTTP 验证与响应头检查选项，已核验 2026-07-30。
静态网站发布检查清单，可下载的配套资源。
Hugo server command reference，开发服务器重新构建、内存渲染与实时刷新控制，已核验 2026-10-15。

通过切换完整目录发布静态网站

Mon, 01 Jun 2026 00:00:00 +0000

直接把新文件复制到活动的静态目录上，会造成一段访问者可能从一个版本拿到 HTML、从另一个版本拿到资源的时期。更安全的模式是：在活动树旁预置一棵完整的树，验证它，再改变目录名。

两次移动之间 live 缺失，崩溃可能延长空窗。恢复需要尝试并验证。浏览器各次请求彼此独立，旧资源 URL 必须继续可访问。

把所有发布目录放在同一文件系统上

把活动树、预置树与回滚树放在同一文件系统上。以下片段假设使用同一个 Bash 会话、GNU Coreutils，且只有一个发布进程独占这些目录名。任何命令或复制管道任一侧失败，都应停止：

set -euo pipefail
df -P /srv/www

在该父目录下创建唯一命名的中转目录。不要把未解析的变量或宽泛通配符当成删除目标来复用。

stage=$(mktemp -d /srv/www/site.new.XXXXXX)

填充并验证预置目录

把生成制品复制进空目录，然后检查代表性文件。最后一条命令只显示数量；应与已核验制品的期望数量或清单比较，不能把任意数字都当作通过：

tar -C public -cf - . | tar -C "$stage" -xf -

test -s "$stage/index.html"
test -s "$stage/404.html"
find "$stage" -type f | wc -l

当工具支持目录参数时，对预置路径运行链接与校验和检查。还要确认服务用户能穿过目录并读取文件：mktemp -d 初始权限较严，解包后的制品必须具备预期权限。未通过验证的预置目录绝不能获得活动目录的名字。

用显式回滚路径切换名字

在第一次移动前解析每个路径：

live=/srv/www/site
stamp=$(date -u +%Y%m%dT%H%M%SZ)
rollback=/srv/www/site.old-$stamp

test -d "$live" && test ! -L "$live" || exit 1
test -d "$stage" && test ! -L "$stage" || exit 1
test ! -e "$rollback" && test ! -L "$rollback" || exit 1
df -P "$live" "$stage"
live_device=$(stat -c %d -- "$live") || exit 1
stage_device=$(stat -c %d -- "$stage") || exit 1
test "$live_device" = "$stage_device" || exit 1

mv -T -- "$live" "$rollback" || exit 1
if mv -T -- "$stage" "$live"; then
 test -s "$live/index.html"
else
 mv -T -- "$rollback" "$live" || {
 printf 'Restore failed; inspect %s and %s before retrying.\n' "$rollback" "$live" >&2
 exit 1
 }
 exit 1
fi

这是两步切换，不是一次原子替换：两次移动之间活动路径不存在，崩溃后可能一直缺失，直到恢复。GNU mv -T 可防止已有目录被悄悄当作容器、把发布树移进其中，但不能协调并发发布进程。文件系统检查结果不一致时不要继续。平台特定的原子交换或符号链接替换能消除名字缺失窗口，但必须结合实际服务器测试。

验证公共边缘

切换之后，请求首页、一个深层路由、一个带指纹的资源与一个缺失路径。把公共字节与预置制品比较。在检查完成与观察窗口结束之前，保留回滚目录。

即使目录名切换是原子的，浏览器请求 HTML 与资源仍不是同一笔事务。让旧指纹资源继续可访问，才能服务缓存中或传输中的 HTML；仅保留一个不对外服务的回滚目录并不能做到这一点。文件系统重命名也不自动保证崩溃后的持久性，这需要平台相应的持久化步骤。

来源

POSIX rename()，名字替换语义，已核验 2026-06-01。
Linux rename(2)，文件系统与替换行为，已核验 2026-10-15。
GNU tar manual，归档创建与解包，已核验 2026-06-01。
GNU Coreutils: 目标目录，-T 与目录嵌套风险，已核验 2026-10-15。
GNU Coreutils: stat，文件系统设备号检查，已核验 2026-10-15。

发布清单应点名每一个已发布的字节

Thu, 16 Jul 2026 00:00:00 +0000

静态制品是一个目录，而不是单个可执行文件。只记录源码提交或首页校验和会留下缺口：缺失的图片、陈旧别名或变化的下载可能悄悄留下来。传输前，应冻结制品并枚举其中每个常规文件。

测量前停止写入、拒绝符号链接和特殊文件，并将清单保存在制品树外。逐项校验发现缺失或变化的字节；重新生成并比较完整清单还可发现多余文件。对可信源端清单做哈希可得到紧凑标识，真实性与元数据仍需独立控制。

生成稳定的列表

从包含 public/ 的目录，在 Bash 中使用 GNU findutils 与 coreutils 运行以下命令。清单应保存在被测目录之外。发布只能包含目录和常规文件：先检查并拒绝符号链接或特殊文件，因为它们不在该清单的契约内。

set -euo pipefail
manifest="$PWD/release.sha256"
(
 cd public
 nonregular=$(find . ! -type d ! -type f -print -quit)
 test -z "$nonregular"
 find . -type f -print0 | LC_ALL=C sort -z | xargs -0 -r sha256sum --
) > "$manifest"
test -s "$manifest"

先排序文件名，再计算哈希。工具之间用 NUL 分隔路径，可保留空格、制表符与内嵌换行；GNU sha256sum 会在普通可校验输出中转义特殊文件名。不要用 awk '{print $2}' 解析该输出：文件名中可以合法包含空白。单独赋值会保留 find 失败时的退出状态；只检查其输出，可能把扫描失败误认成空结果。扫描或管道一旦失败，就应把清单视为不完整，不得发布。测量期间停止写入；这些命令不会创建文件系统快照。

传输后验证

在目标端的同一个可丢弃 Bash 会话中，按顺序运行后续片段，使路径变量与 set 选项保持生效。将清单与制品路径设为实际位置：

set -euo pipefail
manifest=/path/to/release.sha256
artifact=/srv/www/site.new
(
 cd "$artifact"
 sha256sum -c "$manifest"
)

检查列出的文件能发现缺失或改变的字节，却不能发现多余文件。因此按相同流程重新生成目标端清单，并比较完整记录：

observed=$(mktemp "${manifest}.observed.XXXXXX")
trap 'rm -f "$observed"' EXIT
(
 cd "$artifact"
 nonregular=$(find . ! -type d ! -type f -print -quit)
 test -z "$nonregular"
 find . -type f -print0 | LC_ALL=C sort -z | xargs -0 -r sha256sum --
) > "$observed"
diff -u "$manifest" "$observed"

没有差异且退出状态为零，表示常规文件的路径与哈希一致。多出一个陈旧文件也会使检查失败。临时输出位于制品之外，因此检查不会包含自身。空目录、权限、所有者与时间戳不在测量范围内；部署依赖这些属性时需另行验证。

为发布记录增加聚合摘要

对清单本身做哈希，得到紧凑的发布标识：

sha256sum "$manifest"

其含义依赖固定的规则：相对路径、排序区域、算法、工具格式，以及包含哪些元数据。将可信清单与源码提交、构建器版本一起保存。

不要把完整性等同于真实性

SHA-256 摘要一致，是字节一致的强实用证据，并不能证明作者身份。攻击者若能同时替换制品与清单，也能让检查通过。签名与可信分发是独立控制；只应校验通过预期可信渠道取得的清单。

来源

GNU Coreutils: sha2 utilities，校验和生成与验证；通过下列上游手册源码核对，已核验 2026-10-15。
GNU Coreutils 手册源码，非 tagged 校验和的转义、--check 与 NUL 分隔排序，已核验 2026-10-15。
sha256sum(1)，命令行为与输出格式，已核验 2026-07-16。
GNU Bash: Simple Command Expansion，纯赋值命令保留命令替换的退出状态，已核验 2026-10-18。

用两条命令读取公共边缘

Mon, 13 Jul 2026 00:00:00 +0000

部署完成意味着公共响应符合发布契约，而不是最后一条上传命令退出码为零。操作套件里的两个只读工具能提供有用证据，但不能证明整个制品都已正确发布。

这些片段仅为示意。分别判断 HTTP 状态与到期结果；主机名、信任与正文一致性需要对应的独立检查。

检查响应头

check-http-headers.sh 发出 GET、丢弃正文、跟随重定向，打印每一跳的响应头以及最终状态和 URL：

check-http-headers.sh https://www.xbcatm.com/

以下输出只演示要检查的字段，并非刚刚采集的生产观察结果：

HTTP/2 200
accept-ranges: bytes
content-security-policy: default-src 'self'; base-uri 'self'; form-action 'none'; frame-ancestors 'none'; object-src 'none'; script-src 'none'; style-src 'self'; img-src 'self' data:
content-type: text/html; charset=utf-8
last-modified: Mon, 24 Aug 2026 11:20:54 GMT
permissions-policy: accelerometer=(), camera=(), geolocation=(), gyroscope=(), microphone=(), payment=(), usb=()
referrer-policy: strict-origin-when-cross-origin
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff
x-frame-options: DENY

HTTP_STATUS 200
FINAL_URL https://www.xbcatm.com/

核对预期状态、最终主机与路径，以及最终响应上的策略。工具没有使用 curl 的 --fail：HTTP 404 或 500 仍可能使 shell 命令成功结束。必须判断它打印的状态。响应头不一致需要调查服务器、代理或缓存配置；单凭这种不一致，不能证明活动输出目录选错了。

检查证书日期

check-tls-expiry.sh HOST [DAYS] 提取使用 SNI 时服务器呈现的证书，并检查距离到期是否至少还有指定天数对应的秒数：

check-tls-expiry.sh www.xbcatm.com 30

下面是省略了指纹行的示意片段：

subject=CN=www.xbcatm.com
issuer=C=US, O=Let's Encrypt, CN=YE1
notBefore=Aug 21 08:37:13 2026 GMT
notAfter=Nov 19 08:37:12 2026 GMT

certificate remains valid for at least 30 day(s)

工具打印主体、签发者、日期与 SHA-256 指纹，不打印剩余天数。成功消息只描述到期检查：脚本没有强制验证主机名或信任链，-checkend 也不验证 notBefore。主体 CN 不足以证明主机身份；服务身份应与证书的主体备用名称匹配。有效的通配符也可能合法覆盖该主机。

需要验证这些属性时，另行运行：

openssl s_client -connect www.xbcatm.com:443 -servername www.xbcatm.com \
 -verify_hostname www.xbcatm.com -verify_return_error </dev/null

这使用已配置的信任库，并在 OpenSSL 匹配规则下的证书验证出错时失败。在 OpenSSL 3.0 中，没有合适的 DNS 主题备用名称时，主机名验证可能回退到主题 CN。因此，命令成功本身不能证明符合 RFC 9525 仅使用 SAN 的身份策略：还要检查 SAN 扩展，并单独验证目标客户端的策略。TLS 工具本身没有网络截止时间，应在任务层设置超时。证书检查与自动续期配置仍是两项独立检查。

在发布前后使用两者

发布前：保存预期策略、最终 URL、验证器与证书日期，并注明 UTC 采集时间。
部署已经验证的制品。
发布后：重复探测，并下载代表性正文与该制品比较。

响应头与证书日期不能证明字节一致。Last-Modified 可能不变，也可能在复制中被重写。发布冒烟测试保存正文并直接比较；完整清单可将检查扩展到单个页面之外。浏览器行为、不同地区边缘的差异，以及只在负载下出现的故障，需要另行测试。记录实际检查过的路径与观察点。

来源

curl manual，GET、重定向、响应头输出与 HTTP 失败行为，已核验 2026-10-15。
OpenSSL s_client，SNI、显式主机名检查与验证错误时失败，已核验 2026-10-15。
OpenSSL verification options，主机名匹配与主题 CN 回退，已核验 2026-10-15。
OpenSSL x509，证书显示与只检查到期的 -checkend 行为，已核验 2026-10-15。
RFC 9525 — Service Identity in TLS，主体备用名称与通配符身份匹配，已核验 2026-10-15。
Caddy Automatic HTTPS，自动证书管理与续期配置，已核验 2026-10-15。
MDN: Content Security Policy guide，所示策略的背景说明，已核验 2026-07-13。
RFC 9110 — HTTP Semantics，响应元数据与验证器不能证明完整制品匹配，已核验 2026-10-15。

发布在公共边缘一致之前不算完成

Thu, 09 Jul 2026 00:00:00 +0000

静态发布消除了应用运行时的复杂度，但不会消除生成目录与公共响应之间的边界。发布检查应同时覆盖两边。

切换前后使用同一份制品。下载行对应文中的 public/downloads/check-http-headers.sh。cmp 比较前会解码受支持的内容编码；服务器转换需有明确比较规则。状态和响应头另行检查，并保留前一目录供主动回滚。

从干净的制品开始

使用固定生成器构建到干净的目录。记录源码提交、生成器版本、输出文件列表，以及用户会下载的文件的校验和。一次干净的构建能捕获复制式部署可能会意外保留的陈旧文件。

set -eu
make verify
find public -type f -print | sort

文件列表是证据，不是装饰。如果某条路由消失，diff 应能说明是该来源被移除，还是生成器未能产出它。

演练三类响应

发布前，用预期服务器配置测试待发布制品。切换目录后，在公共边缘重复检查；探测仍在线的旧站不能验证新发布。请求一个 HTML 页面、一个静态资源与一个缺失路径。检查状态码、内容类型、缓存策略与安全头：

set -eu
curl --compressed -fsS -D page.headers -o page.body https://www.example.test/
curl --compressed -fsS -D asset.headers -o asset.body \
 https://www.example.test/downloads/check-http-headers.sh
curl --compressed -sS -D missing.headers -o missing.body \
 https://www.example.test/does-not-exist

cmp public/index.html page.body
cmp public/downloads/check-http-headers.sh asset.body
cmp public/404.html missing.body

把每个片段作为独立 shell 脚本运行，或放在可丢弃的 shell 会话中执行。set -eu 让这个顺序脚本在构建、传输或比较失败后停止，避免后面的成功命令掩盖先前失败。缺失路径的请求有意不用 -f：404 是预期结果，仍应被捕获。检查各响应头文件的最终状态：依次为 200、200、404；字节比较不会自动完成状态码检查。这里不跟随重定向。--compressed 在比较前解码受支持的内容编码；若服务器有意转换 HTML，需要另行说明比较规则。cmp 相等时不输出，有差异时返回非零。在 /zh/ 及其错误页上重复检查，不能直接假设两种语言一致。

让回滚保持简单

在新目录通过检查之前，不要删除上一个目录。回滚应选择一个已知良好目录，而不是在事故中凭记忆重新构造一个。发布检查清单与HTTP 响应头检查都刻意做得足够小，能在干净的 shell 里运行。

来源

RFC 9110 — HTTP Semantics，状态与表示语义，已核验 2026-07-09。
curl manual，响应检查选项，已核验 2026-07-09。
静态网站发布检查清单，本地配套资源。

DNS 变更需要一个感知缓存的回滚窗口

Thu, 18 Jun 2026 00:00:00 +0000

改一条地址记录很容易，预测每个解析器何时停止使用旧应答却很难。生存时间（TTL）值随 DNS 响应传播，控制通常情况下的缓存新鲜度。在迁移那一刻降低 TTL，并不能改写更早被缓存下来的应答。

TTL 随每个应答传播。切换前做好准备，让两侧持续有效，并结合旧端点流量与余量决定下线和回滚。

在事件前降低 TTL

如果既有记录是一天的 TTL，至少要在计划切换前一个旧 TTL 时就把它降低。这样在权威记录仍指向旧端点时，缓存有时间去取较短的值。确切间隔应写进变更计划，而不是在迁移中即兴执行。

单独记录权威服务器的应答。下面两条探针比较系统配置的解析器与公共递归解析器，并不天然属于权威查询：

dig +noall +answer www.example.test A
dig @1.1.1.1 +noall +answer www.example.test A

要取得权威证据，应向该区域实际的名称服务器发起非递归查询，并检查 AA 标志、状态、答案与权威部分。递归解析器的剩余 TTL 反映其当前缓存状态，不同解析器可以合理地不同。还应检查服务使用的 AAAA 与 CNAME 链，不能只检查 A。

让两侧都保持有效

切换期间，保持旧端点与新端点都能为预期主机名提供服务。TLS 名称、重定向与应用配置在两侧必须一致。权威记录改变后立刻移除旧端点，会给仍持有先前应答的客户端造成本可避免的停机。

否定应答也会被缓存。一个最近返回 NXDOMAIN 的名字，其出现可能很慢才可见，因为根据区域的权威数据，否定响应可能仍留在递归缓存里。

观察后恢复 TTL

一旦权威与具有代表性的递归应答都指向新端点，且旧缓存窗口已过，就恢复正常 TTL。在变更记录中保留旧值、新值、权威应答与回滚条件。

TTL 不是所有客户端统一的下线期限。解析器在解析失败时可能提供过期数据，长连接与应用缓存也可能超过 DNS 新鲜期。应观察旧端点流量并预留余量；把 DNS 改回去同样有缓存窗口。对否定应答，应检查由 SOA 决定的否定 TTL，不能假设新 A 记录的 TTL 适用。

来源

RFC 1034 — Domain Names: Concepts and Facilities，缓存模型，已核验 2026-10-15。
RFC 1035 — Domain Names: Implementation and Specification，TTL 字段，已核验 2026-10-15。
RFC 2308 — Negative Caching of DNS Queries，否定缓存模型与保留的错误 TTL，已核验 2026-10-15。
RFC 8767 — 提供过期数据，DNS 解析失败时提供过期应答，已核验 2026-10-15。
BIND 9 dig 手册，服务器选择与递归控制，已核验 2026-10-15。

重启策略需要一个速率限制

Mon, 03 Aug 2026 00:00:00 +0000

对长驻服务来说，自动重启很有用，但无界的循环会把一个清晰的失败变成一个嘈杂的失败。单元文件应同时描述正常进程生命周期与可接受的恢复量。

按配置窗口统计启动次数。启动速率限制可以停止快速反复重启，但不能证明健康，也不限制生命周期重试总数。

捕获启动失败

对长驻进程，Type=exec 能在启动时暴露配置程序执行失败，而不是把一次 fork 当成功。把它与显式的 ExecStart 以及能完成工作所需最小权限的 User 搭配使用。

[Unit]
Description=Example foreground site service
StartLimitIntervalSec=60s
StartLimitBurst=5

[Service]
Type=exec
User=site
ExecStart=/srv/site/bin/server
Restart=on-failure
RestartSec=5s

Type=exec 确认程序已执行，并不确认应用已就绪。程序应保持前台运行；应用支持显式就绪通知时可用 Type=notify。Restart=on-failure 是恢复策略，不是健康检查。如果进程在提供错误响应的同时保持存活，systemd 不会知道站点坏了；外部冒烟测试仍有其职责。

限制循环

Systemd 通过 StartLimitIntervalSec= 与 StartLimitBurst= 应用启动速率限制。这两个指令放在 [Unit]，RestartSec 放在 [Service]。示例允许 60 秒内启动五次；快速失败之间只有五秒重启延迟，因此可能达到限制。更长延迟可能让循环一直低于该速率：这并不是整个生命周期的重试次数预算。应按预期故障模式选择限制。当达到限制时，日志里应包含区分"重启成功"与"重复失败后放弃"所需的证据。

在获准使用的测试主机上安装或修改单元后，先验证文件、重载管理器并检查有效配置，再重启。下列命令会改变服务状态，可能中断流量：

systemd-analyze verify /etc/systemd/system/example.service
systemctl daemon-reload
systemctl cat example.service
systemctl show example.service -p Restart -p RestartUSec \
 -p StartLimitIntervalUSec -p StartLimitBurst
systemctl restart example.service
systemctl status --no-pager example.service
journalctl -u example.service -n 80 --no-pager

不要用重启策略掩盖缺失文件、无效权限或糟糕的环境。先修复第一次失败，再测试恢复路径。

启动限制停止自动重启后，单纯等到间隔结束不会自动排定下一次尝试。修复原因后，可等待间隔结束再启动，或有意识地用 systemctl reset-failed example.service 清除计数器后启动。在隔离服务中测试可执行文件缺失与快速崩溃，并保存第一次失败日志，不要只留下最后的“达到启动限制”消息。

来源

systemd.service，服务类型、重启与启动速率限制器，已核验 2026-08-03。
systemd.unit，通用单元段与 drop-in 语义，已核验 2026-08-03。
systemd.service upstream manual (v257)，Type=exec/oneshot、就绪、激活超时与重启语义，已核验 2026-10-15。
systemd.unit upstream manual (v257)，启动限制所属配置段、速率窗口与 reset-failed 行为，已核验 2026-10-15。

维护定时器应让其最近结果可见

Tue, 04 Aug 2026 00:00:00 +0000

cron 式语法并不是维护任务契约的全部。命令需要一个清晰的服务身份、一个有界的运行时间，以及能区分"未调度"与"运行但失败"的证据。一个 systemd 定时器与 oneshot 服务能把这些关注点分开。

定时器触发只证明发生了调度事件。用服务结果、退出状态和新的时间戳判断本次运行。

把工作定义成服务

使用显式用户与绝对命令路径：

# /etc/systemd/system/site-check.service
[Unit]
Description=Read-only public site check

[Service]
Type=oneshot
User=sitecheck
ExecStart=/usr/local/bin/check-public-site
TimeoutStartSec=2min

TimeoutStartSec 限制 oneshot 的激活过程，其中包括命令运行时间；oneshot 默认没有启动超时。超时处理之后还可能需要停止超时，且不能立即结束不可中断的内核 I/O，因此工具本身也需要有界的网络请求。当契约失败时，helper 应返回非零退出码，并且不得修改它所检查的服务。

调度该服务

# /etc/systemd/system/site-check.timer
[Unit]
Description=每小时运行公共站点检查

[Timer]
OnCalendar=hourly
Persistent=true
RandomizedDelaySec=5min
Unit=site-check.service

[Install]
WantedBy=timers.target

若至少错过一次日历事件，Persistent=true 会在定时器重新激活时触发一次补跑；它不会逐小时重放所有错过的运行。补跑仍受随机延迟限制。RandomizedDelaySec 把一个窗口内的例行工作分散开；当任务必须在精确时刻运行时它并不合适。

启用前先验证

创建两个单元文件后，先验证并重载管理器，再手动启动服务。这些是在目标测试主机上的管理操作，不是只读检查：

systemd-analyze verify /etc/systemd/system/site-check.service \
 /etc/systemd/system/site-check.timer
systemd-analyze calendar hourly
systemctl daemon-reload
systemctl start site-check.service
systemctl status site-check.service
journalctl -u site-check.service -n 50 --no-pager
systemctl show site-check.service -p Result -p ExecMainCode -p ExecMainStatus

只有当服务在预期的用户、环境、路径与网络访问下成功时才启用定时器：

systemctl enable --now site-check.timer
systemctl list-timers site-check.timer

对服务结果告警

定时器触发并不等于成功。要监控 oneshot 服务的退出状态或日志结果。保持 stdout 简洁，调试需要的详细制品写入一个有界的路径。

成功的 oneshot 通常回到 inactive (dead)；这本身不是失败，systemctl status 对非活动服务可能返回非零。应将 Result、退出状态与新的日志时间戳对应，避免把旧运行的成功误认成本次结果。不要为了显示绿色而添加 RemainAfterExit=yes：服务仍处于活动状态时，重复定时器不会启动一个新实例。日历时间默认使用主机时区，而且常规定时器精度会在随机延迟之外增加调度余量。

来源

systemd.timer(5)，日历定时器、持久化与延迟行为，已核验 2026-08-04。
systemd.time(7)，日历表达式语法，已核验 2026-08-04。
systemd.service，oneshot 服务语义，已核验 2026-08-04。
systemd.service upstream manual (v257)，Type=exec/oneshot、就绪、激活超时与重启语义，已核验 2026-10-15。
systemd.timer upstream manual (v257)，持久化会合并错过的运行；活动单元、随机延迟与精度，已核验 2026-10-15。

备份只有在演练过恢复之后才有用

Wed, 03 Jun 2026 00:00:00 +0000

“我们有备份"还不是一种恢复能力。一份有用的备份有已知范围、已知新鲜度、一个验证步骤，以及一份确实有人运行过的恢复流程。

恢复演练从可识别的输入，以及取回并核验的存储副本开始。在可丢弃的隔离目标中恢复，再记录文件、权限、依赖与恢复耗时。校验和或归档存在本身，都不能证明可恢复。

定义恢复单元

对静态站点，源码仓库与生成制品用途不同。仓库是权威输入；制品是恢复最近发布版本的最快方式。请把两者的区别说清楚。

至少记录：

源码提交或归档标识；
生成器与主题版本；
制品包含的文件列表；
重要下载的校验和；
保留期限与存储位置。

不要把凭据、私钥、Cookie 或访问令牌放进网站备份。它们应属于独立的机密管理流程。

存储前先验证

打不开的归档不是备份。一个最小的验证循环如下：

set -eu
tar -czf site-2026-06-03.tar.gz public/
tar -tzf site-2026-06-03.tar.gz >/dev/null
sha256sum site-2026-06-03.tar.gz > site-2026-06-03.tar.gz.sha256

生成校验和只是记录基线，并未回读实际存储的副本。先从备份存储取回归档与校验和，再在解包前核验。校验和匹配能发现意外变化，但攻击者若可同时替换两个文件，它便不能证明归档来源可信。能列出成员也不等于备份了正确的文件。

在某个可丢弃的地方恢复

使用可信归档，以非特权用户身份解包到空临时目录或隔离主机，再检查入口点与一个有代表性的资源。不可信归档需要更强的隔离，因为路径与链接会影响解包行为。不要通过覆盖唯一活动副本来测试。

set -eu
sha256sum -c site-2026-06-03.tar.gz.sha256
restore_dir=$(mktemp -d)
tar -xzf site-2026-06-03.tar.gz -C "$restore_dir"
test -s "$restore_dir/public/index.html"
test -s "$restore_dir/public/404.html"

这条命令刻意很平凡。演练应在事故到来之前，暴露出缺失文件、错误权限或未记录的依赖。

诚实地度量新鲜度

备份日程只有在相对可能丢失的工作量时才有意义。如果源码一个月才变一次，每日快照可能不必要；如果某个资源每小时更新，一次月度归档又不够。

写下目标恢复点与恢复时间，再选择能满足这些目标的存储与检查。当最后一次经过验证的恢复备份已经陈旧时，不要宣称"连续保护”。

至少保留一份位于活动主机故障与删除范围之外的可恢复副本。记录恢复耗时、恢复文件的校验和、权限与人工依赖；两个非空 HTML 文件只是冒烟测试，不是完整的恢复验收。

来源

GNU tar manual，归档创建与验证行为，已核验 2026-06-03。
静态网站发布检查清单，本地配套资源。
GNU Coreutils: SHA-2 工具，生成校验和与 --check 核验，已核验 2026-10-15。

可靠的默认行为胜过聪明的恢复

Mon, 20 Jul 2026 00:00:00 +0000

小服务往往在正常路径被充分理解之前，就先累积了恢复逻辑。每一次重试、备用端点与兼容分支，都增加了必须被观察和测试的一个状态。

让常见路径可见。先判断并限制重试，再恢复到保留的已知良好状态，避免选择半成品副本。

让常见路径变得无聊

一个有用的默认行为是明确的、易于检视的、且可安全重复的。对静态站点，可以简单到：

构建自固定的工具链。
检查生成的 HTML、资源与完整的待发布目录。
发布该目录，再把公共响应与它核对。
保留上一个目录以便回滚。

这段序列不如多阶段部署系统炫目，但它的状态可见。当某处失败时，运维者能回答：问题在源码、构建、复制还是 Web 服务器。

只对可限定范围的操作重试

当故障可能是瞬时的、且重复操作不会改变其预期效果时，重试才有用。幂等不等于每次响应或附带日志都相同；响应丢失后，第一次尝试可能早已成功。从源站下载可能可安全重试；数据库迁移则未必。把每个错误都看作可重试的，会掩盖需要关注的边界。

当重试适当时，记录尝试次数与最终原因。类似"发布失败：校验和不匹配"的日志条目，比一串静默重试后跟一个笼统超时更有可操作性。

偏好单一权威状态

配置、运行时状态与文档应一致地说明哪个目录是活动的、哪条命令产生它。如果一个发布可以被不同的人复制到三条不同路径，恢复就变成了猜谜。

对静态部署，一份简短的发布记录就够了：

release: 2026-07-20
source: git commit <commit-id>
builder: Hugo 0.165.0
output: public/
verification: links + headers + checksums

占位符 commit ID 应按设计在发布时解析，而不是在文档里杜撰。

恢复应回到已知状态

当恢复把服务带回最后一个已知良好目录，而不是在几个半成品替代品之间选择时，恢复最容易。保留上一次输出直到新输出通过检查，再按保留策略移除旧副本。

目标不是消除失败，而是把失败缩小到能解释、把恢复缩小到能信任。

同时限制重试次数与总耗时。多个客户端可能一起重试时，使用带随机抖动的退避，并避免每一层都重试。权限错误与确定性的无效输入需要修正，而不是更长的重试循环。

来源

RFC 9110 — HTTP Semantics，9.2.2 节关于幂等方法与重试，已核验 2026-07-20。
静态网站发布检查清单，本地配套资源。
AWS Builders’ Library: Timeouts, retries, and backoff with jitter，重试放大、有界重试预算、退避与随机抖动，已核验 2026-10-15。

事故复盘应留下一份事实记录

Tue, 07 Jul 2026 00:00:00 +0000

一份复盘在它的说法能被重新检查时才赢得信任。记录每项观察的来源、采集时间与时区、命令或查询，以及适用时的退出状态。日志、指标与明确注明来源的人工观察也属于证据；把已确认事实与假设分开，保存脱敏后的证据，不要保存秘密。下面的四个阶段让任何写下来的复盘在日后都可复核。

每个阶段都要连接真实证据。修复后的采样成功仍是有范围的观察；原因、不确定项和有负责人的预防动作仍需明确记录。

检测：症状，而且要带证据

从最小的可验证症状与展示它的命令开始。保存真实采集结果。以下只是格式示例，并不代表刚刚执行过探测：

$ check-http-headers.sh https://www.xbcatm.com/
HTTP/2 200
content-security-policy: ... script-src 'none' ...
last-modified: Mon, 24 Aug 2026 11:20:54 GMT

如果症状是某个响应头变了，那么展示旧策略与新策略的输出应并排放在一起。如果是失败，请包含退出状态与错误行。

界定范围：影响多广，以及你如何知道

用证据而不是形容词陈述影响范围。先界定能够检视的边界：

哪些主机与路径出现症状？记录每次探测的 URL 与观察时间；一次成功请求不能代表所有边缘或访问者的状态。
缓存与源站是否不同？使用相同请求头，比较两条路径的实际响应、缓存元数据与验证器。Vary 描述选择输入，不能证明响应来自缓存。
什么因素拖延恢复？DNS 变更需记录旧 TTL 与解析器观察结果；HTTP 缓存需另记新鲜度与重新验证策略。DNS TTL 不是通用的回滚期限。

修复：变更及其预期效果

记录实际配置差异与部署标识，让修复动作可理解，并在安全时可重放。下面的响应头片段是预期观察结果，不是 shell 命令，也不是完整策略。优先选择恢复契约的最小变更，并说明修复后运行应显示什么：

Content-Security-Policy: script-src 'none'

验证：事后运行

变更后重复检测命令，并演示观察到的输出现在与预期契约一致。没有最后这一节的复盘只是一个故事；有了它，它就是一份允许自己未来被再检查的记录。

最后记录促成事故的因素、仍不确定的事项，以及带负责人、到期日和验收检查的预防动作。一次探测成功只确认该时刻的采样路径；它本身不能确定原因，也不能防止复发。

来源

RFC 9110 — HTTP Semantics，响应元数据与条件请求，已核验 2026-07-07。
制品 HTTP 响应头检查，贯穿本记录使用的只读检查。
Google SRE: Postmortem Culture，影响、促成因素、证据复核与预防动作，已核验 2026-10-15。
RFC 9111 — HTTP Caching，缓存选择与新鲜度不同于 DNS 缓存寿命，已核验 2026-10-15。

发布一个静态站点并证明边缘一致

Tue, 11 Aug 2026 00:00:00 +0000

一次发布，只有在所需公共边缘检查与选定产物一致时才算完成，而不是上传退出码为零就完成。本教程串起构建、校验、发布与验证，同时区分本地检查和部署变更。发布会改变服务器；结尾的探针才是只读网络观察。

命令假定使用 Bash、GNU find/sort/sha256sum、rsync、Python 3 与项目固定版本的 Hugo。构建步骤从仓库根运行。接触线上主机前，先在一次性目录演练目录切换示例。明确实际服务根、部署负责人、上一版目标与回滚过程。下面的 /srv 布局要求部署已配置完成，不是仓库会自动安装的东西。

指针切换改变失败边界：之前停止可保留旧版，之后需要显式回滚并重验。磁盘检查与边缘样本证明不同事实。

1. 从已记录输入构建一份产物

从干净源码版本开始，运行项目构建并记录已安装生成器版本：

set -eu
git status --short
git rev-parse HEAD
hugo version
make build

短状态为空可支持干净工作树的判断，但命令本身不会强制执行。在称其为某个提交的发布前，应检查所有变更。make build 将短提交号和当前 UTC 构建时间写入 data/buildinfo.toml，再生成 public/。页面中的标记说明记录了哪些输入，不能证明有未提交修改的工作树只含那个提交。

固定 Hugo 与 vendored 主题可减少漂移，但构建时间字段使不同时间的普通构建不一定逐字节相同。应构建选定发布一次、验证后传输这份准确产物，而不是在服务器另行重建。

2. 检查完整离线契约

make check 检查当前产物的生成视觉资源、离线包新鲜度、内部链接、无脚本输出、来源链接及下载校验和。完整仓库关卡则使用：

set -eu
make verify
make check-upstream

完整关卡还运行回归测试、双语文章检查和审阅清单新鲜度校验，再重新构建并检查输出。因此要在最后一次构建后才生成发布清单。构建成功及审阅记录未过期，不能证明每篇文章技术正确，也不证明公共服务器使用了预期头部。页数与耗时会变化，应保留实际输出，不与文章里复制来的计数作比较。

3. 用清单标识产物字节

计算哈希前，确认 public/ 只包含目录与常规文件，并停止所有写入，直到暂存完成。下面的命令不会创建快照，也不会检查每种特殊文件类型。清单放在 public/ 外，避免把自身纳入哈希。NUL 分隔文件名可保留空格及其他 shell 敏感字符：

set -euo pipefail
manifest="$(pwd)/release.sha256"
(
 cd public
 find . -type f -print0 | LC_ALL=C sort -z | xargs -0 sha256sum
) > "$manifest"
(cd public && sha256sum -c "$manifest")
sha256sum "$manifest"

GNU 校验行的摘要在文件名前。sha256sum -c 成功说明已列出的文件匹配，不证明没有额外文件。全新的空发布目录可避免目标端残留旧文件，但不能发现计算哈希后在源端新增的额外文件。要证明常规文件清单完整一致，应按相同路径、排序与哈希规则重算暂存清单，在选择指针前比较完整列表。另行检查符号链接：find -type f 不包含它们，而意外链接可能暴露预期根外的文件。将清单及其自身摘要留在发布记录中；校验和证明相对于清单的一致性，不能证明不可信清单的真实性。

4. 暂存并选择完整发布

假定 Caddy 已服务 /srv/www/example-site/current，它是指向 releases/ 内部的符号链接，所有权与读取权限正确。releases 父目录须事先存在。发布者必须串行执行，并选择唯一发布 ID。把此块作为独立 Bash 脚本，在部署机器上包含已验证 public/ 与 release.sha256 的目录中运行。运行前按部署策略检查产物的所有权与读取权限。此块自行设置清单路径和遇错停止策略；前置条件、复制或校验和失败时，必须在选择指针前停止。它拒绝暂存产物内的符号链接；这是会修改部署的步骤。

set -euo pipefail
base=/srv/www/example-site
manifest="$(pwd)/release.sha256"
test -f "$manifest"
test -d public
release_id=20261015T120000Z
release="$base/releases/$release_id"
test -L "$base/current"
previous=$(readlink "$base/current")
mkdir "$release" # Fail if this release already exists.
rsync -a public/ "$release/"
(cd "$release" && sha256sum -c "$manifest")
links=$(find "$release" -type l -print -quit)
if [ -n "$links" ]; then
 echo "Refusing symlinks in the staged artifact" >&2
 exit 1
fi
# Ownership and readable permissions must match the deployment policy.
python3 - "$base" "$release_id" <<'PYTHON'
from pathlib import Path
import os, sys, uuid
base = Path(sys.argv[1])
release = base / "releases" / sys.argv[2]
current = base / "current"
if not current.is_symlink() or not release.is_dir():
 raise SystemExit("Expected current symlink and a complete release directory")
pending = base / (".current-" + uuid.uuid4().hex)
pending.symlink_to(os.path.relpath(release, base), target_is_directory=True)
os.replace(pending, current)
print("selected:", os.readlink(current))
PYTHON
printf 'Previous target: %s\n' "$previous"

临时链接与 current 共用父目录，因此替换通过同文件系统的一次 rename 完成。普通 mv new existing-directory 不会交换两个非空目录。不要用此片段转换已有的真实目录服务根，应单独规划迁移。在预发布环境验证真实服务器的根解析及文件系统行为。

旧目标仍在磁盘上，不等于切换后旧资源 URL 仍可访问。应在新服务命名空间或稳定资源库中保留旧版指纹资源字节。浏览器多个请求可能跨越两个发布，缓存也可能持有旧 HTML。原子命名空间替换不是跨请求快照隔离，也不是断电持久性保证。

5. 验证实际交付字节与策略

切换后，用固定表示选择比较公共响应样本与相应产物文件：

set -euo pipefail
url=https://www.xbcatm.com/
status=$(curl -sS --max-time 20 -H 'Accept-Encoding: identity' \
 -D served.headers -o served.html -w '%{http_code}' "$url")
test "$status" = 200
cmp public/index.html served.html
sh public/downloads/check-http-headers.sh "$url"

从暂存时使用的同一产物目录运行此块。头部辅助脚本使用该可信产物内的副本；此步骤无需源码工作树。cmp 成功证明这个首页样本逐字节匹配。遇到意外重定向、返回 200 的代理错误页、CDN 转换或编码响应时，需要调查。检查 served.headers 中的 Content-Encoding、缓存年龄、CSP 与内容类型。头部脚本打印响应及最终状态，不会强制所有预期条件。

对中文内容、嵌套文章、CSS、SVG、下载项、重定向及错误路由重复适用检查。记录 URL 到文件的映射，包括目录索引。示例的逐项校验只证明所列文件的一致性，不证明暂存清单完整，也不证明所有公共缓存节点的交付结果。完整边缘论断需要更广泛抓取和表示感知检查；少数探针始终只是样本。

切换后的检查失败时，新版仍被选中，直到你采取行动。用新临时链接指向已记录的 previous 值，再次原子替换 current，随后重做探针。不要只移走新树，诊断期间也不要删除证据或上一版。

6. 分别检查 TLS 身份和到期窗口

从仓库根运行到期辅助脚本：

sh static/downloads/check-tls-expiry.sh www.xbcatm.com 30

它提取证书、打印日期、检查剩余到期间隔，却不是完整 TLS 身份测试：当前实现没有让主机名或信任验证失败成为致命错误。应按照公共边缘信任教程执行显式验证握手与 SAN 检查。不能从“至少还有 30 天有效期”推断信任链或吊销检查成功。

临近过期是另一项发布风险。保留实际 notAfter、信任结果与客户端环境，不要把历史签发者或日期复制到发布日志。

7. DNS 变化时纳入缓存窗口

纯内容发布不一定改变 DNS。若主机或边缘变化，应在缓存过期期间继续维护旧目标服务。变更时才降低 TTL，不会缩短已经按旧 TTL 缓存的条目。解析器 serve-stale、负缓存和客户端缓存会让窗口更复杂；TTL 不是保证所有客户端都完成迁移的统一截止点。CAA 变化影响签发策略，不负责把流量路由到新内容。

8. 保留演练过的恢复路径

上一版目录有利于快速回滚，但不是独立备份。磁盘故障、误清理或部署账户被攻破，都可能影响所有本地发布。应保留源码、构建输入、配置及适当的独立产物备份，并在隔离环境演练恢复。一次成功演练证明的是那个时刻的那条恢复路径，不会永久保证之后的变更。

9. 精确记录结果

保留源码版本与干净工作树状态、构建元数据和工具版本、清单摘要、选中与上一版目标、探针时间、HTTP/TLS 观察及任何回滚。说明覆盖的是样本、全部映射 URL，还是多个观测点。关卡失败时，应记录失败与恢复过程，而不是“它工作过”。

切换前失败可以让旧版保持不变；切换后恢复则是需要单独验证的显式操作。区分这两点，才能让发布路径可审计，而不假装每次失败都会自动恢复旧树。

来源

rsync 手册，归档复制与源路径尾斜线语义，已核验 2026-10-15。
RFC 8767：Serving Stale Data，TTL 过期后的 DNS serve-stale 行为，已核验 2026-10-15。
GNU sha256sum 手册，Debian 软件包，校验和输出及验证选项，已核验 2026-10-15。
Python os.replace，原子替换与文件系统限制，已核验 2026-10-15。
Caddy file_server，根与符号链接处理，已核验 2026-10-15。
curl 手册，状态捕获、响应头及内容解码，已核验 2026-10-15。
OpenSSL s_client，显式证书验证，已核验 2026-10-15。
Reproducible Builds：定义，产物身份与可复现性的区别，已核验 2026-10-15。