用Python手写极简区块链：区块、哈希与工作量证明实战

如果让我从自己的实践里推荐一个能把 Python 类、哈希算法、数据结构甚至 Web 接口全部串起来的练手项目，我会选“用 Python 从零写一个极简区块链”。先别被名字吓到，我对朋友做白话解释时特别简单：它就是一个不允许轻易改动的账本，账本的每一页都带着前一页的“指纹”，任何一页被涂改，后面所有页都会对不上。这篇文章我会带着你从空文件开始，写出一个能挖矿、能记账、能校验、并且能被浏览器查询的小型区块链。整个核心实现只依赖 Python 标准库，也完全不涉及真实货币和网络；重点是把区块、哈希、工作量证明这些概念一个个拆开揉碎。适合有基础 Python 语法、想真正理解区块链底层逻辑的人，哪怕是准备技术面试，你也可以用这段代码把共识和防篡改讲得明明白白。

在正式写代码前，先花点篇幅把设计讲清楚，带着这张图开始，后面动手会顺畅很多。

1. 项目整体设计与思路拆解

1.1 区块链大白话：什么是“链”上的区块

我曾试过用一句话向完全没接触过的人解释区块链，最有效的是把它想成“一本每一页都印着前一页防伪码的财务账本”。账本的每一页叫“区块”，里面记录若干条交易信息。每一页除了记录交易，还会印上一个由本页所有内容计算的哈希值，这串哈希可以理解成该页的唯一防伪码。这本账本的特别之处在于，每一页还会把上一页的防伪码抄到自己页面上。所以如果某人想把第 3 页的交易从 100 元改成 999 元，第 3 页的哈希立刻改变，而第 4 页上记录的还是第 3 页原来的哈希，两者就对不上了。想继续伪造，他必须把从第 4 页开始的所有页面全部重写，并且每一页都要做一次很费劲的“找哈希”计算。正是因为重写整本账的成本极高，才让链上的历史数据变得难以篡改。

刚才提到的“很费劲的找哈希”，就是常说的工作量证明 PoW。真实区块链中矿工做的事情，本质上就是对新页面找一个随机数，让新页面的哈希满足一定条件，例如“前 4 个字符必须是 0”。这个条件没有聪明解法，只能拿不同的 nonce 值一遍遍试哈希。哈希函数像一台单向搅拌机，输入稍微变化，输出就会完全不一样；

1.2 为什么用 Python 来手写区块链

这个项目选择 Python，核心是四个字：开发效率。区块链技术本身有大量抽象概念，而 Python 的类、字典、列表能非常直观地对应上区块、交易、节点等结构。在验证共识、链完整性、Web 接口这些功能时，Python 几十行代码就能搭出原型，这对理解原理特别有帮助。如果一上来就使用复杂的 C++、Go 或者 Rust，很多精力会消耗在内存管理、模块组织等基础设施上，反而不利于抓住核心。

技术选型方面，做核心区块和链的部分，只需要三个标准库：hashlib 计算 SHA-256 哈希、json 做区块数据的序列化、time 记录时间戳。如果你希望把链发布到浏览器里查看，可以额外装一个轻量级的 Flask，仅仅是为了提供 HTTP 接口。整套代码的“正确最小依赖”其实比很多人想象中少，这也从侧面证明区块链底层的“账本结构”并没有那么高不可攀。

我在设计时坚持把代码分成四块：

• Block 类：负责定义区块字段，计算当前区块哈希。
• Blockchain 类：负责维护整条链、创建创世区块、追加新区块。
• 工作量证明函数：负责给区块寻找满足难度的 nonce 值。
• Web 展示层：把区块数据通过 JSON API 暴露给浏览器或命令行，主要是为了验证和观察。

这样拆分后，哪怕你只想理解其中某个模块，也不用被几百行代码绕晕。

1.3 动手前先检查 Python 环境

写和运行代码前，最好先确认你的机器上有可用的 Python 环境。我自己在 Windows、macOS、Linux 都跑过，只要是 Python 3.8 以上版本，核心代码基本不需要额外安装依赖。

先打开终端或命令提示符，执行：

bash复制python --version

如果没有正确输出版本，说明你可能还没把 Python 加入环境变量。Windows 安装比较简单，去 Python 官网下载对应安装包，安装时务必勾选“Add Python to PATH”，这是初学者最容易忽略的一步，勾不勾会直接影响后续能否在命令行里直接使用 python 命令。

