拉卡拉开放平台

把一百笔请求合成一次提交，听起来是显而易见的优化。但在支付这类场景里，批量并不总是更优解。

批量真正解决的是请求开销

批量减少的是网络往返次数与连接开销，它并不减少业务处理量，也不降低单笔的失败概率。

为什么有批量上限

批量条数通常存在上限，原因主要有三个：

• 单次请求体过大，传输与解析成本上升；
• 处理时间变长，容易触发超时；
• 一旦失败，影响面过大。

上限不是限制能力，而是把单次失败的影响控制在可承受范围内。

部分成功必须单独处理

批量提交最需要警惕的结果形态是部分成功：一部分成功，一部分失败。这时不能简单地把整批标记为失败或成功。

1. 逐条读取结果，区分成功与失败；
2. 失败的记录下原因，决定是否重试；
3. 重试时只重发失败的那几条，不整批重来。

第三步最关键——整批重发会让已经成功的部分被重复处理。

什么时候改用逐笔

• 每笔金额较大、需要单独确认时；
• 各笔之间业务规则不一致时；
• 需要即时拿到明确结果时。

判断标准可以简化为一句话：如果其中一笔失败会让整批失去意义，就不应该用批量。

批量结果的结构

批量返回通常包含整体与明细两层信息：

处理时应当以明细为准，整体数字只用于快速判断，不能仅凭整体成功数就认为万事大吉。

批量与一致性

一个常见误解是：批量请求要么全成功要么全失败。实际上多数批量操作并不保证这一点，部分成功是完全正常的结果形态。

把批量当成事务来用，是批量场景里最危险的一个假设。

拆批的合理方式

• 按条数上限拆分，不要一次塞入过多；
• 按业务维度拆分，规则相同的放一批；
• 拆批后为每批保留独立标识，便于分别追踪。

第二条常被忽略：把规则不同的请求混在一批，一旦部分失败，重试逻辑会变得非常复杂。

什么时候批量真正划算

批量最适合那些单笔金额小、失败可容忍、量大且规则一致的场景，例如批量查询、批量核对。反过来，涉及资金变动、需要即时确认的动作，逐笔往往更合适。

批量失败后的定位

批量返回里通常包含每条的标识，这是定位的关键。处理批量结果时，应当把每条的标识与结果一起落库，而不是只记录成功了几条。

• 成功条数用于快速判断整体情况；
• 明细记录用于后续逐条处理；
• 两者缺一，后续都会陷入被动。

只记数字不记明细，等于知道有人失败了，却不知道是谁。

此外，批量请求本身也应有一个整体标识，便于把一次提交的所有明细串起来。

批量是一种优化手段，不是一种业务模型。用它之前先问一句：这里面的某一笔失败了，其余的还有意义吗？答案决定了该不该批量。

回到选择本身：批量与逐笔不是优劣之争，而是适用场景之别。想清楚失败时的处理路径，答案通常就自然浮现了。

把这三条放在一起看，批量与逐笔的分界线其实很清晰：凡是需要单独确认结果、单独承担失败后果的动作，都不适合塞进批量。