从一个功能到生产：全栈交付路线

这篇解决什么问题

全栈不是把前端、后端、数据库和运维各学一点，而是能把一个用户需求推进为可用、可观察、可恢复的功能。下面以“用户可以创建并完成一条任务”为例，串起现有知识库；它是一条交付路线，不限定 React、Java 或某个云平台。

先写能验收的结果，再选技术。这个任务的最小结果可以是：

这些句子会分别影响页面状态、接口契约、数据库约束、权限、测试和监控。若某个结果无法被检查，它还不是完成定义。

需求与验收
  → 页面状态与交互
  → API 契约与鉴权
  → 数据模型与事务
  → 测试、构建与发布
  → 指标、日志、告警与复盘

每一层都要留下一个可验证的产物。页面有手工验收步骤；API 有请求和响应样例；数据层有约束或迁移；发布有回滚条件；运行后有指标和日志查询方式。

把“功能完成”理解成“用户能成功点击一次”会漏掉大量真实工作。完整交付至少还要回答：失败后怎么办、重复提交会怎样、出了问题从哪里定位、发布后怎样撤回。

任务页至少有加载中、空数据、成功、提交中和失败五种状态。不要只在成功路径上做界面；网络断开、权限过期和重复点击更能暴露真实交互设计。

点击保存
  → 禁用按钮并显示进行中
  → 请求成功：刷新任务或用服务端返回值更新页面
  → 可恢复失败：显示原因，保留用户输入，允许用同一操作键重试
  → 无权限：引导重新登录，不把服务端错误伪装成“保存成功”

前端禁用按钮只是在降低重复提交概率，不能成为数据正确性的唯一防线。可继续阅读：状态管理、前端异常处理与错误边界。

创建任务可以采用 POST /tasks。请求中带标题和一次操作键，服务端返回创建后的任务。这里的操作键是同一次用户意图的身份：首次提交与超时重试必须使用同一个键；下一次新建任务使用新键。

{
  "title": "整理发布清单",
  "requestId": "b2d02cf4-4a50-4ac5-8b33-5a4d64c8b1a8"
}

契约还要说明失败语义，例如未登录、标题校验失败、同一操作键配了不同请求内容、正在处理中。HTTP 方法本身不替业务保证幂等；服务端需要把“是否已完成”和“结果是什么”持久化处理。可继续阅读：API 设计、接口幂等性实践。

先写出不变量：标题不能为空；任务归属一个用户；同一用户同一操作键只对应一个创建结果。一个概念模型可从下面开始：

数据	关键字段	约束
tasks	id、owner_id、title、status	owner_id 非空；status 只能是约定状态
task_requests	owner_id、request_id、payload_hash、task_id	`(owner_id, request_id)` 唯一；同键请求体必须匹配

创建记录、写入幂等结果必须在同一个事务边界内。缓存、分布式锁和前端按钮都可以优化体验或并发，但不能替代业务数据约束。可继续阅读：数据建模、并发一致性实验。

前端不展示“删除他人任务”按钮，只是体验层控制。每个读取、更新、删除接口都要在服务端根据当前身份限制 owner_id；不要直接信任请求里的用户 ID。

还要定义输入校验、日志脱敏、凭证保存位置和依赖更新责任人。安全投入应根据威胁模型和数据敏感度决定，而不是上线前临时补一条过滤规则。可继续阅读：认证与授权、安全防护。

测试不是只看 200 响应。对“创建任务”这类操作，最后应检查数据库中有几条记录、它们属于谁、重复调用返回的是否是同一结果。可继续阅读：测试策略。

最小观测集可以包括：创建请求量、成功率、P95 延迟、数据库错误数、重复操作键命中数。日志至少包含请求关联 ID、用户或租户的非敏感标识、操作结果和错误原因；不要把 token、密码或完整个人数据写进去。

发布前写下回滚条件，例如“创建接口 5xx 比例连续五分钟超过 1%”或“迁移后错误率高于发布前基线”。数值不是通用阈值，应按实际服务基线、用户影响和团队响应能力设定。可继续阅读：CI/CD、监控、日志与告警、事故响应。

完成这条路线后，再把任务替换为订单、文件上传或实时协作。变化的是业务约束和规模，交付链路仍然成立。