前端算法

前端算法并不等于 LeetCode。它更多是把通用算法思想落到真实 UI、数据处理和交互场景里。真正的价值，不在于会不会做特别难的题，而在于你能不能把页面问题、数据问题快速抽象成结构和过程。

常见应用场景

前端里高频出现算法思维的地方包括：

• 列表排序、筛选、去重
• 树形结构转换
• 路由匹配
• 富文本解析
• 权限树处理
• 搜索建议与高亮

这些问题看起来不像“算法题”，但本质上都在考：

• 数据结构怎么选
• 遍历顺序怎么设计
• 重复计算能不能消掉

基本复杂度意识

写代码时，至少要有下面几层判断：

• 当前算法是 O(n) 还是 O(n^2)
• 是否能用空间换时间
• 是否能提前索引、缓存、中断
• 是否能把多次遍历合并

在小数据量下，这些差异可能不明显；但当列表上千、树节点上万、输入实时变化时，复杂度差异就会直接反映成卡顿。

一个常见例子

数组对象去重：

function uniqueById(list) {
  const map = new Map()

  for (const item of list) {
    map.set(item.id, item)
  }

  return [...map.values()]
}

为什么这种写法常见

因为它利用 Map 快速建立索引，避免了双层遍历去找重复项。

相比“每来一个元素都去结果数组里再查一次”，这种方式通常更稳。

树形结构是前端高频题

很多业务数据天然就是树：

• 菜单
• 部门组织架构
• 评论回复
• 分类系统

一个常见需求是“把平铺数组转成树”。

这类题真正训练的是：

• 建索引能力
• 父子关系组织能力
• 对缺失父节点、孤儿节点的处理意识

搜索与高亮

搜索建议和关键词高亮，看上去更偏交互，但背后也有算法思维：

• 如何快速过滤匹配项
• 是否需要做前缀索引
• 高亮时如何避免重复切分字符串

当输入是实时触发的，算法效率就会直接影响交互体验。

富文本和解析类问题

前端还会遇到一些“半结构化文本处理”问题，例如：

• Markdown 片段处理
• 富文本标签提取
• 模板变量替换

这类问题不一定复杂，但很考验你：

• 是否能先定义清楚输入规则
• 是否能避免正则乱写导致后续不可维护
• 是否知道什么时候该上解析器，而不是继续手搓字符串

学习建议

不要只刷题不落业务

如果算法只停留在题库里，很容易会做题、不会用。更好的方式是把项目里遇到的数据处理问题反过来当算法题看。

多做高频结构题

尤其值得反复练的是：

• 数组转树
• 树转数组
• 递归拍平
• 去重与分组
• 排序与稳定排序

在真实项目里记录性能案例

当你遇到卡顿、重复渲染、过滤慢、搜索慢时，先不要急着上优化库，先判断：

• 是否遍历次数太多
• 是否做了不必要的深层递归
• 是否每次都重新计算全部结果

小结

前端算法真正有价值的地方，不在于题目难度，而在于你能不能把实际问题抽象成：

• 数据结构问题
• 遍历问题
• 索引问题
• 复杂度问题

一旦你形成这种视角，很多业务难题会清晰很多。