Google App Engine 生产环境中，User.ID 是不可预测长度的字符串，常超过 int64 表示范围（±9,223,372,036,854,775,807），强行用 strconv.ParseInt(..., 10, 64) 解析会导致“value out of range”错误；应始终将其作为字符串处理。
google app engine 生产环境中，`user.id` 是不可预测长度的字符串，常超过 `int64` 表示范围（±9,223,372,036,854,775,807），强行用 `strconv.parseint(..., 10, 64)` 解析会导致“value out of range”错误；应始终将其作为字符串处理。
在 Google App Engine 的 Go 运行时中，user.ID 字段的类型明确为 string（见 cloud.google.com/appengine/go/users.User 文档）。虽然该字符串仅由数字字符组成（如 "185804764220139124118"），但它并非设计为数值标识符，也不保证可被 int64 安全容纳。
本地开发服务器（Dev App Server）可能返回较短的、恰好落在 int64 范围内的 ID（例如 12345），这容易造成误解，误以为生产环境也适用数值转换。但实际部署后，App Engine 使用全局唯一、高精度的用户标识系统（通常基于分布式生成的长整数字符串），其长度远超 64 位所能表达的最大值（math.MaxInt64 = 9223372036854775807）。你遇到的错误值 185804764220139124118 已明显大于该上限，正是典型生产行为。
✅ 正确做法：
- 直接使用 user.ID 作为 string —— 用于数据库主键（如 Datastore Key.StringID()）、缓存键、日志记录、API 响应等场景；
- 若需持久化或索引，推荐在 Datastore 中定义 string 类型字段存储该 ID；
- 如需生成确定性哈希（如分片或匿名化），使用 sha256.Sum256([]byte(user.ID)) 等字符串哈希方案，而非数值运算。
❌ 错误做法：
- 调用 strconv.ParseInt(user.ID, 10, 64) 或 strconv.Atoi()；
- 将 user.ID 强转为 int/int64 后参与算术、比较或作为结构体字段类型；
- 混淆 User.ID 与 Datastore Key.IntID() —— 后者是显式设计为 int64 的实体自增 ID，二者语义与生命周期完全不同。
// ✅ 推荐：安全、可移植、符合 API 设计意图
userID := user.ID // string 类型，直接使用
log.Printf("User signed in: %s", userID)
// 存入 Datastore（假设 UserRecord 结构体）
type UserRecord struct {
ID string `datastore:"id"`
Email string `datastore:"email"`
}
record := &UserRecord{ID: userID, Email: user.Email}
// ❌ 危险：在生产环境必然 panic
// id64, err := strconv.ParseInt(user.ID, 10, 64) // ← 不要这样做总结：User.ID 是一个 opaque string（不透明字符串），其内部格式和长度属于实现细节，不应被解析、截断或数值化。尊重其原始类型，是保障应用在开发与生产环境一致健壮的关键实践。
