必须用 bytes 而非 strings 的场景包括：处理非法 utf-8 或二进制数据（如图片头、协议帧）、避免解码 panic 或静默截断、确保字节级精确匹配（如 bytes.index/equal）、防止计时攻击（如 jwt 校验）、避免 string 转换导致的数据损坏及内存分配开销。
什么时候必须用 bytes 而不是 strings
当你操作的数据不保证是合法 UTF-8，或者明确是二进制内容（比如图片头、协议帧、加密密文、HTTP raw body），bytes 是唯一安全选择。strings 会把底层字节当 UTF-8 解码，遇到非法序列可能 panic 或静默截断。
-
strings.Index在含\xFF\xFE的字节切片上可能返回错误位置，bytes.Index按字节逐个比对，结果确定 - 读取网络 socket 的原始响应时，用
bytes.NewReader(buf)，别用strings.NewReader(string(buf))—— 后者强制转 string 可能损坏非 UTF-8 数据 - 处理 HTTP header 值（如
User-Agent: curl/7.68.0）看似安全，但若后端注入了未清理的二进制字段（如某些嵌入式设备返回的 firmware info），string(headerBytes)就会出问题
bytes.Equal 和 strings.EqualFold 根本不是一回事
bytes.Equal 是精确字节相等，区分大小写、不忽略 BOM、不处理 Unicode 归一化；strings.EqualFold 是语义相等，用于 case-insensitive 字符串比较，依赖 Unicode 规则。混用会导致逻辑漏洞。
- 校验 token（如 JWT signature）必须用
bytes.Equal，防止计时攻击 ——==或strings.EqualFold都不安全 - 判断文件扩展名是否为
.jpg：用strings.HasSuffix（输入已是 string）；但判断 raw HTTP body 是否以POST开头？得用bytes.HasPrefix(body, []byte("POST")) -
bytes.Equal对nilslice 和空 slice（[]byte{}）都返回true；而strings.EqualFold("", "")也 true，但传nil给strings函数会 panic
性能差异在哪儿？别猜，看分配和逃逸
关键不在函数快慢，而在是否触发内存分配。只要涉及 string ↔ []byte 转换，就一定有拷贝或堆分配 —— 这是 Go runtime 强制的，因为 string 是只读的，而 []byte 可变。
-
strings.Builder内部用[]byte累积，最后调String()才做一次转换；bytes.Buffer同理，但支持WriteByte、WriteRune等更底层操作 - 频繁拼接小字符串？用
strings.Builder；需要复用缓冲区或写入非 UTF-8 数据？选bytes.Buffer -
strings.ReplaceAll(s, "a", "b")返回新 string，原s不变；bytes.ReplaceAll(b, []byte("a"), []byte("b"))返回新 slice，但如果你用bytes.Replacer预编译规则，多次调用可避免重复解析
容易被忽略的边界：零值、nil 和长度陷阱
[]byte(nil) 和 []byte{} 行为不同，string(nil) 直接 panic，但 string([]byte(nil)) 却合法且等于 "" —— 这个隐式转换常被误用。
立即学习“go语言免费学习笔记（深入）”；
-
len([]byte(nil))是 0，但cap([]byte(nil))是 0；而len([]byte{})也是 0，但 cap 可能非零（取决于底层数组） - 用
bytes.TrimSpace处理nilslice？它返回nil，但strings.TrimSpace("")返回""—— 如果后续代码假设返回非 nil，就会 panic - 向
io.Write接口写nilslice 是允许的（写 0 字节），但写nilstring 不行 —— 所以网络库中常见conn.Write([]byte(data))而非conn.Write([]byte(string(data)))
