计算机与编程基础：从组成原理到Python、HDFS与PLC实战

“计算机与编程基础知识”这几个字，很多人第一次听到是在大学第一节课的PPT封面上，第二次听到就是在面试被问懵的时候。它听起来像是最没有门槛的东西，恰恰又是最容易露怯的地方。真实情况是，工作三五年之后还在回头补这部分内容的人特别多：写Python能跑起来，但问他为什么内存不够用、为什么多线程没变快、为什么HDFS块要设128MB，答不上来。这篇东西就是把这层“基础”拆开讲，从机器怎么执行代码，到语言怎么选、环境怎么搭、大数据和工业场景里的编程长什么样，再到考证、毕设、面试这些现实问题。不管你是刚接触编程的新手，还是已经能写业务代码但想补底子的从业者，都可以按自己的节奏挑着看。

1. 先把“计算机与编程基础”这件事说清楚

1.1 从热搜里能读出什么真实需求

如果去看跟“计算机”“编程”相关的搜索词，会发现一个很有意思的分层。最上层是特别具体、特别急的问题，比如“安装sqlserver2008r2重新启动计算机失败”“小黑课堂计算机一级ms安装包”“你尝试预览的文件可能对你的计算机有害”；中间层是学习路径类，比如“计算机二级c语言”“python编程基础”“plc编程入门基础知识”；再往下是概念类，比如“计算机组成原理”“计算机操作系统管程和协程”“计算机系统结构”。

这三层恰好对应了三种人。第一种是正被环境问题卡住的考生或初学者，他们的痛点非常即时，装不上就是装不上；第二种是有明确目标的学习者，要考证、要转行、要接活；第三种是已经过了入门期，开始发现“会写”和“写得好”是两回事的人。这三种需求没有高下之分，但它们需要的知识组织方式完全不同。环境问题需要的是排查顺序和报错解读能力，而不是从头学一遍操作系统；概念问题需要的是把抽象名词落到具体场景里，比如管程和协程，光背定义没用，得知道什么时候该用哪个。

所以“计算机与编程基础”这个题目，真正的难点不是内容多，而是它的层次太杂。你要在一套体系里同时容纳“双击安装包没反应”和“内存屏障为什么能保证可见性”，这两件事之间的跨度，比很多人想象的大得多。

1.2 基础知识的取舍边界

我自己的判断标准很简单：凡是能解释“为什么这样设计”的知识，都算基础；凡是只记结论、换台机器就不成立的，算临时信息。举个例子，知道TCP三次握手是基础，因为它解释了为什么连接建立要有往返确认，这个逻辑在写网络程序、排查超时的时候天天用。而记住某个版本软件的安装向导第五条要点什么，属于临时信息，换个版本就废了。

按这个标准，计算机组成原理里的数据表示、存储层次、指令执行流程，操作系统里的进程线程、内存管理、文件系统，编程语言里的类型系统、作用域、并发模型，这些是必须啃的。而具体的某个框架API、某IDE的快捷键、某个软件的注册表位置，用的时候查就行。

另外要提醒一句，很多人把“基础”和“底层”划等号，觉得不手写汇编就不算懂计算机。这个想法会把人拖死。基础的核心是建立正确的模型和直觉，不是把每一层都用同一种深度挖穿。你能说清楚一次内存访问比一次寄存器访问慢多少量级、一次磁盘随机读写比内存慢多少量级，这个直觉在性能优化时比会写汇编有用得多。

2. 计算机组成原理：机器是怎么把一行代码跑起来的

2.1 五大部件与数据的实际流向

教科书上讲计算机由运算器、控制器、存储器、输入设备、输出设备组成，很多人背完就忘了。其实这五个部件的关系可以用一个厨房类比：存储器是冰箱和操作台，运算器是灶台，控制器是那个盯着菜谱喊口令的厨师长，输入设备是你买回来的菜，输出设备是端上桌的盘子。现代CPU把运算器和控制器打包在一起，还塞进了高速缓存，但基本角色没变。

关键在于理解数据流动的方向。以Python里执行a = b + c为例，变量b和c的值可能躺在内存里，CPU要把它们搬到寄存器（寄存器本质上是灶台边上那个伸手就能拿到的小碟子），算术逻辑单元做完加法，结果再写回去。这个过程叫“取指-译码-执行-写回”，每一轮都要走一遍。你会发现一个事实：程序快不快，很大程度上取决于数据有没有待在离CPU足够近的地方。

