DNS

1 为何需要名字，DNS 回答什么问题

在 S15 中，IP 地址帮助我们表达目的主机；在 S17 中，端口进一步表达主机上的服务入口。但使用者通常输入 https://app.example/，不会先记住 198.51.100.20:443。名字给人提供稳定的入口，也给运维提供调整空间：服务器从旧地址迁到新地址时，可以修改名字关联的数据，减少逐个修改客户端配置的工作。名字与地址分离，并不意味着名字会自动跟随服务器变化；这份关联仍然需要有人维护。

DNS，即域名系统，回答的是“这个名字对应什么数据”。查询里既有名字，也有记录类型。询问 app.example 的 A 记录，是询问它对应的 IPv4 地址；询问同名的 NS 记录，问题就变成了由哪些名字服务器负责相关区域。因此，把 DNS 简化成名字到地址的表格，适合入门，却不足以解释别名、区域委派以及后面的排查结果。

以访问应用为例，可以先取得 app.example → 198.51.100.20，再向 198.51.100.20 的 TCP 443 端口建立连接，随后进行 TLS 与 HTTP 交互。这些阶段各有自己的证据。DNS 返回正确地址，只证明名字查询取得了预期数据；它不能证明目标端口正在监听，更不能证明页面、登录或数据库健康。反过来，浏览器打不开网页，也不能直接证明 DNS 出错。

延续 S13 的排查习惯，先把结论限制在观察范围内。dig 得到地址，说明这次 DNS 查询有答案；TCP 连接成功，说明该次连接建立；HTTP 返回 503，说明请求已经到达某个能返回 HTTP 的节点，但服务暂时不可用。把这些观察串起来，才能定位故障所在的阶段。本文使用的 .example 名字和示例地址用于讲解；实际练习应替换为自己管理的测试域名和服务器。

2 查询与应答：一次解析里有哪些角色

应用通常不自己从互联网根部逐级查询。它调用系统提供的解析接口，由本机的存根解析器，也称 stub resolver，向配置好的递归解析器发问。存根的工作重点是提出问题并接收结果；递归解析器则负责利用缓存或继续查询，把结果交回客户端。家庭路由器、企业 DNS 服务或公共 DNS 服务都可能承担递归解析器的角色，本机也可能先经过一个转发服务。

权威服务器负责发布某个区域的 DNS 数据。例如，负责 example. 区域的权威服务器可以发布区域里的 app.example. A 记录。递归解析器提供查询服务，权威服务器提供所负责区域的数据，这是职责上的区别；同一套软件可以具备不同能力，但排查时仍应分清本次请求使用了哪种职责。问递归解析器得到的答案可能来自缓存，问正确的权威服务器才是在直接检查发布端。

DNS 报文有查询标识 ID，帮助请求方把应答与尚未完成的查询对应起来。例如，查询 ID 为 18432，应答带回同样的 ID；客户端还需要结合通信端点和问题等信息检查匹配关系。ID 不是服务器地址，也不是记录的版本号。报文的 QUESTION 部分描述问题，如 app.example. IN A；ANSWER 部分放入回答问题的数据，状态码则说明本次查询的处理结果。

常见查询路径使用 UDP 53 端口，答案较大或出现截断等情况时可能改用 TCP 53，因此不能只允许 UDP 就认定 DNS 通信条件完整。这里沿用 S17 的边界：53 是服务器接收 DNS 服务的端口，客户端通常使用临时端口发送请求；DNS 报文中的 ID 又是另一个层面的对应信息，不能把它和传输层端口混为一谈。

观察动画时，先看请求在谁手中，再看数据来自哪里。假设递归解析器已经缓存 198.51.100.20，它可以直接回答，权威服务器此次不会收到查询。若缓存没有可用答案，它才继续查找。浏览器刷新 5 次不等于权威服务器被查询 5 次；缓存正是 DNS 能够承受大量重复请求的重要原因。

3 常用记录类型：A、AAAA、CNAME、NS

A 记录保存 IPv4 地址。本课的交付目标可以写成 app.example. 300 IN A 198.51.100.20：名字是 app.example.，TTL 是 300 秒，类别为互联网常用的 IN，类型是 A，值是 198.51.100.20。末尾的点表示从 DNS 根开始的完整名字，工具输出经常保留它。A 记录的值不包含 https://、路径或 :443，这些属于访问协议和应用入口的其他部分。

