Go os.File Sync 后数据为什么仍不可见

调用 os.File.Sync 后仍然读不到新数据，最常见的原因不是 Sync 失效，而是数据根本还停留在 bufio.Writer，或者读取端没有重新定位到文件的新内容。Sync 只负责把当前 *os.File 已经接收到的内容提交到稳定存储，它不会替你刷新上层缓冲，也不会向其他 goroutine 或进程发送“文件更新了”的通知。

官方文档入口：https://pkg.go.dev/os。排查时把链路拆成“写入缓冲、File、稳定存储、读取端”四层，通常很快就能找到数据消失在哪一层。

先分清 Sync 能保证什么

File.Sync 的文档语义是提交当前文件内容到稳定存储，通常意味着把文件系统的内存副本刷新到磁盘。它的输入是当前 *os.File 的状态，不是某个 bufio.Writer 或另一份已经打开的读取对象。

所以这段顺序有问题：

writer := bufio.NewWriter(file)
_, _ = writer.Write([]byte("ready\n")) // 数据可能还在用户态缓冲区
_ = file.Sync()                         // Sync 看不到尚未 Flush 的字节

这里即使 Sync 返回 nil，也只能说明当前 File 没有报告同步错误；它不能证明 writer 里的字节已经进入 File。另一个常见误解是把 Sync 当成消息通知：它不唤醒等待中的读取循环，也不让已有的 bufio.Reader 自动丢弃预读数据。

如果只是直接对 *os.File 调用 Write，就没有 bufio.Writer.Flush 这一层；但仍应检查返回的字节数和错误。写入、同步、读取是三个不同的结果，不能只看最后一个。

写入端按 Flush、Sync 顺序收口

使用缓冲写入时，推荐把每一层的失败都保留下来。下面的函数只负责把一段内容写入已经打开的文件；它不把“读者已经看到”冒充成写入函数的结果。

package main

import (
	"bufio"
	"fmt"
	"os"
)

func appendRecord(file *os.File, text string) error {
	writer := bufio.NewWriter(file)
	if _, err := writer.WriteString(text); err != nil {
		return fmt.Errorf("写入用户态缓冲失败: %w", err) // 先保留 Write 的错误
	}
	if err := writer.Flush(); err != nil {
		return fmt.Errorf("刷新到文件失败: %w", err) // Flush 才把缓冲交给 File
	}
	if err := file.Sync(); err != nil {
		return fmt.Errorf("同步文件失败: %w", err) // Sync 处理稳定存储边界
	}
	return nil
}

func writeOne(path string) error {
	file, err := os.OpenFile(path, os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0o644)
	if err != nil {
		return fmt.Errorf("打开文件失败: %w", err)
	}
	defer file.Close() // 关闭错误可在需要时单独记录
	return appendRecord(file, "ready\n")
}

这个顺序的关键不是“多调用一次 Sync”，而是先让 bufio.Writer 把数据交给 File，再让 File 处理稳定存储。生产代码还要根据业务决定是否把 Close 错误返回给调用方；不能用忽略错误的 defer file.Close() 掩盖最后一次写入或关闭失败。

读取端也要更新偏移和缓冲

写入成功不等于某个读取对象会自动出现在文件末尾。一个已经读到 EOF 的 *os.File 需要重新调用 Seek，而一个已经预读内容的 bufio.Reader 可能还保留旧缓冲。若读取逻辑要求“每次检查都看到最新文件”，可以在检查前重新打开文件，或明确管理同一个 File 的偏移和 Reader 生命周期。

func readLatest(path string) (string, error) {
	file, err := os.Open(path)
	if err != nil {
		return "", fmt.Errorf("打开最新文件失败: %w", err)
	}
	defer file.Close() // 让本次读取使用独立句柄

	data, err := io.ReadAll(file)
	if err != nil {
		return "", fmt.Errorf("读取文件失败: %w", err)
	}
	return string(data), nil
}

如果需要持续追踪追加内容，不要把“重新打开”当成所有场景的最佳方案，而应明确使用哪个 offset、是否允许复用 Reader，以及文件被截断或替换时如何重置状态。对单次读取而言，独立打开能减少旧偏移和旧预读造成的误判。

同时注意路径和句柄必须对应：写入临时文件后再替换路径时，旧读取句柄可能仍指向旧 inode；写入另一个路径、权限不足或打开标志不对，也会让排查误以为 Sync 没生效。

临时文件替换时，不要混淆可见性和持久化

配置文件常见的写法是“写临时文件、Flush、Sync、Rename”。这样做能把读者看到的内容切换为完整文件，但它解决的是替换的一致性边界，不是通知机制。需要让崩溃后的目录项也尽可能持久化时，还要按目标操作系统的约束处理目录同步；这和对普通文件调用 File.Sync 是两件事。

如果读者已经打开旧文件，Rename 不会把它的句柄神奇地改成新文件。读取方要重新打开路径，或者由上层明确完成句柄切换。若程序依赖文件变化触发 reload，还需要轮询、操作系统通知或应用层消息；Sync 本身没有这项职责。

为什么直接 Write 后还要检查 n？因为 io.Writer 的契约允许返回少于输入长度的字节数；即便某些普通文件场景通常一次写完，也不应把经验当成保证。

Sync 返回 nil 就能保证另一进程马上读到吗？不能。它表示同步调用没有报告错误，不代表读取进程已刷新缓存、重新打开文件或收到变化通知。

只加一个 time.Sleep 能解决吗？不能稳定解决。等待时间无法修复未 Flush、读取 offset 错误或旧句柄指向旧文件的问题。

把问题压缩成一句话：写入端先检查 Write、再 Flush、再 Sync；读取端重新打开或定位到正确位置；需要自动更新时另外设计通知；需要重启不丢数据时再单独处理文件和目录的崩溃持久化。这样就不会把 Sync 当成“让所有读者立刻看见”的万能开关。

参考：os.File.Sync、bufio.Writer.Flush、io.Writer。