想知道大家工作中力扣 Hot100 里的哪个算法在业务逻辑里会用的比较多？为什么？

用不了一点

递归吧，像菜单，组织树，比较常见

如果只是停留在业务层, 几乎不会用到
都是数据结构+简单的遍历, 少量位操作. 很少用到称得上算法的东西
脱离业务向底层, 又息息相关, 用到的东西几乎全是数据结构+算法

topk 这种用到过，别的真没

都是建议同事把自己写的算法改成第三方库。。。

最常用的就是各种树形结构的处理，比如本节点可以查看当前节点一直到根节点，当前节点所有子节点的数据之类

提前 hashMap 存储这种吧 我记得有个题是这样

可以不用，但不能不会

进去拧螺丝，除了大牛，谁敢说自己写的算法能好过开源的。。所以都是 curd,调调 api ，调调参数

做算法题很多时候不是为了让你真的在业务中实现那个数据结构，而是让你对自己代码的时间、空间复杂度有个直观的概念。

拓扑判环，递归，没了

真正原样运用的没有，但是对于时间空间复杂度的思考，会潜移默化地表现在日常写业务代码的过程中。然后一些优化思路偶尔也能用上。举个例子，我遇到过个真实需求，给定 500 万个预先处理好的 7 位浮点数，然后输入一个浮点数，算出来有多少个浮点数比它大。因为要用于线上，所以对耗时的要求比较高，需要在 5 毫秒内搞定。常规地去遍历一遍，一一比对，得花两三百毫秒。这个时候力扣那些以空间换时间的思路就能派上用场了。

还有就是对于递归的理解，没刷力扣之前，真觉得自己理解了递归，刷完才发现自己原来根本不会用。递归在工作中用到的机会还挺多。

主要用来就是筛人，有些功能需要考虑算法设计实现，但是现在 ai 普及，这东西完全交给 ai 去写，所以这块权重又弱了。

@coldle 太对了 我就这样搞过

就写了个递归吧 其他的都没用到

手写 parser (

位运算，前缀树，递归如果也算的话

我最经常用的就是二分

树。
我再一次业务中的 map 的 key 用了 set
构建它的时候用了树。

时间复杂度 o1 ，写了之后同事都说牛批