在Go语言main函数中使用log.Fatalf是否合理？

测试代码 #

func main() {
    var builder strings.Builder
    keys := []int{1, 2, 3, 4}
    for _, key := range keys {
        // Add Iso3166 templates
        builder.WriteString(fmt.Sprintf("This is key %v", key)) // 原代码遗漏右括号，需修正
        builder.WriteString("\n\n")
    }

    file, err := os.Create(fileName)
    if err != nil {
        log.Fatalf("Failed to create file: %v", err)
    }
    defer file.Close()
    _, err = file.Write([]byte(standardBeginning))
    if err != nil {
        log.Fatalf("Failed to write iso3166: %v", err)
    }
}

IDE警告 #

log.Fatalf will exit, and defer file.Close() will not run

问题 #

这段代码可正常运行，但不确定当前场景下使用log.Fatalf是否合理，是否会出现文件未关闭的风险？有没有更优的错误处理方式？

解答 #

1. 文件未关闭的风险确实存在

log.Fatalf底层会打印日志后直接调用os.Exit(1)终止进程，而Go的defer语句仅在函数正常返回或panic被捕获时执行，遇到os.Exit会直接跳过所有未执行的defer。因此代码中defer file.Close()在log.Fatalf触发时不会运行，文件句柄无法主动释放。

虽然进程退出后操作系统会回收资源，短运行脚本不会造成严重问题，但这种写法不符合Go错误处理规范，若后续扩展为长运行程序，会引发文件句柄泄漏风险。

2. log.Fatalf的合理性判断

• 在简单一次性脚本的main函数中使用log.Fatalf是可接受的，脚本生命周期短，进程退出后资源会被回收。
• 但如果是可复用包或服务型程序，绝对不能用log.Fatalf——它会直接终止整个进程，导致其他goroutine无法正常清理，甚至引发数据丢失。

3. 更优的错误处理方式

推荐两种规范写法：

方式一：错误场景下手动关闭文件

在调用os.Exit前手动关闭文件，同时保留defer处理正常流程的关闭逻辑：

func main() {
    var builder strings.Builder
    keys := []int{1, 2, 3, 4}
    for _, key := range keys {
        builder.WriteString(fmt.Sprintf("This is key %v", key))
        builder.WriteString("\n\n")
    }

    file, err := os.Create(fileName)
    if err != nil {
        log.Printf("Failed to create file: %v", err)
        os.Exit(1)
    }
    defer file.Close()

    _, err = file.Write([]byte(standardBeginning))
    if err != nil {
        log.Printf("Failed to write iso3166: %v", err)
        // 手动关闭文件后再退出
        if closeErr := file.Close(); closeErr != nil {
            log.Printf("Failed to close file: %v", closeErr)
        }
        os.Exit(1)
    }

    // 补充原代码遗漏的builder内容写入逻辑
    _, err = file.WriteString(builder.String())
    if err != nil {
        log.Printf("Failed to write template content: %v", err)
        if closeErr := file.Close(); closeErr != nil {
            log.Printf("Failed to close file: %v", closeErr)
        }
        os.Exit(1)
    }
}

方式二：抽离逻辑为函数，通过错误链统一处理

将文件生成逻辑抽成独立函数，通过错误返回传递错误，在main中统一处理。这种方式下defer会在函数返回时正常执行，确保文件被关闭：

func generateFile() error {
    var builder strings.Builder
    keys := []int{1, 2, 3, 4}
    for _, key := range keys {
        builder.WriteString(fmt.Sprintf("This is key %v", key))
        builder.WriteString("\n\n")
    }

    file, err := os.Create(fileName)
    if err != nil {
        return fmt.Errorf("create file failed: %w", err)
    }
    defer file.Close()

    _, err = file.Write([]byte(standardBeginning))
    if err != nil {
        return fmt.Errorf("write header failed: %w", err)
    }

    _, err = file.WriteString(builder.String())
    if err != nil {
        return fmt.Errorf("write template content failed: %w", err)
    }

    return nil
}

func main() {
    if err := generateFile(); err != nil {
        log.Fatalf("File generation failed: %v", err)
    }
}

这种写法更符合Go的错误处理哲学，代码可读性和可维护性更强，也能保证文件始终被正确关闭。

内容的提问来源于stack exchange，提问作者Connor