我们当时学的时候也没有太多的大纲，大概就是把这一堆知识全塞到脑子里
然后靠自己做题和悟😂 我当时没悟出来，是后来带着这些知识去看算法导论才慢慢悟出来的
工程师需要的算法思维应该是通用性的，而不是了解 xxx 个知识点、会做它们的模板题
应该是就算之前没见过某个问题，也能快速想到一个暴力的做法，然后试图优化它到一个能接受的程度
其实跟我写的一些技术文章挺像，无非就是不断优化（性能、编码复杂度）到一个正常人能接受的范围
算法题的背后总是有知识背景，是为了解决一类问题而设计出来的
有了这个心态就已经成功一半了😂 剩下的就是所谓的“知识点”
链表排序高精度搜索树结构图结构动态规划
先慢慢积累这些的基础知识，不求特别难的题；有了一些基础之后，在解题或者看题解的时候特别关注“这个思路是不是利用了我已知的算法和数据结构来优化”
慢慢就搭起来了
到了最后会发现，简单算法是复杂算法的一部分，复杂算法是解题思路的一部分
Q: 生命周期不重要了么 A: 只是两种思维方式而已 生命周期的思维方式：从组件的创建到销毁，精细控制每个阶段可以做什么事情，但你也得对每个阶段非常了解（例如有两个 route 的 component 是同一个的话，这个 component 其实会执行 update 而不是重建） 纯函数的思维方式：当前的状态（props、state、context）对应的 UI 是什么样子的、触发某个操作会导致状态如何改变；只需要考虑不变量
Q: 可是不学习周期这些概念，对hook的理解能到位么 A: hook 跟生命周期我感觉啥关系都没有 你只需要写 state -> UI 的映射，以及触发 state 改变的函数就行了
Q: 这是从功能上来谈，但是从react的理解角度看，生命周期这个还是跳不过去啊 A: 需要依赖 hooks 的执行时机才能写的需求，大多可以再想想有没有更简单的实现 react 就没想太着重于生命周期（或者说着重于让人们用变化的思维 新的教学文档，自始至终都是教大家如何用不变的思维来看待 UI
Q: 感觉挺厉害，但是理解不了 不变的思维？是把react当黑盒么，大家只需要关心丢什么东西，然后它吐出什么东西就行了么？ 只要丢的东西不变，那么吐出来的东西就不变
A: 为了面试或者兴趣可以学一学原理，但使用的时候当黑盒就行 用变化的思维去写函数式组件，可能会写得很难受。。尤其是当你想用 hooks 模拟生命周期的时候
Q: 这确实是函数式编程的精髓。可是前端本身就是一个交互性很强的东西啊。这么搞，我总觉得很奇怪 A: 交互：某个操作触发了状态变更 旧状态（旧 UI）-> 操作 -> 新状态（新 UI）
Q: 这个确实简单，心智负担也低 A: 你只要关心【状态 -> UI】和【操作】就行 如果跟生命周期绑定，很多东西说不清的。。就好比我刚才的例子，两个路由用了同一个 component，路由切换的时候 component 就是会更新而不是卸载重建 那 beforeDestroy 就是不会执行
如果你依赖 beforeDestroy / onBeforeUnmount 来做清理，那就是不会被清理，你还得在 beforeUpdate / onBeforeUpdate 再做一次清理
Q: 更新一下key值就可以搞定 A: 我在说 vue 的生命周期😂 react 函数式组件你只需要考虑 useEffect 引入的副作用啥时候清除就行
Q: 不过这样确实很奇怪 vue也是这个问题啊 A: 一旦用到了 key，就说明你开始依赖底层实现了 key 在我看来一共两种用途：框架文档里要求的（加速 diff）、非常重要以至于不同数据必须用完全不同的组件时（react 文档里要求的）
Q: 感谢r佬。我原先一直有偏见，以为react和vue是为了编程的规范化，而牺牲了其他方面的东西。hooks相比mixin，更容易写成屎山。看来是我的偏见了 A: vue 3 的 mixin 我不太了解，vue 2 的 mixin 确实恶心 所有东西全挂 this 上，你根本不知道某个变量是哪儿来的；hooks 则是随用随取，方便、对类型友好
Q: 我一直奇怪大家伙儿对vue的mixin的偏见那么深。确实mixin不便于追踪数据，可是罗辑复用这块，在hook出世之前确实无敌啊, 只要合理使用，那点儿心智负担还是可以接受的 A: 一个组件三四个 mixin，每个 mixin 里面有若干生命周期函数、若干 watch，还有重名的 key 逻辑复用写普通函数就行了，除非你是想连着 data 和 watch 一起复用，但这个也可以用 vuex 之类的东西来解决 用 vuex 也比用 mixin 好，至少 vuex 有隔离
Q: 那我觉得还不如用mixin，至少把一些逻辑都放在一起了。通过vuex和函数来实现，更加的分散 A: 我是能记住自己六年前写的代码，但不是所有人都能 逻辑放一起：每个组件的逻辑写一个小的 store.js，里面导出了 getters 和 mutations 思维再进一步就可以做 DDD 了
Q: 那watch，计算属性和钩子咋办，有时候就是需要一起耦合使用, 关键还是在合适的场景用合适的工具, mixin就是优点太多太方便，容易被滥用，反过来无线套娃，增加了理解的成本 A: 如果能像现在写 hook 一样写 mixin，并且加上类型、有办法避免命名冲突，那还勉强能接受, 现在有人写 hooks 都能写成一坨，那写 mixin 岂不是更大一坨, 如果真写成这样，可能还不如不复用
Q: hooks更容易一坨吧，mixin类似api，感觉好歹有个约束 A: 就说一个问题：两个 mixin 的 key 重复了咋解决 两个 mixin 之间的 created 和 beforeDestroy 都有执行顺序问题，但前者是 A 先执行、后者是 B 先执行（多见于两个实例的注册是 A->B、卸载是 B->A 的场景），mixin 如何处理？ 可能不是一个人干的，两个人在各自的分支上给两个 mixin 各加了相同的 key，这两个分支都是好的，合代码也没冲突，合完就挂了
所以复用的思路一直在进步、各家框架会逐渐支持业界实践上最好的方案
O: 我也更喜欢hooks。 之前看 ahooks 的源码，他的 Class Fetch 是插件模式，设置了几个生命周期，什么polling，防抖等附加功能都是以插件的形式插入的。 请问生命周期是插件模式的一种实现方式吗，插件模式有没有更好的实现方式。 hook 也不是 react 率先提出来的，比如上述实现能否改造成 hook 实现（自己在 react 场景之外构建一套 hook 体系）
A: 没看过 ahooks，不过对于 fetch 这种严格分阶段的东西，扩展的思路我也只能想到按照阶段来扩展 , 在 react 以外搞 hooks 的难点在于如何跟组件绑定（每个组件的 hooks 隔离），以及如何触发组件更新 , 除此以外，hooks 就是普通函数 ,如何扩展”得看你这插件主要是干什么的，例如一个插件重流程，那八成会按照流程的各阶段扩展；如果重 UI，那八成会按照 slot（或类似的概念）来扩展
G: service → context provider or global service 怎么做就怎么做，react 只是 view A: 你这差不多已经吧数据和UI分离了，超过了90%的用户 缺点就是页面糊起来不快
刷到了阿里数学题目，涉及到离散，数论，线代
Q: 离散对算法学习有帮助吗？ A：有时候有用，例如你恰好需要解一道置换群的问题，可以先学算法本身，不需要学那么深的数学。
Q：刷了算法都不知道能干啥 A：主要是培养一个思维，思维打开后，碰到复杂业务场景/数据交互，人家要写半小时，你可能可以 10min 写出来并且还没 bug， 这不就能摸鱼 20min 了吗（
Q: 有木有一种可能，没刷算法之前。完成一个业务需要半个小时，刷了算法结果用了1个小时。看的东西多了，就容易多想，过度设计 A: 不会，你看我写个题都被大佐抠出来两个边界场景（虽然正常情况下不会有这种数据,有了思路之后，会更快速地排除掉无关的思考；如果这个思考是必要的、无法排除，那你应该庆幸别人可能之后要花 2h 来解决这个问题, 当你有这能力后，你可以很快知道究竟要开发成什么样, 绝对不会有过度设计的问题，因为每个搞算法都想尽可能简化问题
A: 边界场景其实是工程师要考虑的，而不是算法研究员要考虑的 A: 多学。。迟早有一天，面对复杂问题，你会先用算法思维写一个函数专门处理真空中的球形鸡，然后再用工程师思维将普通鸡变成真空中的球形鸡
Q: 就像知乎那些一上来就无脑推荐原版书，一提算法就推算法导论 A: 推荐算法导论的，我觉得都是没看过几页只会装逼的人 A: 算法导论是我在集训两年后才鼓起勇气看的书，虽然也看了好几遍，但其中依旧有几个章节我看不下去 A: 更别提时间复杂度的推导了。。这怎么可能让新人提升自己
Q: 我总是觉得出算法题的人，其实是为了启发大家一类问题，进而想出原理。题我会做，但就是无法想出出题者的意图，就很沮丧。我看了大部分的算法博客，感觉就是为了解题而解题，，就很怀疑这样真的有效么 A: 没有 Q: 哎，虽然嘴里总是说着没有银弹。但是整天幻想着一本算法秘籍，能让我一通百通 A: 这需要不断自我总结，例如这两个算法的思路好像啊，是不是有什么关联；有时候也需要一些引导，例如算法导论的课后习题会教导你如何对本节内容做扩展、能不能利用它（和变种）解决更复杂的问题 A: 前端也一样啊，例如 CSS，一开始看似杂乱无章，但了解多了之后发现这些规则似乎可以分成几类，之后再去看 csswg 的规范，一下子就懂了 A: 了解它是怎么设计之后，我就很少去“试错”，而是直接给出最终解，然后再微调数据 A: 包括之前群里的 CSS 题，我也是顺着 csswg 的规范，一点点找思路的
O: 比如KMP算法和编译原理中的有限自动机，我看这两个的时候感觉就是拍案叫绝 O: 智慧的深度
A: 可以说是用算法思维开了天眼 Q: 算法只能打开你的格局, 感觉你的耐心和悟性这方面太厉害了 O: 发现了吧，这其实就是所谓的智商差距, 这东西是练不出来的