Go GJSON Exists 和空字符串判断有什么区别

在 Go 项目里用 GJSON 读取接口字段时，最容易误判的是把“字段不存在”和“字段值为空”写成同一个条件。gjson.Get(json, path).String() == "" 只能说明最终拿到的字符串表示为空，不能告诉你字段是缺失、JSON null，还是确实存在一个空字符串。

官方地址：https://github.com/tidwall/gjson

需要判断字段有没有出现在 JSON 中，用 Exists()；需要判断它是不是字符串、内容是否为空，再结合 Type 和 String()。不要只用空字符串结果反推字段存在性。

先把缺失、null 和空串分成四种状态

假设输入字段路径是 profile.nickname，下面四份 JSON 看起来都可能“没有可用文字”，但安全含义不同：

这里的关键是：空字符串在 JSON 中是一个真实的字符串值，所以 Exists() 会返回 true。而字段缺失和明确的 null 都属于空的 Result 语义，不能用 String() 的返回值继续区分。

Exists 判断的是存在性，不是内容是否非空

GJSON 官方 API 把 Exists() 定义为结果是否存在。它适合回答“请求里有没有这个字段”这一类问题，不适合直接回答“昵称有没有文字”。最小读取方式如下：

package main

import (
    "fmt"

    "github.com/tidwall/gjson"
)

func main() {
    jsonText := `{"profile":{"nickname":""}}`
    result := gjson.Get(jsonText, "profile.nickname")

    // Exists 判断字段是否在 JSON 中以可识别的值出现。
    fmt.Println(result.Exists()) // true
    // String 只返回字符串表示，空串不能反推出字段是否缺失。
    fmt.Printf("type=%s value=%q\n", result.Type, result.String())
}

上例中的空昵称必须和缺失昵称分开处理时，先看 Exists()，再看 Type 或字符串内容。比如“字段必填”通常拒绝缺失、null 和空串；“字段可选但传空表示清除旧值”则应该接受存在的空串。

为什么只写 String() == "" 会丢失信息

Result.String() 是一个便捷的转换方法。它会把字符串值返回出来，但对于不存在结果或 null，也可能得到空字符串。下面的判断无法回答调用方真正关心的状态：

func readNickname(jsonText string) (string, bool) {
    value := gjson.Get(jsonText, "profile.nickname")

    // 这个条件会把缺失、null 和真实空串都合并为同一条路径。
    if value.String() == "" {
        return "", false
    }
    // 非空字符串之外的类型也不应默认为合法昵称。
    return value.String(), true
}

如果业务只需要“有没有可展示文字”，这个函数可以接受；但如果业务要做补丁更新、权限判断或审计，它就不够精确。因为调用方无法知道用户是没传字段、主动传了 null，还是主动把值改成空串。

用 Type 把校验策略写清楚

把存在性、类型和内容分成三层，代码更容易复查。下面的例子只接受字符串，并把空串单独标记为“已传但为空”：

import "github.com/tidwall/gjson"

type FieldState int

const (
    FieldMissingOrNull FieldState = iota
    FieldEmpty
    FieldValue
    FieldWrongType
)

func nicknameState(jsonText string) (FieldState, string) {
    value := gjson.Get(jsonText, "profile.nickname")

    // GJSON 的 Result 无法仅靠本次结果区分字段缺失与明确 null。
    if !value.Exists() {
        return FieldMissingOrNull, ""
    }
    // Exists 为 true 仍不代表类型就是字符串。
    if value.Type != gjson.String {
        return FieldWrongType, ""
    }
    if value.String() == "" {
        return FieldEmpty, ""
    }
    return FieldValue, value.String()
}

在 GJSON 当前结果模型里，字段缺失和 JSON null 都会落到 Null 这一类，所以不要为了区分它们而依赖一个空的 String()。如果接口协议必须区分“未发送”和“明确发送 null”，应在进入 GJSON 前保留原始 JSON 结构，或改用能表达该协议差异的解码模型。

按风险选择判断方式

把判断方式和数据风险对应起来，代码审查时会更直观：

如果字段来自不可信请求，建议把拒绝原因写成可审计的分类，例如 missing、null、wrong_type 和 empty，而不是统一记录“nickname invalid”。这样既便于定位调用方问题，也不会把敏感原文直接写进日志。

一份紧凑的排查清单

1. 先确认需求问的是“字段存在”还是“字段内容非空”。
2. 需要存在性时调用 Exists()，不要用 String() == "" 代替。
3. 需要字符串时同时判断 Type == gjson.String。
4. 把空字符串是否有业务含义写进接口约定，尤其是补丁更新场景。
5. 对缺失、null、错误类型和空串分别记录内部原因码，避免审计信息被合并。

常见问题

Exists 为 true 能说明 String 一定非空吗？

不能。JSON 中明确存在的空字符串会让 Exists() 为 true，但 String() 仍然是空字符串。

为什么 null 和缺失都像空结果？

GJSON 的 Result 用 Null 表示 JSON null 和不存在的默认结果。需要更细的协议语义时，应在更早的解析层保留“键是否出现”的信息。

只关心显示文本时可以直接比较空串吗？

可以，但要确认你确实不关心缺失、null 和空串的差异。只要这三种状态会触发不同业务动作，就必须保留 Exists() 和 Type 信息。