这也是为什么“数组遍历比链表遍历快”这类结论会反复出现。不是因为链表逻辑复杂，而是因为数组元素在内存里连续排列，CPU的预取机制一次能捞一大把；链表节点分散在内存各处，每次都要等一次新的内存访问。这个差异在数据量小的时候感知不到，数据量上去以后能差好几倍。

2.2 存储层次：那些数字决定了程序快慢

我建议每个人都记住一组量级数字，不用精确，但要形成直觉：

这张表最实用的地方在于换算。主存访问100纳秒，固态盘访问100微秒，差了1000倍；机械盘再差10倍以上。这意味着一个频繁查数据库但没加缓存的接口，瓶颈大概率不在SQL写得漂不漂亮，而在每次都要去“楼下仓库”拿东西。知道这个之后，优化方向就清楚了：先把热点数据往上层搬，再谈算法。

还有个容易被忽略的点：缓存行通常是64字节。如果你有两个线程频繁修改同一个缓存行里的不同变量，会引发伪共享，性能反而比单线程还差。这个问题在Java的@Contended、C++的alignas里都有对应解法，但前提是你知道有这回事。

2.3 指令周期、流水线与“为什么循环要写得更紧凑”

单条指令执行分好几步，如果老老实实一条做完再做下一条，CPU大部分时间在等。流水线就是把不同步骤重叠起来：第一条指令在译码时，第二条已经在取指。理想情况下每个时钟周期都能产出一条指令的结果，这就是所谓的“每周期指令数”概念。

但流水线怕两件事：一是分支跳转，二是数据依赖。分支预测猜错了，整条流水线要清空重来，代价可能是十几个周期。数据依赖则是后面的指令要等前面的结果。

这解释了两个常见的代码习惯。第一，为什么把最可能成立的条件放在if分支前面（而不是else）有时能带来性能差异；第二，为什么在性能敏感的循环里，尽量减少内部的条件判断和函数调用。当然，现代编译器优化很聪明，很多小技巧它自己会做，但如果你写的是解释型语言（比如Python），这些开销就实打实地落在你头上。这也是为什么数值计算场景会推荐用NumPy——它把循环下沉到了C层面，同时利用了连续内存访问。

3. 编程语言与编程范式：怎么选、怎么用、怎么不迷路

3.1 语言选型的现实逻辑

新手最常问的问题是“我该学哪门语言”。标准答案“看你做什么”太敷衍，我给一个更可操作的判断框架。

第一看你要解决的问题所在的生态。做数据分析、爬虫、脚本自动化，Python的库生态是压倒性的；做嵌入式、单片机、PLC上位机通信，C和C++基本绕不开；做企业级后台，Java和C#各有阵地；做数据分析的交互式探索，R和Python都在用；做工业控制逻辑，IEC 61131-3体系下的梯形图、结构化文本才是主角。

第二看学习成本和你现有基础。如果你完全零基础，Python的语法负担最小，能让你把注意力放在逻辑而不是分号和大括号上。如果你有C语言基础，转C++、Java、C#都不算难，因为类型系统和编译流程的思路是通的。

第三看就业市场的真实需求，而不是培训机构的宣传。这个要自己去看招聘信息，注意区分“必须掌握”和“加分项”。

有个常见误区是追求“学一门语言吃一辈子”。实际上语言是工具，真正迁移的是那套思维方式：怎么拆解问题、怎么设计数据结构、怎么处理错误、怎么组织模块。我见过从VB6转到C#再转到Python的人，也见过只会一门语言但写出来的东西质量极高的人。语言切换的成本，远低于你想象。

3.2 四种范式：过程式、面向对象、函数式、异步

过程式编程是最直观的：把步骤一条条列出来，顺序执行。它的优点是简单直白，适合脚本、算法实现、硬件初始化这类线性逻辑。缺点是当状态变多以后，全局变量满天飞，改一处崩三处。

面向对象的核心不是“必须有类和继承”，而是把数据和操作数据的方法绑在一起，通过封装控制变化的影响范围。判断一个设计好不好，看的是改一个需求要动几个文件。如果每次加个功能都要改十几个类，那说明抽象层次没找对。

函数式编程强调无副作用和不可变数据，在并发场景下优势明显，因为不存在共享状态被改来改去的问题。实际工程里很少纯函数式，但把纯函数、不可变对象这些思想局部用起来，能显著减少诡异bug。

