字符串下标取出来的是 byte 而非字符，s[0] 获取 UTF-8 字节流首字节，如“你好”中 s[0] 为 228（0xe4），单独打印显示乱码 ä；仅适用于纯 ASCII 场景，中文等 Unicode 字符需转 rune 切片处理。
字符串下标取出来的是 byte，不是字符
直接写 s[0] 拿到的是 UTF-8 字节流的第一个字节，不是“第一个字符”。对 "你好"，s[0] 是 228（十六进制 0xe4），单独打印是乱码 ä，因为“你”在 UTF-8 中占 3 字节：0xe4 0xbd 0xa0。这种操作只适合纯 ASCII 场景，比如解析协议头或读取固定格式二进制字段。
常见错误现象：用 for i := 0; i 遍历并拼接 <code>string(s[i])，遇到中文会输出一堆乱码或 panic；或者用 s[:n] 截取，n 稍大一点就切在 UTF-8 中间字节，导致 invalid UTF-8 string 错误。
- 安全做法：想按“字符”索引，必须先转
[]rune(s)，再取rs[n] - 性能注意：
[]rune(s)是 O(n) 解码 + 内存分配，大字符串慎用；只需遍历？优先用for _, r := range s - 别把
s[i]当成可显示字符——它连类型都不是rune，只是byte
range 遍历返回 rune，不是 byte
for i, r := range s 中的 r 是 rune 类型，值为 Unicode 码点，比如“你”是 20320，“好”是 22909；i 是该码点在原始字节中的起始位置。这是 Go 唯一能保证拿到完整语义字符的原生方式。
典型误用：把 r 强转成 byte（如 byte(r)）传给 bytes.Contains 或写入文件——中文会丢高位字节，变成乱码或空字符；或者拿 r 和 '中' 直接比较，其实没问题（'中' 字面量本身就是 rune），但若函数参数声明为 byte 就编译失败。
立即学习“go语言免费学习笔记（深入）”；
- 函数签名要匹配：搜索单个 Unicode 字符用
strings.ContainsRune，不是bytes.Contains -
fmt.Printf("%c", r)能正确打印中文/emoji；fmt.Printf("%c", b)（b是byte）只对 ASCII 有效 -
range自动跳过非法 UTF-8 字节（如网络传输损坏数据），返回0xfffd（），比手动解码更健壮
len(s) 返回字节数，不是字符数
len(s) 返回底层 UTF-8 字节数，len([]rune(s)) 才是真实字符数。例如 len("a??") 是 11（emoji 组合占 11 字节），但 len([]rune("a??")) 是 3（a + 1 个 emoji 角色）。
业务上“取前 10 个字”几乎总是指字符数，不是字节数。用 s[:10] 在含中文时大概率 panic 或截出半个字；而 rs := []rune(s); string(rs[:min(10, len(rs))]) 才安全。
- 统计用户输入长度？用
utf8.RuneCountInString(s)，避免构造临时[]rune - 做数据库字段截断、前端展示限制等，必须用
[]rune转换后再切，否则线上出现乱码或崩溃 - 别依赖
len(s)判断“字符串有多长”——它回答的是“占多少存储”，不是“有几个字”
[]byte(s) 是零拷贝，[]rune(s) 是解码重分配
[]byte(s) 只是重新解释字符串底层字节切片的头信息，不复制数据，适合 IO、加密、base64 编码等字节级操作；[]rune(s) 必须逐字节解析 UTF-8，为每个码点分配一个 int32，内存占用翻倍（如 “你好” 6 字节 → []rune 占 8 字节），且无法避免分配。
容易踩的坑：把 []rune(s) 结果直接传给 os.Write 或 http.ResponseWriter.Write——写出去的是二进制 int32 序列，根本不是 UTF-8，接收方看到全是乱码；或者缓存 []rune(s) 用于高频查询，却没意识到它比原字符串还占内存。
- 写文件/发 HTTP 请求？用
[]byte(s)，安全高效 - 做文本处理（反转、分词、首字母大写）？必须用
[]rune(s)，但记得及时丢弃，别长期持有 - 高频场景（如日志截断）可预判长度：
if utf8.RuneCountInString(s) > 100 { rs := []rune(s); ... }，避免无谓解码
byte 和 rune 的类型检查很严格，但运行时行为差异又极其隐蔽：可能只是少显示半个 emoji，或者某次截断后 JSON 解析失败。选错粒度，代码就从“能跑”变成“跑得不对”。 
