bytes.Equal 比较 nil 和空切片安全但返回 false，判断为空应优先用 len(b) == 0；bytes.ReplaceAll 按字节匹配，处理二进制数据易误替换；bytes.Buffer 累积写入更高效，需避免 buf.Bytes() 后继续写；bytes.HasPrefix 前必须检查长度防 panic。
bytes.Equal 怎么比才不会 panic
直接用 bytes.Equal 比较两个 []byte 是安全的，它内部已处理 nil；但很多人误传“必须非空”，其实是被 reflect.DeepEqual 或自写循环带偏了。真正要小心的是：拿 nil 切片和空切片 []byte{} 当作等价——它们底层指针不同，bytes.Equal 返回 false，但业务上常认为相等。
- 别在判断“是否为空”时用
bytes.Equal(b, []byte{})，改用len(b) == 0更快更准 - 如果逻辑真要区分
nil和空切片（比如序列化协议要求），那就必须显式检查：b == nil || len(b) == 0 -
bytes.Equal是逐字节比较，小数据没问题；超过几 MB 且允许近似匹配时，考虑先比长度再比哈希（如sha256.Sum256(b).Sum(nil)）
bytes.ReplaceAll 处理二进制数据会出什么问题
bytes.ReplaceAll 本身不关心内容，它只是找字节序列并替换——但问题出在「找」这个动作上：它按字节匹配，不是按 UTF-8 码点。如果你拿它处理含多字节字符的文本，可能切开一个汉字导致乱码；更危险的是，它完全可能误匹配二进制协议里的字段分隔符（比如把 PNG 文件头 0x89 0x50 0x4E 0x47 中的 0x4E 0x47 当成 “NG” 替换掉）。
- 只用于明确知道目标是纯 ASCII 字节模式的场景，比如 HTTP header 中替换
bytes.ReplaceAll(hdr, []byte("localhost"), []byte("127.0.0.1")) - 处理图像、音频、加密数据前，确认你真的需要修改原始字节流——多数时候该用封装好的解析器（如
png.Decode）而非裸字节替换 - 想“安全替换”，先用
bytes.Index定位，再手动拼接，避免越界或覆盖关键结构
为什么 bytes.Buffer 比 []byte append 更适合累积写入
频繁 append 到 []byte 会触发多次底层数组扩容，每次都要 memcpy；而 bytes.Buffer 内部自带增长策略（类似 slice 扩容但更保守），还预分配缓冲区，写入路径更短。
- 初始化时预估大小：
var buf bytes.Buffer; buf.Grow(4096)，能省掉前几次扩容 - 不要用
buf.Bytes()后继续写——返回的是内部切片引用，后续写入可能覆盖旧数据；需要拷贝就用buf.Bytes()[:buf.Len()]或buf.Next(buf.Len()) - 如果只是单次拼接（比如日志格式化），
fmt.Appendf或strings.Builder（转成 string 后再[]byte）反而更快，Buffer 的优势在多次小写入
bytes.HasPrefix 在协议解析里怎么用才不翻车
bytes.HasPrefix 看似简单，但在解析 TCP 流、文件 magic number 或自定义二进制协议头时，最容易忽略“读够长度”这个前提。比如检查 PNG 头，你得确保输入至少有 8 字节，否则直接 panic。
立即学习“go语言免费学习笔记（深入）”；
- 永远先检查长度：
len(data) >= len(pngHeader) && bytes.HasPrefix(data, pngHeader) - magic number 建议定义为常量：
var PNGHeader = []byte("\x89PNG\r\n\x1a\n")，别用字符串字面量，避免 UTF-8 编码干扰 - 如果协议头含可变字段（比如长度前缀），别只靠
HasPrefix，配合binary.Read解析更可靠
字节操作最麻烦的不是函数不会用，而是忘了数据从哪来、到哪去、中间有没有被截断或复用。特别是网络收包和 mmap 文件场景，[]byte 很可能指向共享内存，一不小心就改了别人的数据。