如果你使用 VSCode 开发，我建议做两件事：第一，安装官方 Python 扩展；第二，在项目目录里创建一个虚拟环境，避免把不同项目的依赖混在一起。

bash复制python -m venv venv

Windows 下激活虚拟环境的命令是：

bash复制venv\Scripts\activate

macOS 或 Linux 下是：

bash复制source venv/bin/activate

激活后命令行前面会出现 (venv) 字样，再执行 python 就走的虚拟环境。如果在 Web 演示部分需要 Flask，再执行：

bash复制pip install flask

看到这里，环境已经就绪。接下来进入最核心的部分，先从区块的数据结构和哈希计算说起。

2. 核心原理与实现细节：区块、哈希与工作量证明

2.1 区块结构设计：先明确一个区块里放什么

我在自己第一次写区块链代码时，犯过“把功能堆在一起”的毛病。后来琢磨清楚，区块对象其实只需要几个关键字段就够了：

index 是区块高度，从 0 开始递增，方便确认顺序；
timestamp 是区块生成时间；
transactions 是交易列表，在这里用 Python 字典来模拟；
previous_hash 是上一个区块的哈希值，这是形成“链”的核心；
nonce 是挖矿时用于暴力尝试的随机数；
hash 是当前区块自己的哈希值。

计算哈希时，我想强调一个容易踩坑的点：区块中存放的 hash 字段本身不应该参与自身的哈希计算，否则你会陷入“自己包含自己”的循环。正确做法是，把除 hash 以外的字段，按照固定顺序序列化，再用 SHA-256 计算摘要。我习惯用 sort_keys=True 对字典键排序，并用 separators=(",", ":") 去掉多余空格，这样保证同一份逻辑在任何平台、任何时候计算出来的结果都一致。

下面是基础版区块类的代码：

python复制import hashlib
import json
import time


class Block:
    def __init__(self, index, transactions, previous_hash, nonce=0):
        self.index = index
        self.timestamp = time.time()
        self.transactions = transactions
        self.previous_hash = previous_hash
        self.nonce = nonce
        self.hash = self.compute_hash()

    def compute_hash(self):
        block_string = json.dumps({
            "index": self.index,
            "timestamp": self.timestamp,
            "transactions": self.transactions,
            "previous_hash": self.previous_hash,
            "nonce": self.nonce
        }, sort_keys=True, separators=(",", ":")).encode()
        return hashlib.sha256(block_string).hexdigest()

    def __repr__(self):
        return (f"<Block #{self.index} hash={self.hash[:10]}... "
                f"prev={self.previous_hash[:10]}... "
                f"txns={len(self.transactions)}>")

我想特别解释一下 separators=(",", ":") 这个参数。如果不去掉空格，和某个外部系统交换数据时，只要对方序列化方式不同，计算的哈希就可能不一致。真实区块链系统里，为了全网统一，序列化规则必须是严格标准。哪怕一个空格不同，哈希就面目全非。这也是为什么后面的链校验模块必须保证“怎么写入，就怎么校验”。

2.2 创世区块：整条链的第一个“页”

要把链起来，第一页的“上一页哈希”并没有现成的页码可抄。行业通用的做法是创造一个创世区块，也就是高度为 0 的区块，它的 previous_hash 用一个约定好值的字符串，例如 64 个字符的 "0"*64。

python复制def create_genesis_block():
    return Block(0, [], "0" * 64)

你是不是想问，这样造出来的创世区块太容易被伪造？需要明确一点：创世区块通常是被硬编码进节点代码的，所有诚实的节点启动时都从这个固定区块开始。它没有历史，所以不涉及“被连接”的问题。我们后面写链校验函数时，也只需要检查下标从 1 开始的区块，下标 0 作为信任锚点使用就好。

有了创世区块，新区块的产生逻辑就清晰了：每要生成一个新区块，就把当前链上最后一个区块的哈希作为新区块的 previous_hash，然后把待打包的交易列表填进去，寻找满足难度的 nonce。这条链接就像一条不停长出尾巴的火车，每一节车厢都牢牢抓住前一节车厢的挂钩。

2.3 工作量证明：为什么挖矿要反复试 nonce

基础版区块在 __init__ 里已经根据初始 nonce 计算过哈希了。但在真实场景中，矿工不能直接使用第一个碰巧算出来的哈希，必须让哈希满足难度条件。我以难度 4 为例：新区块的哈希值前 4 个字符都必须是字符“0”。

