从0到1构建DApp：Solidity合约、React前端与链下服务实战-代码聚汇网

从0到1构建DApp：Solidity合约、React前端与链下服务实战

李德哲·2026-09-01·阅读 26 GEO检测（免费）

DApp智能合约Solidity

|难度：普通|阅读约 42 分钟

1. 这个项目到底在做什么：一个 DApp 的完整血肉

先说个我自己的观察。这两年"Web3"这个词被各种消息刷得有点烂了，很多人一听到就想到币价、NFT头像，反而忽略了它本质上是一套关于"数据到底归谁管"的技术方案。而 DApp（去中心化应用）就是这套方案落地的载体。

我接下来说的项目，不是那种给你画一张架构图就结束的"概念文"，而是一条真正从 0 到 1 把 DApp 跑起来的完整链路：选链、搭环境、写合约、做前端、接钱包、部署上线，每一步都踩过坑，也都有对应的解决方案。如果你正准备入局 Web3 开发，或者已经在做但总感觉"哪里不对"，这篇内容可以帮你省掉至少两周的试错时间。

先给出这个项目最终做出来的东西长什么样：

一个基于 Solidity 的智能合约，部署在测试网和主网，负责核心业务逻辑。
一个 React + TypeScript 的前端应用，用户能通过钱包直接调用合约。
一个链上事件监听服务，负责把合约里发生的事件同步到后端数据库。
一套完整的本地开发、测试、部署、验证流程。

说白了，这不算什么"颠覆性创新"，但它是所有 Web3 项目的骨架。你后续做 DeFi、做 NFT、做 GameFi，甚至做 DAO 工具，底层跑不掉的都是这套东西。

这篇文章适合的人有两类：一是传统前端/后端开发想转 Web3，二是已经写过几个简单合约、但还没把整个 DApp 串起来的人。如果你连区块链是什么都还不清楚，建议先补一下公链、共识、Gas 这些基础概念，再回来读，体验会好很多。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 技术选型：为什么是 EVM 系 + React，而不是其他组合

很多人一上来就纠结"选哪条链"，其实对一个从 0 到 1 的项目来说，这个问题的答案基本是确定的：先做 EVM 兼容链，别碰别的。

我见过一些团队，上来就冲 Solana、冲 Polkadot，结果发现生态工具链不成熟，光是一个钱包适配就折腾了半个月。EVM 系的优势不在于它"最先进"，而在于它的工具链完整度远超其他生态——从开发框架、测试工具、钱包 SDK 到区块链浏览器，全部是现成的，不需要你造轮子。

2.1 合约开发框架：Hardhat 为什么比 Foundry 更适合新手

合约开发框架主流有两个：Hardhat 和 Foundry。

Hardhat 是基于 JavaScript/TypeScript 的，如果你以前写过 Node.js，上手几乎没有门槛。它的插件生态非常丰富，比如 hardhat-deploy 可以管理部署脚本，hardhat-gas-reporter 能直接看到每个函数的 Gas 消耗，solidity-coverage 能做测试覆盖率统计。这些对项目初期的开发效率帮助非常大。

Foundry 是基于 Rust 的，速度和测试能力更强，但它的语法和传统 JavaScript 技术栈差异较大，对新手不算友好，更适合已经有一定合约开发经验、需要做大量复杂测试的团队。

我的选择很简单：项目初期用 Hardhat，跑通全流程；等后面需要做模糊测试（Fuzzing）或者复杂的数学计算验证时，再引入 Foundry 做补充。不要为了"技术先进性"而选择自己不熟悉的工具，开发效率才是第一位。

2.2 前端框架：React 依然是 Web3 生态的第一公民

前端框架我直接选 React + TypeScript。原因很实际：

Web3 领域的核心库（wagmi、viem、ethers.js）全部优先支持 React。
TypeScript 的类型约束对合约调用这种强交互场景非常重要，能避免很多低级错误。
React 的生态成熟，做钱包连接、链上状态管理都有现成的解决方案。

关于状态管理，我建议优先使用服务端状态管理方案，比如 TanStack Query，它可以在后端状态缓存、自动重试、防止竞态条件这些方面帮你省很多事，不用手写一堆 useEffect + useState。

