strings.TrimSpace处理单行后再写入是最直接可控的方式，它只裁剪首尾Unicode空白（含全角空格、不换行空格等），保留中间空格和换行结构，避免粘连或误删；bufio.Scanner不自动修剪，需显式调用。
写入前用 strings.TrimSpace 预处理每一行
最直接、最可控的方式，是在调用 WriteString 或 fmt.Fprintln 前，对每行内容手动裁剪。这能确保只影响目标行，不干扰换行逻辑或中间空格。
常见错误现象：直接对整段文本（含多行）调用 strings.TrimSpace，会把末尾的换行符也删掉，导致所有行粘连成一行。
- 只对单行内容裁剪：
strings.TrimSpace(line)，保留原始换行结构 - 若需保留行尾换行符，可先剥离再补上：
strings.TrimSpace(line) + "\n" - 注意全角空格（
\u3000）、不换行空格（\xa0）等也属于unicode.IsSpace范围，TrimSpace一并处理 - 不要用
strings.Trim(line, " \t\n\r")—— 它漏掉 Unicode 空格，且可能误删行首非空白字符（如"007"被Trim("0")变成"7"）
用 bufio.Scanner 读取时默认已去首尾空白？错，它不自动裁剪
bufio.Scanner 的默认行为是按行切分（\n 或 \r\n），但**不会自动修剪每行内容**。返回的 line 字符串仍包含该行内原有的首尾空白，比如 " data \n" 会被扫成 " data "（末尾换行已被去掉，但空格还在）。
所以不能依赖 Scanner “顺带”清理——必须显式调用 strings.TrimSpace。
立即学习“go语言免费学习笔记（深入）”；
- Scanner 的
Scan()返回的是不含换行符的原始行内容，空白照常保留 - 若用
Text()方法获取整行（含换行符），则需先strings.TrimSuffix(line, "\n")再TrimSpace，否则TrimSpace会把换行当空白删掉 - 对大文件逐行处理时，这个组合（
Scanner+TrimSpace）内存友好，无额外分配压力
想全局过滤写入流？别自己写 io.Writer 包装器
有人尝试封装一个带自动裁剪的 io.Writer，比如在 Write 里识别“行尾空白+换行”再替换。这种做法实际不可靠：
-
Write([]byte)接收的是字节流，无法保证每次调用都对应完整一行；可能半行就写入，导致裁剪逻辑失效 - 缓冲区边界与语义行边界不重合，容易把跨块的空白误判或漏判
- 性能开销隐蔽：每次写都要做字符串转换、
TrimSpace、再转回[]byte - 标准库没有类似设施，说明这不是 Go 推荐的抽象层级——裁剪是业务逻辑，不是 I/O 层责任
为什么不用正则或 strings.Map 清理所有空白？
因为需求明确是“尾部空白字符”，不是“所有空白”。过度清理会破坏格式：
-
strings.Map或regexp.ReplaceAllString会删掉行中缩进、对齐空格、制表符等有效空白 - 例如日志模板
"[INFO] user: alice"，尾部空白可能无关紧要，但中间四个空格是人为对齐，不该动 -
TrimSpace只动头尾，语义清晰、零副作用，且比正则快一个数量级以上 - 如果真要删“行尾连续空白+换行符组合”，可用
strings.TrimRightFunc(line, unicode.IsSpace)，但注意它比TrimSpace更激进（比如会删掉行尾的中文标点前空格）
strings.TrimSpace 处理单行后再写入，是最小侵入、最易验证、最不易出错的路径。别试图在 I/O 流层面“自动化”，那只会把简单问题变成状态机陷阱。 
