调用 os.OpenFile 获取 *os.File 后用 Write 或 WriteString，返回值 n 即实际写入字节数；n 可能小于预期，因 POSIX 仅保证至少写入 1 字节或返回错误，需同时检查 err 和 n。
写文件后怎么拿到写入的字节数和错误
Go 的 os.WriteFile 和 io.WriteString 这类封装函数不返回写入长度，只返回 error。如果需要确认实际写入了多少字节（比如校验、日志、断点续传），必须用底层接口——Write 方法。
典型场景：上传分片落盘后要记录本次写入量；日志写入时需判断是否截断；调试时怀疑写入被截断但没报错。
-
os.WriteFile是原子写入，内部先写临时文件再重命名，无法获取中间n - 用
os.OpenFile(..., os.O_CREATE|os.O_WRONLY|os.O_APPEND)获取*os.File，再调Write或WriteString -
Write返回(n int, err error)，n才是真实写入字节数，可能小于输入长度（尤其磁盘满、权限不足但未触发 error）
为什么 Write 返回的 n 有时比预期小
这不是 bug，而是 POSIX 层语义：Write 只保证「至少写入 1 字节或返回错误」，不保证一次写完全部数据。常见于管道、socket、某些文件系统挂载选项（如 noatime 影响缓存行为），但普通本地文件极少发生——除非磁盘空间不足或进程被信号中断。
- 检查
err == nil且n ：说明写入被截断，需重试或报 warn - 不要假设
os.File.Write等价于len(data)，尤其在容器环境或 NFS 挂载点 - 若需严格一次性写入，用
io.Copy+bytes.Reader或循环调Write直到n == len(data)
用 bufio.Writer 缓冲写入时如何获取最终写入量
bufio.Writer 的 Write 方法也返回 (n int, err error)，但它只反映写入缓冲区的字节数，不是刷盘量。真正落地的字节数只有在 Flush() 后才能通过底层 Write 获得——所以别在 Flush() 前看 n。
立即学习“go语言免费学习笔记（深入）”；
- 正确顺序：
w.Write(data)→w.Flush()→ 此时底层*os.File的写入才发生 - 想统计总写入量？自己累加每次
Write的n，再加Flush()可能触发的额外写入（通常为 0，除非缓冲区未满） - 更稳妥的做法：不用
bufio.Writer，直接用*os.File，避免缓冲层干扰计数逻辑
一个安全获取写入结果的最小可运行示例
下面这段代码处理了最常漏掉的边界：空字节切片写入、n < len(data) 未检查、Flush 忘记调用。
func writeFileWithCount(filename string, data []byte) (int, error) {
f, err := os.OpenFile(filename, os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
if err != nil {
return 0, err
}
defer f.Close()
n, err := f.Write(data)
if err != nil {
return n, err // 即使部分写入也要返回 n
}
if n < len(data) {
return n, fmt.Errorf("short write: expected %d, got %d", len(data), n)
}
return n, nil
}
注意：这个函数不处理 io.ErrShortWrite（标准库没导出该 error），所以用显式比较更可靠。实际项目中，如果允许部分写入，就别 panic，按业务逻辑决定是重试还是告警。
缓冲、原子性、权限、挂载选项——这些都会让「写入成功」变得不那么确定。别依赖函数名里的「Write」就以为数据已落盘，更别默认 n 一定等于 len(data)。