存储方案上，项目使用的是一个中心化的协调服务器，核心数据都上链，但 IPFS（星际文件系统）承担了存储大文件的责任。你也可以通过 Pinata 或 Web3.Storage 上传到 IPFS。

2.3 为什么需要一个"链下"后端服务

很多人对 DApp 有个误解，以为"去中心化"就是所有东西都不能有中心化服务器。实际上，纯链上应用根本做不了复杂业务，原因有三个：

区块链存储成本极高（写一个 256 位的数就要花不少 Gas），不适合存文章、图片、订单列表。
链上无法做定时任务，你没法写一个"每天早上 8 点自动执行"的合约。
链上无法直接访问外部数据，必须通过预言机（Oracle）获取，这会带来额外的延迟和成本。

所以实际成熟的项目都是"链上 + 链下"混合架构：核心资产和数据上链，业务逻辑和复杂计算放在链下服务。

在这个项目里，我们后面要做的就是这样一个架构：

code复制[前端 DApp] -- 连接 -- [合约（链上）]
     |                        |
     |(读写交互)              |
     |                        |
[链下服务] -- 监听事件 -- [数据库]
     |                        |
     |(API 调用)              |
     |                        |
[IPFS] <-- 存储文件/内容

链下服务本质上是"链上数据的忠实解读器"，它监听合约事件，把有用信息整理到数据库，再通过 API 提供给前端。

3. 智能合约开发的完整流程：从编写到测试环境

合约是整个 DApp 的核心，它一旦部署就不能随意修改（除非你做了代理升级模式），所以开发时要格外慎重。

3.1 环境搭建和目录结构

合约开发首先准备好 Node.js 环境（建议 v18 及以上），然后开始初始化和安装：

bash复制mkdir my-dapp && cd my-dapp
npm init -y
npm install --save-dev hardhat
npx hardhat init

选 Create a basic sample project，之后的目录结构长这样：

code复制contracts/          # 存放 Solidity 合约文件
scripts/            # 部署和交互脚本
test/               # 测试文件
hardhat.config.js   # Hardhat 配置文件

这里有一个非常重要的点：Hardhat 的配置文件是全局入口，所有网络配置、编译器版本、插件注册都在这里完成。我第一次做项目时没重视它，后来部署到测试网发现合约编译版本和实际部署不一致，排查了很久。

我用的配置大约这样：

javascript复制require("@nomicfoundation/hardhat-toolbox");
require("hardhat-deploy");

module.exports = {
  solidity: {
    version: "0.8.20",
    settings: {
      optimizer: {
        enabled: true,
        runs: 200
      }
    }
  },
  networks: {
    hardhat: {
      chainId: 31337
    },
    sepolia: {
      url: process.env.SEPOLIA_RPC_URL || "",
      accounts: process.env.PRIVATE_KEY ? [process.env.PRIVATE_KEY] : []
    }
  },
  etherscan: {
    apiKey: process.env.ETHERSCAN_API_KEY || ""
  }
};

注意几个细节：

runs: 200 是优化器参数，表示你期望这个合约被调用 200 次左右时 Gas 最优。如果你的合约是高频交易合约，可以设成 1000 甚至更高。这个值不是越大越好，而是越接近实际调用频率越好。
PRIVATE_KEY 一定要通过环境变量注入（用 dotenv 或 hardhat 自带的变量机制），千万不要硬编码在代码里，更不要提交到 GitHub。我见过有人把带钱的私钥直接推到公开仓库，那基本等于直接送钱。

3.2 写合约时最容易被忽视的"业务边界"

写合约不复杂，但写"能安全应对真实业务"的合约不简单。我以最常见的"任务管理"合约为例，给大家演示一个完整的链上业务逻辑。

也许你会觉得，这跟 Web2 应用有什么区别？区别在一个关键点上：Web2 应用的逻辑可以在服务端随时改，而链上合约的逻辑一旦部署，用户随时都可以去验证和调用。只要合约有漏洞，任何人都可以利用它，不需要通过你的"后端管理后台"。

核心合约结构大致如下：

