在 Go 中使用 json.Unmarshal 解析 Telegram Bot API 等具有动态 result 字段的 JSON 响应时，直接将 Result 定义为 interface{} 会导致其被默认解析为 map[string]interface{}，无法直接类型断言为自定义结构体；应改用 json.RawMessage 延迟解析，再按需反序列化。
在 go 中使用 `json.unmarshal` 解析 telegram bot api 等具有动态 `result` 字段的 json 响应时，直接将 `result` 定义为 `interface{}` 会导致其被默认解析为 `map[string]interface{}`，无法直接类型断言为自定义结构体；应改用 `json.rawmessage` 延迟解析，再按需反序列化。
Go 的 encoding/json 包在遇到 interface{} 类型字段时，会根据 JSON 值的原始形态自动选择底层表示：对象 → map[string]interface{}，数组 → []interface{}，字符串 → string，以此类推。这虽具通用性，却破坏了类型安全性——你无法直接 resp.Result.(*User)，因为运行时实际是 map[string]interface{}，而非已解码的 *User。
解决方案是延迟解析（deferred unmarshaling）：将 Result 字段声明为 json.RawMessage，它本质是 []byte 的别名，仅负责“暂存”原始 JSON 字节流，不执行任何解析：
type Response struct {
Ok bool `json:"ok"`
ErrorCode int64 `json:"error_code,omitempty"`
Description string `json:"description,omitempty"`
Result json.RawMessage `json:"result,omitempty"`
}随后，在明确预期类型后，再对 Result 进行二次 json.Unmarshal：
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
// 假设已获取 resp *Response
var user User
if err := json.Unmarshal(resp.Result, &user); err != nil {
log.Fatal("failed to unmarshal result as User:", err)
}
// 此时 user 已是完整解析的 User 实例
fmt.Printf("User: %+v\n", user)✅ 优势显著：
- 类型安全：编译期无误，运行时精准匹配结构体字段；
- 零反射开销：避免
map[string]interface{}到结构体的手动映射； - 可组合性强：可配合
switch或策略模式统一处理不同Result类型（如User、Message、Chat等）； - 错误定位清晰：解析失败时错误信息直接指向具体字段，而非模糊的接口断言 panic。
⚠️ 注意事项：
-
json.RawMessage必须配合指针接收（如&user），否则解码无效； - 若
Result可能为null，需先检查len(resp.Result) == 0或使用json.Valid(resp.Result)防止Unmarshalpanic； - 不要将
json.RawMessage直接嵌入导出结构体并长期存储——它不满足json.Marshaler接口，序列化时可能意外转义为 base64 或报错；如需持久化，请先解码为具体类型再序列化。
通过 json.RawMessage + 二次解码，你既能保持 API 响应结构的灵活性，又能享受强类型的全部优势——这正是构建健壮、可维护的 Go SDK 的关键实践。