python复制DIFFICULTY = 4


def proof_of_work(block, difficulty=DIFFICULTY):
    target_prefix = "0" * difficulty
    block.nonce = 0
    block.hash = block.compute_hash()
    while block.hash[:difficulty] != target_prefix:
        block.nonce += 1
        block.hash = block.compute_hash()

这段代码看起来简单，背后却是一个核心思想：SHA-256 哈希没有捷径，你无法预知哪个 nonce 能算出满足条件的哈希，只能不断尝试。一个十六进制字符有 16 种可能，难度 4 要求前 4 个字符全为 0，平均要尝试约 16 的 4 次方，也就是 65536 次。你自己的电脑跑这一点并不慢，但如果你把难度调到 6，平均尝试次数会变成 1600 万次，马上就能感受到“工作量”的存在。

真实网络中，矿工反复变更 nonce 寻找目标哈希，这个过程就是“挖矿”；而调整难度，是为了让全网无论算力如何增长，平均出块时间都保持稳定。在教学中，你已经可以通过调节 DIFFICULTY 来观察不同难度下出块速度的巨大差异。建议动手实验一次：难度 3 时可能几十毫秒出一个块，难度 5 时就要明显等待了，这是理解工作量证明最直观的感受。

3. 组装一个能跑的极简链：完整代码与运行结果

3.1 单文件实现：区块、链、挖矿与校验

前面已经准备好组件，现在把它们组装成一个可运行的完整类。为了便于你直接复制运行，我给出一个单文件版本，将区块类、区块链类、工作量证明和链完整性校验放在一起。

python复制import hashlib
import json
import time


DIFFICULTY = 4


class Block:
    def __init__(self, index, transactions, previous_hash, nonce=0):
        self.index = index
        self.timestamp = time.time()
        self.transactions = transactions
        self.previous_hash = previous_hash
        self.nonce = nonce
        self.hash = self.compute_hash()

    def compute_hash(self):
        block_string = json.dumps({
            "index": self.index,
            "timestamp": self.timestamp,
            "transactions": self.transactions,
            "previous_hash": self.previous_hash,
            "nonce": self.nonce
        }, sort_keys=True, separators=(",", ":")).encode()
        return hashlib.sha256(block_string).hexdigest()

    def __repr__(self):
        return (f"<Block #{self.index} hash={self.hash[:10]}... "
                f"prev={self.previous_hash[:10]}... "
                f"txns={len(self.transactions)}>")


class Blockchain:
    def __init__(self):
        self.chain = [self.create_genesis_block()]
        self.pending_transactions = []

    def create_genesis_block(self):
        return Block(0, [], "0" * 64)

    @property
    def last_block(self):
        return self.chain[-1]

    def add_transaction(self, sender, receiver, amount):
        self.pending_transactions.append({
            "sender": sender,
            "receiver": receiver,
            "amount": amount
        })

    def proof_of_work(self, block):
        target_prefix = "0" * DIFFICULTY
        block.nonce = 0
        block.hash = block.compute_hash()
        while block.hash[:DIFFICULTY] != target_prefix:
            block.nonce += 1
            block.hash = block.compute_hash()

    def mine_pending_block(self, miner_address):
        miner_reward = {
            "sender": "系统",
            "receiver": miner_address,
            "amount": 50
        }
        txns = [miner_reward] + list(self.pending_transactions)
        block = Block(len(self.chain), txns, self.last_block.hash)
        self.proof_of_work(block)
        self.chain.append(block)
        self.pending_transactions = []

    def is_chain_valid(self, chain=None):
        chain = chain if chain is not None else self.chain
        for i in range(1, len(chain)):
            current = chain[i]
            previous = chain[i - 1]
            if current.previous_hash != previous.hash:
                return False
            if current.compute_hash() != current.hash:
                return False
            if current.hash[:DIFFICULTY] != "0" * DIFFICULTY:
                return False
        return True

    def get_balance(self, address):
        balance = 0
        for block in self.chain:
            for tx in block.transactions:
                if tx["sender"] == address:
                    balance -= tx["amount"]
                if tx["receiver"] == address:
                    balance += tx["amount"]
        return balance

