google datastore 对每个实体组（entity group）施加约每秒 1 次写入的软性限制，但这并非硬性瞬时阈值，而是面向长期稳定负载的设计约束；短时突发写入（如 25 次并发）通常不会触发 `too much contention` 异常。
在 Google Cloud Datastore（现为 Firestore in Datastore mode）中，“1 写/秒/实体组”并非一个精确、实时强制执行的速率限制（rate limit），而是一个基于底层架构的吞吐量保障下限与工程实践警示。其本质源于强一致性写入需通过 Paxos 协议在实体组内序列化执行——所有属于同一祖先路径的实体共享一个“写入队列”，系统会尽力保证该队列在持续负载下平均维持约 1–5 次/秒的稳定写入能力。
你当前的测试未触发 Too much contention 异常，完全符合预期，原因如下：
✅ 短时突发可被缓冲与调度：25 次并发 Put 请求在毫秒级内发起，Datastore 后端可通过内存队列、批处理优化和短暂延迟重试平滑吸收，不会立即拒绝请求。该异常仅在持续性高竞争（如连续数秒每秒 >5 次写入同一实体组）导致底层锁等待超时或事务回滚率激增时才会返回。
✅ 你的实体组设计实际较宽松：
func usersKey(c appengine.Context) *datastore.Key {
return datastore.NewKey(c, "User", "default_users", 0, nil) // ← 根实体组
}
// 每个 user.UserId 构建的 key 形如: /User/default_users/User/123
// 所有 User 实体均归属同一祖先 "default_users" → 共享一个实体组！⚠️ 这正是潜在风险点：所有用户数据被强制塞入单个实体组。虽然 25 次测试未失败，但若业务增长至每秒数百次用户创建/更新（例如秒杀场景、IoT 设备批量上报），该设计将迅速成为性能瓶颈，并显著增加 Too much contention 出现概率。
? 验证真实瓶颈的建议方法：
- 使用 持续压测（如 10 秒内每秒发起 3–8 次写入）替代单次 25 并发；
- 监控 Datastore 操作日志中的 deadline_exceeded 或 aborted 错误码；
- 在应用层添加重试逻辑（指数退避），观察 datastore.Conflict 或 datastore.Timeout 是否随负载上升而增多。
✅ 正确解耦方案（推荐）：
// 方案1：移除祖先关系（最终一致性读取可接受时）
key := datastore.NameKey("User", user.UserId, nil) // ← 无祖先，独立实体组
// 方案2：按业务维度分片（强一致性仍需保留时）
shardID := user.UserId % 100 // 分 100 个分片
shardKey := datastore.NameKey("UserShard", fmt.Sprintf("shard_%d", shardID), nil)
key := datastore.NameKey("User", user.UserId, shardKey)? 总结：
不要将 “1 write/sec/entity group” 理解为防火墙式限速器，而应视作系统可长期可靠服务的黄金水位线。架构设计目标不是“避免偶尔超限”，而是“确保峰值负载下仍具备确定性吞吐”。当你发现写入延迟上升、重试增多或错误率爬升时，就是重构实体组模型（去祖先、分片、异步化）的关键信号。