异步编程解决的是IO等待问题。同步模式下，一个网络请求要等几百毫秒，线程就干等着；异步模式下，等待期间可以去处理别的任务。这里要区分清楚：异步不等于多线程。单线程也能做异步（比如事件循环），多线程也不一定异步（每个线程各自阻塞）。Python的asyncio、JavaScript的Promise、C#的async/await都是这个思路的不同实现。

3.3 AI 编程与提示词：把它当结对搭档而不是代写

AI辅助编程现在确实好用，但用得好和用得差差别极大。我观察下来，效果差的人通常是直接把需求一句话丢过去，然后拿着生成结果硬跑，报错了再贴回去让它改，来回几轮之后自己也乱了。

比较靠谱的用法是三步。第一步，把上下文给足：语言版本、依赖库、运行环境、这段代码在整个项目里的位置、输入输出的数据结构。第二步，把任务拆小，一次只让它解决一个明确的问题，比如“写一个函数，输入是起始日期和结束日期，输出是这两个日期之间的工作日列表，跳过法定节假日，节假日以列表参数传入”。第三步，自己读懂再合并，尤其是边界条件、异常处理、资源释放这几块，AI生成的内容经常在这里偷懒。

还有一个要警惕的点：不要让它替你决定架构。小工具类代码让它写完全没问题，但涉及数据模型设计、并发策略、错误恢复机制这类决策，必须自己想清楚。否则你会得到一个能跑但改不动的系统，后面每次加需求都是折磨。

4. 上手实操：搭一套能长期用的 Python 环境

4.1 版本与工具选择

先说结论：如果今天开始学Python，直接装3.11或3.12的稳定版本，不要为了兼容某个老教程去装2.7。Python 2在2020年就停止维护了，很多新库已经不支持，踩坑成本远大于收益。

工具链我建议这样配：Python本体从官网下载安装，安装时勾选“Add Python to PATH”，这一步很多人漏掉，导致后面命令行里敲python提示找不到命令。编辑器先用VS Code加Python扩展，轻量、启动快、调试界面清楚；等之后做数据分析再换Jupyter Notebook，做大型项目再考虑PyCharm。

虚拟环境是必须养成的习惯。每个项目一个独立环境，用python -m venv .venv创建，激活后装的库只影响这个项目。这样做的好处是避免库版本冲突——你做项目A需要旧版某库，做项目B需要新版，没有虚拟环境就只能反复卸载重装。

# 创建虚拟环境 python -m venv .venv # Windows 激活 .venv\Scripts\activate # macOS / Linux 激活 source .venv/bin/activate # 确认当前解释器路径 which python

注意：激活虚拟环境后，命令行提示符前面通常会出现环境名。如果没出现，说明激活失败，这时候装库会装到全局环境，后续项目会互相污染。

4.2 第一个脚本：求长方体体积

这个例子看着简单，但能把输入输出、类型转换、异常处理、函数封装都串一遍。

def cuboid_volume(length, width, height): """计算长方体体积，输入单位需一致""" for name, value in (("长", length), ("宽", width), ("高", height)): if value <= 0: raise ValueError(f"{name}必须大于0，当前值：{value}") return length * width * height def main(): try: length = float(input("请输入长：")) width = float(input("请输入宽：")) height = float(input("请输入高：")) volume = cuboid_volume(length, width, height) print(f"长方体体积为：{volume:.2f}") except ValueError as e: print(f"输入有误：{e}") if __name__ == "__main__": main()

这段代码值得注意的地方有三处。第一，把计算逻辑抽成独立函数，和输入输出分开，这样以后要做批量计算或者写单元测试都很方便。第二，参数校验放在函数内部而不是调用处，保证无论谁调用都安全。第三，if __name__ == "__main__"这个写法，让文件既能直接运行，也能被别的模块导入而不触发执行。

很多人写练习代码时直接一坨写到底，能跑就行。但养成这种分层习惯，到了写几百行以上的程序时，差距会非常明显。

4.3 调试习惯与报错阅读方法

Python的报错信息其实信息量很大，关键是读法。拿到一个traceback，先看最后一行，那是异常类型和描述；然后从下往上找第一个出现在你自己代码文件里的行号，那才是问题所在；中间那些库内部的调用栈通常可以直接跳过。