上面代码有一个值得解释的点：为什么矿工奖励要放在 mine_pending_block 生成的区块交易列表里，而不是把奖励放到“待确认交易池”等下一个块再打包？这样做更贴近真实“coinbase 交易”的概念：每个区块的第一笔交易通常就是给矿工的奖励，它不是由别人转账产生的，而是在出块瞬间被系统创建的。代码里 sender 使用“系统”，也只是为了教学方便。

校验函数 is_chain_valid 是整条链的守卫。它要做三件事：检查相邻区块的 previous_hash 是否等于上一块的 hash；重新对每个区块的所有字段计算哈希，确认没人篡改了区块内容；检查哈希是否还满足工作量证明难度。只有这三项全部通过，链才是健康的。

3.2 跑起来：初始化、转账、挖矿与余额

先把刚才的单文件保存为 blockchain_demo.py，然后写一段主流程去调用：

python复制if __name__ == "__main__":
    bc = Blockchain()
    print("创世区块哈希:", bc.chain[0].hash)

    bc.add_transaction("Alice", "Bob", 20)
    bc.add_transaction("Bob", "Carol", 8)
    bc.mine_pending_block("Miner01")

    bc.add_transaction("Alice", "Carol", 5)
    bc.mine_pending_block("Miner02")

    print("整链有效:", bc.is_chain_valid())
    print()

    for block in bc.chain:
        print(f"高度 {block.index}")
        print(f"  交易: {block.transactions}")
        print(f"  哈希: {block.hash}")
        print(f"  nonce: {block.nonce}")
        print(f"  previous_hash: {block.previous_hash}")
        print()

    print("Alice 余额:", bc.get_balance("Alice"))
    print("Bob 余额:", bc.get_balance("Bob"))
    print("Carol 余额:", bc.get_balance("Carol"))

运行效果类似下面这样：

text复制创世区块哈希: 2a0deb52b4ce9e8f2f79cc11f359e3e0873d43c46eaa5f2d74dbb9e9e2543979

高度 0
  交易: []
  哈希: 2a0deb52...
  nonce: 0
  previous_hash: 0000000000000000000000000000000000000000000000000000000000000000

高度 1
  交易: [{'sender': '系统', 'receiver': 'Miner01', 'amount': 50}, {'sender': 'Alice', 'receiver': 'Bob', 'amount': 20}, {'sender': 'Bob', 'receiver': 'Carol', 'amount': 8}]
  哈希: 0000a4f1c11e...
  nonce: 38172
  previous_hash: 2a0deb52...

高度 2
  交易: [{'sender': '系统', 'receiver': 'Miner02', 'amount': 50}, {'sender': 'Alice', 'receiver': 'Carol', 'amount': 5}]
  哈希: 0000bb17...
  nonce: 28340
  previous_hash: 0000a4f1...

注意观察：每个块的哈希都以 0000 开头，这正是难度 4 的效果。nonce 每次运行都不一定相同，因为时间戳不同，但这不影响链的合法性。你还会发现，Miner01 和 Miner02 都各有 50 的挖矿奖励，这在简单教学模型里是故意简化的。因为我这里没有做 UTXO，也没有防止一笔钱被花两次，所谓的“余额”只是遍历区块交易后得到的一个汇总数字。

3.3 坦诚说明：这个极简版和真实区块链的差距

我们可以管现在写的代码叫“一个简化到玩具级别的区块链框架”，如果拿它去类比真实系统，还有几个关键缺失：

第一，没有数字签名。真实交易中，任何“Alice 转给 Bob”的记录都必须有 Alice 的私钥签名，别人无法伪造。而前面代码里任何人都可以直接调用 add_transaction 替 Alice 转账，账号体系形同虚设。

第二，没有 P2P 网络。现实中每个节点都保存一份全量账本，交易通过广播扩散，节点之间要协商出一个统一的链。这里只有一个本地实例，更像一个测试用的日志记录器。

第三，没有真正的共识算法。这里只有一条链，不存在分叉、最长链竞争等问题。矿工每挖出一个块就直接追加，非常“听话”。真实网络中的节点可能有恶意行为，共识算法就是来解决这些问题。

这个差距并不是缺陷，而恰恰是教学价值所在：你先把骨架理解透，再往上面添加密码学、网络、共识，每一步都清楚为什么需要。如果你想继续深入，这节提到的三个点就是三个明确的学习方向。

4. 让区块链可以被浏览器看见：本地接口与简单的“区块浏览器”

