Substrate区块链开发框架详解：从理解核心架构到动手搭建自定义链

1. substrate到底是什么：从一张实验台布说起

很多刚接触区块链底层开发的朋友，看到"substrate"这个词都会愣一下——这到底是个框架、一个库、还是一条链？我第一次接触它的时候也绕了不少弯路，这里先给大家一个最直白的说法：

substrate是一个用来"搭区块链"的模块化开发框架。它由Parity Technologies团队打造，用Rust语言编写，核心目标就是让开发者不用从零开始撸共识算法、P2P网络、账本存储这些底层基础设施，而是把精力集中在业务逻辑和链本身的功能上。

你可以把它想象成一张实验室的工作台布。台布本身把桌面、排水、照明这些基础设施都铺好了，你只需要在台布上摆自己的烧杯、试管和实验仪器。同理，substrate把区块链节点最麻烦的那部分——网络层、存储层、共识层、运行时执行环境——全部打包好，你只需要在上面写自己的业务模块，也就是runtime逻辑，就能组装出一条具备完整功能的链。

这类框架通常被称为"区块链开发框架（Blockchain Development Framework）"或者"链开发SDK"。目前生态里最出名的两个代表，一个是substrate，另一个是Cosmos SDK。两者的思路有相似之处，但substrate在运行时升级、跨链互操作和可定制性上有自己非常鲜明的特色。

适合谁来学？坦白说，substrate不适合完全没有编程基础的人直接上手。你需要至少熟悉Rust的基本语法，理解所有权、生命周期这些核心概念，同时对区块链的基本运作原理——节点、区块、交易、共识、状态存储——有一个大致的概念。如果你已经写过简单的智能合约，或者用其他语言做过区块链相关开发，那substrate的学习曲线会平滑很多。

这篇文章我不打算给你贴一堆官方文档的翻译，而是结合我自己从"跑通一个空链"到"改造出带业务逻辑的自定义链"的完整过程，把那些文档里不会明说、但实际开发中一定会踩的坑和关键思路讲清楚。

2. 为什么选择substrate：框架设计背后的核心思路

2.1 框架要解决的根本问题

造一条区块链，牵扯的东西远比想象中多。假设你想自己做一条链，光是把节点跑起来就需要解决：节点之间的网络通信、交易广播与同步、共识算法、交易执行环境、状态存储、区块最终性确认、客户端与链上数据的交互接口……这些每一个都是一整套子系统。独立开发的话，哪怕只是把P2P网络调通，就足够耗掉几个月的时间。

substrate把一个节点拆成了"外层（Client）"和"内层（Runtime）"两个部分。外层是固定的，包含网络层、数据库、共识、RPC接口等——这部分基本不用动，由框架直接提供。内层是运行时的逻辑，决定了这条链"怎么处理交易""状态怎么变化""有哪些业务功能"。

这个分层有一个巨大的好处：外层代码基本稳定，内层逻辑可以灵活定制。而且substrate的Runtime编译成Wasm字节码，存储在链上。这意味着链的规则可以在不硬分叉的情况下，通过链上投票或治理机制直接升级。传统区块链如果要改共识规则、加新功能，通常要分叉，社区分裂风险极高。substrate把"改规则"变成了一次普通的链上交易，这个能力在开发阶段的价值尤其突出——你还没上线，随时改逻辑，不用反复重置整条链。

2.2 为什么用Rust而不选Go或JavaScript

这里有个很实际的原因：区块链节点是长期运行的网络基础设设施，对内存安全、并发性能和运行稳定性要求极高。Rust在内存安全上没有GC带来的暂停，性能上接近C/C++，同时能通过编译期静态检查避免大部分空指针、数据竞争问题。用Rust写节点，等于在编译阶段就挡掉了一大类bug。

另外，Rust的生态里有非常适合区块链开发的基础库，比如parity-scale-codec用于高效的序列化，trie相关库用于Merkle Patricia Tree的存储，这些已经在substrate里集成好了。如果你用Go，哪怕Cosmos SDK也做了很多封装，但底层细节仍然需要大量的手工处理和一个相对庞大的运行时环境。

当然，Rust的代价就是学习曲线陡峭。你写业务模块的时候，会面对大量trait、泛型、宏展开，类型系统有时候严苛得让人抓狂。但一旦习惯了这种"编译期就管到底"的风格，写出来的链逻辑会非常稳健，我后面会分享几个具体案例。

2.3 substrate与智能合约平台的差异

