前端工程里，我为什么越来越在意接口边界、错误处理和日志

前端项目刚起步时，大家最容易关注的是页面能不能跑起来、组件写得顺不顺手。但项目一旦进入多人协作和长期维护阶段，真正拉开差距的，往往不是某个页面写得多漂亮，而是系统出了问题时，能不能快速定位、快速止损、快速修复。

接口边界不清，后面一定会越来越乱

我现在很怕一种情况：接口返回什么，页面就直接吃什么。短期看确实快，但后面只要后端字段一变、接口多给一层嵌套、状态码策略稍微不同，前端就会有一堆页面一起受影响。

所以我现在更习惯在请求层先做一次整理：

这样做的好处不是“更优雅”，而是让页面层少背很多不稳定性。

很多项目里的错误处理，其实只是“别让它报红”。但工程实践里更重要的是：出了错以后，用户看到什么，业务还能不能继续，开发能不能定位原因。

我现在会更在意这几件事：

如果错误只是在控制台里一闪而过，用户不知道发生了什么，开发也不知道哪一步坏了，那这个错误处理基本等于没做。

平时最容易被省略的就是日志，但真正线上出问题时，日志往往是最值钱的证据。

我说的不是到处 console.log，而是对关键节点有明确记录：

ts
logger.error('submit_order_failed', {
  orderId,
  userId,
  reason,
})

这类日志最大的意义，是帮我们把“用户说它坏了”变成“我们知道它在哪一步坏了”。

接口边界、错误处理、日志这三件事，如果每个页面都临时写，最后通常会风格混乱、质量不齐。所以我更愿意把它们往基础层收：

这样团队里谁来写页面，最低限度的稳定性都比较容易守住。

前端工程实践真正难的部分，不是把正常流程写通，而是让异常流程也可控、可查、可维护。接口边界清晰一点，错误处理多想一步，日志留得完整一点，很多线上问题都会少得多，真出问题时也没那么慌。