Go 导出的 CSV 用 Excel 打开乱码怎么处理

Go 的 encoding/csv 能把一行记录正确写成 CSV，但不会替你添加 UTF-8 BOM。文件内容本身是 UTF-8，Excel 直接双击打开时却可能按本机默认编码猜测，于是中文变成乱码。最稳妥的导出方式是在创建 csv.Writer 前向文件写入一次 \xEF\xBB\xBF，再正常写记录、刷新缓冲并检查错误。

为什么 csv.Writer 导出的中文会乱码

这里有三个容易混在一起的层次：CSV 是字段和记录的组织格式，UTF-8 是文本字节编码，Excel 的直接打开动作还要猜测编码。Go 官方 encoding/csv 文档说明，Writer.Write 会写入一条记录并自动处理必要的引用，写入是带缓冲的；它没有承诺为文件添加 BOM。

所以先不要把乱码归因于逗号。可以用十六进制工具查看文件头：中文 CSV 若以 EF BB BF 开头，通常更适合让 Excel 直接识别 UTF-8；若没有这三个字节，文件仍然可以是合法 UTF-8，只是 Excel 的打开路径可能采用了错误的本地编码。字段被挤到一列，则应另外检查分隔符和地区设置。

在 Go 导出文件开头写入 UTF-8 BOM

关键顺序是“打开文件、写 BOM、创建 CSV writer”。BOM 是 UTF-8 的三个字节，不是业务字段，也不要在每个分片或每个批次前重复写。

package main

import (
    "encoding/csv"
    "fmt"
    "os"
)

func exportCSV(path string, rows [][]string) error {
    f, err := os.Create(path)
    if err != nil {
        return fmt.Errorf("创建 CSV 文件失败: %w", err)
    }
    defer f.Close() // 释放文件句柄，真正的写入错误仍由 Writer.Error 检查

    if _, err := f.Write([]byte{0xEF, 0xBB, 0xBF}); err != nil {
        return fmt.Errorf("写入 UTF-8 BOM 失败: %w", err)
    }

    w := csv.NewWriter(f)
    w.UseCRLF = true // Windows 表格软件常见的换行形式；它不改变字符编码
    for _, row := range rows {
        if err := w.Write(row); err != nil {
            return fmt.Errorf("写入 CSV 记录失败: %w", err)
        }
    }
    w.Flush() // Writer 内部有缓冲，必须显式刷新
    if err := w.Error(); err != nil {
        return fmt.Errorf("刷新 CSV 失败: %w", err)
    }
    return nil
}

func main() {
    rows := [][]string{
        {"姓名", "部门", "备注"},
        {"李明", "研发", "支持 UTF-8"},
    }
    if err := exportCSV("report.csv", rows); err != nil {
        fmt.Println(err)
    }
}

这段代码中，BOM 在第一条记录之前写入，因此不会被 csv.Writer 当作首列文字。Write 负责发现单条记录的问题，Flush 后再调用 Error 才能覆盖底层文件写入失败的情况。

补齐 Flush、Error 和换行设置

导出成功不能只看循环里的 Write 没报错。官方文档明确要求写完后调用 Flush，并通过 Error 检查此前的 Write 或 Flush 是否出现错误。若数据量很大，逐行写入仍然比把全部内容拼成一个字符串更容易控制内存，但 BOM 仍只写在整个文件的开头。

UseCRLF = true 可以让每条记录使用 \r\n，适合需要兼容 Windows 工具的场景，但它不会把 GBK 文件变成 UTF-8，也不会修复乱码。若下游系统严格要求无 BOM，就应导出无 BOM 的 UTF-8，并在导入端明确指定编码。

没有 BOM 时如何在 Excel 中打开

如果文件已经发布给用户，不能随意改变格式，可以在 Excel 中走“数据”导入路径，选择从文本或 CSV 导入，并把文件原点明确选为 UTF-8，再确认逗号为分隔符。这样解决的是 Excel 的识别方式，不会修改 Go 生成的原始文件。

交付前可做一个很小的检查清单：第一行是否从正确的首列标题开始；中文、英文和数字是否均正常；包含逗号的字段是否被双引号包住；打开后是否每条记录一行；大文件尾部是否完整。若只有第一列多出不可见字符，说明 BOM 被某个下游解析器当成普通文本，应在那个读取端去除 BOM，而不是在 Go 导出时重复添加。

Go 导出 CSV 用 Excel 打开常见问题

只加 BOM 就一定不会乱码吗？

不能绝对保证。BOM 能帮助 Excel 识别 UTF-8，但文件如果本来不是 UTF-8、内容已被错误转换，仍需从源字符串和写入链路排查。

BOM 应该写在 csv.Writer 创建之后吗？

不要依赖创建顺序之外的隐式行为。直接在文件开头先写三个字节，再创建 Writer，最清楚地保证 BOM 不会混进首个字段。

UseCRLF 能解决中文乱码吗？

不能。它只改变记录结束符；中文乱码看编码识别，数据挤列看分隔符和导入设置。

为什么 Write 成功但文件仍不完整？

csv.Writer 有内部缓冲，循环结束后必须调用 Flush，随后检查 Error，否则底层写入失败可能被遗漏。