完成第一次前后端联调
联调是把用户输入、网络请求、后端处理和界面反馈连成闭环，并处理等待、失败和重复提交。
- 能够沿完整数据流定位联调问题。
- fetch、序列化、跨域与环境地址
- 让一个表单调用自己的 API，并实现禁用重复提交、错误提示和重试。
- 完成 5.4「输入校验、错误处理与接口契约」
FOUNDATION
必须理解
联调是把用户输入、网络请求、后端处理和界面反馈连成闭环，并处理等待、失败和重复提交。
前后端联调是让界面从本地假数据转向真实接口。核心不是写一行 fetch，而是处理加载、成功、空数据、校验失败和网络失败的完整状态。
柜台提交申请后，会出现排队、受理成功、材料不足、系统故障等状态。界面要把当前阶段告诉用户，而不是按钮按下后沉默。
任务页面加载时请求 GET /api/tasks，提交表单时 POST 新任务；按钮在提交中禁用，失败保留输入并显示服务端 message，成功再更新列表。
fetch、序列化、跨域与环境地址
一个请求不只有成功和失败，它还会经历等待、加载，也可能得到空结果。页面如果不把这些状态说清楚，用户很容易重复点击或以为卡住了。
基础概念
fetch 是浏览器发送 HTTP 请求的接口，序列化把内存数据转换成可传输文本，CORS（Cross-Origin Resource Sharing，跨源资源共享）是浏览器对跨源读取的安全控制。
进一步理解
对象经 JSON.stringify 进入请求体，服务端解析后处理，再把 JSON 响应交回前端。内容类型与字段契约必须两端一致。
源由协议、主机和端口共同决定。浏览器跨源调用时，服务端需明确允许来源与方法；同一 Next.js 应用里的相对 API 路径通常同源。
任务表单把 `{title}` 序列化后 POST 到 `/api/tasks`，服务端返回新任务，前端解析并加入列表。
CORS 不是后端权限系统，也不是所有“接口不通”的原因。服务端到服务端请求通常不受浏览器 CORS 限制。
这一小节记住：联调首先要保证地址、协议、格式与字段契约在两端一致。
加载、成功、空结果、失败和重试状态
浏览器和服务器靠约定好的 JSON 连接，字段名、是否可选、日期长什么样都要一致。跨域时还会遇到 CORS，不过同一个 Next.js 应用里的接口通常简单很多。
基础概念
一次界面请求至少会经历空闲、加载、成功、空结果和失败，失败后还可能重试。每种状态都应给用户可理解且不会造成重复操作的反馈。
进一步理解
加载时保留上下文并防止重复提交；成功展示新数据；空结果解释确实没有内容；校验失败保留输入；网络失败允许安全重试。
重试只适合可重复且不会产生额外副作用的操作，或服务端具备幂等保障。创建请求盲目重试可能生成重复记录。
提交任务后按钮显示“正在保存”并禁用；400 时保留标题并显示字段提示；断网时允许用户重试；成功才清空输入。
空数组是一次成功响应，不是错误；加载中也不是空状态。把它们都显示为空白会让用户误解系统卡住。
这一小节记住：把请求生命周期显式呈现，用户才知道现在发生了什么和能做什么。
请求日志与浏览器 Network 的对应关系
乐观更新会先改页面再等服务器，感觉很快，但失败时必须撤回；保守更新等成功后再显示，慢一点却更容易理解。第一版先选你能解释清楚的方案。
基础概念
浏览器 Network 记录客户端实际发出的请求和收到的响应，服务端日志记录请求进入应用后的处理。通过时间、路径和请求 ID 可以把两侧证据对应起来。
进一步理解
Network 可核对 URL、方法、头部、请求体、状态码和响应正文；服务端日志可说明路由是否命中、校验与数据库在哪一步失败。
若 Network 中没有请求，先查前端事件；请求 pending 查网络或服务处理；有 4xx 查契约与身份；有 5xx 再用请求 ID 查服务端异常。
用户点击后 Network 出现 POST 400，响应指出 title 缺失；服务端日志记录同一 requestId 的校验失败，因此无需怀疑数据库。
console 日志与 Network 不是同一证据。前端打印“准备发送”不证明请求真实离开浏览器。
这一小节记住：用两端证据把“接口不通”缩小成明确失败步骤。
AI COLLABORATION
AI 如何参与
让 AI 同时给出前端请求、后端日志和接口契约三份证据，再判断问题属于哪一端。
推荐协作顺序
- 1
先把已经验证过的接口契约交给 AI。
- 2
让它列出页面在等待、成功和失败时分别显示什么。
- 3
接入后用 Network 的真实请求对照契约，不让 AI 根据代码猜运行结果。
请为 Next.js 任务表单设计前后端联调流程。接口为 POST /api/tasks，返回 201 Task 或 400 字段错误。请先列出 idle、submitting、success、validation error、network error 五种 UI，再给最小客户端代码。失败时保留输入，提交中防止重复点击。
用户在每个阶段都能理解发生了什么，代码根据 status 和错误结构处理，不把所有失败都显示为“出错了”。
人工检查清单
- 确认请求地址、方法和 JSON 字段与契约一致，Network 中实际响应被检查。
- 让 AI 同时引用真实 Network 详情、接口契约和对应服务端日志，不能只猜某一端。
- 按加载、成功、空结果、校验失败、断网和重复点击逐一操作，确认界面状态可观察。
COMMON TRAPS
常见误区
错误不是需要隐藏的失败，而是帮助你看清系统边界的证据。下面三类问题在 AI 辅助学习中最常出现。
按钮按下后毫无反馈
- 你会看到
- 请求正在发送，但用户以为没点到而连续提交。
- 为什么发生
- “接口不通”没有地址、状态码和响应，可能覆盖事件未触发、CORS、404、500 等完全不同问题。
- 怎样纠正
- 提交期间显示状态并暂时禁用按钮。
失败后把输入清空
- 你会看到
- 网络中断或校验失败，用户刚写的任务标题丢了。
- 为什么发生
- 请求期间仍允许重复点击会产生并发和重复记录，尤其在网络慢时用户更容易再次操作。
- 怎样纠正
- 只有成功创建后才清空输入，失败时保留内容和明确提示。
前端接口各自猜字段
- 你会看到
- 列表读取 done，表单更新却写 completed。
- 为什么发生
- 成功后立即乐观显示却没有失败回滚，会让页面与服务器真相分离。
- 怎样纠正
- 所有调用围绕同一契约和共享类型，变更时一起更新。
HANDS-ON
动手任务
让一个表单调用自己的 API，并实现禁用重复提交、错误提示和重试。
- 完成 5.4「输入校验、错误处理与接口契约」
跟着做
- 01
单独验证 GET 与 POST 接口。
- 02
页面首次加载 GET，并显示加载与空状态。
- 03
表单提交 POST，设置 submitting 并禁用按钮。
- 04
成功后更新列表并清空输入。
- 05
分别断网和提交空标题，显示不同且可恢复的错误。
能够沿完整数据流定位联调问题。
模拟服务器延迟两秒，检查加载反馈和重复提交保护是否仍有效。
离开本课前，自问四件事
- fetch、JSON 序列化与 CORS 分别处在请求链路哪一部分？
- 加载、空结果和失败为什么必须是三个不同界面状态？
- 创建请求重试时需要考虑什么风险？
- 如何用 Network 与服务端日志定位一次联调失败？
确认完成后，会同步更新学习中心的课程学习进度。