solidity复制// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract TaskManager {
    enum TaskStatus { Open, Completed, Canceled }

    struct Task {
        uint256 id;
        address creator;
        string title;
        string cid;          // 指向 IPFS 上存储的详细内容
        TaskStatus status;
        uint256 createTime;
        uint256 completeTime;
    }

    uint256 public taskCount;
    mapping(uint256 => Task) public tasks;
    mapping(address => uint256[]) private creatorTasks;

    event TaskCreated(uint256 indexed id, address indexed creator, string title, string cid);
    event TaskCompleted(uint256 indexed id, address indexed completer);

    function createTask(string calldata title, string calldata cid) external {
        taskCount++;
        tasks[taskCount] = Task({
            id: taskCount,
            creator: msg.sender,
            title: title,
            cid: cid,
            status: TaskStatus.Open,
            createTime: block.timestamp,
            completeTime: 0
        });
        creatorTasks[msg.sender].push(taskCount);
        emit TaskCreated(taskCount, msg.sender, title, cid);
    }

    function completeTask(uint256 taskId) external {
        Task storage task = tasks[taskId];
        require(task.creator == msg.sender, "only creator can complete");
        require(task.status == TaskStatus.Open, "task is not open");
        task.status = TaskStatus.Completed;
        task.completeTime = block.timestamp;
        emit TaskCompleted(taskId, msg.sender);
    }
}

这是一个最简单的业务逻辑，但已经涵盖了合约开发的三个核心设计原则：

状态管理：enum TaskStatus 明确定义了任务的所有状态，避免出现"未定义状态"。
权限控制：require(task.creator == msg.sender) 确保只有创建者能完成任务。
事件日志：event TaskCreated 和 event TaskCompleted 是链上数据与链下服务交互的桥梁，前端和链下服务都依赖这些事件来同步数据。

写合约时经常会忽略的一点是：谁来调用？调用的前提条件是什么？调用后的状态变化是什么？ 这三个问题想清楚，合约的骨架就出来了。

3.3 本地测试环境：Hardhat 节点和测试网的区别

开发过程中最常用的本地环境是 Hardhat 内置的节点，它模拟一个网络，可以指定任意账户的余额，非常方便。

bash复制npx hardhat node

这个命令会启动一个本地网络，默认提供 20 个测试账户，每个账户 10000 ETH（假的）。然后把部署脚本连到本地网络：

bash复制npx hardhat run scripts/deploy.ts --network localhost

本地测试的好处是快、免费、可控，坏处是有些行为（比如区块时间）和真实网络有差异。所以本地测试通过后，我会立刻部署到测试网（比如 Sepolia）再做一轮集成测试。

3.4 测试网部署：带参数的部署脚本和常见报错

测试网是真实网络的"排练场"，Gas 是真实的（虽然很便宜），交互流程和主网完全一致。部署前要准备好：

测试网的 RPC 节点地址（可以找公开节点，也可以用 Infura/Alchemy）。
测试网的私钥（用新创建的钱包，不要用主网钱包）。
测试网的 ETH（从水龙头领取，比如 Sepolia 水龙头）。

部署脚本可用 hardhat-deploy 管理，方便重复部署和回滚：

typescript复制import { ethers } from "hardhat";

async function main() {
  const [deployer] = await ethers.getSigners();
  console.log("Deploying contracts with account:", deployer.address);

  const TaskManager = await ethers.getContractFactory("TaskManager");
  const taskManager = await TaskManager.deploy();
  await taskManager.deployed();

  console.log("TaskManager deployed to:", taskManager.address);
  console.log("Verify command:");
  console.log(`npx hardhat verify --network sepolia ${taskManager.address}`);
}

main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

部署到测试网前记得要修改的配置是 network 字段，并确保环境变量里有 SEPOLIA_RPC_URL 和 PRIVATE_KEY。

常见的报错和解决办法：

Error: nonce has already been used —— 说明同一地址发起过相同 nonce 的交易。这个多发生在本地测试后立刻切到测试网，本地网络的交易记录还留在钱包里。解决办法是清掉本地 hardhat 的缓存，或者换一个测试账户。
Error: insufficient funds for gas —— 测试网账户没有 ETH，去水龙头领。
Error: Transaction reverted without a reason string —— 合约内某个 require 失败了，但没有返回错误信息。建议在本地先用 hardhat console 或者在测试脚本里打印更多的状态信息排查。

4. 前端 DApp 的核心：钱包连接与链上交互

合约部署好了，它就像一个"没有界面的数据库"，前端 DApp 的任务就是：把用户的请求打包成交易，发送到链上，并展示链上返回的数据。这里的关键是钱包连接和数据读取。

