多数简单场景应直接用[]byte而非bytes.Buffer，因其支持高效拼接、截取、比较；仅在频繁追加、需读写游标或对接io接口时才用Buffer，误用会增加开销。
为什么直接用 []byte 而不用 bytes.Buffer？
多数简单场景下，[]byte 自身已支持高效拼接、截取、比较等操作，无需额外封装。只有在频繁追加（尤其是不确定长度）、需要读写游标或配合 io 接口时，才该用 bytes.Buffer。误用 Buffer 反而引入不必要的内存分配和方法调用开销。
-
append([]byte{}, data...)比buf.Write(data)更轻量，尤其在已知容量时可预分配：make([]byte, 0, 1024) -
bytes.Equal(a, b)是安全的字节切片比较，避免手动循环或==（Go 中切片不能直接比较） - 截取子串直接用
s[lo:hi]，但注意越界 panic —— 可先用len(s)校验，或用bytes.TrimPrefix(s, prefix)这类安全函数
bytes.ReplaceAll 和 strings.ReplaceAll 的关键区别
二者行为一致，但参数类型不同：bytes.ReplaceAll 接收 []byte，不涉及 UTF-8 解码；strings.ReplaceAll 处理 string，内部按 rune 切分。若操作二进制数据（如协议头、加密密文），必须用 bytes 版本，否则可能破坏字节序列。
- 替换非 UTF-8 安全内容（如 HTTP raw body）：用
bytes.ReplaceAll(data, []byte("old"), []byte("new")) - 替换含多字节字符的文本（如中文）且需按字符语义：用
strings.ReplaceAll，但需确保输入是合法 UTF-8 -
bytes.ReplaceAll返回新切片，原数据不变；若原地修改，需用bytes.Replace配合cap/len控制底层数组复用
如何安全地从 bytes.Buffer 获取可复用的 []byte？
bytes.Buffer.Bytes() 返回的是底层切片的引用，后续对 Buffer 的写入可能覆盖该数据。若需长期持有或并发读取，必须拷贝：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
buf := bytes.NewBufferString("hello")
data := append([]byte(nil), buf.Bytes()...)
- 不要写
data := buf.Bytes()后继续buf.WriteString("world")——data可能被意外修改 - 如果确定
Buffer不再写入，且只读一次，可用buf.Bytes()省拷贝；但代码维护者很难保证这点，显式append更可靠 -
buf.String()同样返回引用，也有同样风险；字符串不可变，所以它更安全，但转换有 UTF-8 验证开销
用 bytes.Split 解析二进制协议时的常见陷阱
bytes.Split 按字节分割，不识别边界语义。例如用 bytes.Split(data, []byte("\n")) 解析自定义帧，若数据中存在未转义的换行符，就会错误切分。
立即学习“go语言免费学习笔记（深入）”；
- 协议设计阶段就应约定帧头/帧尾（如
0xFF 0xFE），用bytes.Index或bytes.Contains手动查找，而非依赖分隔符 - 若必须用分隔符，确保发送端已做转义（如将
\n替换为\n\n），接收端再用bytes.ReplaceAll还原 -
bytes.Split对空分隔符（[]byte{}）会 panic，生产代码中务必校验分隔符非空
