strings.count 适合统计单个字符，但必须传 string 类型而非 rune 或 byte；它按字节扫描，对合法 utf-8 字符串能正确匹配多字节 rune，不支持重叠匹配，空字符串参数返回 rune 数加 1，链式调用低效，应改用单次 range 遍历。
strings.Count 适合统计单个字符吗
适合，但必须传 string 类型，不能直接传 rune 或 byte。常见错误是写成 strings.Count(s, 'a')，这会编译失败：报错 cannot use 'a' (type rune) as type string。
正确做法是显式转换：strings.Count(s, "a") 或对变量用 string(b)（b 是 byte）；对 Unicode 字符如 "好"，直接传字符串字面量即可，但要确保它是合法 UTF-8 —— 比如 strings.Count("你好", "好") 安全，而误拼成 "" 可能匹配不到。
-
strings.Count内部按字节扫描，对 ASCII 完全可靠；对多字节 rune，只要输入字符串本身合法，它也能正确匹配整个码点（因为 UTF-8 编码中一个 rune 对应连续字节序列） - 别指望它处理重叠匹配：
strings.Count("aaaa", "aa")返回2，不是3 - 空字符串
""作为第二参数时返回utf8.RuneCountInString(s) + 1，业务代码应提前校验并拒绝
统计多个字符为何不能链式调用 strings.Count
链式调用 strings.Count 看似方便，实则低效：每调一次都从头遍历整个字符串。比如统计 "a"、"e"、"i" 各出现几次，写三次 strings.Count 就是三次 O(n) 扫描，总耗时 O(3n)。
真正该做的是单次遍历 + map[rune]int 累加。Go 的 for _, r := range s 天然按 rune 解码，支持中文、emoji 等任意 Unicode 字符，且语义清晰、性能最优。
- 只关心 ASCII？可用
for i := 0; i 配合 <code>s[i]（byte），略快但可读性差，通常没必要 - 若只需统计某几个特定字符（如仅
'a'、'e'、'i'），循环内加条件判断即可，不用 map 全量计数 - 别用
len([]rune(s))替代频次统计——那是总字符数，不是某个字符的出现次数
需要重叠匹配时怎么写安全代码
标准库没有重叠子串计数函数，strings.Count 明确不支持。可靠做法是用 strings.Index 循环，关键在每次只前进 1 字节，而不是 len(substr)。
核心逻辑：找到匹配位置 i 后，下一次搜索从 start = i + 1 开始，而非 i + len(substr)。同时必须判空：if len(substr) == 0 直接返回 0 或 panic，否则 strings.Index 行为未定义。
- 别用
strings.ReplaceAll算长度差——会分配新字符串，GC 压力大，大文本性能崩塌 - 正则如
regexp.MustCompile("(?=aa)")属于过度设计：编译开销高、可读性差、边界难控，仅当子串本身含动态模式才考虑 - 注意
strings.Index区分大小写，且不跳过空白或忽略标点，需自行清洗输入
Unicode 字符统计为什么必须用 range 而非下标
因为 Go 字符串底层是 UTF-8 字节数组，直接用 s[i] 取的是 byte，不是 rune。中文、emoji 等多字节字符会被切裂，导致计数错乱或 panic。
for _, r := range s 是唯一安全遍历 Unicode 字符的方式，它自动解码 UTF-8 序列，每次迭代得到完整 rune。这也是为什么所有健壮的字符频次统计函数（如 countChars）都基于这个循环。
- 误用
len(s)统计“字符数”？那是字节数，不是人眼看到的“字”个数；要用utf8.RuneCountInString(s) - 想区分“字节长度”和“Unicode 字符数”，就得明确场景：日志分析常看字节（网络传输），用户界面显示常看 rune（视觉计数）
- map key 必须用
rune类型存 Unicode 字符，用byte当 key 只能覆盖 ASCII
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
