没错，Go中string字段在proto序列化时自动采用Length-Delimited编码（wire_type=2），先写入Varint长度再拷贝UTF-8字节流，空字符串编码为长度00，且严格校验UTF-8合法性；bytes字段虽编码相同但不校验，二者语义不同。
Go中string字段在proto序列化时自动走Length-Delimited编码
没错，只要.proto里定义的是string类型字段（比如string name = 1;），Go生成的struct中对应字段是string类型，那么proto.Marshal()就会用Length-Delimited方式编码——不需要你手动加长度前缀，也不需要调用额外函数。
这是因为wire_type为2（Length-delimited）专用于string、bytes、嵌套message等变长数据。编码过程分两步：先用Varint写入内容长度，再原样拷贝UTF-8字节流。
- 例如
"hello"会被编码为：0A 05 68 65 6C 6C 6F（0A是tag，05是长度5，后面6个字节是ASCII） - 中文字符串如
"你好"（UTF-8占6字节）会编码为长度06+ 六个UTF-8字节，不是Unicode码点数 - 空字符串
""编码为长度00，不带后续字节
string和[]byte在proto中都用Length-Delimited，但语义不同
虽然底层编码完全一样（都是wire_type=2 + Varint长度 + 原始字节），但proto规范对string和bytes字段有明确语义区分：
-
string字段要求UTF-8合法；解析器（如Go的proto.Unmarshal()）会校验，非法UTF-8可能静默截断或panic（取决于实现版本） -
bytes字段不校验内容，任何二进制都可存取，包括\x00、\xFF、无效UTF-8等 - 如果你把二进制数据塞进
string字段，即使能marshal成功，反序列化时可能被破坏或报错——这不是bug，是设计使然
Length-Delimited编码导致的常见错误现象
实际调试中最容易踩的坑，往往不是编码本身，而是对Length-Delimited行为缺乏预期：
立即学习“go语言免费学习笔记（深入）”；
- 用
hex.Dump()看序列化结果时，发现开头多出一个长度字节（如05），误以为是“多余头信息”而手动跳过，结果解析失败 - 把proto二进制消息当纯字符串处理（比如用
strings.ReplaceAll()），因内部含\x00等控制字符直接截断 - 跨语言对接时，对方用C++/Python解析，但自己用Go写了自定义二进制拼接逻辑，绕过了
proto.Marshal()，导致Length字段与实际内容长度不一致 - 误以为Length-Delimited的长度是Unicode字符数——它永远是字节数（
len(s)），不是utf8.RuneCountInString(s)
为什么Length-Delimited对性能和兼容性关键
Length前缀的存在，让proto解析器能安全跳过未知字段——读到tag后，根据wire_type知道接下来该读几个字节（或是否要读Varint长度），然后直接seek过去，不用逐字节匹配边界。
这对演进至关重要：
- 服务端新增一个
string字段，老客户端发来的旧消息仍可解析（新字段被跳过） - 字段重排序、增删字段，只要field_number不变，Length-Delimited结构就保持向后兼容
- 相比JSON/XML，没有结束标签开销，也没有字段名重复存储；相比纯二进制自定义协议，又免去了手写长度校验和越界保护
真正要注意的从来不是“怎么让它工作”，而是别在string字段里塞非UTF-8数据，也别在没理解Length含义时去动二进制buffer的中间字节。