4.1 用 Flask 暴露链和挖矿接口

区块链只有自己能看见，并不直观。为了让链上的数据可以被查询和操作，我通常会给它加一个很薄的 Web API 层。这里需要先安装 Flask：

bash复制pip install flask

如果沿用上面 blockchain_demo.py 里的 Blockchain 类，可以新建一个 app.py，在文件顶部把它们 import 进来，再把 HTTP 接口定义出来。为了方便你直接理解，我写一个完整的演示版本：

python复制from flask import Flask, jsonify, request
from blockchain_demo import Blockchain

app = Flask(__name__)
bc = Blockchain()


def chain_to_json():
    result = []
    for block in bc.chain:
        result.append({
            "index": block.index,
            "timestamp": block.timestamp,
            "transactions": block.transactions,
            "previous_hash": block.previous_hash,
            "nonce": block.nonce,
            "hash": block.hash
        })
    return result


@app.route("/chain", methods=["GET"])
def full_chain():
    return jsonify({
        "length": len(bc.chain),
        "chain": chain_to_json()
    })


@app.route("/transactions", methods=["POST"])
def new_transaction():
    data = request.get_json()
    if not data or "sender" not in data or "receiver" not in data or "amount" not in data:
        return jsonify({"error": "需要 sender、receiver、amount 字段"}), 400
    bc.add_transaction(data["sender"], data["receiver"], data["amount"])
    return jsonify({"message": "交易已加入待确认池"}), 201


@app.route("/mine", methods=["POST"])
def mine():
    data = request.get_json() or {}
    miner = data.get("miner", "Miner01")
    bc.mine_pending_block(miner)
    return jsonify({
        "message": "新区块已生成",
        "height": len(bc.chain) - 1
    })


if __name__ == "__main__":
    app.run(debug=True, port=5000)

启动服务后，访问 http://127.0.0.1:5000/chain，浏览器就能看到整条链的 JSON 数据。你可以把它理解成一台只有本地网络、且不涉及真实加密货币的“区块浏览器”：能看到区块高度、哈希、交易列表，虽然不会飞，但用来观察链的变化足够了。

4.2 用 curl 快速走一遍完整流程

实际操作中，我不会总依赖浏览器，推荐用 curl 在命令行里验证，这样更接近调试习惯。按顺序执行三条命令即可：

当你执行完“查看链”后，应该能看到新增的区块高度。这个新块里第一笔交易就是矿工奖励，第二笔才是 Alice 给 Bob 转的 10。这个流程模拟了“交易进入待确认池—矿工打包—新区块上链”的经典生命周期。用命令行来完成这些操作，后面做自动化测试或扩展多节点时，会自然形成一套可复用的调用方式。

4.3 给区块内容做一个最简单的“浏览器页面”

如果你想在浏览器里看到更友好的页面，而不是一堆 JSON，可以给 Flask 增加一个 HTML 模板页面。这个页面不需要多漂亮，只要把区块的哈希、时间和交易数据列成表即可。比如写一个 /explore 接口：

python复制from flask import Flask, render_template_string

html_template = """
<!DOCTYPE html>
<html>
<head><title>极简区块链浏览器</title></head>
<body>
  <h1>极简区块链浏览器</h1>
  {% for block in chain %}
  <div style="border:1px solid #ccc; margin:10px; padding:10px;">
    <p>高度: {{ block.index }}</p>
    <p>哈希: {{ block.hash }}</p>
    <p>上一哈希: {{ block.previous_hash }}</p>
    <p>时间戳: {{ block.timestamp }}</p>
    <p>nonce: {{ block.nonce }}</p>
    <p>交易: {{ block.transactions }}</p>
  </div>
  {% endfor %}
</body>
</html>
"""

@app.route("/explore", methods=["GET"])
def explore():
    return render_template_string(html_template, chain=bc.chain)

虽然这个“浏览器”极其简陋，但当你把挖矿难度调低再连续点刷新时，能看到页面链条不断增长，对“出块”“上链”会形成更形象的印象。做技术演示时，这种可视化往往比几百行控制台日志更有说服力。

5. 常见问题与排查技巧实录

我写这个项目过程中遇到过不少小坑，也帮同事排查过几个典型问题，在这里集中记录一下。

5.1 为什么前后两次计算的哈希不一致

