结论明确：DynamoDB 在 Go 微服务中必须放弃关系型思维、按访问模式反向建模，严格区分 GetItem/Query/Scan；主键设计决定性能与成本，Sort Key 需复合编码并防前缀冲突，GSI 必须显式配置 ProjectionExpression，空 map 需用 EnableEmptyCollections 处理。
直接说结论：DynamoDB 在 Go 微服务里不是“接入就行”，而是必须放弃关系型思维、严格按访问模式反向建模，否则单表设计会迅速变成维护噩梦。
为什么 GetItem 和 Query 必须区分清楚
DynamoDB 的性能和成本几乎全绑在主键结构上。GetItem 只能靠完整主键（Partition Key + Sort Key）精确命中，毫秒级；Query 只能查一个 Partition Key 下的 Sort Key 前缀，范围可控；而 Scan 是反模式——哪怕加了 FilterExpression，仍要全表扫描，吞吞吐量、烧钱、超时风险高。
- 真实错误现象：
ValidationException: Query key condition not supported—— 说明你在Query里用了非主键字段做条件，DynamoDB 直接拒绝 - 正确做法：把高频查询路径提前编码进 Sort Key，比如用
USER#123#ORDER#2024-05-20#ABC789这类复合结构，再用BeginsWith查某用户所有订单 - Go SDK v2 中，
Query的KeyConditionExpression必须是partitionKey = :pk AND begins_with(sortKey, :sk_prefix)形式，不能写成sortKey BETWEEN :a AND :b
dynamodbattribute 序列化器不处理嵌套 map 的零值陷阱
Go struct 里如果字段是 map[string]interface{} 或嵌套 map，dynamodbattribute.Marshal 默认会把空 map 当作 null 写入，但 DynamoDB 不允许 map 类型字段为 null —— 导致 ValidationException: One or more parameter values were invalid: An AttributeValue may not contain an empty string。
- 典型场景：微服务接收 JSON Webhook，解析到
map[string]interface{}后直传 DynamoDB - 解决办法：要么预处理，把空 map 改成
map[string]interface{}{}（非 nil），要么改用dynamodbattribute.MarshalWithOptions配置dynamodbattribute.EnableEmptyCollections为true - 注意：启用该选项后，空 slice 也会被存为
[]而非null，下游读取逻辑需同步适配
单表设计中 sk 前缀冲突会导致 Query 返回脏数据
很多教程教你在 Sort Key 里拼接类型前缀（如 ORDER#...#、INVOICE#...#），但若没控制好分隔符或长度，就可能触发前缀误匹配。例如 ORDER#123 和 ORDER#1234 都会被 BeginsWith("ORDER#123") 拉出来。
立即学习“go语言免费学习笔记（深入）”；
- 真实后果：用户查自己订单，结果混入了 ID 为 1234 的订单（因 ID 字段未对齐位数）
- 安全做法：固定长度 ID（如 UUID）或加结束标记，例如
ORDER#123#END，再用BeginsWith("ORDER#123#END")—— 但更推荐用ORDER#123#+ 严格校验后续字符不为数字/字母开头 - Go 层建议封装一个
BuildSortKey工具函数，强制注入分隔符和校验逻辑，避免业务代码手拼字符串
最常被跳过的一步：没给 GSI（Global Secondary Index）设置 ProjectionExpression 就上线，结果发现 GSI 查询返回空字段——因为默认只投射主键，其他属性得显式声明。这问题在线上压测时才暴露，但已经没法热修复 Schema。
