Go 的 json.Decoder 本身完全支持 UTF-8，但错误常源于对 Go 字符串底层字节表示与 Unicode 码点（rune）的混淆——尤其在遍历字符串时使用 len(s) 和 s[i] 会按字节而非字符操作，导致多字节 UTF-8 字符被拆解为乱码。
go 的 `json.decoder` 本身完全支持 utf-8，但错误常源于对 go 字符串底层字节表示与 unicode 码点（rune）的混淆——尤其在遍历字符串时使用 `len(s)` 和 `s[i]` 会按字节而非字符操作，导致多字节 utf-8 字符被拆解为乱码。
在你提供的示例中，request.Arg 实际上是完全正确的 UTF-8 字符串（"zářit"），问题并非出在 JSON 解码环节，而在于后续对字符串的错误遍历方式：
for i := 0; i < len(request.Arg); i++ {
char := request.Arg[i]
fmt.Print(string(char)) // ❌ 错误：将单个字节强制转为 string，破坏 UTF-8 编码
}这段代码将 "zářit"（UTF-8 编码为 z + á（0xC3 0xA1）+ ř（0xC5 0x99）+ i + t，共 6 字节）按字节索引访问：
-
request.Arg[0] = 'z'→"z"✔️ -
request.Arg[1] = 0xC3→"\xC3"→ 显示为Ã（UTF-8 下半截乱码） -
request.Arg[2] = 0xA1→"\xA1"→ 显示为¡或其他符号
这就是你看到 záÅit 的根本原因：不是解码失败，而是字节级遍历破坏了 UTF-8 序列完整性。
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
✅ 正确做法是使用 range 遍历字符串，它自动按 Unicode 码点（rune）迭代：
// ✅ 正确：按 rune 遍历，安全处理 UTF-8
for _, r := range request.Arg {
fmt.Printf("%c (U+%04X) ", r, r)
}
// 输出：z (U+007A) á (U+00E1) ř (U+0159) i (U+0069) t (U+0074)此外，在网络通信场景（如你的 socket 服务端），还需注意以下关键点：
-
避免未清理的缓冲区残留
原始代码中buf := make([]byte, bufferSize)读取后未截断有效字节，可能导致string(buf[:])包含尾部零值字节或前次残留数据：n, err := conn.Read(buf) if err != nil { /* handle */ } s := string(buf[:n]) // ✅ 仅取实际读到的 n 字节 -
JSON 解码无需手动转 string → Reader
更高效且安全的方式是直接从io.Reader解码（如bytes.NewReader(buf[:n])或conn本身），避免中间字符串拷贝和潜在编码歧义：d := json.NewDecoder(bytes.NewReader(buf[:n])) d.Decode(&request)
-
验证输入合法性（可选增强）
若需严格确保输入为合法 UTF-8，可在解码前检查：import "unicode/utf8" if !utf8.Valid(buf[:n]) { return errors.New("invalid UTF-8 input") }
总结：Go 的 encoding/json 对 UTF-8 支持完善，所谓“解码失败”几乎总是由字节 vs 字符混淆、缓冲区处理不当或调试方式误导引起。牢记 ——
? len(string) 返回字节数，非字符数；
? string[i] 返回字节，非字符；
? range string 迭代的是 rune（Unicode 码点）；
? 网络读取务必用 n 截断有效数据。
遵循这四点，你的 Go 服务就能稳健处理包括 zářit、こんにちは、你好 在内的任意合法 UTF-8 字符串。
