不能直接用 strings.ReplaceAll 处理大文件，因其需将整个文件加载到内存易触发 OOM；应采用 bufio.NewReader + 滑动窗口 buffer 边读边处理，配合 os.CreateTemp 原子写入临时文件再重命名。
为什么不能直接用 strings.ReplaceAll 处理大文件
因为整个文件读进内存会触发 OOM，尤其当文件超过几百 MB 时，strings.ReplaceAll 要求源字符串完整加载——这在流式场景下完全不可行。真实需求里，你面对的是日志、导出 CSV 或配置模板这类可能达 GB 级的文件，必须边读边处理。
关键不是“能不能替换”，而是“替换后如何不破坏原始文件结构（比如换行符、BOM、编码）”。常见踩坑：用 bufio.Scanner 默认按行扫描，遇到超长行直接 panic；或用 io.Copy + strings.Replacer，但无法处理跨块边界匹配（如搜索字符串被切在两个 buffer 中间）。
- 优先选
bufio.NewReader+ 手动 buffer 滑动，可控性强 - 若搜索词较短且不跨块，可用固定大小
make([]byte, 4096)循环读取 +bytes.Replace - 避免用
regexp在流中做全文匹配——回溯会导致 buffer 无限膨胀
如何安全地边读边写，避免覆盖原文件
直接打开同一文件进行读写是危险操作，Linux 下可能因 inode 复用导致内容错乱，Windows 下常报 text file busy。正确做法永远是“读原文件 → 写临时文件 → 原子替换”。
临时文件名必须带随机后缀（不能硬编码 .tmp），否则并发运行时会冲突。Go 标准库提供 os.CreateTemp，它保证文件名唯一且权限安全。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 用
os.Rename替代os.Copy+os.Remove：前者是原子操作，后者有窗口期导致文件丢失 - 写入前先
os.Chmod(tempFile.Name(), 0644)，避免因 umask 导致权限丢失 - 务必 defer
tempFile.Close()和os.Remove(tempFile.Name())（失败时清理）
处理多行匹配与边界情况的实际方案
纯流式替换无法天然支持“跨行正则”，比如想把 "foo\nbar" 替换成 "qux"。这时必须维护一个滑动窗口 buffer，长度至少为搜索字符串长度 + 1 行最大长度预估（例如 2048 字节）。
推荐用 bytes.Index 在窗口内找匹配，每次读新数据后把旧数据左移、新数据追加到末尾。不要试图用 bufio.Scanner 的 ScanLines 模式——它吃掉换行符，导致跨行逻辑失效。
- 窗口 buffer 初始大小设为
len(search) + 1024，动态扩容但上限设为 64KB 防止失控 - 每次
read后检查bytes.Index(window, search)，找到就写入替换结果 + 未匹配剩余部分 - 特别注意 EOF：最后一次 read 可能返回
n 但 <code>err == nil，需额外 flush window
编码与 BOM 必须显式处理
Go 的 os.File 默认二进制读写，不会自动识别 UTF-8 BOM。如果原文件开头有 0xEF 0xBB 0xBF，而你直接替换内容，BOM 可能被删掉或错位，导致后续程序解析失败。
解决方案不是引入第三方 encoding 包，而是手动检测和透传：
- 读取前 3 字节，比对是否等于
[]byte{0xEF, 0xBB, 0xBF} - 若存在 BOM，先写入目标文件，再从第 4 字节开始流式处理
- UTF-16/UTF-32 同理，但实际中极少遇到；若业务明确要求，才需引入
golang.org/x/text/encoding - 绝对不要用
strings.ToValidUTF8或类似转换——它会静默丢弃非法字节，破坏原始数据
真正麻烦的从来不是“怎么替换”，而是“替换后文件还能不能被下游系统正确读取”。BOM、换行符（\r\n vs \n）、空格缩进这些细节，在自动化脚本里最容易被忽略。
