在 Go 中，并非所有变量都可安全地跨 goroutine 复用；json.Decoder 实例不具备并发安全性，且因依赖不同请求体（io.Reader）而无法全局复用，正确做法是每次请求创建新实例。
在 go 中，并非所有变量都可安全地跨 goroutine 复用；`json.decoder` 实例不具备并发安全性，且因依赖不同请求体（`io.reader`）而无法全局复用，正确做法是每次请求创建新实例。
Go 的并发模型强调“共享内存通过通信来实现”，而非通过锁保护共享状态——因此，是否可并发使用一个类型，首要依据是其官方文档是否明确声明为 goroutine-safe。json.Decoder 正是一个典型反例：它内部维护解析状态（如缓冲区位置、嵌套层级、临时字段缓存等），且构造时绑定特定 io.Reader（如 http.Request.Body）。每个 HTTP POST 请求的 Body 都是独立的 io.ReadCloser 实例，若强行复用同一个 *json.Decoder，将导致：
- 状态混乱（例如前一个请求未读完，后一个请求覆盖解码器内部偏移）；
- Body 被重复读取或提前关闭，引发 io.ErrUnexpectedEOF 或 http: body closed by handler 错误；
- 数据竞争（data race），在 -race 检测下必然报错。
✅ 正确写法：每次请求新建解码器
func handlePost(w http.ResponseWriter, r *http.Request) {
if r.Method != "POST" {
http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
return
}
// 每次请求创建独立的 *json.Decoder
decoder := json.NewDecoder(r.Body)
defer r.Body.Close() // 注意：务必关闭 Body！
var payload map[string]interface{}
if err := decoder.Decode(&payload); err != nil {
http.Error(w, "Invalid JSON: "+err.Error(), http.StatusBadRequest)
return
}
// 处理 payload...
}⚠️ 注意事项：
- *切勿将 `json.Decoder` 声明为包级变量或在 handler 外部初始化后传入**——它不是线程安全的，也不是设计用于复用的。
- json.Encoder 同样不支持并发写入同一 io.Writer，若需并发编码，也应按需创建。
- 若追求极致性能（高频小载荷 JSON 解析），可考虑替代方案：
? 对比参考：真正可安全复用的并发类型
| 类型 | 是否 goroutine-safe | 原因与建议 |
|------|-------------------|------------|
| *http.Client | ✅ 是 | 内部 Transport 已同步封装，推荐全局单例复用 |
| *http.Transport | ✅ 是 | 连接池、TLS 缓存等均线程安全，应复用以提升性能 |
| map[K]V | ❌ 否（默认） | 并发读写 panic，需配合 sync.RWMutex 或 sync.Map（仅适用于低频写场景） |
| bytes.Buffer | ❌ 否 | 状态可变，不可跨 goroutine 复用 |
总结：Go 的哲学是「简单优于通用」——json.Decoder 的不可复用性恰恰降低了隐式状态风险。与其冒险共享，不如信任 Go 的内存分配效率（现代 runtime 对短生命周期对象优化极佳）。用 go tool pprof 实际验证后会发现：新建 Decoder 的开销远低于因数据竞争或逻辑错误导致的故障成本。
