protobuf 中 string 字段采用 length-delimited 编码而非裸 utf-8：先写 varint 长度，再写原始字节；go 中 string 字段不可直接用 []byte 赋值，因 range/len 等操作依赖合法 utf-8；二进制数据应使用 bytes 类型；wire format 上 string 与 bytes 编码相同但语义和类型约束不同。
Protobuf 里 string 字段不是 UTF-8 文本，而是 length-delimited 编码
Go 中 string 类型字段在 Protobuf 序列化后，**不直接以 UTF-8 字节流原样写入**，而是被包装为「length-delimited」格式：先写一个 varint 编码的长度值，再写对应长度的原始字节（即 Go string 的底层 []byte）。这意味着："hello" 不会变成 [104 101 108 108 111] 直接出现，而是类似 [5 104 101 108 108 111]（其中 5 是 varint 编码的长度）。
为什么不能直接用 []byte 赋值或替换 string 字段
Protobuf 的 Go 生成代码对 string 字段做了封装处理，其底层存储仍是 string 类型，而非 []byte。若手动把一段 UTF-8 不完整或含 \x00 的 []byte 强转成 string 再赋值，会导致：
• 序列化时仍按合法 UTF-8 处理（但 Go 允许非 UTF-8 string，只是标准库函数如 strings 可能行为异常）；
• 更严重的是，接收方反序列化后调用 len(p.StringField) 或 range 遍历时可能 panic 或截断——因为 Go 的 range 按 rune 解码，遇到非法 UTF-8 会跳过或中止。
- 正确做法：确保传入的
string值本身是合法 UTF-8（可用utf8.ValidString(s)检查） - 若需传输任意二进制数据（如加密密文、图片片段），应改用
bytes字段类型（即bytes，生成后对应 Go 的[]byte） - 不要依赖
unsafe.String()或反射强行绕过校验——这会让生成代码的字段约束失效，且不同 protoc 版本行为可能不一致
HTTP 传输时 string 字段不会单独“解码”，整个 payload 是二进制 blob
Protobuf 序列化结果是一个完整的二进制 []byte，其中所有字段（包括 string）都已按 wire format 打包。HTTP 层根本不识别内部结构：
• w.Write(data) 发送的是整块二进制，没有字符集协商；
• 客户端收到后必须用 proto.Unmarshal(data, msg) 整体解析，不能对某段子切片单独调用 string() 或 utf8.DecodeRune；
• 如果错误地把响应 body 当作文本读取（例如 io.ReadAll 后转 string(body)），再喂给 proto.UnmarshalText()，必然失败——后者只认文本格式（如 name: "abc"），不是二进制。
- Content-Type 必须设为
application/x-protobuf，而非text/plain或application/json - 禁止用
fmt.Fprintf(w, "%s", data)、io.WriteString(w, string(data))等方式输出——它们会触发字符串强制转义或截断 - 调试时若需查看 string 字段内容，应在反序列化后通过
msg.GetStringField()获取，而不是从 raw bytes 里人工提取
string 和 bytes 字段在 wire format 上编码相同，但语义和 Go 类型不同
Protobuf wire format 对 string 和 bytes 都使用 length-delimited 编码，**底层字节布局完全一样**。区别仅在于生成代码的类型声明和运行时约束：
• string name = 1; → Go 中生成 Name string 字段，赋值时接受 string，序列化前隐式转为 UTF-8 字节；
• bytes data = 2; → Go 中生成 Data []byte 字段，可存任意字节，无 UTF-8 校验。
- 二者 wire type 都是
2（length-delimited），所以抓包看不出来区别 - 如果 proto 文件里误把该存二进制的地方定义为
string，Go 侧可能编译通过，但跨语言通信时其他语言（如 Python）会严格检查 UTF-8，导致解析失败 - 升级 proto 文件时，不可将
string改为bytes（或反之），否则破坏 wire 兼容性——尽管编码一样，但生成代码类型不匹配，Go 会拒绝反序列化
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
