go文件写入慢主因是缓冲配置不当、flush遗漏或并发误用；os.writefile仅适用于≤2mb小文件；bufio.writer需显式flush且建议调大缓冲区；高并发应避免共享writer，推荐channel序列化或独立文件句柄。
Go 文件写入速度慢，八成是缓冲没配对、Flush 没调对、或者并发写错文件句柄——不是代码写得不够“Go”，而是没踩中系统调用和内核行为的节奏。
os.WriteFile 为什么小文件快、大文件崩
os.WriteFile 看似一行搞定，但它内部会把整个数据切片拷贝进内存，再一次性 write 系统调用。对几 KB 的配置文件没问题；但写 100MB 日志时，它会分配等量内存、触发 GC、还可能被 OOM Killer 干掉。
- 只适合 ≤2MB 的一次性写入（如导出快照、生成 token 文件）
- 永远覆盖，不支持追加；路径不存在时直接报
open /path: no such file or directory，不是权限错 - 错误只返回一次，无法区分是磁盘满（
no space left on device）还是路径不可写（permission denied）
bufio.Writer 写入卡住？大概率忘了 Flush 或缓冲区太小
用 bufio.NewWriter 后写入飞快，但文件里空空如也？十有八九是漏了 Flush()。它不自动刷盘，也不在 defer f.Close() 里隐式触发——Close() 只关 fd，不管缓冲区。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须显式调用
wr.Flush()，且要检查返回值：if err := wr.Flush(); err != nil { /* handle */ } - 默认 4KB 缓冲区在高频小写入（如每条日志 50 字节）下，每 80 条就刷一次，毫无意义；建议设为
64 * 1024或256 * 1024 - 追加写必须用
os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_APPEND, 0644)；漏掉os.O_APPEND就是从头覆盖
高并发写同一个文件，加锁还不够
多个 goroutine 共享一个 bufio.Writer 并发 WriteString，即使加了 sync.Mutex，仍可能因缓冲区竞争导致数据错位或截断——bufio.Writer 本身不是 goroutine 安全的，且 os.O_APPEND 在高并发短内容下，内核 write 原子性边界与 Go 调度不一致。
- 正确做法：用 channel 序列化写入，或每个 goroutine 独立打开文件（用
os.O_APPEND）并复用bufio.Writer - 若必须共享 writer，需在
Write和Flush全流程加锁，不能只锁 Write - 更稳方案：用
sync.Pool复用bufio.Writer实例，配合wr.Reset(f)重绑定文件，避免反复 new
要不要用 syscall.Write 或 mmap 提速
除非你正在写高频打点服务（单进程每秒写 >5 万次、每次 ≤16 字节），否则别碰 syscall.Write。它绕过 Go runtime 的切片检查和缓冲封装，但：
- Windows 不可用（
syscall.Write是 Unix-only） - buf 生命周期必须严格管理，
unsafe操作一错就 crash - 无法和
bufio混用，也失去O_APPEND的内核原子保障 - mmap 更适合只读大文件随机访问；写入需额外
Msync，且跨平台兼容差
真正影响性能的，从来不是少一次函数调用，而是缓冲区大小是否匹配写入节奏、Flush 是否在数据安全与吞吐间取得平衡、以及并发模型是否和文件系统行为对齐——这些细节不测就看不出问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
