关键问题
解决问题的能力，就是从已积累的知识中，找到解决问题的方案。差别就在于，知识积累能力和运用能力的差异。
为什么知识无法积累？
同样实践效果不一样？
前者：有些知识看过就忘、忘了再看，实际碰到问题还是联系不上这个知识，这其实是知识的积累出了问题，没有深入理解好自然就不能灵活应用，也就谈不上解决问题。
后者：同样工作一年碰到10个问题，但是结果不一样，那是因为实践过程中方法不够好。或者说我对我为什么做对了、为什么做错了没有去分析，存在一定的瞎蒙成分。
碰到一个问题，身边同事解决了，而我解决不了，该如何思考？
想对方如何解决这个问题 –>
对方看到问题后的思考和逻辑是怎样的 –>
有哪些知识指导了他这么逻辑推理 –>
这些知识哪些我也知道但是我没有想到这么去运用推理（说明我对这个知识理解得不到位导致不能灵活运用） –>
这些知识又有哪些是我不知道的（知识缺乏，此时需要Google帮忙——在这种有场景案例和目的加持的情况下，学习理解起来更快） –>
在想明白对方掌握的知识和进行的逻辑推理后，思考对方的思路有没有不对的、有没有啰嗦的地方、有没有更直接的方式（对知识更好的运用）
知识+逻辑基本等于我的能力 。
知识让我知道那个东西，逻辑让我把东西和问题联系起来。解决问题时，首先要有相关的知识储备，其次要对储备的知识有深层次的理解，只有如此才能灵活地解决遇到的问题。此处的问题，可以是 方案、架构、设计 等。
如何获得整体系统知识
无法获得系统知识的原因：
- 宏观整体大图（某一特定技术主题的大纲脉络）了解不够；
- 关键知识点深度不够，理解不透彻。
好的逻辑怎么来——实践、复盘
作者的前同事X
X不一定擅长解决某些问题，但是他就是能够通过别人的帮助、Google不停地验证尝试，把一个不熟悉的问题给解决了。
例子：
应用刚启动连接到数据库的时候比较慢，但又不是慢查询
- X的解决办法是通过tcpdump来分析网络通讯包，看具体卡在哪里，把这个问题硬生生地给找到了；
- 专业DBA可能会通过show processlist看具体连接在做什么，比如看到连接状态是authentication状态，然后再通过Google或者对这个状态的理解知道创建连接时MySQL需要反查IP、域名，这里比较耗时。通过配置参数skip-name-resolve跳过去就好了；
- 精通MySQL的人，一看就知道skip-name-resolve需要改默认值。
三种方式都解决了问题，最后一种最快但是纯靠经验累积，换个问题也许就不行了；第一种方式是最通用的，只需要最少的业务知识+方法论就可以更普遍地解决各种问题。
场景式学习、体感的来源、面对问题学习
什么是对知识的深入理解？如何才能做到对知识的深入理解？
例子：学习TCP三次握手
当时学的时候觉得自己理解了，但过了几个月再看，发现跟新的没学过一样。回答别人的问题时都是不确定答案的。
为什么会这样？而学习其他具体的可以看到变化过程的知识（用JS写一个程序，输入了某个变量，输出了变量的值）就好多了。作者认为，这是因为我们对于TCP缺乏 体感 。所谓体感，我的理解是，我们自己对于外在事物都有一种思维想象，比如一只狗的样子、一只猫的样子。这就是对于猫和狗的体感。那我问你？你知道什么是TCP吗？即使你学习了计算机网络，你也不一定能第一时间将TCP的过程想象出来。这就是缺乏对TCP的体感。
我们没看过TCP握手的代码，也没法想象真正的TCP握手是如何在电脑里运作的。
作者给出一个理解TCP三次握手的方法：
在我们学习TCP三次握手理论的时候，用Wireshark抓包，看看三次握手具体在干什么、交换了什么信息，这比理论更易理解。这时再去读别人讲解TCP三次握手的文章，就会觉得茅塞顿开。
作者的告诫：
但是这里很多人执行能力不强，想去抓包，但是觉得要下载安装wireshark，要学习wireshark就放弃了。只看不动手当然是最舒适的，但是这个最舒适给了你在学习的假象，没有结果。
这是不是跟你要解决一个难题非常像，这个难题需要你去做很多事，比如下载源代码（翻不了墙，放弃）；比如要编译（还要去学习那些编译参数，放弃）；比如要搭建环境（太琐屑，放弃）。你看这中间九九八十一难你放弃了一难都取不了真经。这也是为什么同样学习、同样的问题，他能学会，他能解决，你不可以。
工程效率与知识效率
只靠理论就能掌握技能，还能举一反三，这是知识效率。
看点知识然后结合实践加深对理论的理解，要经过反反复复才能比较好地掌握一个知识，这就是工程效率，讲究技巧、工具来达到目的。
知识分两种
一种是通用知识（不是对所有人通用，而是说在一个专业领域去到哪个公司都能通用）；另一种是跟业务公司绑定的特定知识。
通用知识是必须要掌握的，因为这是在行业领域深入的基础。对于特定知识，就要依据业务需要，判断掌握的深度。