4.1 钱包连接的基本流程（Web3 的第一步）

钱包连接的本质是：前端向钱包请求账户地址，钱包返回地址并让用户确认签名。这里我用的是 wagmi 库，它把这一过程封装得非常简洁。

先配置一个项目：

typescript复制import { configureChains, createConfig, mainnet, sepolia } from "wagmi";
import { MetaMaskConnector } from "wagmi/connectors/metaMask";
import { publicProvider } from "wagmi/providers/public";

const { chains, publicClient } = configureChains(
  [mainnet, sepolia],
  [publicProvider()]
);

export const config = createConfig({
  autoConnect: true,
  connectors: [new MetaMaskConnector({ chains })],
  publicClient,
});

注意 autoConnect: true 很关键，它让用户刷新页面后不用重新连接钱包。

在 React 组件里切换到钱包连接状态：

tsx复制import { useAccount, useConnect, useDisconnect } from "wagmi";

function ConnectButton() {
  const { address, isConnected } = useAccount();
  const { connect, connectors } = useConnect();
  const { disconnect } = useDisconnect();

  if (isConnected) {
    return (
      <div>
        <p>当前账户：{address}</p>
        <button onClick={() => disconnect()}>断开连接</button>
      </div>
    );
  }

  return (
    <button onClick={() => connect({ connector: connectors[0] })}>
      连接钱包
    </button>
  );
}

这里我建议你在生产环境做两件额外的事情：

链的检测与切换：用户可能连接的不是你部署合约的链，前端要在连接后检查 chainId，如果不匹配就要引导用户切换，否则后面调合约一定会报错。wagmi 有 useSwitchNetwork 可以做这个。
错误处理：用户主动拒绝连接、连接超时、钱包未安装，这三种情况要分别给不同的提示，别统一弹个"连接失败"。这是产品体验的细节，也是开发专业度的体现。

4.2 读数据 vs 写数据：完全不同的交互方式

链上交互分两种：读（call） 和 写（send）。

读操作是免费的、即时的，状态也返回完整数据；不产生交易，不消耗 Gas。
写操作需要用户支付 Gas，有一个完整的交易生命周期：pending → confirmed → receipt。

在 React 里用 hooks 封装一下，代码就非常清晰了：

tsx复制import { useContractRead, useContractWrite } from "wagmi";
import TaskManagerABI from "../abis/TaskManager.json";

const CONTRACT_ADDRESS = "0xYourDeployedContractAddress";

function useTaskManagerRead() {
  return useContractRead({
    address: CONTRACT_ADDRESS,
    abi: TaskManagerABI.abi,
    functionName: "taskCount",
  });
}

function useCreateTask() {
  return useContractWrite({
    address: CONTRACT_ADDRESS,
    abi: TaskManagerABI.abi,
    functionName: "createTask",
  });
}

拿到 useContractWrite 返回的 write 函数后，点击"创建任务"按钮就调用它，传参即可。

重点提醒一下：交易最终状态必须以链上 receipt 为准，而不是以钱包弹窗是否关闭为准。很多用户看到钱包弹窗消失了就以为交易成功了，其实可能是被拒绝了。前端一定要监听交易回执：

tsx复制const { write, data, isLoading, isSuccess, isError } = useContractWrite({...});

// 返回的 data 是交易 hash
// 需要等 receipt（交易回执）

如果你要更精确地跟踪交易状态，可以用 waitForTransaction 这个方式，拿到回执后再更新 UI。这个细节做不好，前端就会给别人一种"操作了半天啥也没发生"的感觉。

4.3 从合约读数据：为什么不能直接在前端遍历所有任务

很多新手会写一个"遍历所有 task"的函数，比如合约里有一个 taskCount，然后前端从 0 到 taskCount 全部查询一遍。这种做法在数据量小的时候没问题，但一旦数据量大了（比如上万条），前端会卡死，因为每一次 read 都是一次 RPC 调用，而且合约的 gas 限制也会导致这种遍历函数很容易 out of gas。

正确解法有三种：

让合约提供"按用户查询"的接口，把遍历范围控制在一个地址下。
用事件监听的方式，把 TaskCreated 事件同步到数据库，由后端 API 提供列表。
用 The Graph 这样的索引协议，把合约事件做成分段读取。

