file.write写入失败却无错误，因仅拷贝到内核缓冲区且err可能被忽略；必须显式检查err、调用flush()或sync()确保落盘，避免依赖defer close()，小数据应合并写或用bufio.writer优化。
File.Write 写入失败但没报错？检查 err 是否被忽略
Go 的 File.Write 不会自动 flush，也不保证写入完成就落盘——它只负责把字节拷贝到内核缓冲区。常见现象是程序退出后文件为空或内容不全，而 Write 返回的 n, err 中 err == nil，让人误以为成功。
- 必须显式检查
err：哪怕n等于你要写的字节数，err仍可能非 nil（比如磁盘满时部分写入后出错） - 写完务必调用
file.Close()或file.Sync()：前者隐式 flush + sync，后者仅确保数据落盘（不关闭文件） - 避免只依赖
defer file.Close()在函数末尾：若中间发生 panic 或提前 return，defer可能没执行
Write 传入 []byte 而不是 string？别用 string 直接转
File.Write 参数类型是 []byte，有人习惯写 f.Write([]byte(s))。这看似没问题，但每次都会分配新底层数组，对高频写入（如日志）有 GC 和内存压力。
- 如果
s是只读字符串且生命周期可控，可用unsafe.StringHeader零拷贝转换（需 Go 1.20+）：func stringToBytes(s string) []byte { return unsafe.Slice(unsafe.StringData(s), len(s)) } - 更安全通用的做法是复用
bytes.Buffer或预分配[]byte，尤其在循环中 - 注意：不能对转换后的
[]byte做 append 或修改原string，否则引发未定义行为
小数据反复 Write 效率低？合并写或换 bufio.Writer
直接对小块数据（如每行几十字节）频繁调用 File.Write，会触发大量系统调用，吞吐骤降。实测在 SSD 上，单次写 1KB 比 100 次写 10B 快 5–10 倍。
- 批量写：把多条记录拼成一个
[]byte一次性Write - 流式写：用
bufio.NewWriter(file)包装，写入走内存缓冲，最后Flush()；注意Flush()可能失败，必须检查其返回的err - 权衡点：
bufio.Writer默认缓冲 4KB，若写入总量远小于此，反而增加延迟；超大缓冲（如 1MB）则可能拖慢错误反馈（失败发生在 Flush 时）
Write 后文件大小没变？确认是否 truncate 或权限问题
写入后 os.Stat().Size 不变，常见于两种情况：打开文件时用了 os.O_APPEND 但没定位到末尾，或文件以 os.O_TRUNC 打开却没写入任何内容。
-
os.OpenFile默认不覆盖也不追加，必须显式传 flag：os.O_CREATE | os.O_WRONLY | os.O_APPEND才能追加；os.O_CREATE | os.O_WRONLY | os.O_TRUNC才会清空重写 - 写入前可用
file.Seek(0, io.SeekEnd)强制移到末尾，绕过O_APPEND的平台差异（Windows 下某些场景下不生效） - Linux/macOS 下检查文件权限和父目录写权限；Windows 下注意文件是否被其他进程独占打开（如 Excel 正在编辑该 CSV）
Write 成功 ≠ 数据落盘，Close 成功 ≠ 磁盘写入完成（ext4 默认是 write-back 缓存），真要强一致性，得配合 file.Sync() 和存储设备支持。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
