前端不懂业务有多可怕？

去年 Q3，我们线上出了一个事故。

不是白屏，不是接口报错，不是样式错乱。页面跑得好好的，功能丝滑无比，Sentry 零报错，自动化测试全绿。

但客服那边的投诉工单，三天之内堆了 200 多条。

内容都差不多：我只想退其中两件商品，为什么系统把整个订单都退了？

问题原因分析

我们排查了两天，最后定位到原因的时候，整个技术团队都沉默了------代码没有任何技术层面的 Bug。API 调用正确、参数传递正确、状态更新正确、UI 渲染正确。

问题出在：写这个退款页面的前端工程师，从头到尾不知道退款还有部分退这回事😖。

他拿到需求文档，看到退款功能，脑子里的模型就是：用户点退款 → 调接口 → 整单退掉 → 跳成功页。于是他写了一个简洁优雅的退款流程，代码质量很高，组件拆得很漂亮，TypeScript 类型一丝不苟。

但他没有问过一句：退款是退整单还是可以退单品？退运费吗？有没有退款上限？已用优惠券怎么分摊？

产品经理的需求文档里确实写了支持部分退款，但藏在一个折叠的备注栏里。Code Review 的时候，审查的同事看了代码逻辑------调用退款接口、传订单号、处理响应------逻辑自洽，没毛病。测试同学写的用例，也是按发起退款 → 退款成功的路径走的。

每一个环节都没有错，但最终的结果是错的。

这就是前端不懂业务最可怕的地方：它制造的不是技术 Bug，而是业务事故。而业务事故的代价，远比一个白屏严重得多🫡。

技术 Bug 有兜底，但业务 Bug 没有

一个 TypeError 会被 Error Boundary 拦住，会被 Sentry 上报，会在 Code Review 里被同事一眼看到。

但一个业务逻辑错误，所有的自动化防线对它都是透明的。

ESLint 不会告诉你这里应该传 orderItemIds 而不是 orderId。TypeScript 不会告诉你退款金额应该允许用户手动修改。Jest 的单元测试只会验证你写的逻辑是否按你的理解运行------但如果你的理解本身就是错的，那测试 100% 通过只是在 100% 地验证一个错误的实现。

我在大厂和跨境电商团队都待过，见过的业务逻辑 Bug 远比技术 Bug 多。而且它们有一个共同特征：上线之前没人发现，上线之后用户最先发现。

为什么前端特别容易掉进不懂业务的坑？

上面这些 Bug 不是因为前端笨，而是因为国内前端岗位的工作模式天然就在制造这个问题。

怎么破？一些我在团队里实际推行的做法

这些不是什么方法论，都是在被坑过之后逼出来的土办法。

需求评审必须带着问题去

我要求团队的前端在参加需求评审之前，必须先看一遍 PRD，至少带 3 个问题进会议室。问不出问题说明你没看，或者你对业务理解停留在表面。

问题的方向很固定：

关键业务逻辑必须写注释

不是写技术注释，是写业务注释。

typescript 复制代码

/**
 * 退款金额计算逻辑：
 * - 部分退支持退单个商品，退款金额 = 商品实付价（分摊优惠后）
 * - 运费只在整单全退时才退
 * - 已使用的优惠券按商品金额比例分摊扣回
 * - 退款金额上限 = 该商品的实付金额，不能超出
 * 
 * 业务文档: https://wiki.internal/refund-rules-v3
 * 最后确认人: 产品经理阿良 2026-08-15
 */
function calculateRefundAmount(
  orderItem: OrderItem,
  order: Order,
): number {
  // ...
}

typescript 复制代码

// 计算退款金额
function calculateRefundAmount(item: OrderItem, order: Order): number {
  // ...
}

第一种注释，即使写这段代码的人离职了，接手的人也能在 30 秒内理解为什么这里要除以总金额再乘以商品金额------因为优惠券是按比例分摊的。

第二种注释等于没写。

测试用例要覆盖业务场景，不只是代码分支

大多数前端的测试思路是按代码分支写：if 走左边测一下，走右边测一下，覆盖率 100%，完事。

但业务 Bug 往往不是代码分支的问题，而是你压根没写那个分支。退款那个例子里，工程师的代码里就没有部分退这个分支，覆盖率 100% 也没用。

所以我现在要求关键业务模块的测试用例，必须按业务场景来写，而不是按代码逻辑来写：

typescript 复制代码

describe('退款流程', () => {
  // 按业务场景组织，而不是按函数名组织
  it('单个商品退款：只退选中商品，不影响其他商品状态', () => { /* ... */ });
  it('整单退款：所有商品退回，运费一并退回', () => { /* ... */ });
  it('含优惠券订单的部分退：优惠金额按比例分摊扣回', () => { /* ... */ });
  it('退款金额不能超过该商品的实付金额', () => { /* ... */ });
  it('已发货商品退款需要走退货流程，不能直接退款', () => { /* ... */ });
});

这种用例，产品经理也看得懂。评审的时候让产品看一眼你的测试场景，漏掉的业务分支马上就能暴露出来。

带了几年团队之后，我越来越确信一件事：一个前端工程师的薪资天花板，不是由他对 React 或 Vue 的理解深度决定的，而是由他对业务领域的理解深度决定的。

代码写得好的前端，满大街都是。但一个能在需求评审时指出这个退款流程缺了部分退的场景 的前端，能在技术方案设计时说出这个库存展示要考虑锁定库存的前端------这样的人，整个团队可能就一两个。

他们的代码不一定最漂亮，但他们写出来的功能，上线之后不会被用户投诉，不会让客服加班，不会让公司赔钱！

你们同意吗？

喜欢我的文章，也欢迎关注我的微信公众号：【前端技术官】。

主要分享：前端架构 · AI 编程 · 职场认知 · 开发者成长

微信扫码关注 👆

不定期更新，不刷屏，聊点真正有用的干货。