同名可以发布多个 A 记录，例如同时返回 198.51.100.20 与 198.51.100.21。这表示存在多个候选地址，并不自动保证每个地址健康，也不保证客户端按固定顺序使用它们。验收时若只检查答案里“出现过正确地址”，可能漏掉另一个仍指向旧服务器的地址；应比较实际返回的完整地址集合。

AAAA 记录保存 IPv6 地址，例如 app.example. 300 IN AAAA 2001:db8::20；本课后续只围绕 IPv4 的 A 记录推演，实际有 AAAA 时也应检查其地址是否可用。

CNAME 记录把一个名字声明为另一个名字的别名，例如 www.example. 300 IN CNAME app.example.。它的值是名字，不是 IPv4 地址。查询 www.example 的 A 记录时，需要沿着别名找到 app.example，再取得最终的 A 数据。CNAME 也不是网页跳转：浏览器中的网址不会因此自动从 www.example 改成 app.example，服务器仍需能处理原访问名字。

NS 记录说明一个区域由哪些名字服务器提供权威服务，例如 example. 3600 IN NS ns1.example.。NS 的值同样是名字；要联系该服务器，还需要取得其地址。不要把“递归解析器配置为某个 IP”和“区域的 NS 记录指向某个名字”当成同一种配置：前者选择客户端向谁提问，后者描述区域由谁负责。MX 记录用于指示邮件接收服务器，本课不展开。

app.example.  300  IN  A      198.51.100.20
www.example.  300  IN  CNAME  app.example.
example.     3600  IN  NS     ns1.example.

这 3 行不是访问顺序，而是不同的问题与数据。应用访问 www.example 时可能用到 CNAME 和 A；递归解析器寻找权威来源时可能用到 NS。另一个需要提前避免的配置错误是让普通 CNAME 名字同时拥有其他业务记录。通常 CNAME 所在名字不能再并列 A 等记录；区域顶点又必须具有区域自身的数据，因此不能随意把顶点改成普通 CNAME。

4 递归与权威：解析器怎样找到答案

假设缓存为空，递归解析器要回答 app.example 的 A 查询。它首先需要知道从哪里开始寻找。根提示提供联系根服务器的启动信息，管理员无需靠背诵根服务器 IP 来理解过程。根服务器通常不会直接给出应用地址，而是告诉查询方下一段命名空间应向谁询问。这个“给出下一站”的回答称为转介。

为理解真实域名的层次，可以把路径想成根、顶级域、具体区域的权威服务器。递归解析器先向根询问，再按转介询问顶级域服务器，接着向被委派区域的权威服务器查询，最终取得 A 记录。这里的 .example 是保留的演示后缀；文中的权威链是教学假设，不能期待在公共 DNS 上为这些演示名字得到真实部署的完整路径。

“递归”描述客户端希望所询问的服务器代为完成查找；“迭代”描述解析器逐站询问并根据转介继续的过程。不是每个收到查询的服务器都替客户端跑完全部路径。权威服务器可以只回答自己负责的数据，或返回区域委派信息。一次客户端请求背后可能有多次服务器间查询，也可能因为缓存而完全跳过前面几个层级。

若某个区域声明 ns1.example 是自身的名字服务器，而寻找 ns1.example 的地址又需要先访问这个区域，就可能形成启动上的循环。父区域在委派信息附近提供必要的地址线索，称为胶水记录，帮助解析器先联系到被委派服务器。这里记住它解决“先联系谁”的问题即可；胶水是联系线索，不能据此把所有附带地址都当作最终业务 A 记录。

判断“谁对 example. 权威”，要关注区域边界与委派。父区域的委派 NS 指向哪些服务器，这些服务器是否实际提供该区域，两边应当一致。直接向服务器查询时，带有 AA 标志的回答表示该服务器以权威身份回答相应数据；它仍不代表数据已经符合业务预期。权威服务器完全可能权威地返回一个填错的地址，配置正确性需要另外验收。

