Go SJSON 原地替换选项为什么不能任意扩展字节长度

Go SJSON 的 ReplaceInPlace 是尽量复用输入字节的提示，不是任意扩容的承诺。当前实现的快捷分支要求替换后的文档长度不大于原文档长度；超过这个长度时仍可完成替换，但会构造新的字节切片。判断原地复用和判断修改成功，是两件事。

官方地址：https://github.com/tidwall/sjson

先比较替换值的编码长度

假设日志加工器把已有字段 job.state 从 ASCII 字符串 queued 改为 done。旧值在 JSON 中包含引号，共8字节；新值含引号，共6字节。文档缩短2字节。反过来改为 completed，编码值共11字节，文档增长3字节。

这组数字只是对示例文本的字节计数，不是吞吐率或延迟测量。讨论长度时看的是 JSON 编码后的字节，而非读者眼中的字符个数。

为什么预留容量也不等于原地扩容

Options 文档规定，原地替换需要字节切片输入以及 Optimistic: true。字符串接口不能借这个选项修改不可变字符串；SetOptions会关闭原地替换。

当前官方实现的快捷分支按新文档长度与 len 比较，而不是与输入切片的 cap 比较。因此 make([]byte, len(src), len(src)+128) 不会让一个变长的值自动获得原地增长能力。容量是底层空间，长度是本次 JSON 文档范围，两者不可混为一谈。

把返回切片当成唯一的新文档

示例只使用现有简单字段和 ASCII 值，避免把转义、复杂路径等成本混在长度问题里。无论是否复用内存，都接收返回值；开启原地替换后，不把旧输入当成仍可用的原文档。

package main

import (
    "fmt"
    "log"

    "github.com/tidwall/sjson"
)

func main() {
    opts := &sjson.Options{Optimistic: true, ReplaceInPlace: true}
    for _, state := range []string{"done", "completed"} {
        // 每种情况使用独立输入，避免前一次修改影响后一次。
        doc := []byte(`{"job":{"state":"queued"},"attempt":2}`)
        oldLen := len(doc)
        next, err := sjson.SetBytesOptions(doc, "job.state", state, opts)
        if err != nil {
            log.Fatal(err)
        }
        // 返回切片可能复用输入，也可能新分配；后续只使用next。
        doc = next
        fmt.Printf("state=%s oldLen=%d newLen=%d json=%s\n",
            state, oldLen, len(doc), doc)
    }
}

这里打印文档长度，不能仅凭长度证明零分配。旧切片可能还保持旧的长度描述，而其底层字节已被改写。要保存原文，就在修改前独立复制；要让多个 goroutine 使用同一数据，就先确定每个调用持有独占可写切片，而不是同时改共享缓冲区。

用同一组输入比较分配成本

下面的基准把输入复制成本纳入两组测量，比较同一业务调用是否因选项减少额外成本。它不是单独的库内部零分配实验。代码尚未执行，不能据此声称具体提速比例。

package inplacecase

import (
    "testing"

    "github.com/tidwall/sjson"
)

var result []byte

func BenchmarkStateUpdate(b *testing.B) {
    src := []byte(`{"job":{"state":"queued"},"attempt":2}`)
    for _, state := range []string{"done", "completed"} {
        for _, enabled := range []bool{false, true} {
            mode := "ordinary"
            if enabled {
                mode = "inplace"
            }
            b.Run(state+"/"+mode, func(b *testing.B) {
                opts := &sjson.Options{
                    Optimistic: true, ReplaceInPlace: enabled,
                }
                b.ReportAllocs()
                for i := 0; i 

# 在保存基准文件的Go模块中运行，保留多次采样与分配指标。
go test -run '^$' -bench '^BenchmarkStateUpdate$' -benchmem -count=5

记录 Go 版本、SJSON 依赖版本、输入大小以及 ns/op、B/op、allocs/op。先比较 done 两组，再比较 completed 两组，不能把不同值的结果直接当成同一工作量的优化比例。仓库 README 的历史基准有明确旧环境说明，不应作为当前机器的性能承诺。

哪些情况不要依赖原地替换

设置ReplaceInPlace后没有报错，能说明复用了内存吗？

不能。成功只说明这次 API 调用没有返回错误。性能收益需通过相同输入的基准观察，业务正确性则始终以返回文档为准。

短字符串一定比长字符串更适合吗？

应比较编码后的值与原值，不比较字符数。转义等特殊内容不在这个 ASCII 最小案例范围内，采用前应针对自己的值建立测试用例。

可以反复拿第一次的输入切片继续修改吗？

不要。把每次成功返回的切片绑定为下一次输入，避免旧长度或旧底层引用与最新文档分离。

原地替换最重要的取舍不是把选项开满，而是确定输入的可写所有权、值的长度范围和返回切片的使用规则。只在相同业务输入的测量显示收益时，才值得为复用内存承担额外管理成本。