在实际项目中，我几乎都是**"前端只查单条数据，列表数据走后端 API"**。这是 DApp 架构里很常见的一条经验。

5. 链下服务：如何监听链上事件并把数据沉淀下来

这是 DApp 架构里最容易被忽略、却又最重要的一块。打个比方，合约是"账本"，链下服务就是"会计"，它盯着账本上每一笔变动，把它们登记到公司自己的表格里，方便报表和搜索。

5.1 为什么需要事件监听服务

假设你的 DApp 有个"任务列表"页面，用户要看到自己创建的所有任务。如果每次打开页面都去链上遍历所有区块，不仅慢，而且浪费。

所以，事件监听服务要做的事情是：

订阅合约发出的事件（TaskCreated、TaskCompleted）。
把事件解析成结构化数据，存到数据库（PostgreSQL 或 MongoDB）。
提供 HTTP API，供前端按条件查询。
定期做一次"校验"，确保数据库里的数据和链上数据一致（防止漏掉事件）。

5.2 一个可靠的事件监听实现（架构与代码）

监听服务的核心是：维护一个"从哪个区块开始扫"的游标，这个游标就是事件的同步进度。如果服务重启了，它应该能从上次中断的位置继续，而不是丢失之前的记录。

我用一个 Node.js + TypeScript 的服务来演示，数据库用 PostgreSQL（因为它的 JSONB 类型很适合存链上数据）。

typescript复制import { ethers } from "ethers";
import { Pool } from "pg";

const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);
const contract = new ethers.Contract(
  process.env.CONTRACT_ADDRESS,
  TASK_MANAGER_ABI,
  provider
);

const pool = new Pool({ connectionString: process.env.DATABASE_URL });

async function syncEvents(fromBlock: number): Promise<number> {
  const toBlock = await provider.getBlockNumber();
  if (toBlock < fromBlock) return fromBlock;

  const events = await contract.queryFilter(
    "*",
    fromBlock,
    toBlock
  );

  for (const event of events) {
    const { blockNumber, transactionHash, args } = event;

    // 判断是否已处理过，防止重复写入
    await pool.query(
      `INSERT INTO chain_events (tx_hash, block_number, event_name, payload)
       VALUES ($1, $2, $3, $4)
       ON CONFLICT (tx_hash) DO NOTHING`,
      [transactionHash, blockNumber, event.log?.name || "unknown", JSON.stringify(args)]
    );
  }

  return toBlock + 1;
}

async function main() {
  let fromBlock = Number(await pool.query("SELECT last_block FROM sync_state WHERE id = 1").then(r => r.rows[0]?.last_block || 0));

  setInterval(async () => {
    try {
      fromBlock = await syncEvents(fromBlock);
      await pool.query("UPDATE sync_state SET last_block = $1 WHERE id = 1", [fromBlock]);
    } catch (err) {
      console.error("[sync error]", err);
    }
  }, 5000); // 每 5 秒扫一次
}

main();

这个实现里有几个关键点：

queryFilter("*") 可以监听合约的所有事件，如果你只想监听某个事件，把 * 换成事件名即可。
ON CONFLICT (tx_hash) DO NOTHING 保证一个交易的事件不会被重复处理两次。
sync_state 表记录了扫描进度，服务重启后从上次的位置继续，不会漏。

5.3 前端如何消费这些链下数据

前端查任务列表我就不直接调合约了，而是请求后端 API：

typescript复制const fetchTasks = async (address: string) => {
  const res = await fetch(`/api/tasks?address=${address}`);
  const tasks = await res.json();
  return tasks;
};

后端 API 返回的每条任务里包含了链上数据和 IPFS 的 cid。前端拿到 cid 后，可以从 IPFS 网关（比如 https://ipfs.io/ipfs/{cid}）获取对应的大文件内容。

需要注意，IPFS 网关在国内直接访问可能不太稳，这时可以考虑使用 IPFS 的镜像网关（如 Cloudflare 的公共网关）、自建网关代理，或者把内容先缓存到自己的 CDN 服务里，这也是 Web3 应用在实际落地时常见的处理方式。

6. 部署上线与版本升级：主网部署、合约验证与多链适配

所有功能开发完，最后一步是把合约部署到主网，让用户真正可以访问。部署到主网和部署到测试网的区别在于：主网上的每一笔交易都是真实的、不可逆的，任何一个问题都可能带来真金白银的损失。

