strings.TrimSpace 不够用，因其仅去除首尾空白，无法压缩中间多余空白；应结合正则替换或双指针遍历实现语义级清洗，并注意 Unicode 空白与 BOM 处理、Scanner 行长限制及 strconv 安全解析。
为什么 strings.TrimSpace 不够用？
处理日志、csv 或用户输入时，strings.trimspace 只能去掉首尾空白，对中间的多余空格、制表符、换行符混杂场景完全失效。比如 "a\t b\n\n c" 经它处理后仍是 "a\t b\n\n c"，根本没“清洗”——真正要的是语义级规整：把所有空白序列压缩为单个空格，并剔除首尾。
实操建议：
- 用
regexp.MustCompile(`\s+`)替换连续空白为单个空格，再套一层strings.TrimSpace - 若性能敏感（如每秒处理百万行），避免正则，改用双指针遍历：逐字扫描，只保留首个空白字符，跳过后续连续空白
- 注意 Unicode 空白字符（如 、零宽空格）不被
\s匹配，需显式补充\u00A0|\u200B等
如何安全处理含 BOM 的 UTF-8 文本？
Windows 记事本或某些导出工具生成的 CSV/JSON 常带 UTF-8 BOM（\xEF\xBB\xBF），Go 的 bufio.Scanner 默认不识别，会导致首行解析失败或字段错位。
实操建议：
- 读取文件前先用
bytes.HasPrefix(data, []byte{0xEF, 0xBB, 0xBF})检测 BOM，存在则切片跳过前 3 字节 - 若用
os.Open+bufio.NewReader，可在读取第一块数据后手动剥离 BOM，再把剩余数据塞回bufio.Reader（用reader.Reset(bytes.TrimPrefix(buf, []byte{0xEF, 0xBB, 0xBF}))） - 别依赖
encoding/binary.Read自动跳过 BOM——它只处理固定长度头，不适用于流式文本
bufio.Scanner 扫描大文件时为什么 panic: "scan: too long"？
默认 bufio.Scanner 单行上限是 64KB，遇到未换行的超长日志行或拼接错误的 JSON，直接 panic，无法恢复。
立即学习“go语言免费学习笔记（深入）”；
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
实操建议：
- 调用
scanner.Split(bufio.ScanLines)前，先设缓冲区上限：scanner.Buffer(make([]byte, 64*1024), 10*1024*1024)（第二参数是最大 token 长度，设为 10MB） - 更稳妥的做法是弃用
Scan，改用bufio.Reader.ReadLine—— 它返回[]byte和isPrefix，可手动拼接跨缓冲区的长行 - 若清洗逻辑允许按块处理（如正则替换），直接用
io.Copy+bytes.ReplaceAll流式处理，绕过行概念
用 strconv 还是 fmt.Sscanf 解析数字字段？
清洗 CSV 时，常需把字符串字段转为 int64 或 float64。用 fmt.Sscanf 看似简洁，但会隐式跳过前后空白、接受十六进制前缀，还无法区分 "0" 和空字符串，易埋下数据歧义。
实操建议：
- 一律用
strconv.ParseInt(s, 10, 64)或strconv.ParseFloat(s, 64)，它们严格按十进制解析，空字符串或纯空白直接报strconv.ErrSyntax - 对可能含千分位逗号的字段（如
"1,234.56"），先用strings.ReplaceAll(s, ",", "")清理，再进strconv - 性能上，
strconv比fmt.Sscanf快 3–5 倍，且无格式字符串编译开销
真正卡住性能的往往不是算法，而是反复的内存分配：每次 strings.ReplaceAll 都产生新字符串，大文件下 GC 压力陡增。用 strings.Builder 预分配容量，或直接操作 []byte 原地清洗，才能稳住吞吐量。
