文件关闭

Go 的 File.Close() 返回错误时，不应把整次文件保存继续报告为成功。写入和关闭是不同操作，defer f.Close() 虽然安排了清理，却会丢弃关闭返回值。对于写文件函数，应显式接住这个错误，并与已有写入错误一起返回。

这里关注的是“文件操作什么时候才能向调用者报告成功”。不必为每个只读操作引入复杂框架，但导出、备份和其他重要输出至少应让调用方知道保存过程是否出现异常。

官方文档：https://pkg.go.dev/os

为什么写入成功还要看关闭结果

把保存过程分成三层更容易判断：应用写入、包装层刷新、底层文件关闭。没有缓冲包装时，主要检查 Write 和 Close；用了 bufio.Writer，还要检查 Flush。需要稳定存储承诺时，才另行设计 Sync 的处理。

关闭返回错误的具体原因取决于操作系统和文件类型，不宜只凭一个错误就断言“磁盘满了”。也可能是资源被重复关闭。关键是保留错误和阶段，再调查对应的调用与环境。

File.Close 调用后，文件不再用于 I/O；再次关闭会返回错误。不要把关闭失败理解为允许继续使用同一个 File，或者无条件重试 Close 就能修复问题。应由明确的资源拥有者完成一次关闭。

让关闭错误进入函数返回值

下面的函数使用命名返回值，让延迟执行的关闭操作能够补充最终错误。代码使用 Go 1.20 起提供的 errors.Join；示例未在本文制作过程中执行。

package exportfile

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

// Save 保存一个可重新生成的导出文件；不承诺原子替换或断电持久性。
func Save(path string, data []byte) (err error) {
    f, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0600)
    if err != nil {
        return fmt.Errorf("打开导出文件: %w", err)
    }
    defer func() {
        if closeErr := f.Close(); closeErr != nil {
            // 保留已有写入错误，并补充关闭错误，不相互覆盖。
            err = errors.Join(err, fmt.Errorf("关闭导出文件: %w", closeErr))
        }
    }()

    if _, writeErr := f.Write(data); writeErr != nil {
        return fmt.Errorf("写入导出文件: %w", writeErr)
    }
    return nil // 命名返回值仍可由上面的延迟函数补充关闭错误。
}

这里有三个结果：只有写入失败时保留 writeErr；只有关闭失败时返回 closeErr；两者都有时合并保留。调用者应先处理函数返回错误，再决定是否向用户展示“导出完成”。

errors.Join 会忽略 nil 参数，所有参数均为 nil 时返回 nil；合并错误仍可通过 errors.Is 和 errors.As 检查。官方说明：https://pkg.go.dev/errors。

不能在 defer 内简单写成 err = f.Close()：如果写入已经失败、关闭却成功，就会用 nil 覆盖原始错误。也不要为了接住关闭错误而在正常路径显式 Close、末尾又由 defer 关闭一次。

缓冲写入需要先处理 Flush

bufio.Writer 的 Write 可能只把数据接收到内存缓冲中。关闭它包装的 os.File，不会自动替 bufio.Writer 调用 Flush。以下函数沿用前例的 errors、fmt、os，并额外导入 bufio。

// SaveBuffered 与前例放在同一包；另外导入 bufio。
func SaveBuffered(path string, data []byte) (err error) {
    f, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0600)
    if err != nil {
        return fmt.Errorf("打开缓冲输出文件: %w", err)
    }
    defer func() {
        if closeErr := f.Close(); closeErr != nil {
            err = errors.Join(err, fmt.Errorf("关闭缓冲输出文件: %w", closeErr))
        }
    }()

    w := bufio.NewWriter(f)
    if _, writeErr := w.Write(data); writeErr != nil {
        return fmt.Errorf("写入缓冲区: %w", writeErr)
    }
    // 先检查缓冲层错误；关闭底层文件不会自动替它刷新。
    if flushErr := w.Flush(); flushErr != nil {
        return fmt.Errorf("刷新缓冲区: %w", flushErr)
    }
    return nil
}

Flush 的职责是把缓冲数据写给底层 Writer，它自身也会返回错误。前面的 defer 负责无论 Flush 是否成功都尝试关闭文件，但不会在返回错误后继续声称全部数据已保存。官方说明：https://pkg.go.dev/bufio。

对压缩器、编码器等其他包装对象，应按照其自身接口安排结束操作；不能把 bufio 的规则机械套到所有 Writer。

是否调用 Sync 取决于保存契约

File.Sync 用于把当前文件内容提交到稳定存储。它和关闭文件不是同一种承诺；若保存接口要求同步内容，可以在缓冲刷新成功后加入下面的错误处理，随后仍由 defer 检查 Close。

// 若业务要求同步文件内容，在 Flush 成功后、函数返回前加入此段。
// 这不是原子替换协议，也不承诺整个目录更新的崩溃一致性。
if syncErr := f.Sync(); syncErr != nil {
    return fmt.Errorf("同步文件内容: %w", syncErr)
}

不需要给每个可重建的临时文件都默认追加同步开销。应先区分临时输出、普通导出、重要持久化数据，再选择保存策略。Sync 成功也不能把前例变成完整事务：它直接截断目标文件，失败后可能留下不完整内容，更不等于提供原子替换和整个目录更新的崩溃一致性。

逐步改造现有文件操作

改造可以从最外层保存函数开始，不必一次重写所有调用。先明确谁拥有 File，再将错误加入返回值，最后更新上层的成功提示与重试策略。不要只在日志打印 closeErr，然后仍返回 nil。

读者可为封装后的写入接口准备可控的失败实现，分别覆盖写失败、刷新失败和关闭失败；对真实文件另行做正常路径测试。观察的是错误能否到达调用者、多个错误是否被保留、关闭是否只由一个拥有者安排，而不是虚构某个平台必然出现的错误文本。

常见问题

用了 defer 就不能处理关闭错误吗？

可以。延迟函数接住 Close 返回值，并通过命名返回值补充错误即可。

只读文件也要合并错误吗？

读取结果与关闭错误的业务权重可能不同，但应有明确政策。重要读取流程可保留关闭异常，不能把“只读”当作资源管理无需负责。

Close 成功是否证明数据已经持久化？

不能据此代替稳定存储契约。需要这种承诺时应设计并检查 Sync，以及实际文件系统要求的其他操作。