因为go字符串底层是utf-8字节序列，直接按[]byte反转会拆分多字节unicode字符（如中文），导致乱码或非法utf-8；必须转为[]rune再反转，rune对应完整unicode码点，避免截断。
用 rune 切片反转字符串时，为什么中文变乱码或长度不对
因为 Go 的字符串底层是 UTF-8 字节序列，直接按 []byte 反转会把多字节的 Unicode 字符（比如中文、emoji）拆开，导致非法 UTF-8 序列。必须先转成 []rune，再反转切片。
-
rune是 Go 对 Unicode 码点的抽象，一个中文字符对应一个rune，不会被截断 - 转换开销存在：每次
[]rune(s)都要遍历并解码整个字符串，对超长字符串（如 MB 级日志）要注意性能 - 反转后需再转回
string，Go 会自动编码为合法 UTF-8，无需额外处理
示例：
func reverseRune(s string) string {
runes := []rune(s)
for i, j := 0, len(runes)-1; i < j; i, j = i+1, j-1 {
runes[i], runes[j] = runes[j], runes[i]
}
return string(runes)
}
用 []byte 直接反转只适合 ASCII 场景
如果确定字符串只含 ASCII 字符（如纯英文、数字、符号），[]byte 反转快且零分配，但一旦混入中文、日文或 emoji，结果就是非法字节流，打印或 JSON 序列化时可能 panic 或静默截断。
- 常见错误现象：
fmt.Println(reverseByte("你好"))输出一堆或空字符串 - JSON 编码时触发
json: error calling MarshalJSON for type string: invalid UTF-8 - HTTP 响应头或 URL 路径中使用该字符串，可能被中间件拒绝或转义异常
安全做法：除非你 100% 控制输入源（比如只处理 base64 片段或 hex 字符串），否则别碰 []byte 反转。
立即学习“go语言免费学习笔记（深入）”；
strings.Builder 在反转中没优势，反而容易写错
有人想用 strings.Builder 拼接反转后的字符，但 Builder 是为「顺序追加」设计的，不支持从后往前写；强行用 WriteRune 倒序调用，代码更绕、可读性差，还失去切片原地交换的 O(1) 空间优势。
- Builder 的
Grow和扩容逻辑对反转无帮助，反而增加分支判断 - 若误用
WriteString(string(r))替代WriteRune(r)，又会掉回 UTF-8 截断陷阱 - 基准测试显示，Builder 版本比纯
[]rune交换慢 15–20%，且内存分配多一次
边界情况：空字符串、单字符、含 NUL 或控制字符怎么办
Go 字符串允许包含 \x00（NUL）和其他控制字符，[]rune 转换完全兼容——它们各自都是合法的 rune，反转后位置互换，语义不变。真正要留意的是外部系统是否接受这些字符。
- 空字符串
""→[]rune长度为 0，循环不执行，返回空字符串，没问题 - 单字符（包括 emoji，如
"?"）→[]rune长度为 1，交换逻辑不触发，原样返回 - 含
\u202E（Unicode RTL 标记）等格式字符时，反转的是码点顺序，不是渲染顺序，别指望它改变显示方向
实际中最容易被忽略的，是把反转结果当“视觉倒序”用——比如想让 “abc你好” 显示成 “好你cba”，但 reverseRune 得到的是 “好你cb a”，因为它是按码点而非字形簇（grapheme cluster）反转的。真有这种需求，得上 golang.org/x/text/unicode/norm 或专用库。
