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