Boto3中DynamoDB的Client与Resource对象Query方法优劣对比

针对DynamoDB服务，初始化对象的两种方式：

dynamodb = boto3.resource('dynamodb')

以及

client = boto3.client('dynamodb')

使用 Client 对象 Query 方法的优点 #

• 原生数据直接可控：返回DynamoDB原生的AttributeValue格式数据（如{'S': 'username'}、{'N': '100'}），适合需要自定义序列化/反序列化逻辑、完全掌控数据处理流程的场景。
• 完全贴合底层API：参数和返回结构与AWS DynamoDB官方API严格对应，能精准控制API调用的每一个细节，比如自定义请求头、精细处理分页参数等。
• 极端场景下性能略优：省去了Resource层的数据转换封装开销，在超大规模批量数据处理的极端场景中，能减少少量转换耗时。
• API覆盖更全面：涵盖DynamoDB所有官方API操作，部分较新或边缘功能会先在Client中提供支持，Resource的封装可能存在滞后。

使用 Client 对象 Query 方法的缺点 #

• 数据解析繁琐：必须手动解析AttributeValue格式，无法直接获取Python原生类型，代码冗余且易出错，比如要获取字符串值需写item['Name']['S']，而非Resource的item['Name']。
• 缺乏高层封装便利：没有自动分页处理，需手动管理LastEvaluatedKey来实现分页；也不支持Resource提供的对象化操作（如直接操作Table、Item实例），代码复杂度更高。
• 可读性与维护性差：手动处理数据格式会让代码变得冗长，不如Resource的代码简洁直观，长期维护成本更高。
• 无内置类型校验：Resource会对输入输出做类型转换和基本校验，Client需自行确保参数格式正确，更容易出现参数错误导致的API调用失败。

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