完成第一次前后端联调
前后端联调要沿一条请求追踪：用户动作产生请求，服务端处理并返回，前端再更新状态。每一段都能单独观察。
- 从页面新增一条任务，能用同一请求的信息串起前端、Network、后端日志和最终界面。
- fetch、序列化、跨域与环境地址
- 实现完成第一次前后端联调后，应当从页面新增一条任务，能用同一请求的信息串起前端、Network、后端日志和最终界面，并保留状态码、响应结构、进程输出和前后端同一次请求作为可重复检查的依据。
- 完成 5.4「输入校验、错误处理与接口契约」
FOUNDATION
必须理解
前后端联调是让界面从本地假数据转向真实接口。核心不是写一行 fetch，而是处理加载、成功、空数据、校验失败和网络失败的完整状态。
本课依次讲清fetch、序列化、跨域与环境地址、加载、成功、空结果、失败和重试状态和请求日志与浏览器 Network 的对应关系，最后通过“分别断网和提交空标题，显示不同且可恢复的错误”检查学习结果。
柜台提交申请后，会出现排队、受理成功、材料不足、系统故障等状态。界面要把当前阶段告诉用户，而不是按钮按下后沉默。
任务页面加载时请求 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 负责根据真实材料解释fetch、序列化、跨域与环境地址并指出遗漏，学习者负责控制范围、执行修改和核对状态码、响应结构、进程输出和前后端同一次请求。
推荐协作顺序
- 1
先把已经验证过的接口契约交给 AI。
- 2
让它列出页面在等待、成功和失败时分别显示什么。
- 3
接入后用 Network 的真实请求对照契约，不让 AI 根据代码猜运行结果。
以下是前端代码、Network 请求、服务端日志和接口契约。请按时间顺序对齐同一次操作，先定位最早偏离预期的层级，再给一个最小修复。不要同时改前后端多个假设。
用户在每个阶段都能理解发生了什么，代码根据 status 和错误结构处理，不把所有失败都显示为“出错了”；完成第一次前后端联调的人工验收必须回到真实页面、请求、终端、测试或数据结果，不能用 AI 的文字说明代替。
人工检查清单
- 确认请求地址、方法和 JSON 字段与契约一致，Network 中实际响应被检查。
- 让 AI 同时引用真实 Network 详情、接口契约和对应服务端日志，不能只猜某一端。
- 按加载、成功、空结果、校验失败、断网和重复点击逐一操作，确认界面状态可观察。
COMMON TRAPS
常见误区
下面三类问题会让任务看似完成，却经不起刷新、错误输入或真实环境检查。先看现象，再找原因和修正方法。
前后端一起大改
- 你会看到
- 问题消失或新增都无法归因
- 为什么发生
- 两端同时变化会失去稳定参照，出现结果差异时无法判断责任边界。
- 怎样纠正
- 一次固定一端和一个假设
只看页面提示
- 你会看到
- 实际状态码和正文被忽略
- 为什么发生
- 页面可能二次加工甚至吞掉错误，原始响应和服务端日志才保留完整线索。
- 怎样纠正
- 同时保留 Network 与后端日志
重复提交请求
- 你会看到
- 快速点击生成多条任务
- 为什么发生
- 按钮未锁定或接口不防重时，每次点击都会产生一笔独立写入。
- 怎样纠正
- 加载期间限制动作并在服务端考虑幂等
HANDS-ON
动手任务
从页面新增一条任务，能用同一请求的信息串起前端、Network、后端日志和最终界面。
- 完成 5.4「输入校验、错误处理与接口契约」
跟着做
- 01
单独验证 GET 与 POST 接口。
- 02
页面首次加载 GET，并显示加载与空状态。
- 03
表单提交 POST，设置 submitting 并禁用按钮。
- 04
成功后更新列表并清空输入。
- 05
分别断网和提交空标题，显示不同且可恢复的错误。
从页面新增一条任务，能用同一请求的信息串起前端、Network、后端日志和最终界面。
模拟服务器延迟两秒，检查加载反馈和重复提交保护是否仍有效。
离开本课前，自问四件事
- fetch、JSON 序列化与 CORS 分别处在请求链路哪一部分？
- 加载、空结果和失败为什么必须是三个不同界面状态？
- 创建请求重试时需要考虑什么风险？
- 如何用 Network 与服务端日志定位一次联调失败？
确认完成后，会同步更新学习中心的课程学习进度。