2024 年 8 月，dev.to 上有人发了篇 React DataGrid 的实践记录，搭了个太空任务浏览器。这类“我拿 XX 库做了个 XXX”的文章我基本扫两眼就关。这篇我倒记住了，记的不是组件，是中间夹着的两个数。
1_200 // 客户端工作集
100_000 // 服务端档案
1200 行，喂给所有交互分析；100000 行，走服务端分页，只做档案浏览。一个应用，两套数据，两种消费方式。谁也没越界。
这种项目一般会长成什么样？要么一把梭，把十万行全量拉到前端，塞进虚拟滚动的大表格里，挂一个全局状态库，让浏览器替你那个数据库扛着；要么干脆整套上后端，分面、聚合、索引、缓存，为了一篇组件试用博客，先搭一个数据平台。
作者哪条道都没走。他连给那十万行配一个独立聚合接口都懒得做。
评论里有人揪着一个问题问：你那个 facet 计数到底算的哪份数据，1200 行的工作集，还是完整档案？作者答得很干脆：分面只作用于客户端这 1200 行，十万行那边是服务端独立分页，没人给它做聚合后端。末尾补了句：真要上生产，计数得靠全量数据来撑。
后一句很诚实。
但前一个决定更诚实：在拿这个组件写演示的语境里，1200 行就是够的。够排序、够搜索、够分面、够分组、够在浏览器里当场给出所有交互结果的即时反馈。Mission Analytics 页上那些图表——发射节奏、机构可靠性、目的地分布、成功率、时长散点——全出自同一份 1200 行数据。
这份数据被分析视图和交互视图共享。表格上筛了什么，图表上就少什么，不用同步层，不用事件总线，更不用哪个中间件帮你把过滤条件翻译给另一个组件。一个状态源，两个视图消费。这架构朴素到连名字都没有，但它比一半所谓的数据中台能站得更稳。
说句题外话。我手头那个玩具存储引擎，核心数据结构改了三遍。第一版想做得通用，什么类型都往里塞；第二版想做得灵活，存储后端可以热插拔；第三版删到只剩两件事：存键，取值。跑得最快，也最好读。
代码这东西，每叠一层抽象，就离“一眼看懂它在干什么”远一步。AI 写的代码偏偏最擅长干这个——它把每一种可能性都当成配置项给你留着，再管那叫“灵活”。数据密集型的工具不是靠灵活活的，是靠数据边界活的。
回到那篇文章。
作者列了一长串测过的功能：多列排序、快速搜索、分面过滤、行分组、行固定、数据透视表构建器、自定义单元格渲染、虚拟滚动、CSV/Excel 导出、树形数据。我看到这串清单的第一反应是：这不叫评估组件，这叫逛超市。
功能都没错。可在 1200 行的客户端数据集上，虚拟滚动属于多此一举；在一个连聚合后端都不想写的项目里，导出是锦上添花。数据透视表强得吓人，可这个太空任务浏览器里，压根没有哪一屏用得上它。
真正被用出味道的，是两处不起眼的地方。
一个是树形数据渲染了 Apollo VIII 的五个任务阶段：发射、入轨、有效载荷调试、运行、离轨。详情页要的那点复杂度刚好够用。
另一个是整套深青色飞行控制终端风，配四种密度模式，从 Ultra Compact 到 Comfortable。应用的样子被定了调，而不是让组件以默认姿态裸在那里。
两种投入都是克制的，为某个具体的界面服务，而不是给组件库的功能表做汇报演出。
评论里有个人说到点子上了：文章缺少配置困难、报错和性能极限的分析，代码量不够。说得对。那篇文章更像一块产品演示板，不是工程记录。它让你看见这层皮能跑，没让你看皮底下那些破事。
工程上的破事反而是评论区漏出来的。有人发现列头显示有异常，作者回了一句：会修。就这么短短一句。用 AI 搭出来的壳，连配套组件的默认样式都没完全吃透——这倒是 2024 年用 AI 辅助写前端时该有的样子。
被嫌“太顺滑”的文章，因为这几个小坑反而真实了。它没有假装自己是从第一行代码到第十万条数据都亲手构建过的系统架构。它是一个人拿 AI 搭了骨架、用组件库拼了表面、发现列头歪了之后说会修的普通工程现场。
我喜欢那股“没打算把十万行当回事”的松弛感。它用 1200 行讲完了所有想讲的组件故事，剩下的十万行留在服务端，正好让虚拟滚动那个功能有个合适的出场机会。
复杂度最爱从“以后可能用得上”这句里长出来。先想清楚一份数据的哪个子集需要在当前的设备上、以当前的交互形式出现在用户眼前。
其余十万行不需要聚合后端，甚至不需要被认真对待。
它们需要你关掉标签页，去睡觉。