strings.replaceall是go中简单字符替换的首选，语义清晰、性能优；换行符\r和\n需分别替换两次，顺序无关；strings.trimspace仅处理首尾空白，不作用于中间换行。
用 strings.ReplaceAll 最直接有效
Go 标准库的 strings.ReplaceAll 是处理这类简单字符替换的首选，它不依赖正则、无内存分配开销（底层复用原底层数组）、语义清晰。换行符 \n 和回车符 \r 是独立字符，需分别替换两次，不能靠一次调用搞定。
常见错误是只替换 \n，结果 Windows 风格的 \r\n 残留 \r；或误以为 strings.TrimSpace 能删中间的换行——它只清首尾空白。
- 先替换
\r为空字符串，再替换\n，顺序无关紧要 - 若源字符串极长且对性能敏感，可改用
strings.Builder手动遍历，但绝大多数场景没必要 - 注意：此方法不处理 Unicode 换行符（如
\u2028、\u2029），纯 ASCII 场景下足够
s := "hello\r\nworld\nfoo\rbar" s = strings.ReplaceAll(s, "\r", "") s = strings.ReplaceAll(s, "\n", "") // 结果: "helloworldfoobar"
用 strings.Map 一次性过滤更灵活
当需要同时剔除多种空白控制符（比如还要去掉制表符 \t 或垂直制表符 \v），strings.Map 更简洁，它把每个 rune 映射为新 rune 或 -1（表示删除）。
相比多次 ReplaceAll，它只遍历一次字符串，且逻辑集中。但要注意：它按 rune 处理，对 UTF-8 安全；而 ReplaceAll 按字节操作，遇到非法 UTF-8 序列时行为不同（不过正常 Go 字符串不会出现）。
- 返回
-1表示丢弃该字符，返回原rune表示保留 - 不能用于替换为多字符（比如把
\r\n替成空格），仅适用于“删或留”场景 - 如果后续可能扩展过滤规则（如跳过 BOM、零宽空格），这里加判断比链式
ReplaceAll更易维护
s := "line1\r\nline2\nline3\r"
clean := strings.Map(func(r rune) rune {
switch r {
case '\r', '\n':
return -1
}
return r
}, s)
// 结果: "line1line2line3"
警惕 strings.TrimSpace 的作用范围
strings.TrimSpace 只移除字符串**首尾**的 Unicode 空白字符（包括 \r、\n、\t、U+0085 等），对中间的换行完全无效。很多人看到函数名带 “trim”，就默认它能“清理全部”，结果调试半天才发现中间的 \n 还在。
- 它适合预处理用户输入的前后空行，不是通用去换行工具
- 若误用，测试用例用单行字符串会通过，一到含内部换行的真实数据就暴露问题
- 源码里明确写了 “leading and trailing”，文档没歧义，但名字确实容易误导
正则方案（regexp.ReplaceAllString）通常不必要
用 regexp 能一行写完：reg.ReplaceAllString(s, "")，模式可写成 `[\r\n]`。但它带来明显代价：编译正则、运行时状态机、额外内存分配。基准测试显示，对普通长度字符串，比 ReplaceAll 慢 3–5 倍。
- 仅当你已有正则对象复用，且同时要处理更复杂模式（如删换行但保留段落空行），才考虑
- 若用
MustCompile写死模式，注意它会在 init 阶段 panic，而非运行时报错 - 线上服务高频调用时，正则的 GC 压力比纯字符串操作高得多
strings.ReplaceAll 就够了。真正容易被忽略的是：换行符来源是否可靠？比如从 HTTP body 或文件读取时，是否可能混入 \r\r\n 或 UTF-16 BOM 后的换行？这时候得先 Normalize 编码，再清洗——但那已是另一层问题了。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
