词频统计用 map[string]int 就够了，别碰 sync.Map
Go 里做词频统计，核心就是把每个词当 key，出现次数当 value。用 map[string]int 最直接，性能好、语义清、无额外开销。除非你真在高并发场景下边读文件边实时更新词频（比如流式日志分析），否则 sync.Map 反而拖慢速度、增加复杂度，还容易误用——它不支持遍历计数，你最后还得转成普通 map 才能排序输出。
常见错误是看到“多 goroutine 写”就条件反射上 sync.Map，但实际多数文本分析是「先读完、再分词、再统、再输出」的单阶段流程，全程串行更稳更快。
- 输入小文件（os.ReadFile 读进内存，
strings.Fields或正则切分，一遍循环塞进map[string]int - 大文件（>100MB）：用
bufio.Scanner流式读行，每行处理完立即更新 map，避免 OOM - 需要忽略大小写：统一转
strings.ToLower，别在 map key 里混用大小写变体
分词不能只靠 strings.Fields，英文和中文得区别对待
strings.Fields 按空白符切，对纯英文文本够用；但一遇到中英文混排、标点粘连（如 “hello,world!”）、缩写（“don’t”）、连字符（“state-of-the-art”），就会漏词或切错。中文更麻烦——没空格，全靠字或词边界。
简单方案是按需选分词策略，不强求“通用”：
立即学习“go语言免费学习笔记（深入）”；
- 纯英文文档：用
regexp.MustCompile(<code>`[a-zA-Z]+`) 提取连续字母，过滤掉数字和符号 - 中英文混合：先用
unicode.IsLetter或unicode.IsHan判断字符类型，把连续的字母/汉字各自聚成 token - 真要中文分词：引入
github.com/go-ego/gse，但注意它会带来构建依赖和初始化开销，小工具慎加
别用 strings.Split(text, " ")——它会把多个空格、制表符、换行当成不同分隔符，导致空字符串进 map，最后统计出一堆 "" : 1234。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
排序输出前必须转 slice，map 本身无序且每次遍历顺序都可能变
Go 的 map 遍历是随机顺序，这是语言设计特性，不是 bug。想按词频从高到低、或按字母序输出，必须先把 map 的 key-value 拎出来，存进 slice，再用 sort.Slice 排。
典型错误是写个 for-range 循环直接 fmt.Println，结果每次运行输出顺序都不一样，误以为程序有竞态。
- 高频优先：定义
type kv struct{ word string; count int }，把 map 转成[]kv，再按count降序排 - 字母序优先：同样转 slice，但按
word升序排，适合生成词表 - 限制 Top N：排完后只取
slice[:min(N, len(slice))]，别在 map 上做“找最大值”循环，O(n²) 太亏
示例关键行：sort.Slice(pairs, func(i, j int) bool { return pairs[i].count > pairs[j].count })
命令行参数和文件读取别硬编码路径，flag + os.Args 就够用
写完发现只能分析固定文件？那是没接命令行参数。用标准库 flag 包三行就能支持 -file 和 -top，比手撸 os.Args 更健壮（自动处理 help、类型校验）。
容易踩的坑是忘记检查文件是否存在或是否可读，直接 os.Open 后 panic。应该先 os.Stat 或用 os.Open 的 error 判断，给用户明确提示，比如 "open input.txt: no such file or directory"。
- 必传参数：用
flag.String("file", "", "input text file path")，然后flag.Parse()后检查*file == "" - 可选参数：如
-top 10，用flag.Int("top", 20, "show top N words") - stdin 支持：如果
*file == "-"，就用os.Stdin替代文件打开，方便管道传入：cat README.md | ./freq -top 5
别写 if len(os.Args) 手动解析——flag 包已经帮你做了参数合法性、help 输出、类型转换。
