gbk/big5 到 utf-8 的转换必须用 golang.org/x/text/encoding，标准库不支持直接解码，硬转 string 会乱码；正确方式是用 charmap.gbk 或 charmap.big5 配合 transform.reader 或 .bytes()，避免 cgo、慎用 charset.determineencoding。
GBK/Big5 到 UTF-8 的转换必须用 golang.org/x/text/encoding
Go 标准库不支持 GBK、Big5 等非 UTF 编码的直接解码，硬编码 string([]byte{0xc4, 0xe3}) 会得到乱码。真正可行的是用 golang.org/x/text/encoding + transform.Reader 或 .Bytes() 方法。
常见错误现象：string(data) 直接转 GBK 字节 → 显示 ；utf8.RuneCountInString 返回异常值；range 遍历出错 panic。
-
charmap.GBK和charmap.Big5是最常用且稳定的实现，无需 cgo 或外部 DLL - Windows 下不要尝试
iconv_windowsx64：它依赖 C 运行时、易崩溃、版本碎片严重，且 Go 官方明确不推荐在生产环境用 cgo 做编码转换 - 转换失败时，
Decoder.Bytes()默认会丢弃非法字节；如需保留（比如日志容错），用decoder := enc.NewDecoder().SetInvalidByte(0xfffd) - 性能影响：每次调用
NewDecoder()有轻微开销，高频场景建议复用 decoder 实例（注意它不是并发安全的）
检测未知编码时别信 charset.DetermineEncoding
很多教程抄来就用 charset.DetermineEncoding，但它在中文文本上误判率极高——尤其当内容短于 1KB、含大量 ASCII 符号或无 BOM 时，常把 GBK 识别成 ISO-8859-1 或 Windows-1252。
真实使用场景中，更可靠的方式是「先验 + 回退」：
- HTTP 响应头带
Content-Type: text/html; charset=gbk→ 直接用charmap.GBK - 文件名含
_gbk.txt或路径含/cn/→ 主动指定编码 - 实在无法预知，先试 GBK，失败再试 Big5，最后 fallback 到 UTF-8；三者都失败才走
charset库（并设MinConfidence: 0.8） -
charset.DetermineEncoding返回的 confidence 值低于 0.6 就不该采信
strings.ToUpper 对中文、日文、韩文无效
标准库 strings.ToUpper 只处理 ASCII 字母（a–z），对汉字、平假名、谚文等完全无作用——这不是 bug，是设计使然。想让「ｈｅｌｌｏ」全角转半角、「αβγ」希腊字母转大写、「проверка」西里尔字母转大写，必须用 unicode 包或 golang.org/x/text/cases。
-
unicode.ToUpper(r rune)可逐字符处理，但需手动遍历[]rune，且对组合字符（如带音标的 é）可能不完整 - 推荐用
cases.Upper(language.Und)：它支持 Unicode 15.1 规则，自动处理德语 ß→SS、土耳其语 i→İ 等特殊 case - 注意：
cases包不处理编码转换，只做大小写映射；输入必须已是合法 UTF-8 字符串 - 繁体中文没有大小写概念，
ToUpper对「你好」返回原字符串，这是正确行为，不是失效
多语言文本分词前必须确保 UTF-8 正确性
像 gojieba、gse 这类中文分词库，底层依赖 utf8.DecodeRune 解析字符边界。如果输入是 GBK 字节却没转 UTF-8，分词器会把每个 GBK 双字节拆成两个非法 rune，导致切词错位、关键词漏匹配、甚至 panic。
- 不要在分词函数里做编码检测和转换——性能损耗大，且不同分词器对非法输入的容错策略不一致
- 统一在 I/O 层（如 HTTP handler、文件读取）完成解码，下游只接收
string或[]rune - 对用户上传的 CSV/Excel 文件，优先按
Content-Disposition或 BOM 判断编码，而非文件后缀 - 日语、韩语文本若含半宽片假名/平假名，也必须是 UTF-8；Shift-JIS 或 EUC-KR 输入会导致
len(str)与字符数严重不符
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
