去年双十一前两周，端项我们电商团队的目经后台管理系统突然卡成了PPT。运营点一下“导出订单”按钮，端项浏览器直接假死五秒。目经查了半天，端项问题不在接口——接口响应只有200毫秒。目经真正的端项凶手是前端表格：一次性渲染了八千行数据，每行还有六个可编辑单元格。目经

这就是端项典型的前端性能债。很多人以为前端就是目经画页面，但项目做多了你会发现，端项真正让你半夜爬起来改代码的目经，往往是端项数据量、交互状态和浏览器渲染机制之间的目经三角债。

虚拟列表不是端项万能药，但没它真不行

当时我第一反应是上虚拟滚动。react-window 和 vue-virtual-scroller 都用过，原理不复杂：只渲染视口内的几十个节点。但坑在于，我们的表格支持行内编辑，用户滚到第500行改了价格，再滚回顶部，那一行的状态得保住。虚拟列表默认会回收DOM，状态就丢了。

解决办法是把编辑状态提升到数据层。每一行的修改实时写回源数组，虚拟列表只负责展示。听起来简单，实际改的时候发现，原来的代码把状态存在了组件内部，几百个单元格各自为政。重构花了三天，但改完之后，八千行表格的首次渲染从4.2秒降到了180毫秒。运营没夸我们，只是说“今天不卡了”——这大概就是前端最朴实的成就感。

组件库用得好是加速器，用不好是沼泽

另一个项目里，我们选了某知名UI库的日期选择器。设计稿要求“只能选未来三个月内的周三和周五”。文档翻了三遍，没有现成配置。最后是靠自定义渲染函数加一层日期过滤逻辑硬啃下来的。代码写了两百行，其中一百五十行在处理时区和夏令时。

我的观察是：组件库的默认行为覆盖了80%的常见场景，但剩下20%的定制需求，消耗的精力可能比从零写一个还多。所以后来我养成了习惯——选型前先翻issue区，看有没有人提过类似需求，官方态度是“支持”还是“你自己想办法”。后者的话，直接放弃，自己封装一个轻量组件反而更可控。

状态管理别过早抽象

见过一个后台项目，用了Redux，又叠了Redux-Saga，再包一层自定义hooks。一个“切换标签页”的操作，数据流要经过action、saga、reducer、selector四层。新同事接手，光理清数据流向就花了一周。

不是说这些工具不好，而是项目规模没到那个量级时，Context加useReducer足够。我现在的判断标准很简单：如果两个组件之间共享的状态不超过五个字段，且没有复杂的异步依赖，就不引入全局状态库。前端架构的复杂度应该跟着业务复杂度走，而不是跟着技术潮流走。

兼容性问题的尽头是用户设备

有个活动页在Chrome上丝滑流畅，测试同事拿了一台两年前的安卓中端机，滑动直接掉帧到个位数。查出来是CSS的backdrop-filter在低端GPU上开销太大。换成半透明纯色背景，视觉上打了八折，但帧率回到了55以上。

这件事让我改掉了“开发机即用户机”的错觉。现在做移动端项目，我会刻意把Chrome DevTools的CPU降速调到4倍，网络限到3G，先看看最差情况下的表现。能接受再往下写。

前端项目经验说到底，就是一次次在“效果”和“代价”之间做选择。选虚拟列表还是分页，选组件库还是手写，选全局状态还是局部状态——每个决定都有账单，只是有的当场付，有的半年后才寄到。