Go字符串以UTF-8编码，len()和下标操作返回字节数和字节值，非Unicode字符数；需用utf8包或range遍历安全处理rune。
Go 字符串不是字符数组，直接用 len() 或下标访问拿到的是字节，不是人眼看到的“字符”——这是所有乱码、越界、截断问题的根源。
为什么 s[0] 取出来是乱码或奇怪数字
因为 s[0] 拿到的是 UTF-8 编码的第一个字节，不是第一个 Unicode 字符。比如 "你好" 的首字节是 0xe4（十进制 228），打印出来就是 228，不是 你。
-
len("你好")返回6：3 字节 × 2 个中文 = 6 字节，不是 2 个字符 -
s[0:2]可能切出非法 UTF-8 序列（如只取了0xe4 0xbd，缺第三字节），string()转换后显示为 - 用
for i := 0; i < len(s); i++遍历，遇到中文会跳过中间字节，导致i值不连续、逻辑错位
用 range 遍历时 i 是字节偏移，不是字符索引
for i, r := range s 中的 i 是当前 rune 在原字符串中的起始字节位置，不是“第几个字符”。比如 s = "café"，é 占 2 字节，i 从 0→1→2→4 跳变。
- 想安全获取前 N 个字符？别用
s[:n]，它按字节截，可能截断 emoji 或中文 - 需要知道某个
rune占多少字节？用utf8.RuneLen(r)，比手动查表或硬编码更可靠 - 判断是否以某个 emoji 开头？用
r, size := utf8.DecodeRuneInString(s); if r == '✅' { ... }，不用strings.HasPrefix(s, "✅")—— 后者依赖源文件编码，IDE 保存格式一变就失效
[]rune(s) 不是零成本操作
把字符串转成 []rune 会完整解码并分配新内存，时间复杂度 O(n)，空间也是 O(n)。对日志、配置、短文本没问题；但处理 MB 级响应体或高频循环时，容易成为性能瓶颈。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 只遍历？优先用
for range s—— Go 内部边读边解码，不额外分配 - 要取第 5 个字符？
rs := []rune(s); rs[4]可行，但若只是偶尔取，且字符串很长，考虑用utf8.DecodeRuneInString循环解码到第 5 个，避免全量分配 - 做子串替换？
strings.ReplaceAll和strings.Map都按rune处理，无需手动转切片；但strings.Split(s, "")拆出来是单字节字符串，不是rune，慎用
utf8.RuneCountInString 和 strings.Count 完全不是一回事
utf8.RuneCountInString(s) 统计的是 Unicode 码点数量，而 strings.Count(s, "x") 是字节子串匹配。两者在 ASCII 场景下结果一致，但一旦涉及多字节字符，行为立刻分叉。
-
utf8.RuneCountInString("??")返回2；strings.Count("??", "?")也返回2（碰巧） -
strings.Count("café", "é")返回1（é是单个 rune，UTF-8 两字节）；但若输入是组合形式"cafe\u0301"（e + ◌́），strings.Count就找不到，而strings.CountRune不存在 —— Go 标准库没提供 rune 级子串计数 - 校验用户昵称 ≤ 10 字符？必须用
utf8.RuneCountInString(nick) <= 10，不能用len(nick) <= 10，否则中文用户只能输 3 个字
真正容易被忽略的点是：rune 本身不做合法性检查，var r rune = 0x110000 是合法代码，但它不是有效 Unicode 码点；而 utf8.ValidRune(r) 才是判断依据。处理外部输入（如 HTTP 请求体）时，别假设 rune 一定合法。
