在DynamoDB分页中，使用LastEvaluatedKey相比条件表达式有何优势？

你的手动拼接键条件的方案在单分区（固定hashKey）、排序键为单一属性的场景下确实能正常工作，但LastEvaluatedKey绝非冗余设计，而是官方针对所有分页场景推出的标准方案，优势体现在这些方面：

• 适配复合排序键与GSI场景
  很多业务场景中，表或全局二级索引（GSI）的排序键是多属性复合结构，或者GSI的分区键和主键不一致。这时候手动拼接sortKey > Last_Y会变得异常繁琐——你必须完全复刻DynamoDB的排序规则（比如多属性的排序优先级、不同数据类型的比较逻辑），稍有偏差就会导致漏数或重复取数。而LastEvaluatedKey包含了完整的主键（或GSI键）信息，直接传入下一次请求的ExclusiveStartKey参数，就能精准定位下一页的起始位置，无需自己处理复杂排序逻辑。

• 解决分页截断的边界问题
  当使用Limit参数分页时，如果最后一页存在多条排序键相同的记录，手动用sortKey > Last_Y会直接跳过这些条目（因为条件是“大于”）。但LastEvaluatedKey基于主键的唯一性，即使排序键重复，也能精准定位到上次停止的那条记录，确保后续请求能获取到剩余的同排序键条目，不会丢数据。

• 兼容所有查询/扫描操作
  LastEvaluatedKey同时支持Query和Scan操作。如果是Scan全表遍历，你根本无法通过手动拼接键条件来实现分页——因为Scan没有固定的排序逻辑，只能依赖LastEvaluatedKey记录遍历的位置。

• 降低数据变更带来的分页错误
  假设两次分页请求之间，有一条和上次最后一条排序键相同的记录被插入。用sortKey > Last_Y会漏掉这条新记录；但用LastEvaluatedKey的话，DynamoDB会基于主键的唯一性从精确位置继续遍历，不受中间数据插入/删除的影响（极端并发场景下的重复数据可通过业务逻辑去重，但比手动拼接方案可靠得多）。

• 代码更简洁易维护
  你当前场景下觉得手动拼接简单，但后续如果表结构变更（比如新增GSI、修改排序键），手动拼接的代码需要大幅调整；而使用LastEvaluatedKey的代码逻辑统一，只需要传递上一次返回的LastEvaluatedKey即可，几乎不需要修改。

简单说，手动拼接是简化版方案，仅适用于单一场景；LastEvaluatedKey是通用方案，覆盖所有复杂边界，扩展性更强，也更符合DynamoDB的设计规范。

内容的提问来源于stack exchange，提问作者Roman