取证：把支撑结论的那几行找出来
场景：光有一个状态码不算证据。 任务：请求 /api/items，看它的响应体（JSON）里的 error_id，再到服务端日志 ~/srv/app.log 里找到带同一个 error_id 的那一行——两边对上了才算证据。到 ~/对照表.
另一个坏掉的接口
场景：同一个服务上 /api/users 也不正常，但它的状态码和 /api/items 不是同一类。 任务：照同样的流程再走一遍——请求 /api/users，拿到状态码、判断它属于哪一边，到 ~/对照表.txt 里查那个状态码对应的标记
修完再验一次
场景：原因已经定位：是 ~/srv/conf.json 里 items_broken 被设成了 true。 任务：把它改掉，重新起服务（再跑一次 bash ~/srv/serve.sh），然后重新请求 /api/items 确认状态码真的变
交付：完整的 HTTP 检查报告
场景：这是这条路线的最终作品。一个全新的服务，故障和前面几题不一样，全程没有分步提示。 任务：独立完成一次检查——现象（/api/items 返回什么）、证据（响应体和 ~/srv/app.log 里的原因）、故障层次、修复（按原因把缺的东
HTTP 明文的风险
同样一段内容，走两条路 明文：谁都看得清 加密：糊成一片看不懂 普通 HTTP 是明文传输的。它最大的安全风险是【0】。
HTTPS 比 HTTP 多了什么
同样一段内容，走两条路 明文：谁都看得清 加密：糊成一片看不懂 比起 HTTP，HTTPS 多出来的是【0】。
加密保护的是什么
HTTPS 的加密，主要保护的是【0】。
中间人对明文能做什么
明文 HTTP 经过的路由、WiFi 等中间环节，能对它【0】。
HTTPS 里的 S 指什么
HTTPS 比 HTTP 末尾多的那个 S，指的是【0】。
明文里这个字段外人看得到吗
按请求模型，https 下 path 字段在链路上还看得到吗？打印 True/False。 贯穿本节的请求模型：status(路径) 交回状态码（/=200、/admin=403、/old=301、其它 404）。visible_on_wi