6.1 合约验证：让用户能看清代码

部署完成后，第一件事是在区块链浏览器（Etherscan）上验证合约源码。验证的好处是：任何人都可以在 Etherscan 上看到合约的 ABI 和源代码，证明合约是开源透明的，这对建立用户信任至关重要。

如果使用 Hardhat 插件，验证命令很简单：

bash复制npx hardhat verify --network mainnet <合约地址> <构造函数参数>

如果合约构造函数有参数（比如初始化的管理员地址），需要你显式传参数。

6.2 代理升级模式：合约不是一成不变的

有基础的人应该听过"合约不可篡改"，但升级合约的方式其实有很多种，其中最简单实用的是代理模式。简单来说，用户始终访问一个固定的"代理合约"，调用后通过 delegatecall 把逻辑委托给"实现合约"。如果要升级业务逻辑，只需部署一个新的实现合约，然后让代理合约指向它。

这种方式适合那些需要持续迭代的 DApp。但注意，使用代理模式会带来额外的复杂度和安全风险，如果业务逻辑很稳定，不需要升级，就没有必要为了"未来的可扩展性"而引入代理。能用简单方案解决的，就不要过度设计。

6.3 多链适配：不同链之间的关键差异

很多 DApp 不止部署一条链，比如同时部署在以太坊主网、Polygon、BNB Chain。不同链之间的差异主要体现在三个方面：

项目	以太坊主网	Polygon	BNB Chain
RPC 地址	需要单独配置	需要单独配置	需要单独配置
原生代币	ETH	MATIC	BNB
Gas 成本	高	低	低
确认时间	12~15 秒	2~3 秒	3 秒
链 ID	1	137	56

代码层面通过 chainId 动态选择 RPC 和合约地址即可：

typescript复制const NETWORKS = {
  1: {
    name: "Ethereum Mainnet",
    rpcUrl: process.env.ETH_RPC_URL,
    contractAddress: "0x...",
  },
  137: {
    name: "Polygon",
    rpcUrl: process.env.POLYGON_RPC_URL,
    contractAddress: "0x...",
  },
  56: {
    name: "BNB Chain",
    rpcUrl: process.env.BNB_RPC_URL,
    contractAddress: "0x...",
  },
};

这一步没什么黑科技，但要特别注意：部署到哪条链，就一定要用哪条链的 RPC 和浏览器验证，尤其不要搞混了部署账号的私钥和链之间的对应关系。以前见过有人把 Polygon 的合约地址配上以太坊的 RPC，前端一调用直接报错，排查半天才发现是把网络配置搞混了。

7. 安全审计与性能优化：上线前必须做的事

合约一旦部署到主网，安全就变成最高优先级。DApp 不像传统 Web 应用可以半夜紧急修复，合约出现漏洞，往往意味着资产损失。这里我说几个我自己踩过的、以及看到别人踩过的坑。

7.1 常见的合约安全漏洞（不只是重入攻击一种）

一提到合约安全，很多人第一反应是"重入攻击"，但实际上还有几类更隐蔽的坑，它们往往出现在业务逻辑和边界条件里：

溢出与下溢：Solidity 0.8+ 内置了算术溢出检查，这解决了一部分问题。但如果你用了 <0.8 的版本，或者在你自己的代码里偷偷用了 unchecked 块，溢出风险会真实存在，而且很难通过常规测试发现。
拒绝服务：例如合约里有个 owner 可以调用某个关键步骤，一旦 owner 是合约且合约里没有接收 ETH 的函数，任何调用都会失败，从而把整个流程卡死。
时间戳操控：如果业务逻辑依赖 block.timestamp（比如"某个截止时间之前可以领取"），矿工可以在短时间窗口内稍微影响时间戳。对绝大多数项目来说，这个风险很小，但如果业务涉及高价值抽奖、竞拍，就要慎重。
权限管理混乱：很多人习惯把关键函数都设成 onlyOwner，但忽略了初始化函数有没有被设置 owner 保护。如果合约部署后 owner 可以被任何人抢走，那整个合约就沦陷了。

7.2 上线前的自查清单

写代码时可以随意，上线前不行。我的固定流程是这样的：

