Too many actions in a TransactWriteItems call

TL;DR — 一次 DynamoDB 事务最多 100 个动作。TransactWriteItems（以及 TransactGetItems）会拒绝超过 100 个 Put/Update/Delete/ConditionCheck 动作的请求。把工作拆成多个事务——或者，如果你并不需要全有或全无的原子性，改用 BatchWriteItem（每次调用 25 个）。

含义

ValidationException: 1 validation error detected: Value '<your request>' at 'transactItems' failed to satisfy constraint: Member must have length less than or equal to 100

服务会在 <your request> 所在的位置原样回显你整个序列化后的请求——对于一个 101 个动作的事务，那大约是 65,000 个字符。真正的结论在最后一句。

TransactWriteItems 把一组要么全部提交、要么一起回滚的动作聚在一起，但单个事务最多只能装 100 个动作，并且事务中各项目的总大小不能超过 4 MB。传得更多，DynamoDB 会在执行之前就拒绝整次调用。这条消息读起来往往像是在说 TransactItems 列表长度的约束。它是 HTTP 400 ValidationException，发生在客户端一侧，在事务变小之前不可重试。

为什么会发生

想原子性地批量写太多东西——试图在一个事务里提交 150 次 put。
一个循环无节制地往单个 TransactItems 列表里追加动作。
扇出超过了 100——一次逻辑操作触及超过 100 个项目，却被建模成了单个事务。
只数了写入——记住 ConditionCheck 动作也计入那 100 个。

如何修复

拆成多个事务，每个 ≤100 个动作——但要注意每个事务各自独立地保证原子性（它们不会一起回滚）。
重新想想你到底需不需要事务——如果这些写入并不要求全有或全无的语义，BatchWriteItem（每次调用 ≤25 个）更便宜，也对吞吐更友好。
减少动作数量——把对同一个项目的多次改动折叠成一次带合并 UpdateExpression 的 Update。
换一种方式给聚合建模，让一次逻辑变更触及更少的项目。

复现方法

一笔交易有 101 个操作，其中一个操作超出限制。拒绝是数组长度上的普通 ValidationException，而不是特定于交易的错误：

const actions = Array.from({length: 101}, (_, i) => ({
  Put: {TableName: 'orders', Item: {pk: {S: `T#${i}`}, sk: {S: 'META'}}}
}));
await client.send(new TransactWriteItemsCommand({TransactItems: actions}));

实际输出：

ValidationException: Member must have length less than or equal to 100
HTTP 400

请注意措辞：DynamoDB拒绝将此作为TransactItems数组的长度约束，因此你得到的字符串根本不包含任何交易。仅搜索该消息显然不会将你带到这里。

DynoTable 工作台

在以原子方式提交 100 多个写入之前，检查 DynoTable 中的目标项 — 使用 ⌘K 打开表并确认每个键都存在。暂存 (⌘S) 可让你首先测试较小的交易。在 Expression Builder 中构建多项目更新，并将一个键上的重复操作折叠到单个 Update 中。使用 ⌘P 切换配置文件；参见连接 AWS和安装。

来源

TransactWriteItems — Amazon DynamoDB API Reference（2026-07-13 验证）
Amazon DynamoDB Transactions: How it works（2026-07-13 验证）

参考资料

最后核实于 2026-07-13，依据上方链接的 AWS 官方文档。

2026-07-26 针对 DynamoDB Local 2.x 与 AWS SDK for JavaScript v3.1095.0 复现——上方输出为原样照录。