首页

Web3 工程学习路线

# Web3 工程学习路线

Web3 开发不只是调用合约，而是让钱包、链上规则、链下服务和用户界面对同一件事达成一致。例如用户购买课程，钱包负责授权，合约负责扣款和购买记录，索引服务同步结果，页面展示进度。任何一层提前宣布成功，都可能造成误导。

# 阅读顺序与内容概览

要解决的问题 阅读入口 主要内容
区块链为什么能让多方共同记账 区块链基础 区块链的发展、密码学、网络与共识机制
一笔交易怎样从签名走到最终确认 密码学与交易生命周期 哈希与签名、交易 nonce、回执、链重组与最终确认
合约怎样执行、为什么失败还收费 Ethereum 与 EVM 账户、Gas、ABI、存储和调试
怎样编写合约并安全修改它 Solidity 与代币标准、测试、部署与升级 前者讲合约编写与代币标准；后者讲测试、部署验证与升级安全
连接钱包是不是登录 钱包、签名与身份 地址、连接、登录、授权和账户抽象
怎样把前后端与链上结果接起来 DApp 全栈开发 常用技术栈选型、钱包与合约调用、界面状态、后端验证与部署
怎样让合约使用链外数据 预言机与可信上链 数据真实性边界、常见预言机、Chainlink Data Feeds 与 CRE
怎样得到可信的数据和看板 Web3 数据分析、事件索引与指标实践 前者讲分析工具与常用指标；后者讲事件解码、历史补扫与指标计算
怎样检查资金和权限风险 Web3 安全检查 攻击过程、修复方法、上线检查

初次学习可以按表格顺序阅读；复习时按具体问题进入对应文章。

# 一次业务请求贯穿全部模块

用户选择课程
  → 后端提供课程与报价（不是链上购买凭证）
  → 钱包确认网络、金额和授权对象
  → 模拟调用，签名并广播交易
  → 节点执行合约，返回交易回执
  → 索引服务核对合约事件和确认状态
  → 数据库更新购买投影，页面展示结果
1
2
3
4
5
6
7

链上保存资产和权限的关键事实，数据库保存方便查询的业务资料与投影。投影就是根据链上事实整理出来的查询结果；它可以重建，不应反过来改写链上结算事实。

云端 API、数据库、队列和监控不属于某一条链，统一复用 应用架构与 AWS 工程路线。

# 同一笔购买，各层到底相信谁

要判断的事情 依据 不能替代它的信号
用户是否控制某地址 后端验证的登录签名与会话 前端提交一个公开地址
钱是否已按规则支付 正确链与合约上的成功执行、匹配事件和确认策略 钱包关闭、交易哈希或前端提示
用户能否查询课程详情 后端业务权限及已确认购买投影 RPC 能查到这个地址
页面为何还没更新 索引进度、API 数据和缓存版本 认为数据库必须瞬间与链同步

例如交易已经成功，但索引器落后十个区块，页面可以显示 “链上已执行，业务同步中” ，并继续查询。不能让用户再次支付，也不能为了消除等待就让前端直接修改购买记录。

把课程名称、搜索与学习进度放数据库，是为了便于查询和修改；把资产转移与关键购买规则放合约，是为了让相应事实可验证。不是所有数据上链才叫 Web3，真正要明确的是哪一层有权决定哪一个事实。

# 面试时可以这样回答

Web3 全栈和普通全栈最大的工程区别是什么？参考答案

多了钱包授权和链上异步确认，而且链上操作不能像普通数据库修改那样随意回滚。前端要区分签名、广播、执行和业务确认，后端要校验事件、处理重复和重组。比如购买交易成功但索引延迟，我会继续同步而不是让用户再付款，关键是让每一层都基于正确的事实来源推进状态。

# 项目复习入口

# 学到什么程度算能用

能在本地完成一次合约调用，解释交易哈希和成功回执的区别；能处理钱包拒绝、交易失败、重复事件和短重组；能说明升级权限与用户授权风险；最后能把一次操作从页面追到合约，再追到数据库与监控。只背工具名称还不够。

区块链基础