Go map 怎么导出确定性 JSON 结果用于签名测试

给 Go 的 map 做签名测试时，不要自己遍历键再拼 JSON。直接把参与签名的值交给 encoding/json.Marshal，它会对可编码 map 的键排序，返回稳定的 JSON 字节；测试应比较这组字节或它的摘要。这样可以避免 Go map 本身无序带来的快照抖动。

在同一个 Go encoding/json 编码路径中，json.Marshal 适合做确定性输出测试；但“键排序稳定”不代表它自动兼容所有语言的签名规范，跨语言场景仍要先约定数字格式、Unicode 转义和字段规则。

先确认签名输入是 JSON 字节

签名函数看到的是字节序列，map[string]string 只是上游的数据结构。若先通过 for key, value := range data 拼接文本，遍历顺序就会成为隐含变量；即使业务上每次得到的是同一组键值，也可能出现不同的签名输入。

更稳妥的边界是：准备好请求对象或 map，调用一次 json.Marshal，后续摘要、签名、测试快照都只使用返回的 []byte。不要在生成字节后再把 JSON 解析回 map，也不要为了“看起来排序”而混用另一套序列化器。

用 encoding/json 生成稳定输出

下面的例子把 map 编码和摘要放在同一条明确路径中。代码没有依赖 map 的迭代顺序，也没有把摘要当成 JSON 内容本身。

package signinput

import (
	"crypto/sha256"
	"encoding/hex"
	"encoding/json"
)

// StableJSON 返回用于测试或签名的 JSON 字节。
func StableJSON(fields map[string]string) ([]byte, error) {
	// Marshal 会按 JSON 对象键规则处理 map 键，不能改成手动 range 拼接。
	return json.Marshal(fields)
}

// DigestForTest 只对最终 JSON 字节计算摘要，便于锁定签名输入。
func DigestForTest(fields map[string]string) (string, error) {
	payload, err := StableJSON(fields)
	if err != nil {
		// 编码失败必须向上返回，不能用半截数据继续签名。
		return "", err
	}
	digest := sha256.Sum256(payload)
	return hex.EncodeToString(digest[:]), nil
}

这里的“确定性”有一个精确范围：对于同一份值、同一套 encoding/json 行为和相同的输入类型，map 键顺序不会因为 map 遍历而变化。它解决的是测试快照和 Go 内部签名输入的不稳定，不负责替你定义业务签名协议。

把稳定输出写进测试

测试时建议同时保留一份可读的 JSON 期望值和一个字节级断言。前者便于审查变更，后者才能发现空格、转义或字段值的细微变化。摘要适合用于签名回归，但失败时仍应打印安全的 JSON 字节或十六进制摘要，方便定位。

package signinput_test

import (
	"bytes"
	"encoding/json"
	"testing"
)

func TestStableJSON(t *testing.T) {
	fields := map[string]string{
		"amount": "18.50",
		"order":  "A-1007",
		"tenant": "demo",
	}
	want := []byte(`{"amount":"18.50","order":"A-1007","tenant":"demo"}`)

	got, err := json.Marshal(fields)
	if err != nil {
		// 测试必须把编码错误当成失败，而不是比较空字节。
		t.Fatalf("marshal sign input: %v", err)
	}
	if !bytes.Equal(got, want) {
		// 直接比较字节，可发现转义、空白和键顺序变化。
		t.Fatalf("json bytes = %s, want %s", got, want)
	}
}

金额在示例中故意使用字符串，因为签名协议若要求“18.50”必须保留两位小数，就不应先把它放进 float64 再期待序列化器替你保留业务格式。测试样例中的字段顺序可以任意书写，期望字节则按编码后的 JSON 键顺序固定。

跨语言签名时别把确定性想成规范

Go 服务和 Java、Python 或前端共同签名时，仅凭“大家都输出 JSON”不够。各语言可能在数字、Unicode、斜杠、空白、空值和字段省略上使用不同表示。即便对象语义相同，签名所需的原始字节也可能不同。

还要注意自定义 MarshalJSON、encoding.TextMarshaler、时间格式和结构体标签。它们都可能改变最终字节。协议升级时，最好把示例输入、规范化后的完整 JSON 和摘要样例一起放进跨语言测试夹具，而不是只约定“字段名大致一样”。

常见问题

Go map 直接 json.Marshal 后一定每次完全一样吗？

在同一 Go 编码规则和同一输入值下，map 键排序是稳定的；但自定义编码、时间值、浮点表示或输入本身变化，仍会改变最终字节。

为什么不能自己对 map 的 key 排序后拼字符串？

还要正确处理 JSON 转义、数字、嵌套值和错误传播。自己拼接很容易只解决键顺序，却制造新的编码差异。

测试应该比较 JSON 内容还是原始字节？

验证业务语义时可以比较解码后的结构；验证签名或快照时必须比较原始字节，因为签名不认识“语义相同”。