Go 文件写入后只 Close 不 Sync 是否可靠

如果“可靠”指正常运行时完成写入并释放文件，检查 Write 和 Close 的错误是基本要求；如果指系统崩溃或断电后仍希望保留数据，就不能把 Close 成功当成持久化确认。Go 的 File.Sync 用于把文件当前内容提交到稳定存储，Close 的主要职责则是关闭文件。

官方文档：https://pkg.go.dev/os#File.Sync。是否需要 Sync，取决于业务承诺的故障范围；它也不是适用于所有平台、文件系统和硬件的完整事务协议。

文件可读不等于崩溃后仍存在

把字节写入文件后立即重新读取，往往能看到刚写的内容。但这只能说明当前系统能读到数据，不能证明它已经离开易失性缓存。正常读取与崩溃恢复是不同问题。

旧写法常见的问题不是忘记调用 Close，而是只检查 Write，随后 defer f.Close() 并直接返回成功。这样既没有同步要求，也没有保留关闭阶段的错误。Linux close 手册明确说明：成功关闭不保证保存到磁盘，文件系统通常不会仅因关闭就刷新全部缓冲。说明地址：https://man7.org/linux/man-pages/man2/close.2.html。

这不意味着只 Close 就必然丢数据。系统可能稍后回写，也可能此前已经完成持久化；问题在于应用不能凭 Close 的成功返回作出这个承诺。

把 Flush、Sync 和 Close 分开理解

对于包着文件的 bufio.Writer，应先检查写入，再检查 Flush，然后调用文件 Sync，最后检查 Close。没有用户态缓冲时可以直接 Write 后 Sync。Sync 时文件必须仍然打开，所以“先 Close 再 Sync”不是合理收尾方式。

Flush 的官方定义见 https://pkg.go.dev/bufio#Writer.Flush。它的底层可以是文件，也可以是其他 Writer，不能把这个通用接口自动理解成磁盘。

给每个失败阶段保留返回错误

下面是独立示例，使用 Go 1.20 或更新版本，以便组合主错误与关闭错误。CreateTemp 创建新文件，不截断现有业务文件。示例故意保留文件供读者观察；它只演示文件层同步和错误传递，不提供新文件路径在崩溃后必然可恢复的完整协议。

package main

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

// 接管文件的关闭责任；调用方不要再重复 Close。
func writeAndSync(f *os.File, payload []byte) (err error) {
    defer func() {
        // 即使写入或同步失败也关闭一次，且不覆盖先前错误。
        if closeErr := f.Close(); closeErr != nil {
            err = errors.Join(err, fmt.Errorf("关闭文件: %w", closeErr))
        }
    }()

    writer := bufio.NewWriter(f)
    if _, err = writer.Write(payload); err != nil {
        return fmt.Errorf("写入缓冲: %w", err)
    }
    if err = writer.Flush(); err != nil {
        // 刷新失败时不把不完整内容当成成功提交。
        return fmt.Errorf("刷新缓冲: %w", err)
    }
    if err = f.Sync(); err != nil {
        return fmt.Errorf("同步文件: %w", err)
    }
    return nil
}

func main() {
    f, err := os.CreateTemp("", "sync-example-*.txt")
    if err != nil {
        fmt.Fprintln(os.Stderr, "创建示例文件:", err)
        os.Exit(1)
    }
    name := f.Name()

    // 此函数返回前已经处理 Close，因此成功消息不会早于关闭。
    if err := writeAndSync(f, []byte("同步职责示例\n")); err != nil {
        fmt.Fprintln(os.Stderr, "写入未确认:", name, err)
        os.Exit(1)
    }
    fmt.Println("写入、刷新、同步与关闭均未报告错误:", name)
}

保存成 main.go 后，可在示例目录运行：

# 只运行独立示例，不对现有业务文件做覆盖写入。
go run main.go

这里没有执行该代码，也没有进行断电测试。若出现成功消息，只代表各调用没有报告错误；不能把一次成功运行或重新读取当成硬件可靠性证明。失败消息保留阶段说明，便于判断错误发生在写入、刷新、同步还是关闭。

具名返回值使 defer 中发现的关闭错误能够进入最终结果。即便 Sync 成功，Close 失败仍会返回错误；如果同步和关闭都失败，两项信息都保留。不要因为关闭返回错误就盲目重复关闭，在 Linux 下重试关闭可能涉及已被复用的描述符。

Sync 也不是完整的事务提交协议

Go 提供可移植的 File.Sync 接口，但实际效果依赖操作系统、文件系统和存储设备的实现与承诺。Linux fsync 会等待设备报告传输完成；对于新建或重命名文件，文件自身的 fsync 不必然保证所在目录的相关条目已持久化，目录同步是另一件事。说明见 https://man7.org/linux/man-pages/man2/fsync.2.html。

因此，示例不是“安全替换配置文件”的完整实现。直接截断旧文件后写新内容，仍可能在同步之前留下部分数据；原子可见性、目录项持久性与文件内容持久性不能只靠一个 Sync 合并解决。这里不展开替换协议，也不把 Linux 的目录行为泛化成所有平台的统一规则。

同样，Sync 不会自动阻止其他 goroutine 或进程写入。示例的前提是此文件由当前代码独占写入；若有并发作者，需要另外决定写入协调和提交边界。

按数据代价选择同步位置

可重建的临时文件与已经对外承诺保存成功的关键数据，不能采用同一丢失容忍度。关键是定义何时回复成功、允许丢失多少数据，再决定逐条同步还是批量同步。批量处理减少同步次数的同时，扩大尚未同步的窗口；没有测量就不要给出固定吞吐提升数字。

迁移已有代码时，先处理被忽略的 Write、Flush、Sync、Close 错误，再明确成功确认位置。如果运行环境不支持所选对象的 Sync，应当返回或处理这个限制，不能静默降级后仍声称完成持久化。

使用 os.WriteFile 就不需要考虑同步了吗？

不要把便捷写入函数自动理解成一个持久化提交协议。需要显式 Sync 和阶段错误控制时，应管理文件句柄并在关闭前同步。

Sync 成功后还要 Close 吗？

需要。同步与资源释放是两个职责；没有继续使用文件的需求时，应关闭并处理返回错误。

Sync 失败是否说明一个字节都没写入？

不是。失败表示要求的同步结果未获得成功确认，不表示之前的写入没有发生。调用方应按未确认状态处理，不能据此假定文件完全未变，也不应无条件重写业务操作。