strings.Map 通过返回 -1 删除字符，返回其他 rune（含 0）均会保留为对应字符；需覆盖 C0、DEL 及可选 C1 控制符；bytes.Map 删除用 0 但仅适用于 ASCII；for range 更安全通用。
strings.Map 的替换逻辑必须返回 rune，不能直接 return -1
很多人误以为 strings.Map 像 Python 的 filter 一样能“删掉”字符，其实它只是逐个映射：对每个 rune 调用传入的函数，若函数返回 -1，该字符才被跳过。但注意——返回 -1 是唯一表示“剔除”的方式，返回任何其他 rune（包括 0 或 '\0'）都会变成对应字符，不是空或忽略。
常见错误是写成：
strings.Map(func(r rune) rune {
if r <= 0x1F || r == 0x7F { // 错！这会把控制字符替换成 U+0000
return 0
}
return r
}, s)
结果字符串里冒出大量 \x00，甚至破坏二进制安全。正确做法只有两个分支：return -1（删）或 return r（留）。
控制字符范围要覆盖 C0、DEL 和部分 C1 区域
ASCII 控制字符是 U+0000 到 U+001F（C0），加上 U+007F（DEL）。但实际文本中还可能混入 C1 控制字符（U+0080–U+009F），比如 Windows 记事本保存为 ANSI 时插入的智能引号附带的 \x81、\x92 等。不处理它们，strings.Map 就会原样保留。
立即学习“go语言免费学习笔记（深入）”；
- 严格剔除所有控制字符（含 C1）：用
r <= 0x1F || r == 0x7F || (r >= 0x80 && r <= 0x9F) - 只剔除传统 ASCII 控制符（推荐默认）：用
r <= 0x1F || r == 0x7F - 额外排除回车换行：单独加
r == '\r' || r == '\n'，因为它们虽属控制符，但有时需显式强调
strings.Map 不修改原字符串，但要注意零值 rune 的陷阱
strings.Map 返回新字符串，原串不变——这点没问题。真正容易踩坑的是：如果映射函数里不小心对某个 rune 返回了 0（即 '\x00'），Go 会把它当做一个合法 Unicode 字符写入结果。而 \x00 在很多场景下是字符串终止符（如 C 互操作、某些协议解析），导致截断或解析失败。
所以务必检查所有分支：
cleaned := strings.Map(func(r rune) rune {
switch {
case r == '\r', r == '\n', r <= 0x1F, r == 0x7F:
return -1 // ✅ 正确剔除
default:
return r // ✅ 原样保留
}
}, s)
别漏掉 default 分支，也别在 case 里写 return 0。
性能与等价替代方案对比：strings.Map vs. bytes.Map vs. for-range
strings.Map 内部按 rune 迭代，自动处理 UTF-8 编码，安全但略慢；如果确定输入全是 ASCII（比如日志清洗），用 bytes.Map 更快，因为它按字节操作：
cleaned := string(bytes.Map(func(b byte) byte {
if b <= 0x1F || b == 0x7F || b == '\r' || b == '\n' {
return 0 // ⚠️ 注意：bytes.Map 用 0 表示删除，和 strings.Map 语义相反！
}
return b
}, []byte(s)))
但 bytes.Map 对多字节 UTF-8 字符（如中文）会拆开处理，导致乱码，所以仅限 ASCII 场景。更通用且可控的方式其实是手动 for range 构建 []rune，尤其当你需要组合多种过滤条件（比如同时剔除控制符、BOM、零宽空格）时，逻辑更清晰，调试也方便。
真正难的不是选哪个函数，而是想清楚：你面对的是纯 ASCII 日志？还是用户粘贴的富文本？后者哪怕只漏掉一个 U+200B（零宽空格），后续 JSON 解析或数据库入库都可能静默失败。
