想要考虑所有情况而焦虑该怎么办？

本来是问答的，写着写着就自己解决问题了，博客写多了，有点像博客了。

的确很多时候我们问问题是为了抒发情绪，而不是解决问题本身。

感觉是迷失在细节里了
斗胆问一下楼主是不是没有学过高等数学以后的数学了？

语法真的不重要，重要的是数据结构、算法和建模

不用的东西一定是会渐渐遗忘的，这个是没有什么办法的。

同意
@kuangwinnie
的看法。楼主你是过度陷入到细节里了。心中要有大画面，要建立直觉。然后真的有必要时，再去扣细节。不要本末倒置。

不要钻牛角尖
够用就好
先上线这个进度就不一样了
三句话够用了吧

@user8341 陷入细节之后甚至会发现一些细节本身就是自相矛盾的。。。
总结出来几个套路然后面试之前学学细节就行了。。。我是这么觉得的

我现在看啥都想记下来...结果就是 需要再读一遍甚至反复，然而没那么多时间，久而久之就堆在一坨了...

你完全不需要焦虑，因为你考虑的东西涵盖了非常多的东西，你一个人不可能有那么多时间来把这么多的问题全部做好。

不然，你以为微软 20 万工程师，2 年才做一个 Windows，是怎么来的？

很多事情并不难，只是复杂，只是麻烦，只是很消耗时间。假设你的寿命是无限的，你完全可以自己做一个操作系统。

很像我经常看见的某些“心得博主”写的高大上的知识点总结树状图，一个知识点后面跟着一个又一个知识点，像是会无限延伸一般，很多新人看到这种东西第一感觉其实是恐惧，恐惧于繁杂的细节，但是编程最终还是实践为王，亲自解决一个问题的记忆往往比了解完美解决该问题的所有方法更加深刻
纸上得来终觉浅，绝知此事要躬行

奥卡姆剃刀：当你觉得学一个知识要考虑很多问题的时候，它就是要考虑很多问题

你这就是“想得太多”，啥时候写个 switch 还这么多戏来了。

没关系。先保持这样的焦虑，并尝试顺着自己的焦虑去多看多实践多想，时间长了，你就知道哪些细节是不重要的，哪些细节是需要记下来的，哪些细节已经成为了你的直觉。那时自然不焦虑了。我更多觉得这样的焦虑是学习的必经过程，也许不必上来就否定。

完美主义者需要解决的主要问题是时间管理和按优先级安排任务，不建议带着这样的态度到工作中。

我觉得把 你是没经历过难得东西
先把简单的 LEETCODE 刷 500 道 再来说你学 Go 的问题吧
你遇到的这些问题 说真的是工程上比较简单的问题了
其实好多技术性博客 已经给你讲透了
比如 channel 那编译时候 底层调用什么函数 你去看过源码么

"哪怕是一个简单的 switch 语法，也有很多种情况，有没有变量，变量声明否，多 case，加不加 default，用不用 fallthrough，break 等等"
这说明 switch 语法并不简单 ... 或者说就是前人挖的大坑，后人都要去摔一跤

楼主自认为想要考虑所有情况，但是没有考虑的是导致这种问题的原因，除了前人挖了这个坑以外，后人非要瞎了眼去踩也是很重要的。

个人认为，学习一门语言或者大的框架，需要制定学习路线或者按照教程等系统性学习，其他的比较零碎的知识点的话，获取最高性价比收益是在你达到熟练掌握使用的时候就可以了，细节或者源码可以针对面试题等专项去看，这些基本也都有网上人家梳理好的。
毕竟你的时间有限，精力有限，智力也是有限的，不要过分强求自己，而且我认为零碎的知识点记下来的零碎的笔记回头再看的可能性也不大

@raaaaaar 啊啊啊啊啊啊啊一摸一样，而且学不完就不想学没动力那种。

掌握体系结构，掌握内在的规律就够了，不要关心细节，任何细节都是内在规律的体现。你没有必要去观察所有的雪花，因为这个世界上不存在两片相同的雪花，但任何一片雪花都是六棱型的冰晶的组合。

选择最重要的事情去做，对于每个人来说，放在自己面前最重要的事情都不一样。

对于学生，这么研究没什么错误。
但是对于工作党，这么学习可能就不一定对了。

针对自己的情况，选择。所以，选择比努力更重要。

先整体再细节吧

选择比努力更重要，就是选择一个最快，利润最大，最省事的道路去走。

所以我不赞同记笔记的学习方式。
像你这样如此机械化地学习知识，完全就是舍本逐末。

