strings.Count 统计单个 ASCII 字符时高效，底层走优化路径；但统计 Unicode 字符（rune）需转 []rune 遍历，否则仅按字节匹配，结果可能错误。
strings.Count 对单字符统计是否高效？
直接说结论：strings.Count 在统计单个 ASCII 字符（如 'a'、' '）时，底层会走快速路径，性能接近手写循环；但若传入多字符子串（如 "ab"），哪怕只是两个字符，也会触发通用子串匹配逻辑，开销明显上升。
它本质是调用 strings.Count 内部的 countGeneric 或优化过的 countBytes —— 前者遍历 + 逐字节比较，后者对单字节做 SIMD 风格展开（Go 1.21+ 在支持 AVX2 的平台启用）。所以「字符」必须是 byte 级别才享受加速。
- 统计
'x'：快，推荐直接用 - 统计
"x"（字符串字面量）：也快，Go 编译器能识别并优化为单字节 - 统计
"?"或"中"：慢，因为 rune > 1 byte，strings.Count只做字节匹配，结果可能错误（比如 UTF-8 编码的"中"是 3 字节，strings.Count(s, "中")实际在找这 3 字节序列，正确但非 rune 意义上的“字符”）
想统计 Unicode 字符（rune）频次，不能只靠 strings.Count
strings.Count 从不解析 UTF-8，它只数字节序列。对中文、emoji 等，它返回的是“编码字节出现次数”，不是“字符个数”。例如：
str := "a?b?" fmt.Println(strings.Count(str, "?")) // 输出 2 —— 碰巧正确，因 emoji 在 UTF-8 中是固定 4 字节且无重叠 str2 := "??" // ZWJ 序列，长度 7 字节 fmt.Println(strings.Count(str2, "??")) // 输出 1，但若你拆开搜 "?"，会得到 1（错误！实际是组合体）
真正安全的做法是转成 []rune 后遍历：
立即学习“go语言免费学习笔记（深入）”；
count := 0
for _, r := range str {
if r == '?' {
count++
}
}
- 这是唯一能保证按 Unicode 字符（rune）计数的方式
- 注意：转换
string → []rune有内存分配和解码开销，短字符串影响小，高频热路径需权衡 - 若只需统计 ASCII 范围内字符（0–127），仍优先用
strings.Count，更快且零分配
strings.Count 和 bytes.Count 性能差异大吗？
几乎没差别 —— bytes.Count 是 strings.Count 的镜像实现，底层共享同一套逻辑。区别仅在于输入类型：string vs []byte。
- 如果你已有
[]byte（比如从io.Read得到），用bytes.Count避免隐式转 string - 如果你持有
string，别为了“看起来快”先转[]byte—— Go 运行时对 string 的底层字节数组访问是零拷贝的，转切片反而多一次 header 复制 - 两者在 benchmark 中差异通常在 5% 以内，可忽略
高频场景下，手写循环一定比 strings.Count 慢？
不一定。当目标字符已知且单一（如统计换行符 '\n'），一个简单 for 循环往往比 strings.Count 更快，尤其在小字符串（
count := 0
for i := 0; i < len(s); i++ {
if s[i] == '\n' {
count++
}
}
- 省去了函数调用开销和参数检查
- 编译器可能进一步内联或向量化（特别是常量字符）
- 但丧失了可读性和维护性 —— 除非 profile 明确指出这里是瓶颈，否则不建议替换
- 若要兼容 rune 或复杂条件（如“统计所有空白字符”），还是用
strings.FieldsFunc或utf8.RuneCountInString+ 自定义逻辑更稳妥
真正容易被忽略的是：strings.Count 的语义是“子串重叠不计”，即 strings.Count("aaaa", "aa") 返回 2，不是 3 —— 这点在处理协议头、分隔符时可能引发逻辑偏差，得看场景是否允许重叠匹配。
