Go中s[i]或s[i:j]处理中文会乱码，因为string是UTF-8字节序列，s[i:j]按字节切片，而中文字符占多个字节，易截断成非法UTF-8序列，导致panic或显示方块。
为什么直接用 s[i] 或 s[i:j] 处理中文会乱码
Go 的 string 是只读的 UTF-8 字节序列，len(s) 返回的是字节数，不是字符数。比如 "你好" 占 6 个字节，但只有 2 个 Unicode 字符（即 2 个 rune）。当你写 s[1:4]，实际是在字节层面切片——可能从“你”的第二个字节开始、截到“好”的第一个字节，结果是一段非法 UTF-8 序列。后续打印、JSON 编码、HTTP 响应都可能 panic 或显示方块/空格。
常见错误现象包括：panic: runtime error: slice bounds out of range、json: invalid UTF-8 in string、终端输出显示 或空白。
- ASCII 字符（如
'a'）占 1 字节，s[0]碰巧能取对；中文、emoji、带重音符号的字母（如'é'）都占多字节，不能靠下标硬算 -
range s是安全的：它隐式按rune迭代，ch是rune，i是该rune在原始字符串中的起始字节索引（不是字符序号） - 别把
strings.IndexRune(s, '好')返回的值直接当字节偏移喂给s[i:j]——它返回的是 rune 位置，不是字节位置
用 []rune(s) 安全截取中文字符串的实操要点
这是最常用也最容易出错的环节。把 string 转成 []rune 后再切片，本质是先解码 UTF-8 成 Unicode 码点数组，再按逻辑字符操作。
- 必须校验边界：
if n >= len([]rune(s)) { return "" }，不能假设n一定合法 - 转换有开销：每次
[]rune(s)都会分配新内存并遍历整个字符串，高频场景（如日志截断、API 响应摘要）建议复用或加缓存 - 转回
string才是最终结果：string([]rune(s)[0:5])，漏掉string()会得到[]rune类型，编译不通过 - 空字符串或
nil必须提前判断，否则[]rune("")虽不 panic，但len([]rune(nil))会 panic
示例：取前 3 个字符（兼容中英文混排）
立即学习“go语言免费学习笔记（深入）”；
func firstNChars(s string, n int) string {
if s == "" {
return ""
}
runes := []rune(s)
if n > len(runes) {
n = len(runes)
}
return string(runes[:n])
}
strings.IndexRune 和 strings.Index 的行为差异
二者底层路径完全不同：strings.Index 是纯字节匹配，strings.IndexRune 是按 Unicode 码点查找。在多数简单中文场景下结果一致，但原理和鲁棒性差别很大。
-
strings.Index("café", "é")成功（因为"é"是合法 UTF-8 子串），但若源字符串是组合形式（"e\u0301"，即e+ 重音符），Index就找不到，而IndexRune('é')仍可命中 -
strings.IndexRune返回的是 rune 序号（从 0 开始计数），不是字节偏移；要转成字节位置需手动计算，例如用utf8.RuneCountInString(s[:pos])不实用，更推荐直接用range遍历时记录 - 查 emoji 连字（如
"??"）时，IndexRune只能定位到首字符（'?'），无法识别 ZWJ 序列整体——这是 Unicode 层面的限制，Go 不做额外解析
乱码真正源头往往不在 Go 代码里
90% 的“Go 输出中文乱码”问题，根子不在 rune 用没用对，而在编码链路断裂：源文件保存为 GBK、终端代码页是 936、读取的 CSV 是 ANSI 编码、HTTP 响应头缺失 charset=utf-8……Go 只负责按你给的字节原样输出，它不管你怎么解。
- 检查 Go 源文件是否为无 BOM 的 UTF-8：
xxd main.go | head -1，开头是ef bb bf就得删 BOM - Windows CMD 下运行前执行
chcp 65001；PowerShell 需设$OutputEncoding = [System.Text.Encoding]::UTF8 - 读非 UTF-8 文件（如 GB18030）必须用
golang.org/x/text/encoding/simplifiedchinese显式转码，不能靠io.ReadAll后再处理 - HTTP handler 中务必写
w.Header().Set("Content-Type", "text/plain; charset=utf-8")，否则浏览器可能按 ISO-8859-1 解
真正难处理的，是那些你以为“只是字符串操作”的地方——比如从数据库读出来的一行文本，它的编码由 driver、连接参数、字段定义共同决定，不是 string 类型本身能兜住的。
