s[0]不是第一个字符而是首字节，因go字符串底层是utf-8字节序列，“你好”中s[0]为0xe4（十进制228），单独打印显示乱码ä；仅ascii场景安全，中文/emoji必用[]rune或range遍历。
Go 里直接用 s[i] 取中文或 emoji，大概率拿到乱码或 panic——这不是 bug，是 UTF-8 编码和 Go 字符串设计的必然结果。
为什么 s[0] 不是第一个“字符”
Go 字符串底层就是 []byte，s[0] 拿到的是 UTF-8 字节流的第一个字节。比如 "你好" 的首字节是 0xe4（十进制 228），单独打印就是 ä，不是“你”。这种操作只在纯 ASCII 场景下碰巧有效，比如解析 HTTP 头或二进制协议字段。
- 错误现象：
for i := 0; i 遇到中文会输出一堆 <code>或崩溃 - 截取风险：
s[:3]对"你好"会切出0xe4 0xbd，缺第三字节，转成 string 后变成 invalid UTF-8 - len(s) 返回字节数，不是字符数；
len("你好") == 6，但真实字符只有 2 个
range 是唯一安全、零分配的遍历方式
for _, r := range s 中的 r 类型是 rune，值是 Unicode 码点（如“你”=20320）；i 是该码点在原始字节中的起始偏移，不是“第几个字符”。这是 Go 唯一原生支持多字节字符语义的遍历机制。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 自动跳过非法 UTF-8 字节（比如网络传输损坏的数据），返回
0xfffd替换符 - 不分配新内存，内部边读边解码，比
[]rune(s)轻量得多 - 别把
i当索引用：在"café"中，é占 2 字节，i会从 2 跳到 4 - 搜索单个字符用
strings.ContainsRune，别用bytes.Contains—— 后者传byte(r)会丢高位字节
什么时候必须用 []rune(s)
只有真需要“字符粒度随机访问”时才转切片，比如取第 5 个汉字、反转字符串、按字符数截断。但它是 O(n) 解码 + 内存分配，对大文本或高频调用是性能陷阱。
- 安全取前 N 个字符：
rs := []rune(s); string(rs[:min(N, len(rs))]) - 只取第 k 个字符？若字符串很长，考虑用
utf8.DecodeRuneInString循环解码到第 k 个，避免全量分配 -
string([]rune(s))和string([]byte(s))行为完全不同：前者重新编码 UTF-8，后者只是类型重解释 - 正则匹配单个汉字？用
\p{Han}，别先转[]rune再遍历——regexp本身按 rune 工作
字符字面量 '中' 是 rune，不是 byte
写 '中' 或 '?' 是合法的，类型就是 rune（即 int32）。而 "中"[0] 是 byte，两者不能混用。
- 编译器会报错：
if s[0] == '中'—— 左边是byte，右边是rune - ASCII 场景下碰巧能过：
s[0] == 'a'成立，因为'a'是 97，s[0]也是 97，但这只是巧合 - 判断是否含中文？用
unicode.Is(unicode.Scripts["Han"], r)，别先转切片再循环 - emoji 组合（如 ??）占多个码点，
len([]rune("??"))返回 3 或 4，不是 1 —— 这是 Unicode 规范决定的，Go 只忠实地反映它
最常被忽略的点：[]rune(s) 和 range 解决的是不同层级的问题——前者给你可索引的字符数组，后者给你流式、低开销的字符迭代。选错就等于在 UTF-8 泥潭里多踩一脚。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
