本文介绍如何用 Go 安全、高效地解析结构不固定的 JSON 数据（可能是单个对象或对象数组），并统一提取 email 字段值，避免 interface{} 类型断言带来的维护风险。
本文介绍如何用 go 安全、高效地解析结构不固定的 json 数据（可能是单个对象或对象数组），并统一提取 `email` 字段值，避免 `interface{}` 类型断言带来的维护风险。
在实际开发中，API 响应的 JSON 格式常存在“弹性设计”：同一字段名（如 /user 接口）可能返回单个用户对象 {"email":"..."}，也可能返回用户列表 [{"email":"..."},{"email":"..."}]。若强行使用 interface{} + 类型断言处理，不仅代码冗长、易出错，还丧失编译期类型安全和 IDE 支持。
推荐做法是优先尝试结构化解码：先按单对象结构体解码；失败后，再尝试按切片结构体解码。这种方式简洁、健壮，且完全类型安全。
以下是一个完整、可直接运行的示例：
package main
import (
"encoding/json"
"fmt"
)
// 定义明确的数据结构，提升可读性与安全性
type User struct {
Email string `json:"email"` // 注意：原始问题中 json tag 写成了 `json:email`（缺引号），正确写法为 `json:"email"`
}
func extractEmails(data []byte) ([]string, error) {
var single User
var users []User
// 尝试解码为单个对象
if err := json.Unmarshal(data, &single); err == nil {
return []string{single.Email}, nil
}
// 失败则尝试解码为对象数组
if err := json.Unmarshal(data, &users); err == nil {
emails := make([]string, len(users))
for i, u := range users {
emails[i] = u.Email
}
return emails, nil
}
return nil, fmt.Errorf("failed to unmarshal JSON as either single object or array")
}
func main() {
// 情况1：JSON 数组
b := []byte(`[{"email":"<a class="__cf_email__" data-cfemail="13766b727e637f764c7a7d4c726161726a53677660673d707c7e" href="/cdn-cgi/l/email-protection">[email​@example.com]</a>"}]`)
// 情况2：JSON 对象
c := []byte(`{"email":"<a class="__cf_email__" data-cfemail="c7a2bfa6aab7aba287b3a2b4b3e9a4a8aa" href="/cdn-cgi/l/email-protection">[email​@test.org]</a>"}`)
if emails, err := extractEmails(b); err == nil {
fmt.Println("Array input → emails:", emails)
}
if emails, err := extractEmails(c); err == nil {
fmt.Println("Object input → emails:", emails)
}
}✅ 关键优势说明：
- 零反射、零 interface{} 断言：全程使用具名结构体，编译器可校验字段、IDE 可自动补全；
- 错误可追溯：两次 Unmarshal 分开处理，便于定位是格式错误还是逻辑误判；
- 扩展性强：如需支持嵌套、额外字段或验证逻辑，只需增强 User 结构体即可；
- 内存友好：无需先解码到 interface{} 再二次转换，减少中间分配。
⚠️ 注意事项：
- JSON tag 必须使用双引号：json:"email" 而非 json:email，否则字段将无法被识别；
- 若业务允许，更优方案是推动 API 统一响应格式（例如始终返回 { "data": [...] } 或 {"data": {...}}），从根本上消除歧义；
- 对于超大规模数据，可考虑流式解析（json.Decoder）以降低内存占用，但本场景下 Unmarshal 已足够高效。
通过这种“先单后多”的策略，你既能保持代码的专业性与可维护性，又能优雅应对现实世界中常见的 JSON 格式波动。
