直接用 github.com/mozillazg/go-pinyin 是最稳妥的选择，因其覆盖简体中文常用场景、不依赖外部服务或C依赖、编译即用，且默认单字转拼音空格分隔，符合多数工具链预期。
为什么直接用 github.com/mozillazg/go-pinyin 是最稳妥的选择
Go 生态里没有标准库支持中文拼音转换，硬写规则会踩 Unicode 归一化、多音字、轻声、儿化音等坑。社区成熟的 go-pinyin 库已覆盖简体中文常用场景，底层用预置词典 + 规则补全，不依赖外部服务或 C 依赖，编译即用。
它默认行为是「单字转拼音，空格分隔」，比如 "你好" → "ni hao"，符合多数工具链预期。
- 安装只需：
go get github.com/mozillazg/go-pinyin - 基础用法极简：
pinyin.Convert("北京", pinyin.NewArgs())返回[]string{"bei", "jing"} - 若需带声调（如
"běi jīng"），传入pinyin.WithStyle(pinyin.Tone) - 遇到「重」这类多音字，默认按常用音（
chong），如需上下文判断，得自己接词典或 NLP 模型——库本身不处理语义
Convert 和 ConvertWithoutTone 的实际差异在哪
二者底层都调用同一核心逻辑，区别仅在声调处理阶段：Convert 会查声调映射表并插入 Unicode 组合字符（如 u+0301），而 ConvertWithoutTone 跳过这步，更快且输出纯 ASCII。
- 性能上，无音调版本快约 15%～20%，尤其批量处理万级字符串时明显
- 兼容性上，某些老旧终端或 CSV 解析器对组合字符支持差，
ConvertWithoutTone更稳妥 - 注意：
Convert返回的带声调字符串长度 ≠ 原字数（例如"妈"→"mā"占 2 字节），做等长对齐或索引映射时要小心
如何正确处理带括号、数字、英文混排的字符串
go-pinyin 默认只转换汉字，其余字符原样保留。但「原样」不等于「不破坏结构」——比如 "iOS15(测试版)" 会被转成 "iOS15(ce shi ban)"，括号位置没变，可直接用于搜索或排序。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 若想跳过所有非汉字（包括中文标点），无需额外配置，它本来就不动这些字符
- 若需把英文也转拼音（如
"iPhone"→"ai feng"），得先用正则提取英文段，再走第三方音译库，go-pinyin不提供该能力 - 数字默认不转，但可手动替换：对匹配到的
\d+片段，用strconv.Atoi转整数后查数字读法映射表（如15→"shi wu"）
自定义词典解决「长沙」被拆成「长 沙」而非「chang sha」的问题
地名、人名、专业术语常因分词粒度出错。go-pinyin 支持加载自定义词典，格式为每行「词 拼音」，用空格或制表符分隔，如：长沙 chang sha。
立即学习“go语言免费学习笔记（深入）”；
- 词典文件路径需绝对或相对于可执行文件，用
pinyin.NewDict("/path/to/dict.txt")加载 - 自定义词典优先级高于内置词典，但不会覆盖单字读音（如「沙」仍保留
sha） - 注意编码必须是 UTF-8，BOM 会导致首行解析失败；词典过大（>10MB）会影响初始化速度，建议按需裁剪
- 热更新不支持——修改词典后需重启程序，线上服务需配合配置中心做 reload 机制
真正麻烦的是多音词边界和未登录词泛化，比如「行长」在银行语境读 hang zhang，但库无法自动识别「银行」上下文。这种场景要么加业务层规则（如正则匹配「银行.*行长」→ 强制替换），要么接受一定错误率——拼音转换本就不是 100% 确定性任务。
