Go原生不支持繁简转换，必须用go-opencc（推荐）或hanzicn（轻量但准确率低）；不可用strings.ReplaceAll，因繁简非一一映射，需分词与上下文匹配。
Go 原生不支持繁简体转换，必须依赖第三方库；目前稳定可用且维护良好的只有 go-opencc（基于 OpenCC C 库封装）和纯 Go 实现的 hanzicn，但后者覆盖场景有限、词典老旧。
为什么不能直接用 strings.ReplaceAll 或映射表硬替换
简体转繁体不是一对一字符映射：同一个简体字在不同语境下可能对应多个繁体字（如「发」→「發」或「髮」），反之亦然。OpenCC 的核心价值在于分词+上下文匹配，而简单字符串替换会破坏语义，导致「发展」变成「發展」（正确）但「头发」也变成「發展」（错误）。
常见踩坑点：
- 用
map[rune]string手写单字映射 → 无法处理多音字、异体字、地名专有名词（如「里」→「裏」/「裡」/「里」） - 忽略编码格式：输入文本若含 BOM 或 GBK 编码，
go-opencc会 panic 报invalid UTF-8 - 未预加载词典：首次调用
opencc.NewConverter时若网络不可达或路径错误，会静默 fallback 到默认配置，结果不可控
推荐方案：go-opencc 的正确初始化与使用
它通过 cgo 调用 OpenCC C 库，准确率高、性能好（实测 10MB 文本约 200ms），但需注意构建环境依赖。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
- 安装 OpenCC C 库：macOS 用
brew install opencc；Ubuntu 用apt install libopencc-dev；Windows 需手动下载预编译 DLL 并设置CGO_LDFLAGS - 初始化必须指定词典路径，不要依赖默认：
opencc.NewConverter("s2t.json")（路径相对于可执行文件，非源码目录） - 支持的配置文件名有：
s2t.json（简→繁）、t2s.json（繁→简）、s2tw.json（简→台湾正体）、tw2s.json（台湾正体→简）等，注意区分tw和hk场景 - 转换函数返回
(string, error)，务必检查 error —— 常见错误是词典加载失败，报opencc init failed: invalid config
示例：
conv, err := opencc.NewConverter("s2t.json")
if err != nil {
log.Fatal(err) // 不要忽略
}
result, err := conv.ConvertString("头发和发展")
// result == "頭髮和發展"
无 CGO 环境下的备选：hanzicn 的适用边界
纯 Go 实现，零依赖，适合嵌入 wasm 或 Alpine 容器，但仅支持单字映射 + 少量常用词（如「中国」→「中國」），不支持「皇后」→「皇後」这类依语境变化的转换。
使用限制明显：
- 只提供
hanzicn.S2T()和hanzicn.T2S()两个函数，无配置选项 - 繁体结果固定为「臺灣」而非「台灣」，不区分地区习惯（如「软件」→「軟體」，但「软体」也是台湾常用写法）
- 对日韩汉字兼容性差，例如「龙」→「龍」正确，但「龙井」不会识别为专有名词，仍作单字转
- 性能尚可（约 5MB/s），但准确率在专业文本中低于 85%
真正需要高质量转换时，go-opencc 是唯一靠谱选择；轻量级场景且能接受误差，再考虑 hanzicn。别碰自己写的映射表——繁简转换的复杂度不在代码，而在几十年积累的语料和规则。