举个例子，如果你看到TypeError: can only concatenate str (not "int") to str，意思是有人试图把字符串和整数用加号连起来。这在刚学时特别常见，比如print("年龄：" + age)，改成f-string就行。

我自己的调试顺序是：先打日志确认变量值是不是你以为的那样，再确认函数有没有被调用到，最后才怀疑库的问题。实际经验里，九成以上的bug都在前两步。另外一个技巧是把大段代码注释掉一半，看问题还在不在，用二分法快速定位，比一行行读快得多。

提示：如果程序卡住不报错也不退出，八成是死循环或者阻塞在IO上。这时候用调试器挂上去看当前线程停在哪一行，比盲猜高效。

5. 大数据编程入门：HDFS 与 MapReduce 到底在解决什么

5.1 HDFS 的存储模型与块大小

单机存不下的数据，要分散到多台机器上，这就是分布式文件系统要解决的问题。HDFS的做法是把文件切成固定大小的块，默认128MB，每块存多份（默认3副本），分散到不同机器上。这样做的好处是：单块损坏可以从副本恢复；读取时可以并行从多台机器拉数据；计算任务可以调度到数据所在的机器上跑，减少网络传输。

128MB这个数字不是随便定的。早期机械硬盘的顺序读写带宽大概在100MB/s上下，128MB意味着读取一个块大约需要1秒多，这个时间足够启动一个计算任务而不至于让任务调度开销占比过高。块太小，元数据压力大、寻址次数多；块太大，任务并行度不够，一个慢节点会拖累整体。

实际写程序时要注意小文件问题。如果一个目录下有几十万个几KB的文件，NameNode要维护海量元数据，内存会撑不住，同时每个文件都要单独起任务，调度开销远大于计算本身。通常的做法是先合并成SequenceFile或者Parquet这类容器格式再处理。

5.2 MapReduce 编程实例：词频统计全过程

词频统计是理解MapReduce最经典的例子，因为它把“分而治之”的思路展示得最清楚。

Map阶段：每台机器读自己负责的那部分数据，把每一行拆成单词，输出键值对(单词, 1)。这个阶段完全并行，机器之间不需要通信。

Shuffle阶段：框架把相同键的记录归拢到一起，保证同一个单词的所有计数都送到同一个Reduce任务。这个过程涉及网络传输和排序，是最耗时的环节，也是调优的重点。

Reduce阶段：对每个单词收到的所有1求和，输出(单词, 总数)。

# 用Hadoop Streaming方式演示Map逻辑（标准输入读，标准输出写） import sys for line in sys.stdin: line = line.strip() if not line: continue for word in line.split(): print(f"{word}\t1")

# Reduce逻辑：输入已按key排序，只需累加连续相同的key import sys current_word = None current_count = 0 for line in sys.stdin: word, count = line.strip().split("\t") count = int(count) if word == current_word: current_count += count else: if current_word is not None: print(f"{current_word}\t{current_count}") current_word = word current_count = count if current_word is not None: print(f"{current_word}\t{current_count}")

这个写法之所以成立，是因为框架保证送到Reduce的输入已经按key排好序。理解这一点很重要，否则你会奇怪为什么不需要用字典做全量累加。当然，用字典在小数据量下也能跑，但一旦数据量超过内存就崩了，而流式累加的内存占用是常数级的。

5.3 伪分布式环境搭建的关键配置

本地学习不需要真集群，伪分布式就够了。核心配置有几项：把文件系统改成HDFS而不是本地文件系统，为NameNode和DataNode分别指定数据目录，指定副本数为1（单机没必要存3份），配置YARN作为资源调度。

最容易踩的坑是权限和目录重复格式化。如果反复执行格式化命令，会导致NameNode的集群ID和DataNode记录的不一致，现象是DataNode启动不起来。解决办法是把所有数据目录清空后只格式化一次。

第二个坑是主机名解析。配置里如果用主机名而不是IP，需要在hosts文件里有对应记录，否则连接会超时。第三个坑是内存，伪分布式默认堆内存可能超过你机器的可用内存，需要手动调小。

我在自己的机器上试过，给NameNode分配1GB、DataNode分配1GB、YARN的NodeManager分配2GB，跑教学用的词频统计完全够用。调这些参数的时候记得同步改对应的环境变量，只改一处是不生效的。

6. 工业与嵌入式：PLC、单片机与那些“教材外的编程”

