Go 服务端使用 json.NewEncoder(w).Encode(err) 时，若 err 为 nil，会向响应体写入 null，导致客户端读取到类似 {"foo":"bar"}null 的非法 JSON。根本原因是错误地将 nil 错误值序列化进响应流，而非仅返回业务数据。
go 服务端使用 `json.newencoder(w).encode(err)` 时，若 `err` 为 `nil`，会向响应体写入 `null`，导致客户端读取到类似 `{"foo":"bar"}null` 的非法 json。根本原因是错误地将 `nil` 错误值序列化进响应流，而非仅返回业务数据。
在你的 FooWriter 服务端代码中，问题出在这一行：
if err := json.NewEncoder(w).Encode(err); err != nil {
// ...
}
这段逻辑存在两个严重问题：
- err 是 nil 时仍被编码：json.NewEncoder(w).Encode(nil) 会直接向 http.ResponseWriter 写入字符串 "null"；
- 响应体被重复写入：你先调用 w.Write([]byte(successJSON)) 输出 {"foo":"bar"}，再调用 json.NewEncoder(w).Encode(err) 追加 null，最终响应体变为 {"foo":"bar"}null —— 这已不是合法 JSON，客户端解析必然失败。
✅ 正确做法是：只编码一次、且仅编码业务响应数据。错误信息不应作为独立 JSON 片段写入响应体；如需返回结构化结果（含成功/失败状态），应统一设计响应结构体。
✅ 推荐修复方案
1. 服务端（FooWriter）：使用结构化响应，避免手动拼接 JSON 字符串
type Response struct {
Foo string `json:"foo"`
Code int `json:"code,omitempty"` // 可选字段，用于错误码
Error string `json:"error,omitempty"`
}
// 正常响应
w.Header().Set("Content-Type", "application/json; charset=UTF-8")
w.WriteHeader(http.StatusOK)
if err := json.NewEncoder(w).Encode(Response{Foo: "bar"}); err != nil {
http.Error(w, "JSON encode error", http.StatusInternalServerError)
return
}
2. 客户端（FooReader）：安全读取并解析 JSON（注意：ioutil 已弃用，推荐 io.ReadAll）
resp, err := client.Do(req)
if err != nil {
log.Fatal("HTTP request failed:", err)
}
defer resp.Body.Close()
if resp.StatusCode != http.StatusOK {
log.Fatalf("Unexpected status: %d", resp.StatusCode)
}
body, err := io.ReadAll(io.LimitReader(resp.Body, 1048576))
if err != nil {
log.Fatal("Failed to read response body:", err)
}
var result struct {
Foo string `json:"foo"`
}
if err := json.Unmarshal(body, &result); err != nil {
log.Fatal("Invalid JSON response:", string(body), err)
}
fmt.Printf("Received: %+v\n", result) // 输出: {Foo:"bar"}
⚠️ 其他注意事项
- ❌ 不要混用 w.Write() 和 json.Encoder：二者都向同一 ResponseWriter 写入，极易造成响应体污染；
- ❌ 不要对 nil 错误调用 json.Encoder.Encode()：它会字面量输出 "null"；
- ✅ 统一错误处理方式：如需返回错误，应在结构体中定义 Error 字段，并保持 HTTP 状态码语义清晰（如 200 + {error:"..."} 表示业务失败；非 200 状态码表示传输或服务异常）；
- ✅ 客户端务必校验 resp.StatusCode：即使响应体含 null，状态码也可能仍是 200，不可仅依赖解析成功与否判断逻辑正确性。
通过以上修正，可彻底消除响应体末尾意外 null，确保 JSON 格式严格合规、客户端解析稳定可靠。