区域边界不一定与名字中的每个点重合。假设 example. 的管理员把 lab.example. 委派给另一个团队，父区域保留这处委派，api.lab.example. 的 A 则由子区域发布。此后递归解析器问到父区域时，会得到指向子区域服务器的转介，再向子区域取得地址。仅在父区域文件中添加同名 A，不能替代子区域的发布；查询已经沿委派转向别处。排查“记录明明存在却查不到”时，应先确认它存在于实际负责该名字的区域，而不是只按名字后缀寻找某个管理页面。

委派还可能指向一台能收到 DNS 请求、却没有加载目标区域的服务器。例如父区域列出 ns1.lab.example. 和 ns2.lab.example.，前者返回带 AA 的正确 A，后者却拒绝查询或不给出该区域的权威答案。不同解析器选择服务器和重试的过程不同，用户可能表现为偶发失败或解析变慢。增加 NS 数量并不会自动复制区域数据；应逐台直接查询同一个完整名字，比较权威标志、状态码和完整地址集合。某台能回答其他区域，也不能证明它已经承担本区域的职责。

胶水地址过期则是另一类断点。假设 ns1.lab.example. 已迁到新 IP，子区域内它的 A 已更新，父区域附带的胶水却仍指向旧 IP。已有可用缓存的解析器可能继续成功，重新寻找入口的解析器却可能联系旧地址而超时。此时反复修改 api.lab.example. 的 A 无法修复入口。需要分别核对父区域提供的胶水与子区域发布的服务器地址，并在迁移期间安排新旧入口的兼容窗口。业务记录 TTL、委派 NS 的 TTL 和胶水 TTL 是不同数据的寿命，不能用业务 A 的 300 秒推算整条委派链何时恢复。

5 TTL 与缓存：为什么改记录不会立刻处处生效

TTL 是缓存可以保留某组记录的时间上限，以秒计。假设旧 A 为 203.0.113.9，TTL 为 300 秒。解析器甲在 T0 前 120 秒取得旧答案，到 T0 修改权威记录时，它的缓存还剩 300 − 120 = 180 秒。只要它继续按这份有效缓存回答，用户在 T0 后 100 秒仍看到旧地址，就是符合这个时间模型的现象。

解析器乙恰好在 T0 前很短的时间取得旧答案，它可能几乎再保留 300 秒；解析器丙在 T0 后首次查询且权威发布已经一致，便可能直接取得新地址。于是同一时刻，甲、乙、丙给不同用户的回答可以不同。所谓“等 TTL”，不是要求所有用户在某个时刻同时切换，而是等待此前取到旧数据的有效缓存逐步到期。

再算一个具体时刻。假设 T0 是 10:00:00，旧 TTL 是 300 秒，某解析器在 09:59:50 缓存旧值。它到 10:04:50 才达到这份缓存的到期点；在 10:02:00 查询时，还可能显示约 170 秒的剩余 TTL。dig 输出中的 TTL 常常是缓存剩余时间，因此看到 170 并不意味着管理员把记录配置成了 170。过期后重新查询能否成功，还依赖解析器与权威服务器之间的通信。

滑块使用明确受限的教学模型：所有权威副本在 T0 同步完成；旧答案的 TTL 相同；各级正常缓存遵守剩余 TTL，转发时不把它重置为完整寿命；没有额外的应用缓存或过期数据服务。若旧 TTL 为 τ，则 T0 后 τ 秒是旧缓存不再有效的等待上界。它表示“等待旧缓存自然到期所需的窗口”，不承诺所有客户端此时已经主动查询，更不能保证真实互联网的全局可见性。

计划切换时，把 TTL 从 3600 改为 300 并立刻更换地址，不能消除已经存活的 3600 秒缓存。更稳妥的时间安排是提前降低 TTL，并留足原 TTL 的等待时间，再在计划窗口改 A。例如 09:00 降低 TTL，原值为 3600 秒，则在模型成立时，10:00 后再改 A，旧长寿命缓存才有机会自然退出。

没有答案也可能被短期缓存，这称为负缓存，其期限依据相应否定回答中的区域信息确定，不应直接套用业务 A 的 300 秒。刚补建一个此前不存在的名字，有些查询方仍可能暂时看到 NXDOMAIN。遇到差异时，先记下查询服务器、状态码、答案和剩余 TTL；清空所有缓存会破坏现场，也无法替别人清除缓存，因此不应作为第 1 个修复动作。

