App Engine 用户 ID 为何不能安全转换为 int64？

App Engine 生产环境中，`user.ID` 看起来像一串数字，但千万别被它的外表迷惑了。它其实是一个不可靠的数字字符串，长度动不动就超过 `int64` 的表示范围，也就是 ±9,223,372,036,854,775,807。一旦你用 `strconv.ParseInt(..., 10, 64)` 去解析它，就会立刻触发“value out of range”错误。所以，正确的姿势是：始终把它当作一个 opaque（不透明）的字符串来处理。

为什么非要用字符串？因为 Google App Engine Go 运行时里，`user.ID` 字段的类型明明白白就是 `string`，人家压根就不是数字。本地开发服务器为了图省事，生成的ID都比较短，像是“12345”这种，所以 `strconv.ParseInt` 能成功解析。但这只是开发环境的“优惠待遇”，千万别当真。

到了生产环境，App Engine 为了确保全局唯一性和分布式扩展性，实际分配的 User.ID 通常是一个超长的整数，例如 “185804764220139124118”。这个数字远大于 `int64` 的最大值 9223372036854775807，你那个 `strconv.ParseInt` 的错误，根因就在这里。

✅ 正确的做法是：始终把 User.ID 当作一个 opaque 字符串来用，不要做任何转换。

• 存储：直接存成 `string` 类型，无论是在数据库、缓存key还是日志里。
• 比较：直接用 `==` 或者 `strings.EqualFold` 比较就行。
• 传递：保持原样，别动它。
• 索引：在 Datastore 或 Firestore 里，作为字符串类型的索引字段。

// ✅ 推荐：直接使用 string
userID := user.ID // 类型就是 string
log.Printf("Authenticated user ID: %s", userID)

// ✅ 安全存储（比如 Datastore 实体）
type UserProfile struct {
    UserID   string // ← 存为 string 就对了
    Email    string
    Created  time.Time
}

// ❌ 危险操作：强制转 int64（生产环境必挂）
// id, err := strconv.ParseInt(user.ID, 10, 64) // 上线就 panic!

// ⚠️ 注意区分：User.ID 和 Datastore Key.IntID() 是两码事
// Key.IntID() 确实是 int64，但它只适用于手动创建的实体键，
// 和用户身份系统完全无关。

关键提醒：

• User.ID 本质上是 OpenID / OAuth 提供方（比如 Google）颁发的全局唯一标识符，设计上就是一个 opaque token，没有数值上的含义。
• 千万别尝试对它做数学运算、排序（除非字典序能满足你的需求），也别假设它能被表示成整数。
• 如果你确实需要一个数值型的用户标识（比如分库分表），那就自己生成一个独立的 `int64` 或 `uint64` 字段，比如基于哈希算法或者 Snowflake ID，千万不要从 User.ID 派生。
• 迁移旧代码时，全局搜索 `strconv.ParseInt(...user.ID...)`，果断替换成字符串操作。

一句话总结：User.ID 是 string，永远是 string。信任它的类型，别信它的内容。