Go 1.27.1 的 encoding/json 和 net/http 修复如何纳入回归测试

Go 1.27.1 的回归测试不要停留在“命令能通过”。更有价值的是锁定两条外部可观察的契约：截断 JSON 流到达 json.Decoder.Token 时，底层的 io.ErrUnexpectedEOF 不能被悄悄变成普通 EOF；HTTP 服务端的 Handler 只读完请求体一部分就关闭 Request.Body 时，正常的提前结束不应被误报成 io.EOF。Go 官方发布记录将 encoding/json、net/http 都列入 Go 1.27.1 的修复范围，正适合把这两种边界写进项目回归集。

先把版本变更拆成两个可观察契约

我在整理点版本升级清单时，先把“修复了标准库”翻译成输入、动作和结果三列。这样测试关注的是应用依赖的行为，而不是某个内部函数名。第一条来自 JSON 解码器面对底层 Reader 提前结束的场景；第二条来自 HTTP 服务端为了复用连接而处理未读请求体的场景。

encoding/json：让截断流错误穿过 Token 循环

不要直接对完整字符串调用 json.Unmarshal，那只能覆盖语法失败，覆盖不到流式 Reader 返回什么错误。下面的 Reader 第一次交出一个未闭合对象，下一次明确返回 io.ErrUnexpectedEOF；测试持续取 Token，直到拿到最终错误。

package jsonregression

import (
	"encoding/json"
	"errors"
	"io"
	"testing"
)

type shortReader struct{ sent bool }

func (r *shortReader) Read(p []byte) (int, error) {
	// 先交出不完整 JSON，再模拟传输层提前结束。
	if r.sent {
		return 0, io.ErrUnexpectedEOF
	}
	r.sent = true
	data := []byte(`{"name":`)
	return copy(p, data), nil
}

func TestTokenKeepsUnexpectedEOF(t *testing.T) {
	dec := json.NewDecoder(&shortReader{})
	for {
		_, err := dec.Token()
		if err == nil {
			continue
		}
		// 用 errors.Is 断言错误语义，避免绑定具体文本。
		if !errors.Is(err, io.ErrUnexpectedEOF) {
			t.Fatalf("Token error = %v, want io.ErrUnexpectedEOF", err)
		}
		return
	}
}

这条测试的重点不是“能否解析成功”，而是错误类型是否仍能帮助上层区分“对端正常结束”与“网络或文件内容被截断”。如果业务把两者都当成重试信号，异常流可能被误判为合法结束。

net/http：验证未读完 Body 的 Close 语义

HTTP Handler 常常知道自己的消息边界，读完字段后就停止，不一定主动读到 io.EOF。回归测试要真正经过服务端请求体路径，而不是拿一个普通 strings.Reader 做假替身。

package httpregression

import (
	"io"
	"net/http"
	"net/http/httptest"
	"strings"
	"testing"
)

func TestRequestBodyCloseAfterPartialRead(t *testing.T) {
	closeErr := make(chan error, 1)
	server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		// 只消费已知字段，故意留下请求体尾部交给 net/http 清理。
		_, _ = io.ReadFull(r.Body, make([]byte, 2))
		closeErr 

这里用通道把 Handler 的结果带回测试 goroutine，避免只看到客户端请求成功就误以为服务端语义正确。若项目自己封装了请求体解码器，也应保留一个类似的“读部分字段后关闭”样例。

用版本矩阵判断升级、回退和兼容范围

把两条测试放进同一个包后，至少在生产使用的 Go 版本和 Go 1.27.1 上运行。JSON 相关问题若需要区分新实现路径，可临时加入第三次运行；这只是诊断手段，不是长期配置建议。

# 先记录实际工具链，避免 CI 使用了错误版本。
go version

# 运行项目的全部回归测试。
go test ./...

# 在 Go 1.27.1 上复跑，自动工具链下载需由环境策略允许。
GOTOOLCHAIN=go1.27.1 go test ./...

# 只用于定位 JSON 新实现是否影响结果，确认后应回到默认路径。
GOTOOLCHAIN=go1.27.1 GOEXPERIMENT=nojsonv2 go test ./...

判定时看“行为是否满足契约”，不要只看某个组合是否绿灯：encoding/json 的测试应确认截断错误没有消失，net/http 的测试应确认清理动作不产生误报。若旧版本失败而 1.27.1 通过，说明回归样例覆盖到了点版本修复；若默认实现失败但 nojsonv2 通过，应先锁定依赖与输入，再决定是否暂时回退。

常见问题

为什么不直接比较 err.Error()？

错误文本可能因为包装层或实现调整而变化。这里真正的契约是能否用 errors.Is 识别 io.ErrUnexpectedEOF。

Body 没有读到 EOF 就 Close，一定是错误吗？

不一定。Handler 已经知道消息长度并主动结束读取时，关闭未读尾部是合法清理路径，测试应锁定 Close 的结果而非强迫业务读空。

升级后还需要保留 nojsonv2 测试吗？

可以保留为诊断或兼容矩阵，但不要把它当成长期替代方案。优先升级到包含修复的工具链，并让行为测试持续守住边界。

最终回归清单很短：一条测试守住 JSON 截断错误，一条测试守住 HTTP 请求体关闭语义，再用版本矩阵确认升级结果。这样标准库点版本的修复就会沉淀为项目自己的防回归资产。