很多人在理解substrate时会混淆：它不是一条现成的链，比如以太坊或Polkadot，而是一个"造链工具"。用substrate可以造出类似波卡中继链的链、类似公开智能合约平台的链，也可以造出联盟链、私有链。

如果你拿它和以太坊对比：以太坊是一个部署好、运行中的智能合约平台，你在上面写Solidity合约，合约跑在以太坊虚拟机里。而substrate给你的是整条链的"骨架"，你写的不是一个跑在别人链上的合约，而是一条链自身的业务逻辑。所有交易、状态转换、存储布局都可以完全自定义。打个比方，以太坊像是租了一间装修好的办公室，你只能往里面搬自己的家具；substrate像是买了一块毛坯地，水电管道都铺设好，户型可以你自由改。

当然，substrate也可以支持智能合约，只需要引入pallet-contracts模块，它就是一个类以太坊的合约执行环境。如果你希望自己链上既能跑Wasm合约，又要有自定义的业务模块，substrate完全可以同时做到。

3. 核心架构与关键概念：手把手拆解substrate的组成

3.1 节点架构：Client、Runtime、Wasm三者的关系

substrate的节点在运行时有两条"执行路径"：原生Runtime（Native Runtime）和Wasm Runtime。Native Runtime以Rust原生机器码运行，通常用于开发调试和性能优化场景；Wasm Runtime则是从链上加载的Wasm字节码，是保证链在不同客户端之间一致性的"标准执行环境"。

这两者的逻辑其实是同一套代码编译出来的两个形态。代码改动后，旧节点运行Wasm新逻辑，新节点既可以用Native性能跑、也能校验Wasm结果。这个双轨设计保证了网络升级过程中的兼容性。

我举个开发中的实际例子：你在本地改好了runtime代码，cargo build生成了新的wasm文件，需要把它通过set_code这种特权调用或治理机制更新到链上。如果没有这个机制，开发中每次改逻辑都要purge-chain重置数据，非常麻烦。有了链上Wasm升级能力，你可以像发一笔交易一样完成逻辑更新，整个调试闭环高效很多。

3.2 运行时Runtime与FRAME：pallet是怎么运作的

substrate的Runtime通常围绕FRAME（Framework for Runtime Aggregation of Modular Entities）来构建。FRAME提供了一组标准化的模块，每个模块叫pallet，比如：

• pallet_balances：管理账户余额、转账
• pallet_staking：PoS质押与验证人选举
• pallet_system：基础系统模块，处理账户、区块头、事件等
• pallet_contracts：智能合约执行
• pallet_governance：治理投票

pallet由一组相关联的业务逻辑构成，通常包含：存储定义、可调用函数（dispatchable calls）、事件（events）、错误（errors）、以及可能的链上常量。编写一个pallet，本质上就是实现一个traitpallet::pallet，并在#[pallet::config]里声明依赖其他pallet的关联类型。

每个pallet可以独立测试和复用。这种模块化借鉴了传统软件设计里的插件化思想，但它的落地方式更彻底——pallet不仅是在代码层面解耦，而是实实在在地定义了一套链上接口和状态转换规则。你可以从crates.io拉取多方的pallet，也可以自己写一个发布出来，像搭积木一样组合成完整runtime。

3.3 存储模型：链上数据是怎么组织的

理解substrate的存储模型对写业务代码非常重要。Runtime中每个pallet可以定义自己的存储项（storage item），存储结构本质是一个键值数据库，键由pallet名称、存储名称和存储key组合而成，最终形成一棵Merkle树，用来做轻节点验证和状态根校验。

常用的存储类型有：

• StorageValue：存单个值
• StorageMap：类似哈希表
• StorageDoubleMap：两级key的映射，适合按账户和资产类别分别存储
• StorageNMap：多级key，灵活但调用稍复杂

存储还会保证类型必须实现Encode和Decode（通过parity-scale-codec），并且所有读写都在区块头的"状态根"中有迹可循。你在开发时如果发现"我改了存储，但链上查询结果没变"，基本就是没把交易提交到区块里，或者存储key的前缀对不上，这类问题非常常见。

3.4 交易流程：从发起交易到状态变化的全过程

一条交易进入substrate节点后的大致旅程是：交易先进入交易池（Transaction Pool），共识引擎出块时把交易打包进区块，执行环境逐笔执行，每一步调用都会触发对应pallet的dispatch函数，最终产生状态变化和事件。

