阅读前提：会函数、数组和条件判断。这里解释共同概念，具体语法仍以各模块为准。例子统一使用“创建一条待办”，避免在不同业务故事之间切换。
输入标题 → 前端状态 → HTTP 请求 → 路由 → 参数校验 → 业务处理 → 存储
↓
列表显示 ← 状态更新 ← HTTP 响应 ← 成功结果或明确错误
| 术语 | 通俗解释 | 在待办应用中的作用与边界 |
|---|---|---|
| 客户端 / 服务端 | 发起请求的一方 / 接收并处理的一方 | 手机发送标题，服务端判断是否允许创建；界面禁用按钮不能替代服务端校验 |
| HTTP | 双方约定的请求与响应格式 | 方法、路径、状态码和请求体各有职责；JSON 是数据格式，不是 HTTP 本身 |
| API | 供另一段程序调用的入口约定 | POST /todos 规定输入、输出、错误；函数也可以有 API |
| 路由 | 按方法与地址分发请求的规则 | GET /todos 查列表，POST /todos 创建；同一个 URL 可有不同处理 |
| DTO | 在边界之间传输的数据结构 | 创建请求只需标题；数据库记录可能还含 ID、时间与内部字段 |
| 校验 | 检查输入是否满足要求 | “是字符串”不等于“不是空白”；类型检查与业务规则都可能需要 |
| 序列化 | 把内存对象转成可传输或保存的格式 | 把待办对象变成 JSON；反序列化得到的数据仍需验证 |
| 中间件 | 包在核心处理前后的通用步骤 | 记录请求时间、检查身份；顺序影响哪些请求能走到业务函数 |
| 依赖注入（DI） | 从外部提供函数或对象需要的协作者 | 把待办仓库传给服务，测试时换成内存实现；不等于一定要使用容器框架 |
| ORM | 把数据库表和程序对象之间的转换交给工具 | 省去部分重复 SQL；不会替你设计索引、事务或并发规则 |
| 迁移 | 用可追踪步骤改变数据库结构 | 新增 done 列；修改类定义不一定会修改已有数据库 |
| 事务 | 把一组数据库操作作为一个整体提交或撤销 | 扣库存和建订单要协调；外部发邮件不会因数据库回滚自动撤回 |
| 术语 | 通俗解释 | 常见误解 |
|---|---|---|
| 状态（state） | 某一时刻决定程序行为的数据 | 所有变量都“有值”，但框架只会观察它支持的状态机制 |
| 声明式 UI | 根据当前状态描述应该显示什么 | 不是点击后手动修改每个控件；状态变化后框架重新计算界面描述 |
| 渲染 / 重组 | 根据输入重新计算视图描述并更新需要变化的部分 | 不等于每次都重建整个屏幕；也不能依赖计算只发生一次 |
| 状态提升 | 把共享状态放到共同的拥有者 | 两个组件各复制一份再互相同步，容易出现不一致 |
| 派生状态 | 可以从现有数据算出的值 | “未完成数量”由列表计算，通常不用另存一个可变计数器 |
| 副作用 | 影响函数返回值之外的世界的操作 | 请求网络、订阅、写文件需要处理触发时机与清理 |
| 缓存 | 保存一份可再次使用的结果 | 缓存不是权威数据源；必须说明键、有效期、失效和清理规则 |
| 失效（invalidate） | 告诉缓存某份结果需要重新确认 | 不一定立刻删除缓存，也不一定立即请求所有未被使用的查询 |
| 水合（hydration） | 客户端接续服务器生成的界面并接入交互 | 服务端和首次客户端渲染不一致会出问题；不是把服务器组件代码全部搬到浏览器 |
| Headless | 提供行为与状态，但把外观交给使用者 | 表格库可以负责排序，却需要你自己写表头、按钮与样式 |
| 术语 | 通俗解释 | 应该追问的问题 |
|---|---|---|
| 并发 / 并行 | 多项任务交错推进 / 同时执行 | 是等待 I/O，还是在计算？async 不会自动给计算增加 CPU 核心 |
| Promise / Future | 表示以后才知道的结果 | 谁启动任务？谁等待？谁处理失败？不同运行时的启动规则并不相同 |
| 事件循环 | 在任务可以继续时调度回调的机制 | 长计算是否占住执行线程？不要跨模块格式背固定输出顺序 |
| 取消 | 告诉正在进行的工作结果已经不再需要 | 是否传递取消信号？底层操作是否配合？取消不等于撤销已提交数据 |
| 幂等 | 相同操作重复执行，目标状态与执行一次相同 | 网络重试会不会重复创建订单？请求 ID 是否被记录和检查？ |
| 背压 | 消费者跟不上时让生产者减速 | 是否无限积攒内存？流式读取只有尊重下游速度才有意义 |
| Mock / Stub | 用可控替身替代真实依赖 | 你验证的是自己的处理逻辑，还是误以为已验证真实网络服务？ |
| 单元 / 集成 / E2E | 测小块逻辑 / 测协作边界 / 从用户入口测完整流程 | 每层能发现的错误不同，不能用很多单测替代数据库集成检查 |
| CI / CD | 自动检查变更 / 自动准备或执行交付流程 | 检查通过证明了哪些行为？哪些平台与外部服务根本没有运行？ |
| 可观测性 | 用日志、指标和追踪理解运行中的系统 | 错误发生在哪个请求？频率如何？耗时在哪个依赖？ |
用户连点两次“创建”，页面出现两个待办。这不是看到“并发”二字就能解决的问题：先检查是否发出了两次请求，再决定产品是否允许重复；若要求只创建一次，需要设计幂等约定及服务端约束。只禁用按钮无法处理网络重试或其他客户端。
练习：画出“创建后列表没刷新”的数据路径，分别列出存储失败、请求成功但缓存未更新、缓存已更新但界面读错状态三个假设。验收：每个假设都能对应一条可观察证据，而不是直接选择一个新库。