len() 对字符串的时间复杂度是 o(1)，因为它直接读取底层 stringstruct 结构体中的 len 字段，不扫描内容；但该值是字节数而非字符数，utf8.runecountinstring() 和 []rune(s) 才真正统计 rune 个数，二者均为 o(n)。
len() 对字符串是 O(n) 而不是 O(1)
直接说结论：len() 对字符串的时间复杂度是 O(1)，但它返回的不是“字符数”，而是底层字节数；这个 O(1) 成立的前提是：它读的是字符串头结构体里的 len 字段，不扫描内容。
Go 字符串底层是一个只读结构体（stringStruct），包含两个字段：str（指向底层字节数组的指针）和 len（该数组长度）。len(s) 就是直接取这个 len 字段——和取 slice 的 len、map 的 count 一样，都是编译器内建的字段访问，零遍历、零计算。
常见误解是以为 “len() 快所以能当字符数用”，但快 ≠ 正确。它快，是因为它根本不管 UTF-8 编码逻辑，也不识别 rune 边界。
为什么 utf8.RuneCountInString() 是 O(n)
utf8.RuneCountInString() 必须逐字节解析 UTF-8 编码，才能判断每个 rune 的起始与结束位置。UTF-8 是变长编码：ASCII 字符占 1 字节，中文通常占 3 字节，emoji 可能占 4 字节甚至更多（如带 ZWJ 的组合 emoji 达 11 字节）。函数无法跳过任何字节，必须从头扫到尾。
- 输入
"你好"→ 扫 6 字节，识别出 2 个 rune - 输入
"??"→ 扫 11 字节，识别出 3 个码元（rune） - 即使字符串里全是 ASCII，它仍要逐字节验证是否为有效 UTF-8 起始字节
没有缓存、不可跳过、不复用中间状态——这就是它稳定 O(n) 的原因。高频调用（比如日志截断、实时 UI 计数）时，这个开销会真实可见。
[]rune(s) 转换的代价与适用场景
写 len([]rune(s)) 看似简洁，但它会触发一次完整分配 + 全量解码：
- 先为所有 rune 分配新底层数组（内存开销）
- 再逐字节解析 s，填入每个 rune（CPU 开销）
- 最后才调
len()读这个切片的长度字段
它比 utf8.RuneCountInString() 更重，但优势是：后续若还需按 rune 截取或遍历，这次转换就“一劳永逸”了。否则纯计数场景下，它属于过度操作。
注意：[]rune(s) 对超长字符串（如 MB 级日志行）可能引发 GC 压力或分配失败，而 utf8.RuneCountInString() 至少不额外分配堆内存。
容易被忽略的边界：空字符串、nil 字符串、常量字符串
Go 中不存在 nil 字符串（string 是值类型，零值是 ""），所以 len("") 安全返回 0，无需判空。
但要注意编译期常量字符串（如 "abc"）和运行时拼接字符串（如 s := "ab" + "c"）在底层都共享同一套结构体布局，len() 行为完全一致——O(1)，无例外。
真正容易踩坑的是把 len(s) 当作 UI 显示宽度、分页项数或光标偏移依据。一旦遇到 emoji 或 CJK 字符，字节数和人眼感知的“长度”立刻脱钩。这种错位往往上线后才暴露，且难以复现（取决于用户输入内容）。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