人的精力很有限，人的寿命更有限。

人的一生为什么需要做选择，因为你的生命和精力都很有限，你只能有所舍弃。

学习不是知识的堆砌. 而是需要在脑中构建出一个概念.

比如链表, 当你脑中有了链表这个概念时, 就算你从来没有了解过双链表, 但是你只需要搜索一下双链表是个什么东西, 几分钟后, 你就已经理解了双链表了, 甚至脑中已经能想出他是怎么实现的了

人脑适合运算,而不适合存储.

确实很容易沉溺在细节里。如果楼主去看源码。。。难以想象了

@kuangwinnie #2 还是本科计算机，的确没学过更后面的数学了

@chocovon #6 要实践，这个的确，经常用到那些的就算不特意总结，也能写个大概

@laminux29 #10 的确是很全面的，我日常和别人交流，或者实际应用到的都是很小的一点，这我也能体会到，不过我也不是一直都是这样，有时候事情多了，一焦虑就管理不过来，就想面面俱到。

@laqow #12 这些知识的问题本来就是一直存在的，哪怕我们不去接触，也存在，总不可能全都掌握吧。

@cassyfar #13 我最近在写 go 的简单课件，我其实是在更多的在文字上，从符合人脑认知的方式来讲的，也不想单纯罗列知识，但是有时一看感觉自己写的又太少了，因为我过去学都是一来就把这些情况过一遍代码，感觉有点脱离代码，又考虑到有些的确是平时会用的，一加又是一大堆，有些冲突。

@ljpCN #14 的确不是时刻都这样，有时候学这些，学得比较深入了我就会有些焦虑，适度的焦虑也有好处，能给我们压力，回头看有些知识我掌握得也挺全面。

@marat1ren #15 的确是这样，完成任务和学到知识，我有时候无法忍受知识断层，所以我想要的是学懂知识，但是很多时候别人要的只是能跑起来，怎么管理这两者我也在学，

@beidounanxizi #16 也不能这么说，lc 我也一直在学，但是这是思维上的问题，语法本身的确没啥技术性，但是也要过一遍吧，多放时间在重点上，这我有点想法。 有些东西不罗列知识，而从原理上看，这的确是个着手点。

@secondwtq #17
的确是个左手点，为什么有这个东西，自然而然引出这个东西，知道这个考虑的方向，具体的细节反而可以忘记。

@rodrick #18 按知识体系去学是挺好，但是这有点难以做到。

@XiLemon #22 嗯

@wutiantong #24 这我就不赞同你的观点了，我并不是完全这么单纯罗列知识，我学这些也是从顶向下学的，知道自己学的是哪一层词的知识，只是到了这一层细节比较多而已，而记笔记的方式就不说了，只有记过的人才能体会它的好处。

@InkAndBanner #27 我看过源码，有时也经常出现那种 a->b->c 这种知识的缺漏，感觉有些舍本逐末了，也在改。

逐渐积累吧，你要明白的是你最终是为了解决问题的，而不是单纯的学习知识，学习用知识解决问题的能力。

时隔半月，还是来回复一下吧，最近我又学了一些东西，有了这个意识后我，我的理念改变了许多。

最近我在学习 string 匹配算法，我先学了整体的框架，搭了个小体系吧。重点了解了模式匹配有哪些，它们的原理不同，区别，时间复杂度等等，没有一来就深入源码或者画图看细节。

现在我感觉没那么容易就陷入 kmp 的细节了，kmp 有很多细节，又有一些改进的方法，但是我学的时候知道自己在学些什么，我要掌握的是什么，而不是想要所有的东西都学一遍，为了学而学。

现在回想我以前学线性表的时候，也只能记起他们的原理，分类，大概应用，时间复杂度这些理念上的东西，但是要让我忽然写个顺序队列的入队出队操作还真不行，毕竟不是天天都刷题的竞赛党，但是我平时在遇到它时，我知道它的很多东西，要用的时候随手就能看懂源码。

我想这才是我们学习这些东西的原因吧，我们又不是为了记住所有代码细节而去学这些东西的，知道它是什么，它的原理，作用这些就够了。

回想起来我为什么会试图搞懂所有细节，原因之一应该是，我接触到了画图这个工具，变成了重度用户，我总有一种自己效率更高的优越感，总想学好证明自己，这使我有些过于关注细节了。

最近我在学校做项目读别人源码也有些体会，怎么实现的的确真的没那么重要，重要的是，怎么解决这个问题，怎么高效的解决这个问题，细节本身，无关紧要。