这个流程中有一个关键概念叫SignedExtension，它在交易执行前做前置校验，比如检查交易签名、nonce、支付费用是否足够。你在自定义pallet时，如果业务需要增加前置条件（比如"只有黑名单之外的账户才能发起交易"），就可以扩展SignedExtension或在dispatch函数开头加检查。

开发中最需要注意的是资源的计量（weight）。每条交易或调用都需要标注weight（可以理解为计算和存储开销），节点根据weight来决定交易费和执行时间上限。如果你写的函数weight给得太小，实际运行时可能跑不完；给得太大，交易费又显得过高，用户不愿意用。这块需要反复测试，我后面会展开讲。

4. 实操前准备：环境搭建与工具链选型

4.1 Rust环境与substrate开发环境

substrate要求使用特定版本的Rust工具链，通常以nightly分支为主。搭建环境我建议直接参照官方文档，但有几个容易踩的坑先提醒：

• Rust版本不稳定：substrate更新频繁，某个pallet可能在老版本上编译不过。最稳妥的方式是使用官方提供的rust-toolchain.toml文件，它会锁定一个可用的nightly版本，cargo build时会自动用这个版本编译。
• 依赖编译时间很长：第一次编译substrate节点，依赖树非常庞大，往往要编译20-30分钟甚至更久。如果你的机器内存小于16G，建议把CARGO_BUILD_JOBS调低一点（比如export CARGO_BUILD_JOBS=4），避免内存吃满。
• substrate-node-template是官方提供的初始化模板，建议从这里开始。它是一个最简可用节点，包含几个基础pallet，改动它比从零写快得多。

4.2 必备工具：substrate-node-template与前端交互

开发中至少需要两个终端：一个开启节点服务（提供JSON-RPC接口），另一个编译或运行前端交互工具。

常见的工具有：

• polkadot-js/apps：可以直接在浏览器访问，连接本地节点，查看区块、账户、事件、链上存储。开发自测时非常方便。
• subxt：Rust客户端库，用于在Rust程序里通过RPC与substrate链交互。
• polkadot{js}JavaScript API：适合写前端界面。

我一开始只用命令行和curl调RPC，后来发现错误排查效率特别低。换到polkadot-js/apps之后，直接在页面上看到交易、事件和存储状态，开发体验完全不同。建议一开始就配好浏览器工具。

4.3 首次编译：一个完整的"Hello World"链

按官方模板，你只需要：

git clone https://github.com/substrate-developer-hub/substrate-node-template.git cd substrate-node-template cargo build --release

如果一切顺利，编译结束后运行：

./target/release/node-template --dev --tmp

就能启动一个单节点的开发链。这时候用浏览器打开polkadot-js/apps，切换网络到"Development"并填入本地地址ws://127.0.0.1:9944，就能看到区块不断出产，默认账户里有一笔初始余额。

这个环节最常见的报错是编译中途内存不足或依赖冲突，建议先把依赖都拉全，再一次性编译，尽量避免反复改Cargo.toml。还有一个细节：--dev模式下节点自动使用Alice等预置账户，私钥是公开的，千万不要把这个模式用到有真实资产的环境里。

5. 实战搭建：从零写一个自定义pallet

5.1 需求场景设计：做一个"链上点赞"模块

单纯跑通模板没有太大意义，真正有学习价值的是自己动手写业务逻辑。我设计了一个比较简单的场景：一个"内容点赞"模块，用户可以对某个内容ID点赞，每个账户对一个内容只能点一次，点赞后事件被记录到链上。

这个例子很适合入门，因为它覆盖了pallet开发的核心点：存储、可调用函数、事件、错误处理。而且逻辑简单，哪怕完全没写过pallet，跟着代码走一遍也能建立起整体概念。

5.2 开始写代码：pallet目录与Cargo配置

建议把自定义pallet放在pallets/目录下。模板里已经有一个pallet-template，你可以直接把它改成pallet-like。先看Cargo.toml：

[package] name = "pallet-like" version = "0.1.0" edition = "2021" [dependencies] codec = { package = "parity-scale-codec", version = "3.0.0", features = ["derive"] } scale-info = { version = "2.0.0", features = ["derive"] } frame-support = { git = "https://github.com/paritytech/substrate.git", branch = "polkadot-v1.0.0" } frame-system = { git = "https://github.com/paritytech/substrate.git", branch = "polkadot-v1.0.0" } sp-runtime = { git = "https://github.com/paritytech/substrate.git", branch = "polkadot-v1.0.0" } sp-std = { git = "https://github.com/paritytech/substrate.git", branch = "polkadot-v1.0.0" }

