excelize/v2 是 Go 读写 Excel 最稳妥选择，纯 Go 实现、维护活跃、兼容 .xlsx；需用 /v2 安装，避免旧版；读公式需预计算，写大数据用 SetSheetRow；CSV 优先用 encoding/csv；中文乱码须设字体；大文件导入应先存临时文件再异步解析。
用 github.com/xuri/excelize/v2 读写 Excel 文件最稳妥
Go 原生不支持 Excel，必须依赖第三方库；excelize 是目前最成熟、维护活跃、兼容性最好的选择（支持 .xlsx，不支持旧版 .xls）。它底层不调用外部程序，纯 Go 实现，适合服务端批量导入导出。
常见错误是误用已归档的 tealeg/xlsx 或过时的 360entsecgroup-skylar/excelize（旧 v1 版本），导致无法读取新 Excel 格式或 panic 在 GetSheetMap 等函数上。
- 安装命令必须带
/v2：go get github.com/xuri/excelize/v2 - 读取时若文件含公式但未计算，
GetCellValue返回空字符串 —— 需提前在 Excel 中另存为“值”或用GetSheetRow+ 类型判断绕过 - 写入大量数据（>10 万行）时，避免逐单元格调用
SetCellValue，改用SetSheetRow批量写入切片，性能提升 5–8 倍
package main
import (
"fmt"
"github.com/xuri/excelize/v2"
)
func main() {
f := excelize.NewFile()
rows := [][]interface{}{
{"姓名", "年龄", "城市"},
{"张三", 28, "北京"},
{"李四", 32, "上海"},
}
f.SetSheetRow("Sheet1", "A1", &rows)
if err := f.SaveAs("output.xlsx"); err != nil {
fmt.Println(err)
}
}
CSV 导入导出优先用标准库 encoding/csv，别自己解析逗号
CSV 看似简单，但字段含换行符、双引号、逗号时极易出错。Go 标准库 encoding/csv 已正确处理 RFC 4180 规范，包括转义、引号包裹、多行字段等边界情况。
典型翻车点：用 strings.Split(line, ",") 解析 CSV，遇到 "Alice, Jr.",New York 就直接劈成三段，后续字段全部错位。
- 读 CSV 时，
csv.NewReader的FieldsPerRecord要设为 -1（允许每行字段数不同），否则含空字段的行会报record on line X: wrong number of fields - 写 CSV 时，
csv.Writer默认不加 BOM，若需 Excel 正确识别中文，得手动在写入前输出\uFEFF - 大文件（>100MB）导入建议配合
bufio.Scanner分块读，避免内存
爆掉
package main
import (
"encoding/csv"
"os"
)
func main() {
f, _ := os.Create("users.csv")
defer f.Close()
w := csv.NewWriter(f)
defer w.Flush()
// 写入带中文和逗号的字段，自动加引号
w.Write([]string{"张三", "北京,朝阳区", "研发部"})
w.Write([]string{"李四", "上海", "测试组"})
}
excelize 导出时中文乱码？检查字体设置和保存方式
导出 Excel 后用 WPS 或 LibreOffice 打开正常，但 Excel for Windows 显示方框 —— 这不是编码问题，而是字体缺失。Excel 默认用 Calibri，但该字体不包含中文字形，系统 fallback 失败就显示乱码。
不能靠改文件编码（.xlsx 是二进制格式，无 UTF-8/GBK 概念），必须显式设置中文字体。
- 全局设置：调用
f.SetFontFamily("Sheet1", "SimSun")（宋体）或"Microsoft YaHei"（微软雅黑） - 单元格级设置更灵活：
f.SetCellStyle("Sheet1", "A1", "A1", styleID)，其中styleID由f.NewStyle(&excelize.Style{Font: &excelize.Font{Family: "SimSun"}})创建 - 务必用
f.SaveAs()而非f.Write()—— 后者生成的文件缺少必要 ZIP 元数据，Excel 会提示“文件损坏”
导入失败卡在“read tcp: i/o timeout”？别让 HTTP handler 直接读文件
Web 服务中接收用户上传的 Excel/CSV 并解析，若在 HTTP handler 内直接调用 f.LoadFromStream 或 csv.NewReader(r.Body)，且文件超大或网络慢，就会触发上下文超时或连接中断，错误日志里只看到模糊的 I/O timeout。
根本原因：HTTP body 是流式读取，一旦解析逻辑耗时长，底层 TCP 连接可能被中间代理（Nginx、ALB）主动断开。
- 先将
r.Body完整拷贝到临时文件（io.Copy(tmpfile, r.Body)），再关掉 body，最后异步解析该文件 - 用
context.WithTimeout单独控制解析阶段，与 HTTP 超时解耦 - 对 >50MB 的上传，前端应加 ZIP 压缩，后端解压后再处理 —— Excel 的 .xlsx 本质就是 ZIP，二次压缩收益极低，但能规避 Nginx 默认 1MB 上传限制