最常见的根源是序列化不统一。你在创建区块时计算哈希用了一段字典，但校验时又用了另一套字段顺序或者加了空格。只要两次 json.dumps 的结果不一样，compute_hash() 就算不出同一个值。解决方法是所有地方统一使用同一个函数，并且固定传入 sort_keys=True 和 separators=(",", ":")。不要手写字符串拼接去拼哈希，那是最容易出错的做法。

还有一点值得提醒：在 Python 里，字典的插入顺序是保持的，但不同系统或不同代码路径可能向你展示不同顺序，特别是当你从外部 JSON 接口读入数据再转字典时。所以“排序键后序列化”不是可选项，而应当是默认项。

5.2 修改历史区块后，链校验为什么立刻失败

这是我让学员做对抗测试时最常用的一招：手动修改链上第二个区块的交易金额，再调用 is_chain_valid()，返回 False。

因为在你修改交易后，那个区块的 hash 字段仍然保留着被修改前的旧哈希。校验函数调用 current.compute_hash() 会得到一个新值，和旧哈希不匹配。即使你足够聪明，同步把当前区块的 hash 字段也改成新计算出的哈希，试图瞒天过海，那也没用：它的下一个区块的 previous_hash 仍然指向旧哈希。你还是需要把后面所有区块全部重新挖一遍。

这里就是“工作量证明”真正发挥作用的地方。在难度 4 的情况下，每个后续区块平均需要约 6 万多次哈希尝试。如果难度提升到像真实网络那样，重写一整条历史链所需的算力会大到几乎不可能支付。让我用一个小实验展示一下篡改的代价：

python复制bc.chain[1].transactions[1]["amount"] = 99999
# 第二笔交易被改成 99999
bc.chain[1].hash = bc.chain[1].compute_hash()
print("当前块自己校验是否通过?", bc.chain[1].hash[:DIFFICULTY] == "0" * DIFFICULTY)
print("整条链是否有效?", bc.is_chain_valid())

如果没有重新运行 proof_of_work，而是直接调用 compute_hash，大概率新的哈希并不满足难度条件，所以第一步就可能失败。哪怕你运气好碰到一个满足难度的哈希，下一区块的 previous_hash 依然对不上，整条链依旧无效。

5.3 交易已经添加，为什么链上查不到

这个问题的原因通常很简单：add_transaction() 只是把交易放进 pending_transactions 列表，它还没有被“打包”进区块。只有调用 mine_pending_block() 之后，区块才会生成并追加到链上。很多初学者以为添加即上链，其实这和现实中的“待确认交易池”概念一样，是两回事。

我在设计代码时也有意保留了这种区分，目的是让你体验到交易的生命周期。如果你希望查看待确认交易，可以在 Blockchain 类里加一个查看方法，或者直接访问 bc.pending_transactions。但不要误以为它会天然出现在链数据上。

5.4 常见问题速查

下面是我把常见问题和排查思路整理成的一张速查表，方便你遇到问题时快速对照：

5.5 如何继续扩展这个项目

如果你跑通了整条最简单的实现，我强烈建议你按下面顺序继续折腾，每增加一步都会让模型更接近真实系统。

第一步，把难度改为可配置，并实现根据出块时间自动调节难度。这是理解“矿工算力越高，难度越高”这个动态平衡的最好方法。

第二步，为每个交易增加简单的签名和验签逻辑。可以用 Python 标准库生成一对 RSA 密钥，交易里存储签名，验证时用发送者的公钥验签。加完后你会发现，真正区块链里“不能冒充别人”到底是怎么实现的。

第三步，模拟两个在本地端口上运行的节点，让它们互相广播交易和区块。即使不采用复杂协议，你也会遇到“收到两条不同链该信谁”的实际问题，这正是最长链规则存在的意义。

第四步，给浏览器页面加上区块高度、交易数量统计和查账入口，让它看起来更接近你平时听到的区块链浏览器。这并不难，却会让你对“链上信息可公开查询”有更直观的感受。

我个人在实际操作中的体会是，手写一遍区块链，比看十遍概念解析都管用。你会在调试哈希不一致时真正理解什么是序列化，会在挖矿等待中体验到难度的杀伤力，会在篡改测试失败时理解为什么账本不可伪造。这套代码虽然极其朴素，但它就像一辆只装骨架的自行车，让你看清所有部件是如何咬合在一起的。后续你想加入密码学、网络还是共识机制，都等于往已经转动的轮子上装加速装置，方向会非常明确。