交付：完整的 HTTP 检查报告

场景：这是这条路线的最终作品。一个全新的服务，故障和前面几题不一样，全程没有分步提示。 任务：独立完成一次检查——现象（/api/items 返回什么）、证据（响应体和 ~/srv/app.log 里

阅读更多 →

修完再验一次

场景：原因已经定位：是 ~/srv/conf.json 里 items_broken 被设成了 true。 任务：把它改掉，重新起服务（再跑一次 bash ~/srv/serve.sh），然后重新请求

阅读更多 →

另一个坏掉的接口

场景：同一个服务上 /api/users 也不正常，但它的状态码和 /api/items 不是同一类。 任务：照同样的流程再走一遍——请求 /api/users，拿到状态码、判断它属于哪一边，到 ~/

阅读更多 →

取证：把支撑结论的那几行找出来

场景：光有一个状态码不算证据。 任务：请求 /api/items，看它的响应体（JSON）里的 error_id，再到服务端日志 ~/srv/app.log 里找到带同一个 error_id 的那一行

阅读更多 →

判层：这是哪一边的问题

场景：状态码已经拿到了。判定口径：4xx 是「请求这边」的问题，5xx 是「服务端」的问题，200 但正文里 ok=false 是「数据本身」的问题。 任务：请求 /api/items 拿到状态码，按

阅读更多 →

先复现：它到底返回什么

场景：有人报「/api/items 这个接口打不开」，但没说是怎么个打不开。 任务：自己请求一次 /api/items，确认它的状态码到底是多少，到 ~/对照表.txt 里查它对应的标记。 （判分只看

阅读更多 →

这个接口返回的是什么格式

查一个响应头，确认对面给的是什么格式： Content-Type 的值是什么？（分号前面那一段就够） $ curl -sI http://localhost:8080/api/user.json |

阅读更多 →

“验证结论”具体指什么

报告里说的"验证结论"，指的是【0】。

阅读更多 →

一份 HTTP 检查报告要有什么

一份能交出去的 HTTP 故障报告，至少要有【0】。

阅读更多 →

交付：指定响应头的当次值

场景：这是本节的验收。本次实验环境在首页 / 的响应头里放了一个现生成的值 X-Token。 任务：把它取出来，到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里做出的真机产物：找东

阅读更多 →