Go 的 os.File.Write 确实返回已写入字节数 n，它表示本次调用实际写入的字节数而非累计值；n < len(b) 是合法常见情况，必须校验以避免静默截断。
为什么 os.File.Write 不返回已写入字节数？
Go 的 Write 方法签名是 func (f *File) Write(b []byte) (n int, err error)，它确实返回了 n —— 但很多人误以为这个 n 是“累计进度”，其实它只是本次调用实际写入的字节数。操作系统可能因缓冲、磁盘满、权限等原因只写入部分数据，n < len(b) 是合法且常见的。不检查 n 就直接认为写完了，会导致静默截断。
用 io.Copy + 自定义 io.Writer 实时上报进度
最稳妥的方式不是轮询或猜，而是把进度逻辑嵌进写入流程本身。你可以包装一个带回调的 io.Writer，在每次 Write 被调用后触发进度通知：
type ProgressWriter struct {
w io.Writer
total int64
written int64
onWrite func(n int64)
}
<p>func (pw *ProgressWriter) Write(p []byte) (n int, err error) {
n, err = pw.w.Write(p)
if n > 0 {
pw.written += int64(n)
pw.onWrite(pw.written)
}
return
}使用时：io.Copy(<code>ProgressWriter{w: file, onWrite: logProgress}</code>, src)
- 适用于大文件流式写入（如下载保存、日志归档）
- 回调函数里可更新 UI 进度条、发 HTTP 事件、写入临时 .progress 文件
- 注意：如果
src是*bytes.Reader或内存切片，io.Copy可能一次就写完，回调只触发一次；真实场景建议搭配io.LimitReader或分块读取控制粒度
手动分块写入并累加计数比依赖 WriteAt 更可靠
WriteAt 看似能“跳着写”，但它不保证原子性，也不推进文件偏移量，且在某些文件系统（如 NFS）上行为不一致。真正可控的进度记录方式是自己管理块和偏移：
立即学习“go语言免费学习笔记（深入）”；
const chunkSize = 64 * 1024
buf := make([]byte, chunkSize)
for {
n, err := src.Read(buf)
if n > 0 {
written, err := file.Write(buf[:n])
totalWritten += int64(written)
log.Printf("written %d / %d bytes", totalWritten, expectedSize)
if err != nil || written != n {
// 必须处理 partial write！
break
}
}
if err == io.EOF {
break
}
}- 每次
Write后必须校验written == n，否则要重试或报错 - 不要用
file.Seek模拟进度 —— 它不反映磁盘落盘状态，仅影响下一次读写位置 - 如果目标是精确到百分比，
expectedSize需提前知道（如 HTTP Content-Length、os.Stat源文件大小）
注意 os.File 的缓冲与 Sync 对进度感知的影响
即使你累加了所有 Write 返回的字节数，这些数据可能还卡在内核页缓存里，没真正落盘。用户关机或断电时会丢数据，而你的“进度”却显示 100%。这时候：
- 调用
file.Sync()强制刷盘，但会显著拖慢速度 —— 别每写一块都 Sync - 更实用的做法是：每写入 1–5 MiB 同步一次，并在最后一次写完后调用
Sync() - 若需强一致性，考虑用
os.O_SYNC标志打开文件，但会全局降低吞吐，且某些 Linux 文件系统会忽略该标志 - 进度 UI 上建议区分“已写入内存”和“已落盘”，后者可通过同步成功回调更新
进度不是数字游戏，关键是让写入行为可观察、可中断、可恢复。别省略对 n 的校验，也别把 Seek 或 Stat 当作进度依据 —— 真实的进度只存在于你亲手累加的、经过 partial-write 校验的字节数里。