6 看本机：dig、getent 与系统解析路径

dig app.example A +short 适合快速查看答案中的简短数据。单个 A 记录可能只输出 198.51.100.20；如果存在别名，也可能先显示目标名字再显示地址。简短输出为空却不能直接判定 NXDOMAIN，因为查询成功但没有该类型数据、查询失败等情况都需要完整报文来区分。正式排查应保存带状态码和各部分内容的结果。

dig app.example A +short
dig app.example A
dig @192.0.2.53 app.example A +norecurse
getent hosts app.example

第 3 条命令显式选择 192.0.2.53，并关闭请求中的递归期望。+norecurse 的意思不是强制绕过缓存：递归解析器仍可能返回已有缓存，也可能返回转介、拒绝或没有最终答案。要直接核对发布数据，应把 @ 后面的地址替换为已确认的权威服务器地址，并检查权威标志。示例中的地址只是占位，不能直接当作可用的公共解析服务。

系统应用不一定走与 dig 相同的数据来源。以常见 Linux 系统为例，getent hosts app.example 经由系统名称服务配置查询主机信息，具体顺序受 /etc/nsswitch.conf 的 hosts 项及已启用模块影响。若顺序包含 files dns，通常先检查 /etc/hosts，找到可用结果后可能不再向 DNS 查询。其他系统或应用还可能使用各自的解析服务和缓存。

# 情境 1：dig 从所选 DNS 取得的简短结果
198.51.100.20

# 情境 2：本机 hosts 中仍有旧映射时，getent 的可能结果
203.0.113.9    app.example

这 2 个输出可以同时成立。它们证明的是不同查询路径上的数据，不足以相互否定。dig 通常直接询问 DNS 服务器，不把 /etc/hosts 当作业务答案来源；getent 用于观察系统名称服务路径。对本课只使用 A 的环境，也可以补充 getent ahostsv4 app.example，明确查看系统给出的 IPv4 结果；其输出可能按不同套接字类型重复列出地址。

排查记录应写明“在主机 client-1，向解析器 R 查询，得到什么”，避免只写“DNS 正常”。如果浏览器启用了独立的加密 DNS 或保留了自己的缓存，它的结果还可能与系统不同。先明确被测应用实际采用的路径，再选择能覆盖这条路径的命令，才能解释为何命令行成功而应用仍失败。

7 常见坑：hosts 覆盖、缓存未过期、CNAME 链与“改了不生效”

本机曾为测试加入 203.0.113.9 app.example，测试结束后忘记删除，是常见的局部故障。在名称服务配置优先使用文件且命中该项时，这条 hosts 映射会覆盖后续 DNS 查询机会。此时修改权威 A 记录 3 次也不会改变本机结果。应先比较 getent 与 dig，再检查本机覆盖项的来源与用途，确认后只修正相关条目。

另一个常见误判是把缓存剩余时间当作发布失败。若权威已经返回新地址，而递归解析器仍返回旧地址且 TTL 从 240 逐渐下降到 180，证据更符合旧缓存仍有效。若间隔 60 秒后 TTL 反而不断回到接近 300，就需要继续检查是否仍有某个权威副本提供旧值、查询是否落到不同缓存实例，或是否存在额外缓存策略，不能只重复等待。

CNAME 链增加了需要核对的名字。假设 www.example → app.example → edge.vendor.example，最后才由 A 返回 198.51.100.20。前 2 段别名都正确，不代表最终地址正确；外部目标若不存在，别名入口也不能凭空得到可用地址。每段记录有自己的 TTL，改动第 1 段不会主动清除后面名字已经存在的缓存。设计时尽量让链条短且责任清楚，排查时记录每段指向。

循环别名也无法得出最终 A。例如 a.example 指向 b.example，而后者又指回前者；解析器通常会终止并报告失败，具体呈现取决于实现。多加一个别名不是修复措施，应恢复能够到达最终地址的关系。在不同网络看到不同答案时，还要考虑分区解析或视图：同一个名字可以按查询来源返回不同结果，验收必须注明所在网络。

