DynamoDB 查询构建器
组合整个 Query 或 Scan 请求——表、索引、键条件、筛选条件、投影、Limit、排序顺序、强一致性读取和分页——并复制为可直接运行的 AWS SDK v3、DocumentClient、CLI、boto3、Java、Go、.NET、Rust、Kotlin、PHP、Ruby 或 DynamoDB-Toolbox 程序，或复制 PartiQL 语句。
dynamodb-expression-builder 是这个工具背后的开源（MIT）库。
从访问模式到可运行的请求
表达式很少是全部工作。生产环境的 Query 还要决定读哪个索引、每次请求评估多少项、排序键朝哪个方向遍历、读取是否必须强一致，以及响应带着 LastEvaluatedKey 回来时该怎么办。这些请求级参数位于表达式字符串之外 —— 复制粘贴的代码片段通常就是在这里出错。
这个构建器把请求当作工作单元。你在与我们的表达式构建器相同的类型化、保留字安全的模型之上组装键条件、筛选和投影，并在旁边设置请求选项。输出不是片段，而是可以直接运行的程序 —— import、客户端初始化、调用本身，以及在启用“获取所有页”时，把每一页结果都取完的 ExclusiveStartKey 循环。
生成的代码对每个目标都保持诚实。AWS CLI 会自动分页，所以它的 Limit 变成 --page-size，单次请求运行则加上 --no-paginate；PartiQL 拒绝那些属于 ExecuteStatement API 而非语句本身的参数；降序 Query 在可表达时会变成对排序键的 ORDER BY。
只需要表达式本身 —— 六种操作中任意一种的条件、筛选或更新表达式及其占位符映射？ DynamoDB 表达式构建器正是为此而生。 还在两种读取操作之间做选择？ Query 与 Scan 对比 拆解了各自适用的场景。
常见问题
这与 DynamoDB 表达式构建器有什么不同？
两者刻意分工。表达式构建器关注表达式语法 —— 覆盖全部六种操作的键条件、筛选条件、更新表达式和条件表达式，以及它们的 ExpressionAttributeNames/Values 映射 —— 并只输出命令本身。查询构建器关注完整的 Query 或 Scan 请求：表和索引、键条件、筛选、投影，再加上表达式工具不提供的请求级参数（Limit、排序方向、ConsistentRead、ExclusiveStartKey），并输出一个带客户端初始化和可选分页循环的可运行程序。
在 Query 或 Scan 中，Limit 到底限制的是什么？
Limit 限制的是 DynamoDB 每次请求评估的项数，而不是你收到的匹配项数。筛选在读取之后执行，所以带 Limit 25 和 FilterExpression 的 Query 可能返回不足 25 个项 —— 甚至一个都没有 —— 却仍然消耗其评估的全部读取容量，分页则从 LastEvaluatedKey 继续。在会自动分页的 AWS CLI 中，同一参数通过 --page-size 设置。
DynamoDB 分页（LastEvaluatedKey）是如何工作的？
若 Query 或 Scan 的响应还有更多数据，其中会包含 LastEvaluatedKey——最后读取的那一项的主键。你在下一次请求中把它作为 ExclusiveStartKey 传回，如此反复，直到返回的响应不再包含它。开启“获取所有页”后，生成的 SDK v3、boto3、Java 和 .NET 程序中就包含这个循环；Go、Rust、Kotlin、PHP、Ruby 和 DocumentClient 使用各自 SDK 的原生分页器；AWS CLI 除非你传入 --no-paginate，否则会自行翻页。
什么时候可以使用强一致读取？
ConsistentRead 适用于基础表和本地二级索引，但不适用于全局二级索引 —— 对 GSI 发起并设置了 ConsistentRead 的 Query 会被拒绝。强一致读取消耗的读取容量也是最终一致读取的两倍。它是 API 参数，不属于 PartiQL 语句文本，所以 PartiQL 标签页会如实拒绝它。
我在这里输入的内容会被上传到任何地方吗？
不会。这是一个静态页面：请求的组装和代码的生成完全在你的浏览器中完成，表名、键值和筛选条件永远不会到达服务器。“复制链接”会把整个请求打包进 URL —— 分享该链接是你输入的内容离开页面的唯一途径，而这由你掌控。