关于算法优化在前端工程实践中运用的思考
在做算法题的时候,我们经常用 “空间换时间” 的方法,把 O(n) 的算法优化到 O(1) ,并“引以为傲”。但今天碰到的这个场景,让我开始重新思考这件事:
在前端领域,“空间换时间”有时候不一定是一件好事“
案例展示
我们有一个大大的路由表,现在,我们需要处理这个路由表,把它变成面包屑菜单(Breadcrumb)组件可用的样子。
也就是对于每一个页面 URL,我们都要有一个对应的链路,来指导组件怎么渲染出面包屑菜单。
例如:
对于 http://localhost:xxxx/dashboard/committee/create
渲染出 Mypaper => Dashboard => Committee => Create Committee
案例源码在下面,有兴趣的可以看看。
如果考虑到最极致的优化:
我可以将所有 pathname 对应的 SideBarItem[] 在组件顶部就计算出来并存到 hash map,这样每次 pathname 变化时只需要进行一次 O(1) 的查找即可。
然而,从 nav-items.ts 得到 hash map 的这样的过程,还是要交给用户的浏览器(考虑到 RSC ,也有可能是部署 node 项目的服务器)计算。
不过显而易见的,由于 nav-items.ts 不可能动态改变,所以其实在编译期就应该已经可以计算出来了,也就是编译的时候计算一次,之后就不用让每个用户或者每台服务器都去跑一遍 nav-items.ts 到 hash map 的计算。
工程架构与性能的思考
nextjs, vite 等等框架都有办法在编译期就执行某些脚本或者代码,能计算出咱们需要的静态 map 数据,如此一来确实能实现上面的优化了。
但是实际工程开发中,我考虑到了下面的两点:
1. 是否值得牺牲灵活性、增加复杂度和维护难度?
要实现上面的想法,我们需要改 build 时候的配置。将来逻辑变了,我们可能还要到处改,带来额外的复杂度和维护难度。
我们写的是前端网页,这个场景本身就不会处理大量数据。这不是百万并发的 GO 服务,也不是跑在用户 PC 上的 Rust 应用,在前端领域工程开发速度和迭代时候的维护难度,相比这一点性能提升会重要的多。
2. ”空间换时间“行为本身的问题?
这点甚至比第一点更致命。
在提升算法性能上,这笔账可能会值。但是在前端领域,如果真做到了上面的优化,最后也需要传一个大大的 json map 给用户的浏览器。
浏览器算出一个 map 往往很快,但是让用户等待体积巨大的 json map 传过来,往往对用户体验的影响更明显,尤其在网络不佳的移动设备场景等等。
案例源码
frontend\src\app\dashboard\components\site-header.tsx:
1 | "use client"; |
frontend\src\app\dashboard\constants\nav-items.ts:
1 | import { |
- 标题: 关于算法优化在前端工程实践中运用的思考
- 作者: 三葉Leaves
- 创建于 : 2025-12-24 00:00:00
- 更新于 : 2026-03-16 12:05:05
- 链接: https://blog.oksanye.com/d6bcf10210cb/
- 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。