“控制台显示保存成功”只证明一次配置操作被接受。接下来还要确认改的是正确区域和完整名字、权威副本是否一致、递归缓存是否到期、本机是否有覆盖，以及应用是否使用预期解析路径。逐层保存证据，比看到旧地址就连续改记录更有效；连续改动还会制造多个版本，让别人难以判断应该等待哪份旧数据消失。

8 案例：为 app.example 设计可交付的解析记录

现在把需求收束成一次可交付变更：应用服务位于 198.51.100.20，用户通过 app.example 访问，同时允许使用 www.example。交付 A 记录给主入口，给 www 设置指向主入口的 CNAME，2 项 TTL 都为 300 秒。这样未来更换主入口地址时，通常只需修改主入口 A；别名仍沿同一个名字找到地址。

这张表必须与区域上下文一起交付。若管理界面已经选中 example. 区域，名称栏可能要求填 app；若界面要求完整名字，则应填 app.example.。不了解界面规则而重复拼接，可能误建成 app.example.example。提交后查询完整名字，比只检查界面中的短标签更可靠。还应记录该区域由哪些权威服务器服务，便于发布端核对。

验收分成数据与访问 2 部分。先向权威服务器确认 A 和 CNAME 的值及配置 TTL，再从 2 个指定递归解析器查询并保存结果。递归答案 TTL 可以小于 300；验收重点是最终地址正确、别名方向正确、没有多余旧 A。随后从实际用户所在网络访问服务，检查 TCP 443 与 HTTPS。若服务没有配置 www.example 对应的证书和应用入口，CNAME 正确也不能代替这些配置。

假设 10:00 改动前的 TTL 已是 300，10:01 时解析器甲返回新地址，乙返回旧地址且剩余 210 秒。交付记录应写出乙的预期等待范围，并在到期后复查，不能把这次部分成功直接写成全部通过。保留旧服务到计划的兼容窗口结束，也有助于处理仍持有旧地址的用户；具体保留多久要结合实际缓存和业务风险安排。

9 排查案例：NXDOMAIN、SERVFAIL 与错误 A 记录

共同症状是浏览器打不开 https://app.example/。先在出现问题的客户端保存完整 DNS 查询结果，注明时间、查询名字和所用解析器。下面 3 条路径是独立情境，输出为教学示例；状态码与 ANSWER 要一起读。只复制最后一个地址，或者只记录“打不开”，都会丢失区分故障所需的信息。

路径 A：dig 返回 NXDOMAIN。它表达查询名字不存在的否定结果，应先核对拼写、查询是否落到预期 DNS 视图、区域是否正确建立及委派。若是在私有网络使用的名字，公共解析器的否定回答也不能直接证明私有区域缺失。仅由 NXDOMAIN 不能得出“网络断了”，也不应先去调整目标应用的 TCP 443。

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18432
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1
;; QUESTION SECTION:
;app.example.                  IN A
;; ANSWER SECTION:  （本例为空）

若状态为 NOERROR 但 A 的 ANSWER 为空，可能是名字存在而没有所问类型的数据，不能直接归入 NXDOMAIN。NXDOMAIN 本身也是一个收到的 DNS 应答；完全收不到响应、命令超时，是不同的证据。修复缺失名字之后，还要把负缓存纳入复查计划，避免用一次立即重试就否定修复结果。

路径 B：应答成功，却返回错误地址。服务明明部署在 198.51.100.20，DNS 却给出 203.0.113.9，此时 DNS 协议查询可以成功，业务数据仍然错误。应核对权威记录并修正错误值；若权威已经正确，则继续追踪缓存与本机覆盖。成功状态码不能代替“答案是否符合交付表”的比较。

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18433
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0
;; QUESTION SECTION:
;app.example.                  IN A
;; ANSWER SECTION:
app.example.          240      IN A    203.0.113.9

可以用下面的对照请求，临时让这次访问连接预期地址，同时保留 URL 中的主机名，让 TLS 和 HTTP 仍按 app.example 访问。它只影响这次命令，不是修改 DNS；执行环境需要目标服务可达，并具有匹配证书。

curl -v --connect-timeout 5 https://app.example/
curl -v --connect-timeout 5 --resolve app.example:443:198.51.100.20 https://app.example/

