一笔 Solana 交易的一生

开场

用户点击「买入」的那一刻，对他来说是一个动作。

对平台来说，是一条流水线的启动。这条流水线上有 10+ 个环节，每个环节都可能卡住或失败。平台的核心工程能力，就体现在怎么把这条流水线做得又快又稳。

我见过不少新手开发者上手就做交易 Bot，然后在用户投诉「交易失败」「买不到」的时候不知道问题出在哪里。因为他们只看到了”发一笔交易”这一步，没看到前后还有十几步。

这篇文章把整条流水线摊开讲一遍。

流水线全景

用户点击「买入 1 SOL 的 Token X」
  │
  ├─ 1. 参数校验
  ├─ 2. 路由选择
  ├─ 3. 交易构建
  ├─ 4. 交易模拟
  ├─ 5. 签名
  ├─ 6. 提交（Jito Bundle 或直接 RPC）
  ├─ 7. 传播到 Leader
  ├─ 8. 排队进入区块
  ├─ 9. 执行
  ├─ 10. 确认
  └─ 11. 状态同步到用户

下面逐个拆。

步骤 1-3：交易构建阶段

1. 参数校验

平台首先要判断这笔交易是否值得提交：

余额检查：用户账户是否有足够的 SOL
权限检查：用户是否有 KYC、是否在黑名单
Token 检查：Token 是否还在正常交易（不是刚 Rug 的）
滑点检查：用户设置的滑点是否合理
风控检查：是否触发平台的风控规则（短时间内频繁买卖同一 Token 等）

成熟的平台在这一步就会拦截 80% 的问题交易，不让它们进入后续流水线，节省大量资源。

2. 路由选择

同一个 Token 可能在多个 DEX 上有流动性：

Token X 的流动性分布：
  - PumpSwap: 60%
  - Raydium:  30%
  - Meteora:  10%

买入 1 SOL 的最优路径可能不是走流动性最深的池子，而是拆单：

0.6 SOL → PumpSwap
0.3 SOL → Raydium
0.1 SOL → Meteora

这样每个池子的价格影响都更小，总滑点最低。

实现选择：

自己实现路由算法（复杂但灵活）
直接集成 Jupiter（简单但多一层依赖）

大多数成熟平台的方案：狙击直连 PumpSwap / Raydium（追求速度），普通交易走 Jupiter（追求最优价格）。

3. 交易构建

构建一笔 Solana 交易需要设置：

Instructions：要执行的指令（DEX Swap、Token Account 创建等）
Recent Blockhash：防重放 + 过期机制，约 1 分钟后过期
Compute Unit Limit：这笔交易最多消耗多少算力
Compute Unit Price：每单位算力愿意支付多少
Signers：签名者

对于复杂路由（多跳、多 DEX），还要考虑：

是否需要创建 Associated Token Account
是否需要 wrap/unwrap SOL
Token 账户的 rent exemption

步骤 4：交易模拟

这是最容易被新手忽视、但至关重要的一步。

const simulation = await connection.simulateTransaction(tx);
if (simulation.value.err) {
  // 模拟失败，不要提交
  return handleSimulationError(simulation);
}
// 从模拟结果获取准确的 CU 消耗
const actualCU = simulation.value.unitsConsumed;

为什么要模拟？

提前发现会失败的交易（滑点超限、流动性不足等），避免白白浪费 Gas
获取准确的 CU 消耗，精确设置 CU Limit（设太低会失败，设太高浪费钱）
检查是否触发蜜罐（买入交易如果显示返回 0 Token，就是蜜罐）

什么时候可以跳过模拟？

极端追求速度的狙击场景（省下模拟的 50-100ms）
跟单（交易模式已知且相似）

但要承担额外的失败率。

步骤 5-6：签名和提交

5. 签名

托管钱包：后端用存储的私钥签名，用户无感知，速度最快
非托管钱包：发回前端让用户钱包（Phantom / Backpack）签名，用户要点一次”确认”

速度对比：

托管：0ms（后端直接完成）
非托管：2-10 秒（等用户点击确认）

这就是为什么几乎所有专业 Meme 交易平台都提供托管钱包选项 —— 速度在这个场景下比安全性优先级更高（用户自己也愿意接受这个权衡）。

6. 提交

有两种提交方式：

方式 A：直接通过 RPC 提交

const sig = await connection.sendTransaction(tx);

简单、延迟低
但没有 MEV 保护，大额交易容易被夹

方式 B：通过 Jito Bundle 提交

