HTTP 请求实验室：用一个清晰页面看懂请求方式、地址与响应反馈
开场：这是一个什么样的页面
打开页面，首先看到的是"HTTP 请求实验室"这个标题。标题下方是一组并排的请求方式按钮，当前选中的是 GET，旁边还有 POST。再往下是"请求地址"区域，里面有一个可以编辑的地址输入框，以及一个发送按钮。选择 POST 后，地址输入框下方还会出现一个带有 JSON 示例提示的输入框。页面底部则是深色的"响应体"区域和请求次数提示。
这个页面没有试图做成完整的网络调试工具，也没有连接服务器、读取天气数据或发起真实 HTTP 请求。它把一次请求交互中最容易被忽略的几件事放到同一屏幕上：请求方式是什么、请求地址是什么、用户什么时候点击发送、页面如何显示返回值、连续点击了多少次。所有结果都由页面本身根据当前输入和当前次数即时组织出来，因此它更适合用来观察请求表单与响应展示之间的关系。
初始状态非常克制。GET 按钮使用深色背景，表示它是当前方式；POST 按钮使用浅灰色背景，表示它没有被选中。地址框中已经有一条示例路径，响应体区域显示"等待发送请求"，请求次数为零。用户不用先猜测页面是否加载成功，因为标题、默认方式、默认地址、等待文字和零次计数一起构成了明确的初始状态。
一、先从页面上的四个状态理解交互
页面的变化围绕四个互相配合的状态展开。第一项是请求方式，它只有 GET 和 POST 两个选择。第二项是请求地址，初始内容是一条天气接口风格的路径，用户可以把它替换成其他文字。第三项是响应文本，页面刚打开时是等待提示，发送之后会变成包含状态码、地址和次数的多行文本。第四项是请求次数，初始为零，每点一次发送按钮就增加一次。
这四项状态并不等价。请求方式和地址负责描述"准备发送什么"；响应文本负责描述"发送之后页面显示什么"；请求次数则负责保留操作发生过多少次。点击 GET 或 POST 时，只改变方式，不会自动改变地址、响应文字和次数。编辑地址时，只改变地址，不会自动产生响应。只有点击发送按钮，次数和响应文本才会同时变化。这种分工让操作结果容易预测，也避免了输入一个字符就突然刷新响应区域的问题。
可以把页面看成一张很小的请求状态卡片。方式是卡片的选择条件，地址是卡片的输入内容，发送是明确的提交动作，响应是提交后得到的演示结果，次数是操作历史的简化统计。虽然页面很小，但每个控件都能在这条关系中找到位置，没有出现与请求过程无关的菜单、日志列表或复杂配置项。
1. 请求方式的默认值
页面进入时默认选择 GET。GET 按钮的背景色是深灰色，文字为白色；POST 按钮使用浅灰色背景和深色文字。这里的颜色不是装饰，而是方式选择的可见反馈。用户不需要先点击一次才能确认当前方式，进入页面后就能知道接下来发送按钮会显示"发送 GET 请求"。
点击 POST 后，页面会把当前方式切换成 POST，并在请求地址输入框下方显示一个额外输入框。这个输入框的提示内容是一个城市字段 JSON 示例，作用是让页面看起来符合 POST 请求通常需要填写请求数据的场景。切回 GET 后，这个额外输入框消失，页面又回到只有地址输入框的状态。
这里有一个容易误解的细节：POST 输入框在页面上出现了，但当前交互没有把它保存到响应文本中。用户在其中输入城市名称不会改变响应里的 path，也不会出现在后续的 200 OK 文本中。它是一个可见的请求体提示入口，而不是已经接入业务处理的完整请求体模型。理解这个页面时必须把这两层含义分开，不能因为出现了 JSON 提示，就说页面已经解析并提交了 JSON 数据。
2. 地址输入的默认值
地址框的初始内容是 /api/weather/today。它没有被锁定，用户可以点击输入框、删除原内容，再输入任意地址文字。地址一改变，后续响应中 path 后面的内容也会跟着改变。也就是说，地址框不是仅用于展示的装饰，它确实参与了响应文本的组织。
地址输入和发送动作之间有清晰的时间关系。用户可以先切换方式，再编辑地址，最后一次点击发送；也可以先改地址，再来回切换方式。只要没有点击发送，响应区域都保持上一次结果，页面不会因为输入过程而伪造一条新响应。这一点让用户能够观察"准备阶段"和"提交阶段"的差别。
地址框也没有提供格式校验、域名校验、协议校验或空值提示。输入空字符串后点击发送，演示响应仍会按照当前地址拼接出 path 字段。输入一段普通文字也不会弹出错误。原因不是页面忽略了地址，而是它的目标是展示状态如何进入响应，而不是验证一个网络地址是否可访问。因此不能把这个页面描述为 URL 检测器。
3. 响应文本的初始状态
刚打开页面时，响应区域标题是"响应体"，深色内容框里只有"等待发送请求"。这句话很重要，它告诉用户当前还没有发生发送动作。页面没有在启动时直接显示 200 OK，也没有虚构一条已经完成的请求记录。
响应区域使用深色背景、浅色文字和等宽字体。这样的处理让多行返回文本看起来接近调试窗口，也让状态码、path、request 和 message 这些字段更容易被逐行辨认。响应卡片本身仍然保持白色外层与圆角边界，因此它既像一个页面模块，又保留了返回数据区域的视觉特征。
4. 请求次数的初始状态
底部提示一开始显示请求次数为零，并附带"模拟握手、传输与 JSON 解析"的说明。这个短句已经明确告知页面是模拟演示。点击发送一次后，次数变成一；再次点击，不论当前方式是 GET 还是 POST，都会继续增加。次数没有按方式分成两列，也没有保存每一次历史地址，只保留一个累计数字。
因此，计数器的含义是发送按钮被触发的总次数，而不是网络成功次数、服务端访问次数或响应数量。因为页面没有网络连接，所以"次数"只能代表当前页面内发生了多少次模拟发送操作。
二、从上到下阅读页面布局
页面整体采用从上到下的单列结构。最外层背景是浅灰色，内容区域左右留有边距，多个白色卡片按照固定间隔排列。这样安排的好处是，用户可以沿着一个自然的阅读顺序完成操作：先看标题，再选方式，再填地址，点发送，最后看响应和次数。
顶部标题卡片使用深灰蓝背景，白色大字号标题和圆角边界构成最醒目的区域。标题没有附加额外标签或来源说明，只把页面目的直接告诉用户。标题卡片下面是方式切换行，两个按钮等分宽度，按钮之间留出小间距。由于它们是并列选择，等宽布局比一个很长的下拉菜单更直观。
请求输入卡片使用白色背景和较大的内边距。卡片先显示"请求地址"文字，再显示地址输入框，必要时显示 POST 的 JSON 提示输入框，最后显示发送按钮。这个顺序符合实际操作心理：先确认要使用的地址，再补充 POST 场景下的输入，最后提交。发送按钮占据整行，深色背景和白色文字让它与上面的输入项形成明显的动作区分。
响应卡片同样使用白色外层，但其中的响应内容使用深色内框。标题"响应体"位于内容框上方，说明下面的多行文字是反馈区域，而不是可以继续编辑的输入框。页面底部的次数文字使用较小字号和灰色颜色，说明它是辅助信息，不会抢走响应内容的注意力。
从截图可以看到，操作前后的视觉重点没有改变：标题始终在顶部，方式按钮始终可用，地址仍然可以修改，响应框负责显示结果。变化集中在三个地方：选中的方式颜色发生变化，响应文字从等待提示变成 200 OK，多次操作后底部数字发生变化。这种局部变化让用户能迅速定位操作带来的影响。
三、GET 与 POST 的切换应该怎样理解
GET 和 POST 在这个页面里首先是两个可选择的页面模式。点击 GET，页面只保留地址输入框，发送按钮文字为"发送 GET 请求"；点击 POST，页面显示额外的请求体提示输入框，发送按钮文字变成"发送 POST 请求"。按钮文案会跟随方式变化，因此用户在点击发送前仍然可以再次确认当前模式。
方式按钮的颜色通过当前选择决定。选中项深色、未选中项浅色，两个按钮不会同时显示为选中。用户在 GET 和 POST 之间连续切换时，可以观察 POST 输入框随方式出现和消失；响应体不会因为切换而清空或重置；请求次数也不会因为切换而增加。只有发送才是会计入次数的动作。
这种设计把"选择请求方式"和"发出请求"分成两个步骤。很多表单问题来自用户刚切换选项，页面就立刻执行操作；这里没有这种隐式行为。用户可以先选择 POST，阅读出现的请求体提示，再决定是否发送；如果发现方式不合适，也可以切回 GET，不会留下额外的计数。
需要注意的是，页面没有展示 GET 与 POST 真正的协议差异。它没有建立请求头、没有设置查询参数、没有发送请求体，也没有接收服务端返回的状态码。200 OK 是点击后的固定演示文本，方式主要影响按钮状态、POST 输入框的显示以及发送按钮上的文字。因此，学习这个页面时，重点是观察 UI 状态切换和响应文案组织，不应把它当作网络库用法的完整示例。
四、地址、响应和次数之间的关系
三者之间的关系是页面最值得观察的部分。地址是响应内容的输入来源，次数是每次发送动作的累计结果，响应则把这两项信息组合成一段可读的多行文本。发送一次时，响应包含 200 OK、当前地址、当前请求序号以及"响应解析成功"这句固定消息。
假设地址仍然是默认路径，第一次点击 GET 发送按钮后，响应区域会显示状态码行、path 行、request 为 1 的行和成功消息。此时底部请求次数也是 1。接着把地址改成 /api/weather/detail，再点击一次，第二次响应中的 path 会变成新地址，request 会变成 2，底部计数也变成 2。页面没有保存第一条响应，所以新结果会覆盖旧结果，但计数不会回到零。
如果在第二次发送前切换为 POST，响应的 path 仍然取自地址框，request 继续按照总次数递增。也就是说，计数不区分 GET 和 POST。用户可以先发两次 GET，再发一次 POST，最后看到请求次数为 3。响应中只显示最近一次的地址和序号，不显示前两次的方式或地址。
这种覆盖式反馈适合做一个简单实验：每次只看最新结果，同时使用数字确认动作确实发生过多次。它不适合做请求历史分析，因为页面没有列表、时间戳、失败记录或按方式统计。页面的可见结果应该准确理解在这个范围内，不能从一个累计数字推导出网络日志系统。
五、点击发送时页面发生了什么
点击发送按钮后，页面先把请求次数加一，再按照当前地址和新的次数拼接响应文本。由于响应文本包含换行符，深色响应框会分成多行显示。第一行是 200 OK，接着是一个对象形式的内容，里面有 path、request 和 message 三个字段。
用户可以从这个动作观察到两个状态同时变化：响应框更新，次数文字更新。发送按钮本身的颜色不需要变化，也没有加载动画、禁用状态或进度条。页面不会等待一段时间后才显示结果，因此它给人的感觉是点击后立即完成模拟操作。
若连续快速点击发送按钮，每次点击都会被计算，数字连续增加。页面没有防抖，也没有"正在请求"阶段。即使选择了 POST 而没有填写 JSON 示例内容，点击依然会增加次数并产生 200 OK 文本，因为当前结果组织没有读取那个额外输入框。
这个现象可以帮助理解当前页面的边界。按钮确实有事件，次数确实发生变化，响应确实更新，但这些变化全部属于本地状态转换。没有网络异常、超时、重试、取消或服务器错误分支。看到 200 OK 只能说明模拟发送动作完成了，不能说明任何远端地址可访问。
六、POST 输入框为什么出现又为什么不影响结果
选择 POST 后出现的第二个输入框是页面中最容易被过度解读的地方。它带有类似 { "city": "深圳" } 的提示内容，用户可以看到 POST 请求通常可能需要携带一段 JSON 数据。这个提示让页面比单纯的地址表单更贴近请求调试的视觉想象。
但是，从实际交互来看，输入框没有参与响应内容的生成。用户在里面输入城市、删除城市或完全不填写，都不会改变 200 OK、path、request 和 message 这几部分文字。点击 GET 后该输入框隐藏，再切回 POST，它会重新出现提示状态；页面没有显示此前输入过的内容，也没有把它放进次数统计或响应对象。
因此，介绍这个输入框时需要使用准确的说法：它是 POST 模式下的请求体演示输入，不是已经生效的请求体提交功能。页面把"请求方式发生变化"展示出来了，把"请求体如何被读取、校验和发送"留在了未实现范围内。这样既能说明用户看得到什么，也不会把占位输入误写成真实接口能力。
七、响应区域的阅读方式
响应区域是页面的结果中心。它使用等宽字体，让不同字段在视觉上更容易分行比较；深色背景与浅色文字形成类似控制台的效果，和上方的白色输入卡片区分开。响应内容并不是可以编辑的输入框，用户只能阅读最新结果。
第一行 200 OK 是固定的成功演示状态。path 后面紧跟当前地址，所以它能帮助用户确认地址框的修改是否进入了这次模拟结果。request 后面是当前发送序号，可以帮助用户把响应和底部累计次数对应起来。message 行则提供一条固定的成功说明，让结果看起来像完成了响应解析。
响应内容的结构并不随着 GET 或 POST 改变。切换方式会影响按钮和 POST 输入框，但不会让响应自动更新；发送之后，GET 和 POST 都会得到同样结构的 200 OK 文本。这个细节告诉我们，方式选择当前主要作用在交互展示层，并没有被进一步用于构造不同的模拟数据。
如果用户只修改地址而不点击发送，响应仍然是上一次结果。此时地址框和 path 可能暂时不一致，这是正常现象，因为地址框表示待发送内容，响应框表示上一次发送结果。再次点击发送后，两者才会重新对应。这种"编辑状态"和"结果状态"暂时不同步的情况，在真实表单中也很常见。
八、页面中的反馈是否足够明确
对这个小页面来说，反馈主要来自四处。第一处是方式按钮的选中颜色；第二处是发送按钮文字中的 GET 或 POST；第三处是响应框里的 200 OK、地址和次数；第四处是底部累计数字。四处反馈互相补充，用户能够确认选择、提交和结果三个阶段。
但页面没有错误反馈，这也符合它的实际范围。地址为空不会显示错误；JSON 输入不完整不会显示错误；网络不可用也不会显示错误，因为页面没有连接网络。不能把缺少错误提示理解为遗漏了完整的异常体系，它只是说明当前演示把注意力集中在成功路径和状态变化上。
如果从初学者角度观察，最有价值的反馈是请求次数。只看响应文本时，连续两次操作可能看起来一样；看到 request 从 1 变成 2，再结合底部数字变化，就能确认每一次点击都被页面记录。对于测试状态绑定来说，这比添加一堆无关弹窗更容易理解。
九、为什么这个页面不等于真实 HTTP 客户端
页面标题和按钮文字使用了 HTTP 术语，但它没有调用网络请求接口。发送时做的是本地字符串拼接：使用当前地址和当前次数填入固定的响应格式，然后把结果显示在响应框中。200 OK、响应解析成功、模拟握手、传输与 JSON 解析都是演示用文字。
页面没有服务器地址配置，没有网络权限申请，没有请求头，没有真实请求体，也没有返回数据解析过程。它无法告诉用户远程服务是否存在，无法验证路径是否正确，也无法证明某个城市天气是否返回。看到"响应解析成功"只说明页面把演示字符串放进了响应框。
这个边界并不会削弱页面的学习价值。恰恰因为没有异步网络细节，用户可以先把方式、地址、按钮事件、响应展示和计数状态看清楚，再决定是否需要引入真正的网络能力。把这两种层次混在一起，反而容易让学习者误以为改变文字就等同于完成了一次请求。
十、适合怎样的交互练习
第一次打开时，可以先不做任何修改，直接点击发送 GET 请求。观察等待文字如何变成 200 OK，底部次数如何从零变成一。然后只修改地址，不点击发送，确认响应保持旧内容；再次点击发送，确认 path 更新且 request 继续递增。
接着点击 POST，观察第二个输入框出现，发送按钮文字变化。可以在 JSON 提示框中输入任意内容，再点击发送，确认响应结构仍只包含固定的 path、request 和 message。这一步特别适合验证一个控件是否真正参与数据流：它可见、可输入，但当前结果没有读取它。
最后来回切换 GET 和 POST，分别发送几次，确认切换本身不增加请求次数，只有发送动作增加次数。整个过程不需要服务器，也不需要准备复杂数据，只通过页面上的几个控件就能把状态变化完整走一遍。
十一、从页面行为总结 ArkUI 状态驱动
这个页面的结构很简单，但清楚地展示了声明式 UI 的思路。页面不是在点击后手动找到某个标签再修改文字，而是让方式、地址、响应和次数成为页面状态；按钮和输入框改变状态，依赖这些状态的文字、颜色和条件区域随之更新。
方式按钮是否深色取决于当前方式；POST 输入框是否存在取决于当前方式；发送按钮的文字取决于当前方式；地址框内容取决于当前地址；响应内容取决于发送后生成的响应状态；底部次数取决于累计数字。每一处变化都有明确的状态来源，页面不需要额外维护一套"当前显示是什么"的副本。
输入框的变化行为把用户正在编辑的地址及时写回地址状态，但这并不触发响应生成。按钮的点击行为负责切换方式或发送请求，发送动作才同时改变次数和响应。事件职责被分开后，页面行为更容易预测，也更容易通过一次次操作观察。
十二、使用过程中容易产生的误会
第一个误会是把 200 OK 当成服务器返回。页面没有网络调用，所以它不是远端响应。第二个误会是认为 POST 输入框的内容会进入 JSON。当前页面没有这样处理。第三个误会是把请求次数当成成功请求数。这里它代表点击发送的次数。第四个误会是认为修改地址后响应会立即改变。响应只在发送动作发生时更新。
还有一个视觉上的误会：深色响应框很像终端或调试控制台，但它只是普通文本展示区域。它没有滚动日志、复制按钮、展开折叠或错误标记。方式按钮也很像真实网络工具中的方法选择器，但它只负责页面模式切换。把视觉隐喻和实际能力分开，才能准确理解这个应用。
十三、可以如何判断一次操作是否完成
一次完整的页面操作可以用四个问题判断。第一，当前方式是否是自己想要的 GET 或 POST；第二，地址框是否显示了准备使用的地址；第三，点击发送后响应框是否出现 200 OK、path、request 和成功消息；第四，底部请求次数是否增加了一次。如果选择 POST，还可以额外观察请求体提示输入框是否出现。
这四个问题只针对页面可见行为，不要求网络条件，也不要求真实接口。它们能够覆盖当前应用已经实现的全部核心反馈。若地址为空、POST 输入未填写或连续重复点击，页面仍然会按本地规则显示结果，用户可以据此理解当前没有输入校验和失败分支。
十四、页面结构中的取舍
页面没有把请求方式、地址、请求体、响应头、响应体和历史记录全部塞进来，而是只保留方式、地址、一个 POST 提示输入、发送按钮和响应文本。这样的取舍让一屏内容保持紧凑，初学者也不容易被大量概念淹没。
响应只保留最近一次结果，换来更简单的阅读路径；次数只保留一个数字，换来更清晰的累计反馈；GET 和 POST 只保留两个选项，换来明确的选择状态。每项信息都与当前页面演示直接相关，没有为了看起来完整而添加未使用的配置项。
同时，页面也故意留下清晰的边界：没有真实网络、没有输入校验、没有异常分支、没有历史列表、没有按方法统计。边界本身也是页面设计的一部分。用户知道页面在演示什么，也知道哪些能力还不能从当前结果中推断出来。
结语：把一次模拟请求看成一条可读的状态链
这个 HTTP 请求实验室页面用很少的控件表现了一条完整而易读的状态链：选择 GET 或 POST，编辑请求地址，必要时查看 POST 的 JSON 提示，点击发送，响应区域展示固定格式的 200 OK 结果，底部累计数字记录发送次数。每个动作都有对应的可见变化，但这些变化都发生在页面内部。
它最适合用来理解请求表单和响应反馈的 UI 组织方式，理解输入状态、选择状态、结果状态和统计状态如何共同构成一个小型交互。它不承担真实网络通信，也不提供服务端数据。只要把这个边界说清楚，页面就能作为一个很好的 ArkUI 状态驱动练习：内容少而明确，操作路径短而完整，反馈足够直接。
十五、一次完整操作的细节观察
可以按照页面上的自然顺序观察一次完整操作。第一步不要触碰任何输入，直接查看默认方式、默认地址和等待提示。此时页面表达的是"还没有发送"的准备状态，按钮可以点击，响应区域还没有结果，底部数字为零。第二步点击地址框，在默认地址末尾增加一段文字。输入过程中，响应区域应该保持原来的等待提示，不能因为正在输入就提前出现成功消息。
第三步点击 POST。此时方式按钮的深色选中效果移动到 POST，发送按钮中的方式名称也跟着变化，下面出现请求体提示框。这个变化只说明页面进入了 POST 展示模式，并不说明已经发送。第四步在提示框中输入一段内容，再观察响应区域是否变化。按照当前页面的实际行为，响应区域不会变化，次数也不会变化，因为这两个变化都只由发送按钮负责。
第五步点击发送 POST 请求。此时请求次数增加，响应区域覆盖为最新的 200 OK 文本，path 使用地址框里最后确认的文字，request 使用增加后的数字。第六步切换回 GET，页面隐藏请求体提示框，但刚刚显示的响应和累计次数不会被清空。通过这六步，可以把选择、编辑、输入和发送这几个阶段区分开，不会把"控件出现"误认为"请求已经发生"。
十六、不同地址输入下的结果变化
地址框是这个页面中最直接的可变输入。保留默认路径时，响应中的 path 也保持默认路径；把它改成 /api/user/profile，响应中的 path 就会变成新的文字；输入带有查询符号的字符串，页面也会原样放入 path 字段。页面没有对字符进行拆分、编码或格式化，所以用户看到的结果最容易和自己的输入对应。
如果输入框被清空，点击发送后仍然会产生一条 200 OK 结果，只是 path 后面没有有效地址文字。这个行为说明页面没有空地址校验，也没有"请输入地址"的提示。它不是在判断地址是否合理，而是在演示当前值如何进入一个响应模板。输入中文、数字或普通说明文字时，页面也按同样规则显示。
修改地址后不立即发送，响应仍然保留上一次的 path。此时页面同时存在两个时间点的内容：地址框是下一次准备使用的内容，响应体是上一次提交的内容。只有点击发送，最新地址才会出现在响应中。这种差异可以帮助理解表单输入与结果展示为什么不应该绑定成同一个即时变化。
十七、连续发送和覆盖式响应
连续发送是观察 count 状态最简单的方式。第一次发送后，底部显示请求次数为 1，响应中的 request 也是 1。再次点击发送，底部变成 2，响应中的 request 也变成 2。无论两次之间是否改变地址，只要发送按钮被点击，数字就增加。用户不需要重新加载页面，页面也不会自动把数字限制在某个固定范围内。
响应采用覆盖式显示。第二次结果出现后，第一次的 path 不再显示，响应框只保留当前一次的 200 OK、最新 path、最新 request 和固定消息。这样做让页面保持简洁，用户总能把视线放在最后一次操作上；代价是无法在页面上回看之前使用过的地址，也无法比较两次结果的内容。
如果用户先发送 GET，再切换 POST 发送，最终的计数是两次，响应只显示第二次的地址和序号。页面不会给每种方式单独计数，也没有 GET 成功次数和 POST 成功次数的分栏。方式是当前选择，count 是总发送次数，这两个概念始终保持分开。
十八、颜色、字体与信息层级
标题的深灰蓝背景把页面目的固定在视觉起点，白色大字让"HTTP 请求实验室"成为第一阅读目标。方式按钮通过深色与浅灰的差异表达当前选择，未选择项不会消失，仍然保持可点击状态。输入卡片使用白底和圆角，和浅灰背景形成边界，帮助用户识别可以操作的区域。
响应框使用接近黑色的背景和浅色文字，与输入区形成明显对比。等宽字体让 200 OK、path、request、message 这些不同长度的文本看起来更接近结构化返回内容。它没有使用彩色错误标记，也没有把每个字段做成独立卡片，因此阅读焦点集中在最新的多行结果。
底部次数文字字号更小、颜色更淡，属于解释和统计信息。它除了显示数量，还附带模拟握手、传输与 JSON 解析的提示。这句说明是页面能力边界的重要组成部分：视觉上它可能像网络工具的状态栏，但文字已经告诉用户这些过程只是模拟。把这句提示和 200 OK 放在同一页面，能减少用户把演示结果当成远端返回的可能。
十九、为什么发送按钮要带上当前方式
按钮文字不是永远固定的"发送请求"，而是随着方式显示"发送 GET 请求"或"发送 POST 请求"。这样做有两个作用。第一，用户点击前就能确认当前提交的是哪种页面模式；第二，切换方式后，按钮文字的即时变化会成为选择已经生效的第二重证据。
如果按钮只显示"发送请求"，用户必须回头看上面的方式按钮；如果方式按钮和发送按钮颜色都没有变化，切换之后就容易产生不确定感。当前页面同时改变选中颜色、POST 输入框的可见性和发送按钮文案，三个局部反馈指向同一个 method 状态，因此行为很容易理解。
按钮本身没有加载文字，也没有在点击后变成"请求中"。这是因为页面没有异步等待过程。点击后直接增加 count 并生成响应，因而按钮不需要进入处理中状态。这个细节也再次说明它是本地模拟，而不是需要等待网络返回的请求流程。
二十、输入框在页面中的不同职责
地址输入框和 POST 提示输入框虽然都是文本输入控件，但职责并不一样。地址输入框的内容会进入下一次响应的 path，因此它连接了用户输入和结果展示。POST 提示输入框目前只用于展示一种可能的请求体形式，它的内容不进入响应，也不会改变 count。
两个输入框的可见性也不同。地址框始终存在，说明无论 GET 还是 POST，页面都需要一个地址概念；POST 输入框只在选择 POST 时存在，说明它是方式相关的附加区域。切换 GET 时，附加区域消失，页面保留地址和发送按钮，核心操作路径仍然完整。
在输入过程中，两个框都不会触发发送。用户可以停下来修改内容，也可以在填写后切换方式。只有发送按钮把当前准备状态转换成结果状态。这种职责划分能防止输入事件被误当成提交事件，也使页面交互更适合逐步观察。
二十一、页面实际覆盖和没有覆盖的情况
当前页面覆盖了方法选择、地址编辑、条件显示、按钮动作、响应文本更新和次数累计。它还覆盖了输入与结果暂时不同步、GET 与 POST 共用次数、POST 输入不进入响应等容易被忽略的细节。这些都是用户可以通过当前页面直接观察到的行为。
页面没有覆盖服务器地址连接、真实状态码、请求头、请求体序列化、响应 JSON 解析、超时、重试、取消、网络断开和历史记录。它也没有根据不同地址返回不同业务数据，默认天气路径只是初始文字，不代表页面真正查询天气。任何超出这些可见行为的推断都不应被当作当前页面已经提供的能力。
清楚列出这些边界并不是给页面增加无关内容，而是帮助读者正确理解结果。一个 200 OK 文本可以是服务端返回，也可以是本地演示。当前页面底部已经使用"模拟"二字，响应又采用固定格式，因此结合这两处信息就能确认后者。
二十二、适合初学者的阅读顺序
初学者可以先只观察 method：点击 GET 和 POST，确认颜色、按钮文字和附加输入框如何变化。再观察 url：编辑地址但不发送，确认响应保持不变；发送后，确认 path 使用最新地址。接着观察 response：等待提示如何被最新结果覆盖。最后观察 count：切换方式不增加次数，点击发送才增加次数。
按照这个顺序，每一次只关注一个状态，不容易把多个变化混在一起。等四项状态都能解释之后，再回头观察它们的组合，例如选择 POST、修改地址、填写提示、发送一次，最后检查四处反馈是否符合预期。页面很小，正适合通过重复的短操作建立状态驱动界面的直觉。
如果遇到"输入了 POST 内容但响应不变"的情况，不应该立即认为页面失效。先确认当前页面行为：POST 输入框是可见的，但响应模板只读取地址和次数。只要发送后 count 增加、path 使用地址、200 OK 出现，就说明当前模拟流程按设计完成。这个判断比根据控件外观猜测数据是否被使用更可靠。
二十三、把页面当作一张交互说明图
页面的布局和行为可以合在一起看成一张交互说明图。标题告诉用户主题；两个方式按钮告诉用户有两种模式；地址标签和输入框告诉用户可以准备目标文字；POST 下方的提示告诉用户该模式可能带有数据；发送按钮告诉用户何时触发结果；响应框告诉用户结果出现在哪里；底部文字告诉用户操作次数以及模拟范围。
这张图没有隐藏步骤。用户不需要打开另一个页面查看历史，也不需要等待状态栏变化，更不需要根据颜色之外的图标猜测发送是否成功。每个可见区域都对应一个具体状态或动作，页面的可读性来自这种直接关系，而不是来自复杂功能。
因此，理解这个页面的重点不在于记住一套网络术语，而在于观察"哪个动作改变了哪个显示"。方式改变选择反馈，地址改变下一次响应的内容，发送改变响应和计数，POST 模式改变附加输入框。只要把这四条关系说清楚，就已经准确覆盖了当前应用。
二十四、结尾：从可见行为开始理解请求页面
HTTP 请求实验室把一个常见的请求界面压缩成一条短而清楚的操作链。用户可以选择 GET 或 POST，编辑地址，在 POST 模式下看到 JSON 提示，点击带有当前方式的发送按钮，然后在深色响应区域查看 200 OK、path、request 和固定成功消息，同时在底部看到累计次数。
它的价值在于可见行为稳定、状态关系明确，而且主动把模拟边界写在页面上。它没有连接网络，却能展示请求表单如何组织；没有服务端，却能展示响应文本如何更新；没有历史列表，却能用 count 表示重复操作。只要不把演示文字误认为真实通信，这个小页面就能帮助读者建立对方式选择、输入状态、提交动作和结果展示的清晰认识。