strings.ToUpper/ToLower适用于95%场景，因按rune处理Unicode字符（如café→CAFÉ、ß→SS），中文等无大小写文字原样返回；需土耳其语等locale敏感转换时才须用golang.org/x/text/cases。
直接用 strings.ToUpper 和 strings.ToLower，95% 的场景够用；真要处理土耳其语、希腊语词形或 locale 敏感逻辑，才需要换 golang.org/x/text/cases。
为什么 strings.ToUpper 不是“简单 ASCII 转换”
它内部遍历的是 rune，不是 byte，所以能正确处理带重音的字符（如 "café" → "CAFÉ"）、德语 ß（→ "SS"）、希腊大写 Σ（→ "Σ"），甚至中文、日文这类无大小写概念的字符也会原样返回，不 panic、不静默损坏。
常见误判点：
- 看到
strings.ToLower("İ")还是"İ"，以为函数失效——其实是 Unicode “简单映射”规则下，土耳其语带点大写 I 没有标准小写形式 - 传入含非法 UTF-8 的字节流（比如从 GBK 文件强制转
string）——strings.ToUpper不校验编码合法性，会照常处理，但结果可能错乱 - 在循环里反复调用
strings.ToUpper(s)判断是否已全大写——应改用!strings.ContainsAny(s, "abcdefghijklmnopqrstuvwxyz")快速筛
bytes.ToLower 为什么不能替代 strings.ToLower
bytes.ToLower 只操作字节，不理解 UTF-8 编码。如果传入含中文、emoji 或任何非 ASCII 字符的字符串，它会把多字节 UTF-8 序列当作独立字节乱改，导致损坏或乱码。
立即学习“go语言免费学习笔记（深入）”；
例如：bytes.ToLower([]byte("Hello 世界")) 会破坏“世界”二字的 UTF-8 编码，输出不可预测的二进制垃圾。
仅适用于已知为纯 ASCII 的 []byte 场景（如 HTTP header 名、base64 数据）；切勿对从用户输入、文件读取或网络接收的字符串先 []byte(s) 再用 bytes.ToLower。
若必须操作字节切片且内容可能含 Unicode，请先转为 string，用 strings.ToLower，再转回 []byte。
什么时候必须用 golang.org/x/text/cases
当你的业务明确依赖语言环境规则时，比如：
- 土耳其语用户输入
"İSTANBUL"，期望转小写后是"istanbul"（注意：标准库返回"i̇stanbul"或仍为"İSTANBUL"） - 希腊语中，词尾大写
Σ需转为小写ς，而非通用的σ - 需要按特定语言做首字母大写（如德语名词首字母必须大写），且要求上下文感知
cases 包提供 cases.Upper、cases.Lower 等函数，需显式指定 language.Tag，例如：
import "golang.org/x/text/cases"
import "golang.org/x/text/language"
c := cases.Lower(language.Turkish)
result := c.String("İSTANBUL") // → "istanbul"
该包体积略大，仅在真有 locale 需求时引入；不要试图用 strings.Map + 自定义映射模拟——Unicode 大小写映射复杂，易漏边角 case。
真正容易被忽略的是：大小写转换不是纯文本操作，而是语义行为。同一个字符在不同语言规则下可能有完全不同的映射结果，而标准库只提供通用 Unicode 映射。如果你的系统面向多语言用户，尤其涉及姓名、地名、表单校验等场景，别只看“能跑通”，得确认映射是否符合目标语言的实际书写规范。
