go字符串是utf-8字节序列，len()返回字节数而非字符数；处理unicode需用rune、utf8包函数及unicode正规化。
Go 里字符串不是字符数组，直接用 len()、s[0] 或 strings.Split(s, "") 处理 Unicode 字符，90% 情况下会出错——不是逻辑 bug，是字节和码点的底层混淆。
为什么 len("你好") 是 6 而不是 2
Go 的 string 是只读 UTF-8 字节序列，len() 返回的是字节数。每个中文字符在 UTF-8 中占 3 字节，所以 len("你好") == 6。这不是缺陷，是设计事实。
- 错误做法：
s[0]取首字节 → 得到0xE4（乱码开头），不是“你” - 错误做法：
for i := 0; i → 可能越界或解析出非法 UTF-8 片段 - 正确做法：用
for i, r := range s→i是字节偏移，r是rune（完整码点） - 需要随机访问第 N 个字符？先转
[]rune(s)，再取rs[n]；但注意大字符串时有内存和性能开销
获取真实字符数和首字符：用 utf8.RuneCountInString 和 utf8.DecodeRuneInString
这两个函数不复制数据、不分配内存，是做长度校验、安全截断、前缀判断的轻量级首选。
-
utf8.RuneCountInString(s)返回字符数（rune 数），比len([]rune(s))快且省内存 -
r, size := utf8.DecodeRuneInString(s)返回首个rune和它占用的字节数，可用于安全判断是否以某个 emoji 或汉字开头 - 别用
strings.HasPrefix(s, "✅")做 emoji 判断——它按字节比，而 ✅ 是 4 字节 UTF-8 序列，编辑器/传输过程可能破坏字节一致性；用r == '✅'更稳 - 空字符串或非法 UTF-8 输入时，
utf8.DecodeRuneInString返回rune(0)和size == 0，生产环境需检查size > 0
判断字母、数字、汉字：用 unicode.IsXxx 而不是 ASCII 比较
unicode.IsLetter(r)、unicode.IsHan(r) 这类函数接收 rune，支持全球语言，且内部基于 Unicode 标准的 *unicode.RangeTable，不是简单查表。
-
unicode.Is(unicode.Han, r)可精准识别汉字（含扩展 A/B 区），比正则\p{Han}更轻量、无需开启(?U) -
unicode.IsDigit(r)匹配全角数字、罗马数字（Ⅰ、Ⅱ）、上标数字（⁰、¹），不只是'0'–'9' - 所有
IsXxx函数都不接受string或byte；传错类型编译不过，强制你先遍历或转[]rune - 大小写转换用
unicode.ToUpper(r)，它处理德语ß → SS、土耳其语I/i映射等边界情况，比手动加减 ASCII 值可靠得多
字符串相等、map key、数据库比对前必须做 Unicode 规范化
同一个字符可能有多种合法 UTF-8 表示：比如 "é" 可以是单个 \u00E9（NFC），也可以是 "e\u0301"（NFD，基础 e + 组合重音符）。Go 的 == 是纯字节比较，二者永远不等。
- 必须用
golang.org/x/text/unicode/norm.NFC.String(s)统一为 NFC 形式后再比较或用作mapkey - 前端输入、JSON 解析、数据库读出的内容，都可能混杂 NFC/NFD；别假设“用户输的肯定规范”
-
norm.IsNormal(norm.NFC, s)只能告诉你“是不是 NFC”，不能代替转换；检测后仍要调用.String()确保一致 - 高频比对场景（如鉴权、去重），提前缓存正规化结果，避免重复调用
norm.NFC.String分配新字符串
最常被忽略的点是：Unicode 正规化不是“可选项”，而是文本系统中字符串比较、哈希、排序、索引的基础设施。没做这一步，所有上层逻辑都建立在不可靠的字节等价假设上。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
