string(buf)只是将字节原样解释为UTF-8，不进行编码解码；真正解决乱码需先用golang.org/x/text/encoding/gbk等解码器将GBK等编码转为UTF-8字节，再string()转换。
string() 不是转换，是强制解释；真正做网络原始字节流到结构化字符串的高性能转换，必须分清「编码解码」和「类型转换」两件事——前者用 golang.org/x/text/encoding/gbk，后者才用 string()。
为什么直接 string(buf) 在网络收包里总显示乱码或方块
因为网络层收到的 []byte 很可能不是 UTF-8 编码（比如 HTTP 响应头声明 Content-Type: text/html; charset=gbk，或 Modbus/串口协议自带 GBK 字段），而 string(buf) 只是把字节原样当 UTF-8 解释，不校验、不解码。结果就是：0xC4 0xE3 被当成非法 UTF-8，显示为 或空格。
- 常见错误现象：
fmt.Println(string(resp.Body.Bytes()))打印中文全是问号，但用 Python 的resp.content.decode('gbk')却正常 - 根本原因：Go 的
string()没有编码上下文，它不读Content-Type，也不查 BOM，更不会 fallback - 正确路径：先按协议约定的编码（如 GBK）解码成合法 UTF-8
[]byte，再string()
gbk.Decoder.Bytes() 怎么调才不 panic、不丢数据
别复用 gbk.Decoder 实例，每次都要新建；错误不能忽略，encoding.InvalidUnreadableError 是常态，不是异常。
- 解码前务必跳过 BOM：GBK 无标准 BOM，但如果上游误加了 UTF-8 BOM（
0xEF 0xBB 0xBF），得手动切掉：if len(data) >= 3 && bytes.Equal(data[:3], []byte{0xEF, 0xBB, 0xBF}) { data = data[3:] } - 调用方式固定：
utf8Bytes, err := gbk.NewDecoder().Bytes(gbkBytes)，传入原始[]byte，返回 UTF-8[]byte和 error - 错误处理必须显式：
if err != nil { if _, ok := err.(encoding.InvalidUnreadableError); ok { /* 替换或跳过非法字节 */ } else { /* 其他错误如内存不足 */ } } - 别用
gbk.Decoder.String()：它内部调Bytes()+string()，多一次分配，且无法控制错误策略
结构化字符串提取时，string() 和 []byte() 哪里最容易翻车
网络字节流解析后常需切片、拼接、正则匹配，这时 string() 的只读语义和底层共享会出问题。
立即学习“go语言免费学习笔记（深入）”；
- 危险操作：
s := string(pkt); pkt = pkt[2:] // 修改原切片 → s 内容可能突变，尤其在 HTTP handler 中复用req.Body缓冲区时必现 - 安全做法：确定生命周期可控才用
string(pkt)；否则用append([]byte{}, pkt...)拷贝后再转，或直接对[]byte做bytes.Index()、bytes.Split() - 性能陷阱：在循环里反复
string(header)→regexp.MustCompile(...).FindStringSubmatch(...)→[]byte(match)，三次转换，逃逸+GC 压力；应提前转一次s := string(header)，后续全用s - 注意
len(s)≠ 字符数：含中文时，for i, r := range s才是取第 N 个 rune，s[i]可能截断 UTF-8 字节
要不要用 unsafe 加速 []byte ↔ string 转换
不要。除非你在写数据库内核或网络栈底层，且已 profile 确认转换是瓶颈；否则 unsafe 带来的维护成本和崩溃风险远超零分配收益。
-
string(buf)本身不分配，快；[]byte(s)也不分配，快；真正慢的是解码（gbk.Decoder.Bytes()）和后续字符串操作（如strings.ReplaceAll()） -
unsafe版本（如bytesToString）绕过 Go 内存模型，在 GC 收集或 slice realloc 时可能读到已释放内存，调试极难 - 实测：10MB GBK 数据解码 + 转
string，耗时 95% 在gbk.Decoder.Bytes()，5% 在string()；优化后者毫无意义
真正卡住性能的，从来不是 string() 这一行，而是没搞清「原始字节流」和「文本字符串」之间隔着一层编码契约。网络协议字段怎么标编码、BOM 怎么处理、错误怎么降级、切片生命周期怎么管——这些细节漏一处，后面所有字符串操作都建立在沙上。
