我最早接触《计算机科学概论》是大学一年级，那时候觉得它是一门“背概念”的水课，考前突击几天照样能过。后来做了很多年后端开发，再回头翻这本书，才意识到第5章到第12章才是整本书真正的核心资产。它不负责给你一个具体的编程框架，也不教你怎么写某个网站的接口，它做的是更底层的一件事：把网络、算法、程序设计语言、软件工程、数据库、图形学、人工智能、计算理论这些模块之间的逻辑关系彻底打通，让你脑中形成一张完整的计算机科学地图。这篇文章就是我基于第13版第5到12章的导读式复盘，适合正在学这门课的科班生、准备转码的自学者，以及工作几年后想补基础的在职开发。我会尽量少讲“是什么”，多讲“为什么”。
1. 5-12章在整本书里的位置：为什么这8章最值得精读
1.1 从单机到系统：1-4章与5-12章的分界点
大多数《计算机科学概论》的前4章，讲的是数据存储、数据运算和底层硬件。你学完那部分，能理解CPU怎么执行一条指令、内存地址是什么、二进制和逻辑门是怎么回事。这些知识当然重要，但它解决的是“一台计算机自己怎么工作”的问题。
第5章开始，视角一下子拉高了：两台计算机怎么通信、成千上万个进程怎么同时跑、海量数据怎么组织、程序怎么被翻译成机器能执行的形式、软件项目怎么在团队里推进、机器怎么具备智能、哪些问题在原理上就不可计算……你会发现主题从“单机”切换到了“系统”，从“硬件”切换到了“软件和抽象”，从“现状”切换到了“边界和未来”。第13版在这个区间里补充了大量贴近现代技术的内容，比如云计算、物联网、机器学习的基础概念，但骨架仍然是那个经典的计算理论体系。
我见过很多读者的误区是：1-4章认真看，5-12章草草翻完。这正好反了。1-4章是“零件手册”，5-12章才是“整机设计图”。对绝大多数人来说，工作中天天打交道的HTTP、数据库索引、进程线程、对象模型、测试方法，全部长在这8章的土壤里。
1.2 五条主线与“自然证明”式阅读法
仔细看这8章，信息量很大但不是散的。我自己读的时候，会从五条主线去抓：
- 分层与抽象：网络分层、软件分层、数据抽象，本质都在做同一件事——把复杂系统拆成可独立替换的层次。
- 资源管理：CPU、内存、磁盘、带宽、电池，计算机科学很大一部分是在解决“怎么把有限资源用好”。
- 安全与信任：加密、身份认证、事务一致性，都是在不确定性很大的环境里建立信任。
- 人与机器的边界：语言设计、图形界面、AI，都在不断降低人使用机器的门槛。
- 可计算性边界：哪些问题能算、哪些问题不能算、哪些问题看起来能算但实际很贵。
顺着这五条线走，5-12章就不是一堆孤立名词，而是一张互相勾连的网络。
这里我要重点说一个词：自然证明。我第一次看到这个词是在计算理论的讨论里，但后来发现它是一种极好的阅读方法。所谓自然证明，就是面对任何一个技术结论，不满足于“书上说它是对的”，而是把它还原成一条可追踪的推理链：从前提出发，经过一步步直观的推导，最后得到结论。你不一定要写出严格的形式化证明，但至少要在脑子里把“为什么”走通一遍。举个例子，为什么不建议在循环里频繁拼接字符串？如果只背结论，你记不住；如果你沿着“字符串是不可变对象—每次拼接都要创建新对象—创建新对象要分配内存和复制数据—循环次数越多代价越大”这条路推一遍，这个结论就永远忘不掉了。这就是自然证明式的学习，我会在后面的章节里反复用它来拆解问题。
2. 逐章导读：每个知识主题到底在解决什么问题
第5到12章在不同版本里章节编号可能略有调整，但知识模块非常稳定。我按主题来拆，你对照目录就能找到对应位置。
2.1 网络与互联网：分层抽象的第一个大现场
网络部分是很多人第一次接触“协议”这个概念。协议不是某种神秘代码，它就是双方约定好的通信规则：包头怎么填、数据怎么分段、出错怎么重传。教材一般从电路交换和分组交换讲起，引出“为什么要分组”。分组交换的好处很直观：线路不用独占，数据可以走不同路径，某条线路故障时还能自动绕路，有点像快递而不是打电话——打电话要霸占一条线路直到挂断，快递则是一堆包裹各自走最优路线。
接着进入分层模型。OSI七层模型不用死背，你要理解它们之间“下层为上层服务”的关系。真正实用的是TCP/IP四层模型：链路层、网络层、传输层、应用层。链路层解决局域网内两台设备怎么传帧，网络层解决跨越多个网络怎么路由，传输层解决端到端的可靠或高效传输，应用层则直接面向用户需求。
用自然证明的方式去理解TCP的三次握手：为什么需要三次？第一次，客户端发SYN，服务器知道客户端能发；第二次，服务器回SYN-ACK，客户端知道自己能发、服务器也能发；第三次，客户端回ACK，服务器才知道客户端能收到自己的回应。整个过程是让双方都确认“我的发送和接收能力都正常”。如果只握手两次，服务器无法确认客户端能不能收到自己的SYN-ACK，就可能因为一个迟到的历史连接请求而浪费资源建立错误连接。这个推理不依赖背RFC文档，逻辑自己会走到答案。
我的实操建议是：打开一个终端，执行curl -v https://www.baidu.com，看输出的每一条连接信息；再用ping和traceroute观察网络延迟和路径。有条件的话，用Wireshark抓一次本机HTTP请求，亲眼看到SYN、SYN-ACK、ACK三个包，比看十遍图都有用。
2.2 算法与复杂度：把“会做”变成“做得快”
算法这块的核心不是背排序代码，而是建立“复杂度”思维。复杂度描述的是当输入规模变大后，运行时间或空间怎么增长。大O记号只关心增长趋势：O(1)是常数，O(log n)是缓慢增长，O(n)是线性，O(n log n)是常见排序的级别，O(n²)是嵌套循环，O(2^n)是指数爆炸。
为什么复杂度重要？用自然证明的方式想一下：同样是从100万个元素里找目标，线性搜索最坏要比较100万次，二分搜索只要约20次。当数据量变成1亿时，线性搜索要1亿次，二分搜索只要27次。差的不是常数倍，而是量级上的鸿沟。这就是为什么算法设计值得专门研究。
教材通常会介绍排序、搜索、递归、分治、贪心、动态规划的基本思想。你需要掌握的是“这个算法在什么场景下有效、代价是什么”。比如选择排序思路最简单，但O(n²)的代价决定了它只适合小规模数据；归并排序稳定且是O(n log n)，但需要额外内存；快速排序平均很快，最坏情况下却会退化。没有万能算法，只有场景匹配。
这里也可以用自然证明来验证算法正确性。最经典的是循环不变式：比如证明选择排序正确，你只需要说明三件事——初始时前0个元素是有序的，每一次循环后前i个元素保持有序，循环结束时所有元素有序。这种证明方法非常直观，它和数学归纳法是一个灵魂：先证明起点成立，再证明每一步保持性质，最后自然收敛到目标。
2.3 程序设计语言与编译：人和机器之间的翻译官
这一章会把机器语言、汇编语言、高级语言放在一起对比，让你看到抽象层次提升带来的解放。机器语言全是二进制，人类几乎无法直接阅读；汇编用助记符表示指令，可读性提升但和硬件强绑定；高级语言接近自然语言和数学表达，可以跨平台。每提升一层，程序员的生产效率都会上一个大台阶。
编译器和解释器是两条常见路线。编译器把源代码整体翻译成目标机器代码再运行，比如C、Go；解释器是逐行翻译逐行执行，比如早期Python、JavaScript。两者各有代价：编译型启动前有构建时间，但运行时性能好；解释型开发反馈快，但运行时需要解释环节。Java和C#走的是中间路线——先编译成字节码，再由虚拟机JIT编译或解释执行。理解了这些，你就能明白为什么不同语言有不同的生态定位。
编译器本身是个很好的“自然证明”现场。语法分析是怎么知道一段代码合不合法的？编译器拿着文法规则（BNF，即巴科斯-瑙尔范式）对代码做推导，尝试从起始符号一步步匹配出整个程序的语法树。匹配成功，程序合法；匹配失败，抛语法错误。这个过程本质上就是一个证明过程，只是由机器完成了。类型系统也是类似思路：通过类型检查在生产环境运行之前证明“这种操作不会发生类型不匹配”，把运行期错误提前到编译期。
2.4 软件工程与开发方法：写代码不是写小说
一个人写几百行脚本，不需要严格工程方法。但几千人协作、几百万行代码的产品，核心问题变成了：怎么保证质量、怎么控制进度、怎么让需求变成可维护的系统。软件工程本质上是在应对“复杂性”。
教材会介绍瀑布模型、增量模型、敏捷开发等生命周期模型。瀑布模型把开发拆成需求、设计、实现、测试、维护几个阶段，每个阶段完成后才进入下一阶段，适合需求稳定的项目；敏捷开发强调短迭代、持续反馈、拥抱变化，适合需求快速演进的产品。不是哪种模型更先进，而是哪种更匹配你的项目约束。
测试是这一章不能绕过的话题。Dijkstra有句名言：测试只能证明程序存在错误，不能证明程序没有错误。这句话用自然证明来理解很清楚：你测试了100个用例都通过，只说明这100个输入下程序行为正确，并不覆盖所有可能输入。想证明程序完全正确，理论上有形式化验证手段，但在工程中成本极高。所以业界的现实策略是：用自动化测试尽量覆盖关键路径，用代码评审和架构设计降低出错的概率。理解这个逻辑，你就不容易陷入“反正测不出来，所以不用测”或“测试越多软件就越对”两个极端。
2.5 数据抽象与数据结构：组织数据的常用套路
数据结构章节的重点不是背代码，而是建立“抽象数据类型”和“实现方案”的区分。抽象数据类型描述的是接口：栈只能在一端压入弹出，队列先进先出，列表支持按位置访问。实现则关心怎么用连续内存或指针串起来。
数组和链表是两块基石。数组在内存中连续，按下标访问是O(1)，但中间插入要搬移元素；链表节点离散，插入删除只需改指针，但按下标访问要遍历。那有没有两者兼具的结构？有，比如跳表、树、哈希表。二叉搜索树把有序数据和二分查找结合在一个动态结构里：每个节点左小右大，查找时每比较一次就能排除一半子树，树高是O(log n)，所以查找是O(log n)。这种性能不是凭空来的，而是数据组织方式决定的。
用自然证明的方式去看哈希表：为什么平均O(1)？因为哈希函数把任意键映射到固定范围的桶，只要桶数量和数据规模成比例，且哈希函数分散均匀，每个桶里平均只有常数个元素。查找时计算一次哈希、定位桶、再在桶内找，时间几乎不随数据量增长。代价是什么？哈希函数设计、扩容策略、以及处理冲突的空间开销。每种数据结构都是某种权衡，不存在完美的万能结构。
我建议读这部分时不要只看文字，动手画出插入、删除、遍历的每一步状态变化。画一次比抄十遍印象深。
2.6 数据库系统：让海量数据持久、一致、可查
数据库章节通常从文件系统与数据库的对比切入：文件系统适合按路径存取整份文件，但如果要在几百万行数据里查找某个条件、并且要求并发写入时保持一致，普通文件操作会非常痛苦。于是有了关系数据库。
关系模型把数据组织成表，行是一条记录，列是一个字段，主键唯一标识一行，外键表达表之间关联。SQL就是操作这些表的标准语言。教材会教基本的SELECT、INSERT、UPDATE、DELETE，以及JOIN如何把多张表拼起来。理解SQL的关键是：你声明“我要什么数据”，数据库引擎负责决定“怎么找”。
索引是数据库性能的命门。索引本质上是一棵B树或哈希表，用额外存储空间换取查找速度。为什么B树而不是二叉搜索树？因为数据库数据在磁盘上，磁盘读写的单位是页，B树每个节点能容纳更多键，树高更低，一次查找需要访问的磁盘块更少。这又是一个自然证明：从“磁盘随机访问很贵”这个前提出发，推导出“尽量降低树高、让每个节点占一个整页”的结论。
事务的ACID特性值得仔细理解。原子性保证要么全做要么全不做，一致性保证事务前后数据都满足约束，隔离性保证并发事务互不干扰，持久性保证一旦提交就不会丢。为什么这四者缺一不可？从“数据库必须保证可靠”这个前提往前推，每一步都是必要条件。
实操上，本地装一个SQLite，建两张有外键关系的表，自己写JOIN查询、建索引、比较一次全表扫描和索引查询的耗时差别，数据量无需很大，几万行就能看出趋势。
2.7 计算机图形学：像素背后的几何与数学
图形学在很多读者眼里是“选修中的选修”，其实它是计算机科学里数学工程结合得最典型的领域。显示器是一个像素矩阵，计算机要做的核心工作是把几何描述变成像素颜色。
三维图形的基础是变换。平移、旋转、缩放都可以写成矩阵，但平移单独用矩阵不好表达，于是引入齐次坐标，把二维点用三维向量表示、三维点用四维向量表示。这样一来，所有变换都统一成矩阵乘法。为什么这个统一这么重要？因为多个变换可以预先相乘成一个矩阵，对每个顶点只做一次矩阵乘法，GPU可以大规模并行执行。从这个角度理解，图形卡的强大不是因为“它很玄”，而是因为矩阵运算天然适合并行。
光栅化是图像生成的必经之路：把几何图形转换为屏幕像素。教材会介绍画直线、画圆的经典算法，比如Bresenham算法。它的核心思想是用整数运算避免浮点乘除法，只比较误差项，一步步决定下一个像素点亮哪个位置。这里又是典型的自然证明：从“像素只能取整坐标，但直线方程经过的位置是浮点数”这个冲突出发，推导出“用误差累积来逼近理想直线”的算法。
想动手体验，直接用HTML Canvas写一个几十行的程序画一个旋转三角形，或者用Python的turtle库画点几何图形。你不会成为图形工程师，但会对“像素背后的数学”有一个直观感受。
2.8 人工智能：从搜索到学习，机器开始“变聪明”
AI在概论教材里的位置很有意思：它既讲经典人工智能，也会带一点现代机器学习的直觉。
经典人工智能的起点是搜索。很多“智能”问题可以变成状态空间里的搜索问题：从初始状态出发，不断应用操作，找到通往目标状态的路径。盲目搜索像深度优先、广度优先，不利用任何领域知识，纯粹按顺序展开，代价是搜索空间可能爆炸；启发式搜索用评估函数估计“离目标还有多远”，优先探索更有希望的节点，A*算法就是代表，它在满足一定条件下能找到最优路径，这是一个可证明的结论。
现代AI的重心转向了机器学习。机器学习不追求人为写出所有规则，而是从数据里自动总结规律。你给它大量“输入-输出”样例，它通过优化参数让预测和真实答案之间的误差逐渐下降。这里有个非常重要的概念：过拟合。模型在训练数据上表现极好，但在没见过的新数据上一塌糊涂。用自然证明来理解：模型如果只记住了训练样本的细节，而不是学到背后的规律，那它面对不同分布的数据自然失效。所以机器学习不是“喂数据就能变聪明”，数据质量、模型容量、正则化策略缺一不可。
教材里可能会提及神经网络的基本结构：若干层神经元，每层做加权和再经过非线性激活函数。为什么多层网络表达能力更强？直觉上，单层网络只能表达线性边界，而多层网络通过逐层组合可以把简单特征组合成复杂特征。虽然这还不是严格的证明，但足够让你理解“深度学习为什么需要深”。
想体验AI并不难，用scikit-learn跑一个简单的分类器，或者用浏览器里的在线实验平台玩一玩手写数字识别，感受“训练”到底在做什么。
2.9 计算理论与形式化证明：计算机到底能做什么、不能做什么
这通常是最容易被忽略、却也最震撼的一章。它告诉你计算机的能力上限在哪里，很多问题在原理上就不可能被程序解决。
教材会从有限自动机讲起，这是能力最弱的计算模型，只能识别正则语言，对应许多文本匹配和词法分析场景。然后引入上下文无关文法，能力更强，能描述编程语言的语法结构。最后是图灵机，它几乎能模拟任何机械化的计算过程。图灵机虽然结构简单——一条无限长的纸带、一个读写头、一张状态表——但它被广泛认为等价于所有计算机的能力。这就是Church-Turing论题。
真正让人倒吸一口气的是停机问题的不可判定性。问题是：能不能写一个程序H，它接收任何程序P和输入I，然后判定P在I上会不会停机？结论是：这样的H不存在。自然证明过程是这样的：假设存在H，我们构造一个新程序D，D接收参数x，然后调用H(x, x)，如果H说“程序x在输入x时会停机”，D就故意进入死循环；如果H说“程序x在输入x时不停机”，D就立即停机。现在问：D(D)会停机吗？如果H判定它停机，按D的定义，D会死循环，矛盾；如果H判定它不停机，按D的定义，D又会停机，还是矛盾。两边都矛盾，说明最初的假设不成立。
这个证明没有一个复杂的公式，完全靠自指和反证把逻辑逼到墙角，是“自然证明”的最佳教材。读过这个证明之后，你会对“有些问题再多的算力也解决不了”有真切的敬畏感。计算理论最后一站通常会带到P与NP问题：有些问题求解很困难，但验证一个候选答案很容易，NP完全问题是否存在多项式时间算法至今悬而未决，是计算机科学最重要的开放问题之一。
3. 具体的学习方法论：怎么读、怎么练、怎么记住
3.1 三步阅读法：先扫地图，再带问题读，最后合书复述
我读这类较厚的概论教材，最有效的方法是三步走。
第一步概览。每章开始前，只用10分钟把标题、图表、小节标题、每节最后的术语表扫一遍，先在脑中建一张“地图”，知道这章讲几个部分、之间大概什么关系。这步的收益是防止在细节里迷路。
第二步带问题读。把每章的标题翻译成问题，比如读到网络层就问“路由器是怎么决定把包往哪送的”，读到文件系统就问“为什么删除文件不等于销毁数据”，读到数据库就问“为什么需要索引”。带着问题读，读到的内容会更容易被编码成长时记忆。我还会顺手在页边写下“这解决的是什么问题”“如果不这样做会怎样”两句备注。
第三步合书复述。读完一节后合上书，用自己的话把内容讲一遍，最好讲给一个不懂技术的朋友听，或者写一篇几百字的笔记。如果讲到一半卡住，说明这个点没真正理解，回头再读。这个过程会有点痛苦，但它比反复划线有效太多。
3.2 把概念画成图：用箭头表达设计的因果关系
技术概念特别适合用图来巩固。不一定要画得多漂亮，关键是强迫自己把关系和流程画出来。TCP握手画三个箭头，编译过程画一条从源代码到机器码的流水线，数据库索引画一棵B树的局部结构，AI的过拟合画训练误差和验证误差两条曲线。画的过程就是在做自然证明：每一条箭头，都对应一个“为什么从这到那”的理由。
我个人的习惯是用“分层盒子+箭头”的方式：盒子代表模块或层次，箭头代表依赖或数据流，箭头旁边用一行字标注意图。比如画网络分层，从应用层往下画到链路层，每个盒子上注明该层解决什么问题，箭头旁边注明“上层数据被封装进下层的载荷”。一张图的信息量抵得上十页书。
3.3 低成本动手实验清单：不用买设备也能验证大部分结论
很多概念看起来抽象，但只要动手做一遍，立刻就变得具体。我的低成本实验清单是这样的：
- 网络：
curl -v看HTTP请求全过程；traceroute看路由跳数；自己写一个简单的HTTP服务，然后用Wireshark抓包看三次握手。 - 算法：用Python写选择排序和归并排序，分别跑1万、10万、100万个随机数，观察耗时增长趋势，亲身体验O(n²)和O(n log n)的差别。
- 语言与编译：写一个函数，分别用编译型语言和解释型语言跑同样的计算任务，感受性能差异；再故意写个语法错误，观察编译器报错的位置。
- 数据结构和数据库：给SQLite表插入10万行数据，先不带索引执行查询，再建索引执行查询，看时间差异。
- 图形：用HTML Canvas画一个三角形并让它旋转起来，理解矩阵变换的作用。
- AI：用scikit-learn在鸢尾花数据集上训练一个简单分类器；再故意只用一个特征训练，观察准确率下降，体会“特征工程”的意义。
- 计算理论：找一个图灵机模拟器在线跑一个简单程序；读一遍停机问题的证明，尝试自己复述出来。
这些实验加起来可能就一个周末的时间，但带来的理解深度远超读两遍书。
4. 常见误区与踩坑记录
4.1 把概论当“背诵手册”
最大的坑就是把这门课当文科背。背了“TCP是可靠的、UDP是不可靠的”“B树是平衡的多路搜索树”这些结论，过两周必忘，因为结论没有长在你已有的知识结构上。
我踩过这个坑。大二时我能默写OSI七层每一层的名字，但面试被问到“一个HTTP请求从你按下回车到页面显示，中间发生了什么”，我完全答不上来。原因就是我只背了孤立名词，没有把分层、协议、寻址、响应这些环节串成一条推理链。正确的做法是用自然证明的方式把每个结论“重新发明”一遍：从问题出发，分析约束，推导出设计方案。这样推导出来的结论，是你自己思维的一部分。
4.2 只记协议和名词，不追问“为什么”
第二个常见问题是知识点之间有断层。比如学完网络，知道TCP是可靠的，但问“TCP靠什么机制实现可靠”就只能挤出“重传”两个字，完全说不出序号、确认、滑动窗口这些配套机制。
原因很简单：没有追问“为什么可靠”。可靠性不是凭空承诺，而是一套机制的组合：发送方给每个字节标序号，接收方收到后回确认，发送方在一定时间内没收到确认就重传，接收方还能根据序号把乱序的数据重新排好。每新增一个机制，都是为了解决前一个机制留下的漏洞。把这个链条走一遍，“TCP为什么可靠”就不再需要背了。
4.3 跳过课后题和实验，追求“读完但没学会”
我见过很多同学，一本书一周翻完，笔记工整，概念都能画线，但合上书什么也说不出来。原因是阅读太被动了，眼睛扫过文字，大脑其实没有参与。
破解方法特别老土：做课后题，做实验，写总结。概论教材的课后题通常不难，但需要你用自己的话重组概念，这本身就是一种自然证明。实验更不用说，网络抓一次包、数据库建一次索引、AI跑一次训练，抵得上读十遍书。别贪多，每个主题完成一个最小实验就够。如果什么都不做，只是在“读过”层面自我感动，下次和别人聊起时你会真实地意识到大脑一片空白。
我把常见问题和应对策略整理成一张速查表，方便你对照自查：
| 问题表现 | 根本原因 | 应对办法 |
|---|---|---|
| 概念背完就忘 | 孤立记忆，没有因果链 | 用自然证明式推导重走关键结论 |
| 只会说术语，不会解释原理 | 只记名词，没有还原机制 | 画分层图并标注“为什么” |
| 实验做不出效果 | 只复制命令，不理解参数含义 | 先读文档，再手敲命令并观察输出 |
| 学完不知道有什么用 | 缺乏全景视角 | 按章节主线串讲给朋友听 |
| 读得很慢且进度停滞 | 想在每个细节上做到完美 | 先概览全章，再带问题精读重点 |
5. 这些章节与现代开发和面试的连接点
5.1 日常工作里到处是这本书的影子
很多人觉得概论教材和实际工作脱节，其实恰恰相反。你写后端接口，要懂HTTP状态码、TCP连接复用、数据库索引、事务隔离级别，这些原型全在5-12章里。你写前端页面，要理解浏览器渲染流程，要知道HTTPS为什么能防窃听，要明白Cookie和Session的区别，这些同样来自这些章节。甚至你排查一个线上卡顿问题，最终往往会落到“是不是慢查询没走索引”“是不是网络重传导致延迟增加”这类基础判断上。
面试更是直接检测这些基础功底的场所。我举几个常见的经典问题，你都能在5-12章里找到原型：
- 从输入URL到页面渲染，中间发生了什么？对应网络、Web、图形渲染的串联。
- 进程和线程有什么区别？对应操作系统与并发的核心概念。
- 数据库索引为什么能加快查询？对应B树、数据结构的复杂度分析。
- 对称加密和非对称加密有什么区别，HTTPS为什么用混合方案？对应信息安全与密码学基础。
- 如果数据量从1万涨到1亿，你选的算法和数据结构还能用吗？对应复杂度思维。
这些问题都不需要你背出某本框架文档，它们考察的就是你能否从底层原理解释上层现象。所以这本教材不是在给你“过时的基础”，而是在给你一套可以迁移到任何新技术上的思考框架。
5.2 不同基础的人应该怎么分配阅读精力
如果你是还没接触过编程的初学者，我建议按顺序通读，不要跳过计算理论部分。前4章帮你建立硬件心智模型，5-12章帮你建立软件生态全景，这个顺序是最平滑的。每章读完后，至少完成教材里的3道课后题，并挑一个最简单的实验做一遍。
如果你是跨专业转码，时间紧张，可以先把重心放在网络、算法、数据库和软件工程这四个主题上，它们和面试、日常开发的关联最紧密。程序设计语言章节可以结合你正在学的语言去对照，图形学和AI先掌握直觉理解即可，计算理论第一遍读到“理解停机问题不可判定”就够了，不必死磕所有细节。
如果你已经在职，遇到瓶颈才回补基础，可以按问题索引来读。比如线上接口慢，就去重点看算法复杂度和数据库索引；项目老是出线上故障，就去读软件工程中关于测试和模块化的部分。不必从头顺到尾，把这些章节当成“基础问题词典”来查，效率更高。
我个人读完这8章最大的体会是：技术名词会过时，框架会换代，但“从一个前提推出一个结论”的能力永远不会过时。很多东西你当时觉得没用，几年后遇到一个真实问题，突然就想起书里某个机制的用意，那种感觉类似拼图最后一块落位——整个系统一下子通了。如果你也打算读第5到12章，我建议你给自己留一个能连续投入的完整周期，每周两到三章、同步做实验，读完后找一个你用过的系统，尝试用这本书的语言重新解释它。到那时你会发现，你看到的不是一堆器件和代码，而是一整套环环相扣的工程设计。
