一个接口，前后搞了三天。 第一天卡在报错里出不来。晚上画图到深夜，第二天完善对改代码，第三天进行总结和梳理。 回头一看，我卡住的不是代码，是“不知道数据怎么走”。
一、三天时间线
| 天数 | 在做什么 | 卡在哪 |
|---|---|---|
| 第1天 | 写 POST /users，调不通 | 报错看不懂，不知道数据到哪一步断了 |
| 第2天 | 画数据流图，拆输入/处理/输出 | 脑子里没东西，只能比着代码画 |
| 第3天 | 对照数据流改代码，跑通 | 能看图复述整个流程，不卡壳 |
一个接口搞三天，的确慢，但这是我第一次“先画图，再写代码”。
二、核心代码（跑通的最终版）
代码关键点：
- 两个
pool.query是异步串行，第二个必须写在第一个的回调里，否则拿不到insertId result.insertId是mysql2自动返回的，不需要额外指令- 每个错误分支都用
return终止，避免继续执行
三、我画的数据流图（最终版）
GET /users 数据流
关键理解：res.json(results) 是后端行为。后端把数据转成 JSON 字符串发出去，前端收到再解析。这一步没离开后端之前，还是后端的事。
POST /users 数据流
关键理解：
- 两个
pool.query是异步串行，必须第一个执行完拿到insertId，才能执行第二个 result.insertId是mysql2自动返回的，不需要额外指令- 400/500 错误直接返回前端，不继续往下走
这是我第一次画数据流，前前后后修改多次。我知道这张图数据过于冗杂，这也是以后要去优化的点。
四、我踩过的坑
| 坑 | 原因 | 解决 | |
|---|---|---|---|
| 漏括号 | 没把 pool.query 当成异步嵌套 | 理解第二个查询必须放在第一个的回调里 | |
insertId 不知道从哪来 | 不知道 mysql2 会自动返回 | 查文档 + 问 AI | |
| Postman 改不了 Body | 编辑器状态卡死 | 重开窗口或切 Raw 模式 | |
res.json 算前端还是后端 | 混淆了“数据转换”和“数据渲染” | 后端转 JSON，前端解析 |
五、数据流个人理解不一定准确
以前我看代码，是“一行一行看的”，只确保理解这一行就可以。
我把他抽象成“看山是山”，也就是敲代码第一阶段。
现在我看代码，是“一段一段看的”——这一段是接收请求，这一段是处理数据，这一段是返回响应。
可以近似理解成“看山不是山”阶段。
这种感觉，就像从“看字”变成了“看句子”。
数据流是骨架，代码是血肉。没有骨架，血肉就支撑不起来。
六、总结
数据流学校不教，视频不讲，只能自己从报错里悟。
薄薄的两张图搞两天，第三天来汇总。
但当图纸敲定，代码跑动，仿佛真的看到流动的数据。
这一刻就觉得。这三天没有白费。