6.1 PLC 的扫描周期与梯形图思维

PLC编程和通用软件开发最大的区别是执行模型。PC程序是按代码顺序跑，PLC是循环扫描：读输入、执行逻辑、写输出，一圈一圈不停。这个循环时间叫扫描周期，通常在几毫秒到几十毫秒。理解这一点之后，很多写法就能解释通了。

比如，PLC里不用“等待”这种操作，因为等待会拖长扫描周期，导致输出响应变慢。需要延时就用定时器指令，让它在后续扫描中判断时间到没到。再比如，如果输出依赖多个条件，要靠中间变量和状态位来组织，而不是像普通程序那样嵌套一堆判断。

梯形图看起来像电路图，左边是电源轨，右边是回路，触点串联是“与”，并联是“或”。这种表示法对电气背景的人很友好，但复杂逻辑用梯形图画会很难维护。所以实际工程里，复杂控制多用结构化文本，梯形图留给互锁、启停这类简单可靠的部分。

有个经验是：涉及安全的部分（急停、限位、过载保护）一定要用硬件回路兜底，不能只靠程序判断。软件会死机，继电器不会。

6.2 VB6 能不能写嵌入式

这个问题偶尔会有人问。结论很直接：基本不行，至少不是主流做法。VB6编译出来的是运行在Windows上的本地代码，依赖运行库，体积和资源占用对单片机来说都太大了。单片机开发主流是C语言，因为可以直接操作寄存器、控制内存布局、代码尺寸可控。C++在资源稍宽裕的嵌入式场景也在用，但一般会限制异常和RTTI这些特性。

那VB6还有用吗？写上位机是有的。很多老产线上的工控机还在跑VB6写的界面程序，通过串口或以太网跟下位机通信。维护这类系统的时候，改界面逻辑、调通信协议都是常见工作。所以如果你是维护老系统，学VB6的价值在于读懂和修改现有代码；如果是新做嵌入式开发，别往这个方向投入。

STM32这类的开发环境现在是Keil、IAR或者基于GCC的工具链，配合厂商提供的配置工具生成初始化代码，再在生成的框架里填业务逻辑。这种“工具生成骨架+手工填肉”的模式，跟现代前端、后端开发其实很像。

6.3 几个领域里的编程长什么样

顺便说说那些看着不像“编程”但其实在编程的场景，这个视角有助于理解编程的本质是“把规则翻译成机器能执行的形式”。

同花顺这类股票软件的指标编程，写的是公式语言，本质上是时间序列上的表达式计算，比如均线就是某段窗口内的算术平均。Fusion360的刀路编程，是把加工策略和几何参数翻译成机床能走的路径，核心约束是刀具半径、切削深度、进给速度。MATLAB做有限元求解，是构造刚度矩阵然后解线性方程组，重点在网格划分和边界条件设置。这些场景里，语法都是小事，难的是理解背后那个领域的物理规律和工程约束。

这也回答了一个常见的困惑：为什么有些人换了个领域就写不动代码了。因为他们掌握的是语法，不是领域知识加建模能力。

7. 操作系统里的并发：进程、线程、协程与管程

7.1 四个概念的边界

这四个词经常被混着用，但它们的抽象层级完全不同。

进程是资源分配的单位。它拥有独立的地址空间、文件描述符表、信号处理等。进程之间隔离性好，但切换成本高，通信要走IPC。

线程是调度的单位。同一个进程内的多个线程共享地址空间，所以切换快、通信方便，代价是需要自己处理同步问题，一个线程崩了整个进程都受影响。

协程是用户态的轻量执行单元。它的切换不经过内核，由程序自己控制，所以在单线程里就能实现高并发IO。代价是如果一个协程里做了阻塞操作，会把整个线程卡住。

管程是一种同步机制，不是执行单元。它把共享变量和对它的操作封装在一起，保证同一时刻只有一个线程在管程内部执行。Java里synchronized修饰的方法就类似管程的语义。理解管程的关键是：它是用来解决“多个线程怎么安全地访问同一份数据”这个问题的，而不是用来解决“怎么让程序跑得更快”的。

7.2 选型建议与常见误解

选择策略可以这样归纳：CPU密集型任务用多进程，因为能真正并行利用多核；IO密集型任务用多线程或协程，因为等待期间可以切去干别的；需要极高并发连接数（几万以上）时，协程优势明显，因为每个连接的内存开销远小于一个线程。

