json.Marshal 默认输出带换行缩进的 JSON，不符合单行日志标准，因日志系统按行切分会导致误判为多条记录；必须用 json.Compact 清洗并确保严格单行、无多余空白。
为什么 json.Marshal 直接输出的 JSON 不符合单行日志标准
直接用 json.Marshal 序列化结构体，会生成带换行和缩进的格式化 JSON，比如：
{"level":"info","ts":1718234567.89,"msg":"user login","user_id":1001}——这在控制台或文件中是合法 JSON，但日志采集系统（如 Filebeat、Fluentd）默认按行切分，遇到换行就误判为多条日志。关键不是“能不能解析”，而是“会不会被日志管道当多条记录切开”。
解决思路很明确：必须确保整个日志对象序列化后 **严格单行、无换行符、无多余空格**，且保留语义完整性。
-
json.Marshal默认不压缩，json.Compact可去除空格换行，但需额外 bytes.Buffer 或 []byte 中转 - 不要用
fmt.Sprintf("%+v")—— 它输出 Go 语法格式，字段名不带引号、布尔值是true而非"true"，下游 JSON 解析器会直接报错 - 如果结构体含 time.Time、自定义类型或 nil 指针，
json.Marshal默认行为可能不符合预期（比如 time 输出为 RFC3339 字符串，但有时需要 Unix 时间戳）
用 json.Compact + bytes.Buffer 做安全单行序列化
这是最轻量、兼容性最好、无需引入第三方库的做法。核心是绕过 json.Marshal 的默认格式化，用 json.Compact 清洗原始字节。
func MarshalLogLine(v interface{}) ([]byte, error) {
buf := &bytes.Buffer{}
enc := json.NewEncoder(buf)
enc.SetEscapeHTML(false) // 防止 < 被转成 \u003c，影响可读性
if err := enc.Encode(v); err != nil {
return nil, err
}
// Encode 写入了换行，需去掉末尾 \n，并 compact 剩余内容
b := bytes.TrimSuffix(buf.Bytes(), []byte{'\n'})
var compactBuf bytes.Buffer
if err := json.Compact(&compactBuf, b); err != nil {
return nil, err
}
return compactBuf.Bytes(), nil
}
-
enc.SetEscapeHTML(false)必须设，否则 HTML 敏感字符（如<、>）会被转义，日志里看到的是\u003c而不是原始符号 -
bytes.TrimSuffix(..., []byte{'\n'})是关键：因为json.Encoder.Encode()总会在结尾加一个换行，不删掉会导致最终结果末尾有 \n，违反单行要求 - 别试图用
strings.ReplaceAll(string(b), "\n", "")——json.Compact已处理内部换行，只需清理 Encoder 自带的尾部换行
字段顺序不稳定？用 map[string]interface{} 替代 struct 时要注意
Go 的 map 遍历顺序是随机的，json.Marshal 对 map 的序列化结果每次运行都可能不同。这对日志可读性、diff 对比、甚至某些基于字段顺序做解析的旧系统是隐患。
立即学习“go语言免费学习笔记（深入）”；
- 如果日志结构固定，优先用 struct 并按字母序声明字段（Go 1.19+ 的
json包对 struct 字段序列化顺序是稳定的） - 若必须用 map（比如动态字段），改用
orderedmap类型或预排序 key 列表手动构造map[string]interface{} - 不要依赖
json.Marshal对 map 的输出顺序做任何假设——它不是 bug，是语言规范
性能敏感场景下，避免重复分配内存
高频日志（如每秒万级）调用 MarshalLogLine 会频繁触发 GC。可复用 bytes.Buffer 和 json.Encoder 实例，但要注意并发安全。
-
bytes.Buffer不是 goroutine-safe，不能全局复用；可在函数内用sync.Pool管理 -
json.Encoder也不是线程安全的，不能跨 goroutine 复用；每次 new 代价不大，不必强求复用 - 真正瓶颈通常不在 JSON 序列化本身，而在日志写入 I/O；如果发现 CPU 占用高，先 profile 确认是不是这里，而不是盲目优化
单行日志的本质约束是「一行一事件」，所有技术选择都得服从这个前提。最容易被忽略的不是怎么序列化，而是忘记检查最终字节流里是否混入了不可见的 \r、\n、\u2028 或零宽空格——它们一样会让日志系统切错行。