用 Slither 或 Mythril 跑一遍静态分析，排除最常见的漏洞模式。
把合约部署到测试网后，用专门的攻击脚本试一遍关键路径。
做一次 Gas 优化：把高频函数（比如转账、更新状态）的 Gas 消耗记录在案，对比是否有明显异常。
请至少一个没参与过项目的人review一遍合约，因为写代码的人很容易"看着自己的逻辑合理"。
如果合约涉及资金，建议找专业审计团队做一次完整审计，这不是花钱买心安，而是给用户一个交代。

7.3 Gas 优化：不是玄学，是算术

Gas 优化可以省很多钱，尤其对高频交互的 DApp 来说，节省的 Gas 等于用户的成本体验。几个实用技巧：

用 uint256 而不是更小的类型：EVM 的存储槽是 32 字节，用 uint8 和 uint256 消耗的 Gas 在存储时几乎一样。盲目使用 uint8 想省 Gas 往往适得其反。
合并存储变量：多个小的状态变量如果打包在一个存储槽里（在声明顺序上相邻），写的时候可以省一笔 SSTORE 的成本。
避免在循环中读存储：循环里每次访问 storage 都会触发 SLOAD，成本很高。可以把循环条件里的状态变量先放到 memory 里。
事件参数用索引字段：indexed 参数可以让你更高效地查询历史事件，但它也会用一个额外的日志 topic，如果没有查询需求，不要随便加 indexed。

Gas 优化一定是在合约逻辑稳定之后再做的，不要一开始就纠结这个，那是本末倒置。

8. 部署后的运维：实时监控、数据备份与常见故障处理

部署完成后，我一般不会觉得"搞定了"，反而会觉得这才刚刚开始。DApp 的运维和传统后端不太一样，你需要关注链上交易是否正常、节点是否稳定、事件监听服务有没有掉队。

8.1 实时监控怎么搭

最简单的做法是，给事件监听服务加一个 健康检查接口，用定时任务检测：

RPC 节点是否可用（可以定时查询最新区块高度，确认它是不是在一直增长）。
事件同步游标是否落后于链上最新高度（如果落后超过一定区块数，说明同步服务异常）。
后端 API 的响应时间和错误率。

用一个简单的定时脚本就能实现，不至于上很重的监控平台。对很多小团队来说，与其搞一整套 Prometheus + Grafana，不如先用一个 cron + webhook 把核心指标发到群里。先把核心的报警做起来，再考虑逐渐完善。

8.2 链上数据备份冗余

数据库里的链上事件数据可以随时从链上重新拉取，但如果数据库服务宕机，前端的读接口也会挂。所以数据库要定时备份。

另外，不要把数据库当作唯一事实来源。链上数据才是事实来源，数据库只是缓存。只要合约还在链上，即使数据库全丢了，你也能通过重新扫区块把数据恢复回来。这也是 DApp 架构相比传统应用的一个优势——不容易出现"数据完全丢失"的情况。

8.3 常见故障和排查思路

用户报"交易一直 pending"：首先确认这个交易在链上有没有被别的节点接纳。多等一会儿或者取消重发（提高 gas price）是常见解法。如果是自己写的监听服务没反应，优先看同步区块的高度是否正常。

前端显示数据为空：先确认合约事件有没有被监听到，再确认数据库里有没有数据，最后看接口查询有没有出错。从链上事件到数据库再到 API，这一段链路的每一步都可能出问题。

用户反馈"签名失败"：多半是用户连接的是其他链，或者钱包里账户地址没有导出。检查你拿到的 address 是否和合约调用时用的 address 一致，并且与当前 chainId 对齐。

运维这块靠的是习惯和细心，没有什么高深的技术。但如果你能把上面这些检查项都提前做好，大概率能确保 DApp 稳定运行。

经过这个项目，我自己最大的体会是：Web3 开发其实并不神秘，它就是在"去中心化存储 + 去中心化执行"的特殊约束下，重新搭建一套业务系统。把这套架构玩熟了，无论以后做哪个细分赛道，底层的模式和坑都是相通的。现在再回头看，最难的不是写合约那几行代码，而是"从 Web2 思维切换到 Web3 思维"——你不再有一个能随便改逻辑的后端，你所有的决策都要考虑"一旦上线就不可逆"的后果。有了这个心态，你离一个合格的 Web3 开发者已经不远了。