这里需要注意frame-support和frame-system的版本要跟runtime里其他pallet保持一致，否则会编译出一堆trait冲突。最省心的方式是直接拷贝模板里的依赖配置，再对package名做替换。

然后在runtime的Cargo.toml里加上pallet-like依赖，并在construct_runtime!宏中注册：

construct_runtime!( pub enum Runtime { System: frame_system, Balances: pallet_balances, Like: pallet_like, // 其他pallet } );

5.3 构成一个pallet：结构、存储、错误与事件

一个pallet的骨架如下，我用最简单的方式把点赞模块写出来：

#[frame_support::pallet] pub mod pallet { use frame_support::pallet_prelude::*; use frame_system::pallet_prelude::*; #[pallet::config] pub trait Config: frame_system::Config { type RuntimeEvent: From<Event<Self>> + IsType<<Self as frame_system::Config>::RuntimeEvent>; } #[pallet::pallet] pub struct Pallet<T>(_); #[pallet::storage] pub type Likes<T> = StorageMap<_, Blake2_128Concat, T::AccountId, u32, ValueQuery>; #[pallet::storage] pub type AlreadyLiked<T> = StorageDoubleMap< _, Blake2_128Concat, T::AccountId, Blake2_128Concat, u64, bool, ValueQuery, >; #[pallet::event] #[pallet::generate_deposit(pub(super) fn deposit_event)] pub enum Event<T: Config> { ContentLiked { who: T::AccountId, content_id: u64 }, } #[pallet::error] pub enum Error<T> { AlreadyLiked, ContentNotFound, } #[pallet::call] impl<T: Config> Pallet<T> { #[pallet::weight(10_000)] pub fn like( origin: OriginFor<T>, content_id: u64, ) -> DispatchResult { let who = ensure_signed(origin)?; ensure!(!AlreadyLiked::<T>::get(&who, content_id), Error::<T>::AlreadyLiked); let likes = Likes::<T>::get(content_id); Likes::<T>::insert(content_id, likes + 1); AlreadyLiked::<T>::insert(&who, content_id, true); Self::deposit_event(Event::ContentLiked { who, content_id }); Ok(()) } } }

这个模块虽然简陋，但已经包含了核心要素。值得注意的是存储类型的选择：为什么不直接用StorageMap存(account, content_id) -> bool，而要拆成两个存储？因为我希望查询"某个内容的总点赞数"和"某个账户是否点过赞"都能高效完成，而不是遍历整个map。这是设计存储结构时的重要考量。

另外，ValueQuery的default值，当你查询一个不存在的键时，它会返回该类型默认值。u32默认是0，bool默认是false，这在很多场景下省去了手动处理Option的麻烦。

5.4 把pallet编译进runtime：别让小错误卡你一整天

写完pallet只是第一步，把它正确集成到runtime里才是新手最容易卡住的地方。

第一步，确保在runtime/src/lib.rs里引入了pallet_like，并出现在construct_runtime!中。第二步，确认runtime的impl pallet_like::Config for Runtime块里定义了RuntimeEvent类型。模板里通常写着type RuntimeEvent = RuntimeEvent;，这行代码的作用就是把pallet自己定义的事件类型桥接到整个runtime统一的事件枚举里。

如果你在编译时遇到类似"the trait bound ... is not satisfied"的问题，先检查两处：一是Cargo.toml里的feature是否启用了std和runtime-benchmarks，二是是否所有依赖的git分支都跟frame分支一致。很多编译错误看起来像代码问题，实际是版本不匹配。

我建议每改一个文件就做一次cargo check，而不是攒到最后cargo build。cargo check不会真正生成可执行文件，速度快很多，适合开发期频繁迭代。

5.5 本地测试：新模块到底能不能跑通

编译通过后，启动节点：

./target/debug/node-template --dev --tmp

打开polkadot-js/apps，在"Developer" -> "Extrinsics"页面选择like模块的like函数，填入content_id。提交后，在"Chain state"里查询Likes存储项，就能看到对应content_id的点赞数。再提交一次相同的调用，应该会报错AlreadyLiked。

执行速度上，--release模式更好，但开发期用debug模式也没问题。debug模式跑业务逻辑性能差一些，但对正确性调试没有影响。

6. 共识机制与自定义：让链真正按你设想的方式运作

6.1 substrate支持的共识类型：从Aura到BABE/GRANDPA

substrate把共识分成了两大块：区块生产（Block Production）和区块最终性（Finality）。区块生产决定了谁在什么时候可以出块，最终性决定了哪些区块一旦确认就不可回滚。

常见的组合有两种：

• Aura：基于slot的轮流出块，选中的验证人按顺序出块。简单高效，适合单机开发和联盟链场景。
• BABE + GRANDPA：波卡生态的标准配置。BABE负责随机选取出块人，GRANDPA负责对区块进行最终性确认，两者配合起来既能保证出块效率，又能提供高安全性。

开发个人链时，如果对安全性和去中心化要求不高，直接用Aura最简单：所有预定验证人轮流打包区块，没有复杂的随机性博弈。如果你想模拟一个接近公链的环境，再改成BABE/GRANDPA。

这里要特别提醒一个坑：共识类型改变，往往需要重新指定验证人集合。如果你直接把--dev链的验证人配置放到多节点网络上，可能由于session或staking逻辑没配好，导致没有节点出块。先理解"出块权"是怎么分配的，再动手改。

6.2 出块频率与区块时间

模板默认的区块时间是6秒一个块。这个参数可以在runtime里的timestamppallet配置中看到，相关常量是MinimumPeriod，通常设置为SLOT_DURATION / 2。

区块时间对用户体验影响很大。如果想让链响应更快，可以把区块时间调短到比如2秒，但出块太快可能让节点来不及同步或处理交易，网络延迟也会造成大量空块。反之，区块时间太长，用户等到确认的时间拉长。

我的建议是开发期保持默认6秒，不要在早期追求"快"而忽略了链的稳定性。等你把业务逻辑跑顺了，再调快不迟。

6.3 自定义共识的边界：不是所有东西都要自己写

很多人在刚开始开发时，容易被"自定义一切"的冲动支配，连共识算法都想自己写。实际上，绝大多数业务需求不需要自定义共识。共识是整个链最底层、最需要安全性验证的部分，自行设计容易引入严重漏洞。

如果只是想验证某个共识想法，可以用substrate的"共识引擎"接口做一个简单的模拟，但不要直接部署到生产环境。在真实的公链或联盟链环境里，从成熟方案（Aura/BABE/GRANDPA）开始，把精力放到pallet和业务创新上，是更务实的路线。

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

7.1 编译到底为什么这么慢？怎么破

第一次编译substrate节点动辄半小时，这不奇怪，因为它要编译整个依赖树。之后增量编译会快一些，但如果改动涉及底层trait，仍然要重新编译大量代码。

几个提速建议：

• 使用sccache做编译缓存，它能复用不同target目录下的编译产物。
• 不要频繁cargo clean。很多新手一看编译报错就clean重来，结果把缓存全部清掉，陷入"越clean越慢"的循环。
• 把--release和debug时机分清楚。开发定位问题时用debug，发布和性能测试才用release。
• 如果你的机器多核，适当调大CARGO_BUILD_JOBS，但要注意内存上限。16G内存建议4-6个并行任务，32G以上可以开到8-12。

7.2 链上存储查询结果不对，怎么排查

这类问题通常有几个源头：

• 交易没被打包。如果你用RPC发送交易，先看Events里有没有你的调用事件，没有说明交易可能还在交易池里或已被丢弃。
• 存储key使用错误。StorageMap的key有前缀，不同pallet的存储名一样也会导致前缀不同。用polkadot-js/apps的"Chain state"直接查，而不是手动猜key。
• 区块还没最终确定。Aura模式下出块后很快就最终化，但BABE/GRANDPA下最终性确认需要额外时间。如果前端查询的是"最新最终化区块"的状态，那就注意区分。

7.3 常见报错对照表

7.4 权重(Weight)问题：为什么交易费高得离谱或执行到一半被拒

Weight可以理解为substrate里的"虚拟机gas"。每个dispatchable call都要标注#[pallet::weight(...)]或实现WeightInfotrait。如果weight给低了，交易一执行就报错或被打回；给高了，用户费用高。

一个参考做法：先用一个保守值（比如10_000）跑通逻辑，再用substrate提供的frame-benchmarking来生成更精确的weight。通过benchmark，你能得到每个pallet在真实机器上的执行时长和存储依赖，从而给出合理数值。开发早期不必过度优化，但上线前一定要做基准测试。

7.5 多节点开发：本地跑出一个"迷你网络"的坑

模板默认是单节点开发链，但有时你想模拟多节点网络，观察共识如何协作。常见方式是启动多个节点实例，用--validator和--port等参数区分。

我踩过最大的坑是忘记设置--chain参数，所有节点默认指向同一个本地链，导致节点间无法连接。正确的做法是为每个节点指定一份相同的chain spec文件（由第一个节点生成），再各自用自己的密钥对启动。另外要记得开放--rpc-port和--ws-port，不然前端连不上。

多节点模式下，存储和历史数据的清理由--tmp控制，但如果你用了持久化存储目录，改链逻辑后一定要purge-chain，否则旧数据会污染新逻辑。

8. 从开发链到正式环境：部署与治理的若干思考

8.1 本地Dev链、测试网、主网之间的差异

很多新手把--dev链跑通，就直接想"这就上线了"，这是很危险的。--dev模式默认使用预置账户、单节点、无私钥安全，它只适合开发调试。

测试网至少要有多个节点、多个验证人、明确的token经济模型和治理机制，甚至要跑一段时间来验证链的稳定性。主网则更进一步，涉及真实资产、安全审计、社区治理、节点分布等。

substrate的价值恰恰在于：你可以先用--dev快速迭代业务逻辑，再逐步把链部署到Staging环境、测试网、主网。整个流程中使用同一套runtime代码，只是网络配置和账户体系不同。

8.2 链上治理：让链本身拥有升级能力

substrate的运行时升级能力使链上治理变得非常自然。你可以通过pallet_democracy（民主投票）、pallet_collective（委员会）、pallet_technical_committee（技术委员会）组合出适合自己链的治理模型。

需要区分两种模式：一是完全由sudo账户直接触发升级，适合开发期；二是通过治理流程，多个利益相关方投票后升级，适合正式网络。开发期用sudo最省事，但上线前一定要把sudo权限移除或转移到多签/治理模块，否则任何持有sudo私钥的人都能改链上代码。

8.3 与波卡生态、平行链的关系

很多人学substrate，最终目标是成为波卡的一条平行链。平行链通过租用一个插槽（slot）接入波卡中继链，获得共享安全性，并能通过XCMP（跨链消息传递）与其他平行链通信。

这个愿景很宏大，但实现的复杂度也不小。建议先把基础链打磨好，再考虑接入平行链。平行链开发需要额外处理拍卖、插槽租赁、跨链资产转移等机制，不是一蹴而就的事。

8.4 生态工具与社区资源

除了官方文档，社区里值得关注的项目有：

• substrate-graph-benchmarks：用于自动化生成weight和benchmark。
• frontier：在substrate链上提供以太坊兼容层，让Solidity合约可以跑在自定义链上。
• orml：Open Runtime Module Library，提供了一些开箱即用的pallet，比如oracle、auction、nft等。
• substrate-open-runtime-module-library：对快速搭建DeFi场景特别有用。

社区论坛、Riot群、Stack Overflow上也有大量经验分享。遇到问题先搜索，通常比你重新读源码快得多。

9. 从substrate出发，你能走多远

substrate不是一条链，而是一个"造链的宇宙观"。它把区块链开发的复杂度大幅降低，同时保留了极高的可塑性。从简单的单节点Demo，到多节点联盟链，再到接入波卡生态的平行链，它的能力范围可以覆盖完整的区块链产品生命周期。

我个人在实际使用中最深刻的体会是，substrate的学习曲线虽然是"先陡后平"，但一旦你理解了pallet、Runtime、Wasm和共识这几个核心概念，后面所有项目都会变得顺理成章。遇到"这块为什么不按我想的工作"的时候，不要急着推翻框架，先去理解它为什么要这样设计——很多时候你会发现，框架的选择比你的直觉更合理。

最后再分享一个小技巧：多写、多跑、多拆。不要只读文档，找一个小场景（比如本文的点赞模块），从零集成一个pallet，再把它部署到本地网络、再改出一些"故意出错"的版本去观察错误如何发生。这个过程会把你从"会用模板"推向"真正理解substrate"。

如果你打算长期在这个方向深耕，接下来可以研究一下平行链开发、跨链协议、以及runtime升级的治理细节。substrate这个生态的前沿发展很快，几乎每个月都有新的pallet和工具出现，保持跟社区同步很重要。祝你在造链这条路上，玩得开心，踩得有价值。