从完成页面到理解系统

做前端很容易用页面作为工作边界：接口给什么就展示什么，需求写什么就实现什么。页面完成后，如果整体流程仍然难用，可以归因给产品；如果数据不稳定，可以归因给服务端。

这种分工能保护局部效率，也会让系统问题无人负责。很多线上故障并不属于某一层，而是发生在层与层之间。

沿着结果向外走

我开始在需求评审时追问数据来源、权限规则和失败路径，在接口联调前理解服务端的成本，在上线后关注用户是否真正完成任务。前端仍是主要职责，但判断不再停在浏览器边界。

理解上下游并不意味着替所有人工作。它意味着能识别问题属于哪里，提前暴露冲突，并用共同目标而不是职位边界推动解决。

一次“发布按钮一直转圈”的问题让我看清这种差别。浏览器请求在 30 秒后超时，服务端其实已经创建构建任务；用户再次点击，又创建了第二个任务。页面层加长超时只能掩盖问题，真正需要的是一条完整任务语义：

用户提交发布
  → API 以幂等键创建任务
  → 立即返回 taskId
  → Worker 执行构建和部署
  → 页面订阅任务状态
  → 成功、失败或等待人工确认

前端职责变成展示任务状态和提供恢复入口；API 负责幂等创建；Worker 负责执行；数据库保存事实。每一层都更简单，因为“发布是否完成”不再由一个长连接猜测。

架构始于责任分配

一个字段在哪里计算，一个状态由谁保存，一个失败由哪一层恢复，这些看似细小的决定组成系统架构。责任模糊时，各层都会做一点，最终没有任何一层拥有完整语义。

我会用下面四个问题检查责任是否清楚：

这张表后来也用于 AI 工作流。技术换了，责任问题没有换。

工程师走向更复杂工作，不一定先从学习另一门语言开始。更关键的是扩大观察范围：看到请求之外的发布，组件之外的业务，代码之外的协作。

用图把共同理解外化

当问题开始跨层，仅靠口头描述很容易让每个人在脑中形成不同系统。我会画最简单的数据流和状态图：请求从哪里进入，事实由谁保存，失败在哪一层被处理。图不追求完整，而是暴露责任空白和循环依赖。

共同地图还能改善讨论。前端不再只说“接口慢”，服务端也不只说“请求正常”，大家可以沿同一条用户路径查看时间和状态。系统思维并不是知道全部细节，而是能让相关细节在需要时连接起来。

页面是系统与用户接触的地方，却不是系统的全部。只有理解结果如何由多层共同产生，才可能对结果真正负责。

图：页面症状沿依赖链回溯，才能找到真正责任层。

我开始为每个页面画依赖地图

地图只画完成用户任务必须经过的节点：入口、接口、缓存、队列、数据库和外部服务；每条边写超时、重试与负责人。页面报错时先沿地图判断故障属于哪层，而不是默认回到组件代码。

地图不追求一次完整，事故和新功能后持续修正。能把页面症状连接到系统依赖，是我从“实现需求”走向“对结果负责”的一个可观察变化。