全栈工程师

全栈不是“什么都会一点”，而是愿意对一条完整请求负责：用户看到什么、服务收到什么、数据最后变成什么。我们从一个按钮开始，走一遍这条链路。

09:30一条请求，穿过三层

需求是给订单页增加“再次购买”。按钮、接口和订单数据都会变，任何一个环节漏掉，用户看到的都是失败。

先把动作拆开：点击后读哪份订单、由谁校验库存、失败时返回什么、成功后页面停在哪里。先画出一条能走通的路径，再决定每一层写什么。

11:00边界和契约

前后端各自实现之前，先把接口约定写清楚：请求字段、成功结果、错误码、权限和重复提交的处理。

约定不是给别人看的文档，而是两边都能执行的测试。前端用同样的字段做模拟，后端用同样的错误码返回失败；任何一边擅自改字段，联调时就应该立刻暴露。

14:00把整条链路跑通

下午先跑最小路径：一个用户可以点、接口能收到、订单能读出来、页面能显示结果。然后再补失败路径：未登录、库存不足、重复点击、网络超时。

全栈的优势在这里：可以从前端一路查到数据，判断问题究竟出在显示、请求还是数据；但边界仍然要清楚，不能因为“都能改”就把业务规则散落在每一层。

17:00发布以后

发布后同时看三件事：前端有没有报错、接口的延迟和错误率有没有变化、数据结果是否符合预期。任何一项异常，都先回到同一条链路上定位。

记录这次改动留下的取舍：哪些错误由前端兜底、哪些必须由服务端拒绝、哪些数据需要以后补。下一次遇到类似需求，可以直接复用这条路径。

这一天，带走什么

全栈工程师的价值，不是把三个岗位合并成一个人，而是让一条请求在边界之间少掉几次“这不是我负责”的推诿。能走完整条链路，也要知道每一层该守住什么。