常见的误解有两个。第一，以为多线程一定能加速。如果任务本身是CPU密集的，加上语言有全局解释器锁，多线程反而会因为切换开销变慢。第二，以为异步就是快。异步提升的是吞吐量，单个请求的延迟不会因此变短，因为IO本身的时间省不掉。

还有一个隐蔽的坑是共享可变状态。加锁能保证正确性，但锁的粒度、加锁顺序都可能出错。死锁的典型成因就是两个线程以相反顺序获取两把锁。排查这类问题最好的办法是把所有加锁点的顺序写成文档，强制统一。

8. 学习路线、考证与面试的落地打法

8.1 二级、三级怎么安排

计算机等级考试是很现实的目标，它的好处是给了你一个明确的进度表。二级里的MS Office和WPS方向偏应用操作，把真题过一遍、把常用的函数和数据透视练熟，通过率会明显提高。Python和C语言方向则要真的写代码，光看题解没用，得自己敲一遍。

我的建议是先明确用途。如果是为了毕业门槛或者简历上一个凭证，选跟自己专业最相关的方向。如果是想借考试逼自己入门编程，那选Python方向，因为它能把你引到真正能用的技能上，而不是考完就忘。

三级、四级更偏理论和系统，内容涉及操作系统、数据库、网络。这些知识本身有价值，但考试形式偏记忆，所以备考时要搭配动手实践。比如学数据库就真的装一个环境，把建表、索引、事务写一遍，比背概念有效得多。

8.2 保研面试与毕业设计怎么准备

保研面试被问到的技术问题，通常不会太偏，但会很基础。常见的问法包括：解释一下进程和线程的区别；数组和链表的适用场景；什么是索引，为什么能加速查询；学过哪些课，做过什么项目。这些问题答得是否清晰，取决于你平时有没有想过“为什么”，而不是背了多少八股。

毕业设计的坑主要在选题和时间管理。选题不要贪大，一个能完整跑通、有明确输入输出、能演示的小系统，比一个概念宏大但只做了三分之一的东西强。技术选型上，优先选你熟悉且资料多的栈，别在毕设期间第一次学新框架。

时间安排上，把论文写作往前放。很多人把代码拖到最后，写完才开始写论文，结果实验数据不全、图表要重做。我的做法是边做边记，每完成一个模块就补一小节文字和截图，最后组装起来比从零写快得多。

9. 常见问题速查与踩坑心得

9.1 安装与环境类问题速查表

这里特别说一句那个“文件可能对计算机有害”的提示。这是系统对外来文件的常规保护，不代表文件真的有问题，但也不代表可以无脑点开。合理的做法是：只从你能确认的官方渠道获取文件，如果是同事或同学发的，先确认对方确实发过；对可执行文件保持警惕，文档和压缩包风险相对低。企业内部环境里，走统一的软件分发渠道是最省事的。

9.2 几条我自己一直在用的经验

第一条，把“能跑”和“懂”分开对待。学习阶段允许先跑通再回头理解，但不能永远不回。我会给自己定个规矩：任何一段代码，如果三天后我还说不清它为什么这么写，就重写一遍。

第二条，报错信息一定要完整读完再动手搜。很多人看到红字第一反应是复制第一行去搜，结果搜出来的答案驴唇不对马嘴，因为关键信息在最后一行。养成从头读到尾的习惯，能省下大量时间。

第三条，环境问题优先怀疑最近改过的东西。程序昨天还好好的，今天不行了，那大概率是你昨天改了配置、装了新库、或者系统更新了。沿着时间线往回找，比漫无目的地试快得多。

第四条，别在工具上花太多时间。选编辑器、配主题、折腾各种插件，这些事带来的成就感很虚，但对能力提升几乎没有帮助。选定一套用上半年，把精力放在真正的问题上。

第五条，保持一个自己的代码片段库。常用的文件读写、日志配置、参数解析、重试逻辑，整理成可以直接复用的模板。这个习惯坚持一年，你会发现自己写新东西的速度明显不一样。

最后再分享一个小技巧，关于学新东西的节奏。遇到一个陌生的概念，先花十分钟搞清楚它解决什么问题、在什么场景下用，然后立刻写一个最小的可运行示例。理解和使用交替进行，比先啃完一本厚书再动手要快得多，也不容易中途放弃。