若普通请求连接旧地址失败，而对照请求得到预期 HTTP 响应，就支持“当前名字解析路径把访问引向错误地址”的判断。若对照也超时，还应检查到正确地址的路由、防火墙和监听状态；若出现证书错误，则说明还存在 TLS 相关问题。对照实验用于缩小范围，不能把一次成功扩大成所有用户、所有功能都正常。

路径 C：解析器返回 SERVFAIL，表示本次解析未能正常完成。可能涉及解析器自身、上游通信或权威服务异常；单凭这个状态不能断言记录不存在，也不能直接决定要新建一个 A。先对比另一个解析器，再直接检查已知权威服务器，才能逐步缩小故障范围。

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18434
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0
;; QUESTION SECTION:
;app.example.                  IN A
;; ANSWER SECTION:  （本例为空）

对于实际公开委派的域名，可用 dig 真实域名 A +trace 观察逐级查询停在哪段；它由运行命令的主机直接执行查找，依赖该主机能访问相关服务器，不等同于重放原递归解析器的内部过程。演示后缀或私有区域不能直接套用公共追踪。若追踪停在某段超时，它提供了下一步调查位置，还需要结合服务器和网络证据确认原因。

最终记录应能让别人复述因果：NXDOMAIN 优先核对名字与区域；错误 A 优先核对记录值及缓存来源；SERVFAIL 优先检查解析服务与上游过程；答案正确而 TCP 连接失败，再转向传输路径与服务监听。排查不是给每个状态码机械分配唯一原因，而是用状态与答案决定下一次最有区分力的观察。

放进方案里

在部署方案中单独列出 DNS 变更单，写明区域、完整名字、记录类型、旧值、新值、当前 TTL、计划时间和负责人。明确修改发生在区域发布端，还是父区域委派端；本案例只需把 app 的 A 指向 198.51.100.20，并让 www 的 CNAME 指向 app。把管理界面的名称填写规则记下来，避免交接人员把区域后缀重复拼接。附上权威服务器信息，使复核者知道应直接向谁确认发布结果。

变更前保存旧记录和查询证据，确认旧 TTL 是否已经降到 300 秒。若原来是 3600 秒，先降低并留出原缓存到期时间，再安排地址切换。写清旧服务保留窗口、观察时间和回滚条件；例如新地址持续无法通过约定的 HTTPS 检查时恢复旧 A。回滚也受缓存影响，不能承诺点击恢复后所有客户端立即回到旧地址。保留旧服务的安排应与回滚步骤相互配合。

变更后先检查所有指定权威服务器，再从 2 个递归解析器查询，记录查询时间、服务器、状态码、完整 ANSWER 与剩余 TTL。若出现旧值，计算可能的到期时间并预约复查；若答案冲突超过预期窗口，检查权威副本、本机覆盖和实际解析路径。之后验证最终地址上的 TCP 443 与 HTTPS，分别留下结果，使名字交付与应用可用性都有证据支撑。

验收应由第 2 人在约定网络执行。交接材料让其能区分 NXDOMAIN、返回错误 A、以及 A 正确但传输连接失败，并指出各自下一步查哪里。记录出现 SERVFAIL 时使用的对照解析器和权威查询方法。只有对方能够按材料重现查询、解释差异、执行有等待窗口的回滚，方案才具备可交付性；“我这里已经能打开”只能作为其中一条观察。

10 小结：走向 HTTP（S19）

DNS 把名字查询变成具体数据：A 提供 IPv4 地址，CNAME 引出另一个名字，NS 描述区域的权威来源。递归解析器沿委派寻找数据并缓存，TTL 则帮助解释不同查询方为何暂时得到不同答案。排查时把状态码、答案值、查询来源与时间放在一起，才能选择下一步操作。

可以用 3 个问题检查理解：旧 TTL 为 300 秒、在改动前 80 秒取得的缓存还可能存活多久？为什么 dig 正确而 getent 仍可能给出旧地址？为什么 curl --resolve 成功有助于定位错误 A，却不等于修改已经全网生效？答案分别涉及剩余 220 秒、系统名称服务来源，以及单次对照请求的证据边界。S19 将继续沿着已经取得的地址，观察 HTTP 请求与响应如何表达应用层的交互。

下一课转向 S19 HTTP：把本章验收过的结论带进后续主题，写成可检查的方案约束。