const bundle = [tx];
await jitoClient.sendBundle(bundle, tipAmount);

保证 Bundle 内的交易不会被插入
支持 DontFront 防三明治
稍微慢一点（经过 Jito Block Engine）

实战策略：

普通小额交易：方式 A，省 Jito Tip
大额交易、狙击：方式 B，保护优先

高级玩法：两种方式同时提交，哪个先成功用哪个。代价是多付一份费用，收益是最大化落链率。

步骤 7-9：链上执行阶段

7. 传播到 Leader

Solana 每个 slot 有一个指定的 Leader 验证者负责打包交易。你的交易需要传到那里。

影响传播速度的因素：

RPC 节点的地理位置
是否使用 Staked Connection（优先传输通道）
网络拓扑

优化手段：

使用 Helius、Triton 等高性能 RPC
关键场景用 Staked Connection
自建节点，直连验证者集群（极端场景）

8. 排队进入区块

Solana 每个区块的容量有限：

Compute Unit 上限：每 block 约 48M CU
交易数上限：视每笔交易的 CU 而定

当交易量暴增（热门 Token 发射），你的交易会和其他交易竞争打包顺序。Priority Fee 和 Jito Tip 决定了优先级。

经验值（2025 年数据）：

正常时期：Priority Fee 0.00001-0.0001 SOL
热点时期：0.001-0.01 SOL
极端时期：0.1-1 SOL（热门发射的前 30 秒）

9. 执行

进入区块后，验证者按顺序执行每一笔交易。执行结果有三种：

Success：正常成交
Failure (Slippage/CU/…)：交易被打包但执行失败
Dropped：交易没被打包（Gas 不够优先）

这里一个微妙的点：失败和 Dropped 对用户都显示为「交易失败」，但处理方式完全不同：

Failure：参数问题，要让用户调整（比如增加滑点）
Dropped：竞争问题，要增加 Priority Fee 重试

平台的监控需要区分这两种情况才能给出正确反馈。

步骤 10-11：确认与同步

10. 确认

Solana 有三个确认级别：

级别	含义	延迟	适用
processed	节点已处理	~400ms	乐观展示
confirmed	多数验证者确认	~1s	一般操作
finalized	不可回滚	~6-12s	大额资金

对 Meme 交易：

用 confirmed 级别就够了
涉及提现、大额的才等 finalized

11. 状态同步

交易确认后，平台要做一系列后续操作：

更新用户的 Token 持仓
推送通知（订单成交、止盈止损触发等）
记录到用户的盈亏历史
触发相关的自动化规则（比如跟单者的跟单逻辑）

全流程的延迟预算

一笔典型的 Meme 交易，端到端时间预算：

参数校验、路由、构建：  50ms
交易模拟：              50-100ms
签名：                  0-5ms（托管）
提交到 Jito：           50-100ms
传播到 Leader：         100-200ms
等待区块：              400ms（一个 slot）
执行 + 确认：           1-2s
状态同步、通知：        100ms
━━━━━━━━━━━━━━━━━━━
总计：                  2-3s

这就是为什么你在平台上点击「买入」，通常 2-3 秒能看到结果。 快于这个数字的是特殊优化，慢于这个数字的说明某个环节出了问题。

失败处理：比成功路径更重要

一个专业交易平台 70% 的代码在处理失败场景。

常见失败原因和处理

失败原因	自动处理	需要用户介入
Blockhash 过期	用新 Blockhash 重试	-
CU Limit 不足	增加 CU 重试	-
Priority Fee 不够	提高 Fee 重试	-
滑点超限	是否自动调高？（风险决策）	通常需要用户确认
余额不足	-	提示充值
Token 流动性枯竭	-	提示
RPC 错误	切换 RPC 重试	-
Jito Bundle 失败	降级为直接提交	-

好的平台把这些处理做得对用户透明，让用户感觉”交易很少失败”。差的平台把错误原样抛给用户，导致用户看到一堆看不懂的报错。

给开发者的几个建议

先模拟再提交，失败率能降低 50% 以上
动态设置 Priority Fee，不要写死
监控每一步的延迟，发现瓶颈才能优化
准备好降级策略，Jito 挂了要能退回直接提交，主 RPC 挂了要能切换备用 RPC
把失败处理做好，这直接决定了用户体验

系列文章

这是《Meme 交易平台深挖》系列第 3 篇。

后续计划：

《Pump.fun 凭空造了一个十亿美元市场》
《Jito 到底是什么》

开场