Go语言中文字符串截取不能用substr或s[start:end]，因为字符串底层是UTF-8字节序列，直接按字节切片易截断汉字导致乱码或panic；必须先转[]rune按字符索引操作。
中文字符串截取为什么不能用 substr 或 [start:end]
Go 的 string 本质是字节序列，不是字符序列。中文在 UTF-8 编码下占 3 个字节，直接用切片（如 s[0:3]）可能截断一个汉字，导致 或 panic（尤其在 range 或 len() 后再切时）。这不是 bug，是设计使然——len(s) 返回字节数，不是字符数。
实操建议：
- 永远避免对中文
string做字节索引切片，除非你明确知道每个位置对应完整 UTF-8 码点 - 需要按“第几个汉字”截取时，必须转成
[]rune，再切片：r := []rune(s); sub := string(r[0:2]) - 注意：转
[]rune是 O(n) 操作，频繁调用需考虑缓存或预处理
range 遍历字符串时拿到的是 rune 而不是字节
这是 Go 处理 Unicode 最友好的机制：range 自动按 Unicode 码点（即 rune）迭代，每次返回的索引是字节偏移，值是 rune。这意味着你可以安全地计数、跳过、拼接中文字符，而不会出现乱码。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 写
for i := 0; i → 输出乱码或问号 - 误以为
range的i是字符序号（其实是字节起始位置），导致截取逻辑错位
正确做法：
for i, r := range s {
// i 是该 rune 在原 string 中的字节起始位置
// r 是当前汉字/符号对应的 Unicode 码点（int32）
if i >= 6 { // 字节偏移超 6，不一定等于前 2 个汉字
break
}
}
// 要取前 N 个汉字，仍推荐先转 []rune
性能敏感场景下如何避免反复转换 string ↔ []rune
把长中文字符串转成 []rune 开销不小，尤其在高频日志、分词、API 响应等场景。一次转换多次复用比每次截取都转更合理。
使用场景与参数差异：
- 若只需取前 N 个字符且 N 较小（如标题截断），可用
utf8.RuneCountInString(s)先判断长度，再转[]rune截取 - 若需多次随机访问（如高亮第 5～8 个字），缓存
[]rune比反复转换划算 - 若只做单次前缀截取且字符串不长（[]rune 更简洁；反之可手写 UTF-8 解码循环（但极少必要）
示例（带边界检查）：
func substrRune(s string, start, end int) string {
runes := []rune(s)
if start < 0 { start = 0 }
if end > len(runes) { end = len(runes) }
if start > end { return "" }
return string(runes[start:end])
}
第三方库是否值得引入？比如 go-runewidth 或 golang.org/x/text
标准库已足够处理绝大多数中文截取需求。golang.org/x/text 主要解决宽度、排序、大小写等国际化问题，不是为简单截取设计；go-runewidth 关注终端显示宽度（如 CJK 字符占 2 列），和“字符个数截取”目标不同。
容易踩的坑：
- 引入
x/text/width试图解决截取问题 → 它返回的是“显示列宽”，不是字符数，你好宽度是 4，但字符数是 2 - 用
strings.Count统计中文 → 它按字节计数，对 UTF-8 中文完全不可靠 - 依赖正则
regexp.MustCompile(`.`)匹配中文 → 性能差，且无法控制“取前 N 个”这种精确需求
结论：95% 场景，老老实实用 []rune 转换 + 切片最直接、最可控。复杂格式化或双向文本才需深入 x/text。
真正容易被忽略的是：rune 不等于“人眼看到的一个字”——emoji 表情（如 ??）、组合字符（如 á）、代理对（超出 BMP 的 Unicode）都可能占多个 rune。纯中文场景没问题，但一旦混入 emoji 或生僻字，[]rune 截取仍可能“切开”一个视觉字形。
