strings.map 不能直接批量改大小写，而是按 rune 逐个映射；需自定义 func(rune) rune 实现 ascii-only 转换，避免 unicode.toupper 在 unicode 下的 locale 相关错误。
strings.Map 在 Go 里根本不能直接批量改大小写
它不是 strings.ToUpper 那种开箱即用的批量转换函数，而是按 rune 逐个映射——传入一个 func(rune) rune，返回新字符串。想全转大写？得自己写逻辑，而且要注意 Unicode 和 ASCII 的区别。
常见错误是直接传 unicode.ToUpper：结果可能出错，比如土耳其语的 'i'、德语的 'ß'，或者遇到组合字符（如带重音的字母）时行为不符合预期。
-
strings.Map不处理字符串上下文，不识别单词边界，也不支持 locale - 纯 ASCII 场景下可用
unicode.ToUpper，但必须先确认输入不含非 ASCII 字符 - 真正需要 locale 感知的大小写转换（比如 HTTP 头、用户显示名），该用
golang.org/x/text/cases
用 strings.Map 实现安全的 ASCII-only 大写转换
如果你确定输入只含英文、数字和 ASCII 符号（比如 HTTP 方法、枚举值、路径段），可以用 strings.Map + 自定义函数，比 strings.ToUpper 略快（无额外分配），但差别微乎其微。
关键点在于：别依赖 unicode.ToUpper 的全局行为，自己写分支判断更可控。
立即学习“go语言免费学习笔记（深入）”；
func asciiToUpper(r rune) rune {
if r >= 'a' && r <= 'z' {
return r - 'a' + 'A'
}
return r
}
s := strings.Map(asciiToUpper, "Hello-123!") // → "HELLO-123!"- 这个函数对非 ASCII 字符（如中文、é、α）原样保留，不会 panic 或乱码
- 比调用
unicode.ToUpper少一次类型断言和表查找，但实际性能差异在纳秒级，别过早优化 - 如果输入可能含 Unicode 字母（比如用户昵称），这个函数会漏转，此时必须换方案
strings.Map 的空 rune 处理很容易被忽略
当映射函数返回 0（即 rune(0)），strings.Map 会把这个位置的字符“删掉”，不是替换成空格或占位符。
这常被误用作过滤，比如想删掉所有数字：
strings.Map(func(r rune) rune {
if '0' <= r && r <= '9' { return 0 } // ← 这里是重点
return r
}, "abc123def") // → "abcdef"- 返回
0是唯一能删除字符的方式；返回' '或'_'都只是替换 - 别在映射函数里返回
nil或未初始化变量——Go 里rune是整型，没有 nil - 如果逻辑复杂（比如要跳过某类组合字符），务必测试
\u0301（重音符）这类零宽字符，它们单独 map 可能破坏渲染
替代方案：什么时候不该用 strings.Map
当你的需求超出单 rune 映射能力时，strings.Map 就是错的选择。典型场景包括：需要前后文判断（如首字母大写）、处理连字（fi → fi）、做 Unicode 正规化（NFC/NFD）、或转换涉及多 rune 的序列（如 emoji ZWJ 序列）。
- 首字母大写请用
strings.Title（注意已弃用）或cases.Title（推荐） - 大小写折叠用于比较（case-insensitive match）？该用
strings.EqualFold，不是 map - 要做 URL 安全编码、base64、HTML 转义？这些都有专用函数，
strings.Map无法保证正确性
最常被忽略的一点：strings.Map 返回新字符串，原字符串不变——但这不是坑，是 Go 字符串不可变的自然结果；真正容易错的是以为它能“就地修改”或复用底层内存，其实每次调用都 new 一个 []byte。
