16 · 理解必要的 Web 概念与开发工具

本页为文字教程；视频与配套媒体仍以实际发布状态为准。

返回课程总览 · 返回模块

本课交付：一份请求地图与可复现故障记录

这一课不要求记住全部 Web 术语，而要求你能够解释示范工具的一次操作：用户填写产品事实，浏览器提交，服务器处理，结果回到页面。你将使用自行创作的样例，记录真实请求，而不是把 AI 给出的架构图当成程序现状。

准备一个测试页面与一个经过确认的代码基线。若目前只有原型，先用本地固定结果完成练习，并标记没有接入真实模型。不要为了学习网络面板直接操作未知的生产账户、用户资料或正式支付。

跟做一：找到页面由哪些资源组成

打开浏览器开发者工具的 Network 面板，刷新测试页。观察第一份文档，以及随后加载的样式、脚本、字体和图片。为每一类记录用途、来源域名、响应状态和大致大小，不需要复制所有响应内容。使用可公开测试页时，这张图能帮助你理解为什么“网站打开了”并不等于每一项资源都正确。

MDN 的 HTTP 概述将网页取得过程描述为客户端发出请求、服务器返回响应。Overview of HTTP | MDN 因此，资源可能来自不同服务，页面也可能在初始 HTML 之后继续请求数据。你要能够指出正文是在第一份文档里，还是通过接口加载，而不是仅凭框架名称猜测。

跟做二：追踪一次生成操作

填写自创的产品事实并提交，在网络面板里找到新请求。记录路径、方法、请求字段名称、状态码与响应结构；不要把令牌、Cookie 或完整用户文本放进公开作业。再记录界面在请求之前、等待时和返回后发生什么变化。

Chrome DevTools 的网络检查文档提供 Headers、Response、Initiator 与 Timing 等视图。Inspect network activity | Chrome DevTools 实际练习中，你可以用 Initiator 确认谁发起请求，用 Timing 看时间花在哪里，用 Response 判断返回的是预期 JSON 还是错误 HTML。不要把网络等待直接归因于模型慢，也可能是前端根本没发出请求或打到了错误地址。

跟做三：建立最小术语对照

用自己的话解释 HTML 负责内容结构，CSS 负责表现，JavaScript 可以处理交互，API 是服务之间交换数据的契约，数据库保存需要持久化的状态。再在请求地图上指出它们实际出现的位置。术语可以简化，但不要把前端本地变量叫作数据库，也不要把一张静态页面描述成完整后端。

示范站的模型密钥不属于浏览器资源。若你能在页面脚本或网络请求里看到服务端秘密，先停止使用那种设计，改为受控服务端调用。课堂记录只写“所需变量名及服务端用途”，不抄录实际值。这个边界会在后续接入中继续使用。

跟做四：制造一个可解释的失败

在测试环境暂时让接口不可用，或使用浏览器离线模拟，观察用户输入、按钮、错误提示和请求状态。记录能否恢复，而不是只写“失败了”。随后恢复环境，重新执行同一输入，确认系统回到正常路径。模拟故障不能替代真实上游验证，但能帮助检查自己的状态处理。

还可以清空测试页缓存再加载，与有缓存的访问比较。网络面板提供首次访问模拟与资源细节查看方式。Inspect network activity | Chrome DevTools 要明确这是受控实验，不能把本机一次加载时间当作所有地区与设备的体验。截图可以说明现象，文字步骤则让别人有机会复现。

跟做五：用版本控制保留基线

GitHub 的 Git 文档说明版本控制记录修改与历史。About Git | GitHub Docs 在练习中先检查现有差异，保存一个可运行状态，再修改一处明确行为，例如更清楚的错误提示。查看修改前后的差异，确认没有顺便变更账户、费用或部署配置。

你不必马上掌握复杂协作，但要知道当前代码对应哪个版本、哪一部分是尚未完成的工作，以及如何保留而不覆盖它。代码恢复与数据库恢复不同：Git 能帮助恢复代码，不能自动找回从未备份的用户记录。将这两个概念在笔记中分开。

加练：识别“返回成功”中的假线索

在受控测试中准备一个错误路由，让它返回网站首页而非预期 JSON。网络面板可能显示成功状态，但响应类型与内容已经不符合契约。你要记录请求实际地址、响应类型与正文开头，再指出错误可能发生在路由、代理或构建回退配置，而不是模型输出。

不要把完整请求导出文件直接公开，其中可能包含会话与用户输入。作业只保留必要字段和自行构造的材料。若需要与他人协作排查，先在本地检查并脱敏，再分享最小复现。

最后把这个反例加入术语笔记：HTTP 成功说明某次响应成功返回，不自动说明业务任务正确完成。以后面对 AI 的“接口已经二百”报告，你就知道还应继续问返回了什么、对应哪条任务。

独立作业：写一份 AI 能继续排查的报告

选择本课的一次失败，提交环境、操作步骤、期望、实际、请求路径与状态、相关错误类别，以及你已经排除的原因。最后写出下一条想验证的假设，不要求 AI 一次重写全站。若你不知道原因，就明确说不知道，准确的未知比编造结论更有用。

同时提交资源地图和一次代码差异说明。验收人应该能够据此判断请求走到了哪一层，哪些是固定演示、哪些是真实服务，以及需要到哪里继续查证。本课通过的标志是你能找到事实，不是你背出了多少技术名词。