os File.Sync 什么时候值得调用

如果文件只是缓存、临时导出或可以重新生成，通常不值得每次写入后调用 os.File.Sync。如果文件承担配置、检查点、恢复标记这类“写完就要尽量留住”的职责，比较稳妥的边界是：先完成一批 Write，再显式调用一次 Sync，最后处理 Close 的返回值。

先分清 Write 成功与 Sync 成功

Go 官方对 File.Sync 的定义是：把当前文件内容提交到稳定存储，通常意味着将文件系统最近写入的内存副本刷新到磁盘。它解决的是“什么时候把当前内容推进到更可靠的存储层”，不是给每个 Write 自动加上的确认按钮。

需要这个边界时，可以把错误拆开写。这样日志里能区分写入失败、同步失败和关闭失败，而不是只看到一个模糊的“保存失败”。

package main

import (
    "fmt"
    "os"
)

func persistState(path string, data []byte) error {
    // 创建或截断状态文件，权限只给当前用户读写。
    f, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0o600)
    if err != nil {
        return fmt.Errorf("open state: %w", err)
    }

    // 写入错误表示本次内容没有完整交给文件对象。
    if _, err := f.Write(data); err != nil {
        _ = f.Close() // 写入错误优先，关闭错误不能覆盖它。
        return fmt.Errorf("write state: %w", err)
    }

    // 在恢复边界显式同步当前文件内容。
    if err := f.Sync(); err != nil {
        _ = f.Close() // 同步失败时仍然释放文件描述符。
        return fmt.Errorf("sync state: %w", err)
    }

    // Close 也可能返回错误，不能无条件丢弃。
    if err := f.Close(); err != nil {
        return fmt.Errorf("close state: %w", err)
    }
    return nil
}

哪些文件状态值得调用 Sync

判断标准不是“这个文件是不是重要”，而是“这次写入后，程序能不能接受状态回退”。下面的划分更适合做工程决策：

如果一轮操作会写入多段内容，先把这些内容写完，再在“状态可以被外部看到”的位置同步一次。把 Sync 放在循环里，往往只是把存储等待放大，并没有增加一个新的业务提交点。

控制 Sync 成本，并保留失败信号

Sync 不是免费的内存操作：底层文件系统、设备和挂载方式都会影响等待时间。高频小文件场景可以采用“内存中聚合一批内容—一次 Write—一次 Sync”的节奏，并避免在持有全局锁时长时间等待。

还要注意两个边界。第一，Sync 只针对当前打开文件的内容；如果流程还涉及换名字、替换目录项或多个文件之间的顺序，就不能用单次文件同步冒充完整的原子提交方案。第二，Close 不是 Sync 的替代写法：对有明确持久化要求的文件，先检查 Sync，再关闭文件，错误才有清晰归属。

常见问题

Write 返回 nil 后，数据是不是已经安全了？

不能这样推断。它只代表这次写调用没有返回错误；需要更强的稳定存储边界时，还要显式检查 Sync。

每次写一小段数据都要 Sync 吗？

通常不需要。把同步放在一批内容完成、状态正式提交的时刻，能减少额外等待；缓存和可重建文件甚至可以不调用。

Close 能代替 Sync 吗？

不要把两者当成同一个语义。需要明确持久化时先调用并检查 Sync，再调用并检查 Close，这样才能知道失败发生在哪个边界。

一句话判断：只有当“这次文件内容不能轻易回退”比一次同步等待更重要时，os.File.Sync 才值得调用。