Spring Boot 3+Vue3出行旅游系统实战：从零到答辩全流程解析
2026/9/20 8:20:41
先用一句话给结论：这不是合约代码的问题，也不是 Remix 的问题，而是你的交易根本没有被 Ganache 正确打包。
我当初第一次配这套环境的时候也被这个问题折磨过：Remix 里选好了 Injected Provider，MetaMask 也连上了，账户列表跟 Ganache 里的地址、余额全都对得上，可只要一点 Deploy，交易就挂在 pending 上纹丝不动。换成 Remix 内置的 JavaScript VM 之后，一步部署、秒出结果。当时我也一度以为是自己合约写错了，后来排查了一圈才发现，问题出在“钱包和本地节点之间的链路配置”上，而且坑位相当固定。
这篇文章就把我踩过的坑和完整的排查流程整理出来，给卡在同样位置的同学一条清晰的解决路径。内容围绕Remix + MetaMask + Ganache 这套本地开发三件套，专门解决“部署一直 pending、切内置网络就成功”的问题，适合刚入门 Solidity 开发、第一次搭本地测试环境的同学。
1. 先别改合约：搞清楚两种部署模式为什么会不一样
1.1 JavaScript VM：浏览器内存里的“假链”
Remix 内置的 JavaScript VM 本质上是一个跑在浏览器内存里的模拟区块链。它不需要任何真实网络，也不存在“出块”“广播”“Gas 手续费”这些概念。你点 Deploy，交易在浏览器内部直接执行，代码跑完就算成功，整个过程根本不会产生 pending。
所以在VM 里能部署成功，说明你的合约语法、构造函数、字节码这些都没问题，至少从 Solidity 编译和部署角度是通的。这也是很多同学陷入误区的地方：以为 VM 能跑、Ganache 就该能跑，然后开始怀疑 Ganache 坏了、MetaMask 坏了，甚至怀疑人生。
其实 VM 和你本地搭的 Ganache 环境之间，差的不是“合约好不好”，而是“交易走不走真实链路”这一大截。
1.2 Injected Provider + MetaMask：交易真实广播链路
当你把 Remix 的 Environment 切到 Injected Provider（新版 Remix 是在 Wallet 区域连接 MetaMask），整个交易链路就变成了这样：
- Remix 把部署合约的交易发给 MetaMask；
- MetaMask 弹窗让你确认签名；
- 签名完成后，MetaMask 把交易广播到当前选中的网络；
- 如果当前选中的网络是 Ganache，那么 Ganache 这个本地节点负责接收交易、执行合约、产出新区块；
- 交易被打包进区块后，Remix 才能拿到部署结果。
这个链路里任何一个环节出问题，交易都会卡住。而 Ganache 的默认配置是“交易一到就立即出块”，正常情况下根本不该出现 pending。一旦 pending，基本就是交易压根没有到达 Ganache，或者在 MetaMask 签名之后被发到了别的网络。
1.3 一个类比：为什么账户对得上还会 pending
很多同学卡住的点在于：“我 MetaMask 里的账户就是 Ganache 的账户，余额也是 100 ETH，怎么还连不上？”
这里我打个比方。账户能对上，相当于你找到了正确的门牌号，但这不代表房间里有人开门。你把一封信塞进邮筒，邮局能不能送到，取决于邮编（Chain ID）写没写对、收件地址（RPC）对不对。如果邮编写错了，信会送到另一个城市；如果地址端口写错了，信就一直在快递中转站里躺着，状态永远都是“运输中”，也就是交易永远 pending。
所以排查的方向很明确：先确认交易到了哪里，再回头检查链路配置。
2. 两分钟定位问题：交易到底有没有到 Ganache
2.1 第一步：看 Ganache 的 Transactions 列表
这是整个排查过程中最关键的一步，直接决定你往哪个方向找问题。
打开 Ganache，看到界面上的 Transactions 标签页。如果你刚才在 Remix 里发起过部署，但 Transactions 列表里面什么都没有，说明交易压根没到 Ganache 这个节点，问题出在 MetaMask 或者网络配置上。
如果 Transactions 列表里有一条交易，状态一直停在 Pending，说明交易已经到达 Ganache，但节点没有把它打包出块。这时候就要检查 Ganache 的区块高度有没有在增长，以及自动挖矿是不是被关掉了。关于自动挖矿的问题，我后面会单独讲。
提示：GitHub 上有叫 ganache-cli 的命令行工具，它的日志输出更直白，能看到 inbound transaction 的消息。如果你用的是命令行版本，直接看终端输出就行。我之前排查类似问题时，就是靠终端日志判断出交易根本没进来的。
2.2 第二步：看 Remix 控制台和 MetaMask 活动记录
接下来打开 MetaMask 的“活动”标签页，看刚才的部署交易在钱包这边的状态。如果 MetaMask 里显示这笔交易是“已签名”或者“已发送”，但状态一直没有确认，那你在 MetaMask 里就已经能看出交易被发到了哪个网络。
同样，Remix 的 Terminal 面板也会打印交易详情。交易卡住时，Remix 的日志里通常会显示 pending 状态，或者一直转圈。这里有一个很实用的信息：交易 hash，以及当前等待确认的网络 ID。
如果你会用 MetaMask 的“查看自定义网络 RPC”功能，也可以在设置里看一下当前激活网络的详细信息，重点核对 RPC URL 和 Chain ID。
2.3 第三步：看 Ganache 的 Logs 日志
Ganache 桌面版界面上有 Logs 标签页，里面会记录合约部署和交易调用的明细。如果交易确实到达了节点，日志里会有对应的请求记录。如果日志里干干净净，那结论就很明确了：交易在 MetaMask 那一层就已经走丢了。
我当时排查的实际情况是这样的：Ganache 的 Transactions 列表是空的，Logs 里面什么都没打印。这说明什么？说明 MetaMask 虽然显示已连接、账户能对上，但它签出来的交易根本没有发给 Ganache。最后我检查链 ID 才发现，Ganache 启动后的链 ID 是 1337，而 MetaMask 里配置的链 ID 填成了 5777（那是旧版 ganache-cli 默认值），交易被 MetaMask 当成另一条链的交易发走了，自然没人认领，永远 pending。
3. 四个高频根因，挨个排除
3.1 坑一：MetaMask 的 Chain ID 填错了
这是出现频率最高的原因，没有之一。
Ganache 新版默认的 Chain ID 是1337，旧版本或者某些教程里写的是 5777。如果你在 MetaMask 自定义网络里填了跟 Ganache 实际链 ID 不一致的值，MetaMask 会把它当成不同链来处理，交易签名之后广播出去，Ganache 根本不会接受，因为节点校验的时候发现链 ID 对不上。
为什么链 ID 这么关键？我给新手解释一下。链 ID 是用来防止“交易重放攻击”的——一条链上的合法交易，不应该能被复制到另一条链上重新执行。所以每个交易里都会带上链 ID，节点收到交易后第一个检查的就是它。链 ID 对不上，其他都不用看了，直接拒收。
所以排查第一步：打开 Ganache，找到当前工作区的 Chain ID 是多少（新版 UI 在 Server 配置里，一般显示在右上角或者设置中），然后去 MetaMask 的自定义网络设置里核对，确保完全一致。如果你用的是 ganache-cli，启动时可以通过--chain.chainId指定，比如：
ganache-cli --chain.chainId 1337这样就能保证每次启动的链 ID 一致，不会出现本次 1337、下次又变成其他值的情况。
3.2 坑二：RPC 地址或端口配置错误
Ganache 桌面版默认 RPC 端口是7545，旧版的 ganache-cli 是8545。这个数字改了又改，确实容易搞混。
更隐蔽的是，有些教程让你在 MetaMask 里填http://localhost:7545，有些让你填http://127.0.0.1:7545。大多数情况下两者都能用，但个别场景下（特别是 Node 版本、浏览器代理设置不同的时候），localhost 的解析可能会出问题。我在 Windows 上就遇到过 localhost 被代理拦截的情况，换成 127.0.0.1 之后立刻通了。
建议直接用http://127.0.0.1:7545，避开 DNS 解析环节，少一个变量就少一个坑。
还有一个容易忽略的点：如果你电脑上同时跑着别的区块链节点服务，比如其他端口被占用，Ganache 会自动换端口。Ganache 启动界面会显示当前实际监听的端口，你在 MetaMask 里填的一定要和界面显示的完全一致，不要凭记忆填 7545 或者 8545。
3.3 坑三：Gas 价格低于 Ganache 门槛
交易能不能被打包，还有一个硬性指标：Gas 价格。
Ganache 默认会配置一个最低 Gas 价格门槛，如果 MetaMask 发送的交易里带的 Gas Price 低于这个值，节点出于防止垃圾交易的目的会拒绝打包，表现就是交易一直 pending。
Ganache 桌面版当前的默认 Gas Price 是20 Gwei，但你在 MetaMask 里如果手动调整过 Gas 策略，或者某些钱包扩展默认设置了很低的 Gas 上限，就可能低于 Ganache 的要求。
处理方式很简单：
- 在 Ganache 设置里找到 Gas Price 的配置值；
- 在 MetaMask 高级设置里，把“自定义交易 nonce”之类的高级选项关掉，或者恢复默认 Gas；
- 部署时 MetaMask 弹窗里显示的 Gas 费，让它自动估算就行，不要手动改成特别小的数值。
注意：本地测试网根本不缺 Gas，Ganache 预置的 100 ETH 就是为了让你随便造。这里讲的不是“Gas 太贵付不起”，而是“Gas Price 报价低于节点的接受下限”，概念上别混淆。
3.4 坑四：自动挖矿被关掉了
Ganache 默认是自动挖矿（Automine）模式，也就是收到交易立刻出块，秒级确认。但如果你改过设置，把自动挖矿关掉了，或者设置了固定的出块间隔，交易就会在队列里排队，直到你手动触发挖矿或者等待下一次出块。
判断方法：看 Ganache 界面的“区块”高度。部署完一笔交易之后等五秒钟，如果区块高度完全没有增长，说明自动挖矿没在工作。
解决办法：
- 在 Ganache 设置里把 Automine 打开；
- 如果你确实需要模拟固定出块时间的场景，可以通过点击 Ganache 界面上的挖矿按钮手动出块。
实际上大部分本地开发场景，自动挖矿开着就够用了。这个坑出现的概率不如前两个高，但一旦出现，排查起来也比较隐蔽，因为账户、网络、Gas 全都正常，唯一不对的就是区块不出。
4. 从零配一遍：完整可复现的修复流程
前面讲了原理和常见根因，下面给一份可以直接照着操作的完整配置流程。这一套流程我实测过很多次，配完之后再部署基本不会再卡 pending。
4.1 重置 Ganache 工作区
先别急着在现有配置上修修补补，直接把 Ganache 的工作区重置一下，拿到一个干净的环境最省事。
启动 Ganache 桌面版，点击“新建工作区”——如果你之前用 Quickstart 启动过，直接重新创建一个。创建之后在界面上记录三个关键信息：
- RPC 地址（一般是
http://127.0.0.1:7545）； - 链 ID（新版默认 1337）；
- 第一个测试账户的私钥（界面右侧有复制按钮，用于导入 MetaMask）。
另外记住，Ganache 每个测试账户默认有 100 ETH，这个余额在我们验证网络连接时非常有用。
4.2 在 MetaMask 里添加正确的自定义网络
打开 MetaMask，点击右上角账户头像，进入“设置 → 网络 → 添加网络”。在弹出的表单里按下面这个配置填：
| 配置项 | 填写内容 |
|---|---|
| 网络名称 | Localhost Ganache |
| RPC URL | http://127.0.0.1:7545 |
| 链 ID | 1337 |
| 货币符号 | ETH |
填完之后点击保存，然后确保 MetaMask 当前激活的网络是刚才添加的“Localhost Ganache”。激活状态下，MetaMask 顶部显示的网络名称应该就是它。
这里有一个很容易忽略的细节：MetaMask 底部有一个“切换网络”菜单，除了这里能切网络以外，在 Remix 部署时弹出的交易确认界面也会显示当前网络名称。一定要在签名前看清楚了，确认显示的是 Localhost Ganache，不是 Ethereum Mainnet 或者 Sepolia。
4.3 导入测试账户并确认余额
回到 MetaMask，点击账户头像，选择“添加账户或硬件钱包 → 导入账户”，把 Ganache 第一个账户的私钥复制进去，导入之后账户地址应该和 Ganache 显示的第一个账户地址一模一样。
导入成功后，MetaMask 的资产页应该会显示 100 ETH 的余额。如果余额显示是 0 ETH，甚至提示“私人交易失败”，那说明网络配置有问题，别继续部署了，先回去检查 RPC 和链 ID。
这步本质上是验证“钱包到节点的读取链路通不通”。能读到余额，说明 RPC 连接是通的；链 ID 不对，在切换网络的时候 MetaMask 会直接报错，但有些时候 MetaMask 不会立刻报错，而是等到交易的时候才出问题，所以余额检查是一个很好的提前预警手段。
4.4 Remix 侧部署面板的设置与确认节点
打开 Remix，打开你的合约文件，先完成编译。编译成功后，进入“部署和运行交易”面板：
- 在 Environment 下拉菜单里选择Injected Provider - MetaMask（如果你用的新版 Remix 界面，可能是在 Wallet 连接区域选择 MetaMask）；
- 在 Account 下拉菜单里，确认显示的是刚才导入的 Ganache 账户地址；
- 合约下拉菜单选中你要部署的合约；
- 点击 Deploy。
点击 Deploy 之后，MetaMask 会弹出一个交易确认窗口。注意看这个窗口里的信息：网络名称、Gas 费用、合约地址。确认网络是 Localhost Ganache 之后，点击确认。
正常情况下，几秒钟之后 Remix 左下角的“已部署合约”区域会出现部署的合约实例，Ganache 的 Transactions 列表里也会出现一条成功记录。至此，整个链路就打通了。
如果在确认窗口里发现网络是其他的（比如显示的是 Localhost 8545 但实际配置不对，或者直接显示主网），立刻取消交易，回到 MetaMask 检查网络选择，别签。
5. 常见问题速查表与独家避坑经验
5.1 问题速查表
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 账户能对上，部署一直 pending，Ganache 无记录 | 链 ID 不匹配 / RPC 端口错误 | 核对链 ID、检查 MetaMask 网络配置 |
| Ganache Transactions 有 pending，但区块高度不变 | 自动挖矿关闭 / Gas 低于节点门槛 | 开启 Automine、恢复默认 Gas 设置 |
| MetaMask 弹窗一直转圈不出现 | RPC 地址不可达 / localhost 解析异常 | 换 127.0.0.1、确认端口 |
| 部署失败提示 insufficient funds | 导入的账户不是 Ganache 的账户 | 核对私钥导入是否正确 |
| 切内置 VM 能部署，切 Ganache 就 pending | 链路配置问题，非合约问题 | 按本文第 4 节重新配一遍 |
| 之前能部署，突然一直 pending | MetaMask 有卡住的旧交易 / Nonce 错乱 | 重置账户 nonce 或清除缓存 |
这里面最后一条值得展开讲一下。MetaMask 的“活动”列表里如果有之前卡住的交易，且它的 nonce 排在前面，后面新发出的交易会被阻塞，表现就是所有新交易全部 pending。处理方式是在 MetaMask 的“设置 → 高级”里找到“清除活动日志和 Nonce 数据”，点一下，再重试。这个操作不会清掉你的账户和余额，但会重置交易状态。
5.2 避坑技巧：开发时的最优实践
最后分享三条我在本地开发中沉淀下来的实践心得。
第一，开发顺序上，先 VM 后网络。我现在的习惯是，写合约的时候先在 Remix 内置 VM 里把逻辑跑通，所有的单元测试、边界条件都在 VM 里验证。确定合约没问题之后，再切到 Ganache + MetaMask 环境做钱包交互和真实签名测试。这样能最大程度避免“合约问题”和“链路问题”混在一起时难以排查的局面。VM 是纯逻辑验证，Ganache 是集成验证，两个阶段各司其职。
第二，本地开发时尽量少用 MetaMask 弹窗，多用 Remix 的注入模式。有了 Ganache 这种零确认出块的节点，事务速度已经很快了。但如果你部署频繁，可以试试给 Ganache 配置更大的 Gas 限制，减少大合约部署时的失败概率。另外，频繁测试时，MetaMask 的确认弹窗会拖慢节奏，但千万不要因此跳过网络配置的检查。
第三，遇到玄学问题先重启三个东西：Ganache、MetaMask、Remix 页面。很多人卡在 pending 半天，最后发现只是 MetaMask 的扩展缓存出了问题。按顺序先重启浏览器里的 MetaMask，再重启 Ganache 工作区，最后刷新 Remix 页面。大部分情况下，这三个都做完了，pending 就消失了。如果还不通，再按本文第 2 节的方法去定位。
我自己的体会是，Remix 和 Ganache 这套组合在本地开发里依然是最趁手的工具，尤其是配合 MetaMask 做钱包登录、签名这类有真实交互的场景。pending 问题看起来吓人，本质上就是“交易没有被正确的链处理”。只要顺着“交易到没到节点”这个思路去查，大概率十分钟内就能定位到原因。最怕的就是一上来怀疑合约或者重装软件，反而把自己绕进更深的坑里。把这套配置流程多走两遍，你会发现本地部署速度比内置 VM 也没慢多少，而心里的底气和对整个链路的掌控感，是完全不一样的。