json遇到非法UTF8为什么不报错

在 Go 服务里看到 JSON 解码返回 nil，并不代表每个字符串字节都原样保留下来了。encoding/json v1 对带引号字符串中的非法 UTF-8 有一条很容易忽略的兼容语义：它会把异常字节替换成 Unicode replacement character，也就是 U+FFFD，然后继续完成解码。

官方文档：https://pkg.go.dev/encoding/json

所以，标题里的“为什么不报错”，答案不是 JSON 接受了任意乱码，而是标准库把这类编码问题定义成可修复的字符串内容，并没有把它提升为 error。如果业务要求字节完整，就必须在进入 JSON 解码前自己检查。

先把“没报错”拆成两个层次

我第一次遇到这个现象时，直觉是把所有异常都归到“JSON 解析失败”。但 encoding/json 实际上至少分开处理三类问题：

• JSON 结构损坏，例如括号、逗号或字符串边界不合法，通常会返回语法错误。
• JSON 值无法放进目标 Go 类型，例如数字超出范围或类型不匹配，可能返回类型错误。
• 带引号字符串中出现非法 UTF-8，v1 默认替换为 U+FFFD，不一定返回错误。

这解释了为什么只写 if err != nil 不够：错误分支只能告诉你标准库没有报告结构或类型问题，不能证明输入字符串没有发生内容变化。

encoding/json v1 到底改了什么

Go 字符串本质上保存字节，字符串本身可以暂时装下不符合 UTF-8 的序列。真正把它当作 Unicode 文本解释时，标准库才需要决定怎么处理。encoding/json v1 的选择是把每段非法序列替换成 U+FFFD，让输出继续成为合法 UTF-8 文本。

下面的代码只构造一个带异常字节的字符串，再分别查看 UTF-8 判定和 JSON 编码结果。注释中的“替换”是 API 语义说明，不是把某次本地运行结果当作证据。

package main

import (
    "encoding/json"
    "fmt"
    "unicode/utf8"
)

func main() {
    // 用原始字节构造示例，0xff 不是合法 UTF-8 起始字节。
    raw := string([]byte{'A', 0xff, 'B'})

    // 先单独判断字符串是否由合法 UTF-8 rune 组成。
    fmt.Println("valid:", utf8.ValidString(raw))

    // encoding/json v1 会把异常字节替换为 U+FFFD，而不是返回 InvalidUTF8Error。
    encoded, err := json.Marshal(raw)
    if err != nil {
        // 这里处理的是 Marshal 的其它失败原因，不把 nil 当成内容完整。
        panic(err)
    }
    fmt.Printf("json: %s\\n", encoded)
}

另一个容易混淆的点是旧资料里出现的 InvalidUTF8Error。官方文档说明它只是为兼容保留的类型，Go 1.2 起 Marshal 已改为替换非法字节，因此不能用“我没收到这个错误”来推断输入没有异常。

如果业务不能接受替换，怎么把检查前移

日志、签名、文件校验、用户昵称或需要保留原始字节的导入任务，往往不能接受静默替换。这时应该把原始请求体保留在检查边界，先用 utf8.Valid 判定，再决定拒绝还是显式清洗。

package main

import (
    "encoding/json"
    "fmt"
    "strings"
    "unicode/utf8"
)

type Request struct {
    Name string `json:"name"`
}

func decodeStrictOrRepair(data []byte, repair bool) (Request, error) {
    // 在 Unmarshal 前检查原始字节，避免替换发生后才发现线索已经丢失。
    if !utf8.Valid(data) {
        if !repair {
            // 严格模式保留拒绝语义，调用方可以记录长度和请求标识。
            return Request{}, fmt.Errorf("request body is not valid UTF-8")
        }
        // 清洗模式明确写出替换字符，避免把策略藏在 JSON 解码器内部。
        data = []byte(strings.ToValidUTF8(string(data), "�"))
    }

    var req Request
    // JSON 结构解析成功，只说明结果可映射到 Request。
    if err := json.Unmarshal(data, &req); err != nil {
        return Request{}, err
    }
    return req, nil
}

严格模式和清洗模式没有谁天然更正确。严格模式适合签名、审计和不可丢字节的数据；清洗模式适合展示型文本，但应把“发生过替换”记入日志或指标，并在必要时保留原始长度、请求编号和来源字段。

把“合法 JSON”和“可接受文本”分开记录

一个实用的排查顺序是：先保留原始 []byte，再记录 utf8.Valid 的判定，最后记录 JSON 的解析错误。这样日志里可以明确区分“协议结构坏了”“编码坏了但被替换了”和“业务字段类型不匹配”。

如果只在 json.Unmarshal 之后检查字符串，可能已经错过原始异常字节；如果只看返回错误，又会把静默替换误认为完整成功。检查前移不是为了让所有请求失败，而是让业务明确选择“拒绝”或“修复”。

常见问题

非法 UTF-8 会让 json.Valid 返回 false 吗？

不要把 json.Valid 当成业务文本完整性检查。它回答的是输入是否符合 JSON 编码规则；字符串中的非法 UTF-8 在 encoding/json v1 解码时有替换语义。若要单独判定字节编码，应检查原始数据的 UTF-8 有效性。

把 U+FFFD 再转回原始字节可以吗？

通常不可以。替换字符只表示“这里有一段无法按 UTF-8 解码的内容”，并不携带原始字节，所以需要恢复原文时必须在解码前保存原始输入，不能依赖解码后的字符串反推。

小结

encoding/json v1 不为 JSON 字符串中的非法 UTF-8 报错，是因为它选择用 U+FFFD 把字符串规范化为合法 UTF-8。真正关心数据完整性时，把 utf8.Valid 放在 JSON 解码前，并明确采用拒绝、清洗和审计哪一种策略，才能避免“接口成功但内容已经变化”的误判。