用 io.MultiWriter 可将数据同时写入目标和进度计数器避免修改数据源自定义 Write 方法原子累加字节数配合 Flush、context 控制超时与取消、分批事务、流式解析及节流回调实现高效可控的带进度导入。用 io.MultiWriter 把导入过程“镜像”到进度计数器Go 里没有内置的“带进度的 Reader”但你可以把原始数据流和进度统计逻辑耦合在同一个写入路径上。核心思路是不改数据源只在写入目标前加一层“透明代理”。io.MultiWriter 就是干这个的——它把一份数据同时发给多个 io.Writer比如一个存文件一个算字节数。常见错误是试图在 Read() 过程中手动累加结果发现 CSV 解析器、JSON 解码器这些库根本不走你重写的 Read()它们内部用 bufio.Reader 或直接 syscall你的钩子根本挂不上。把原始数据比如 *os.File 或 net/http.Response.Body先包装成 io.ReadCloser创建一个自定义的 io.Writer 类型只实现 Write(p []byte) (n int, err error)里面做原子计数atomic.AddUint64(progress.bytes, uint64(len(p)))用 io.MultiWriter 把这个计数器和真实目标如 *sql.Tx 的批量插入器、或 csv.NewWriter串起来注意如果目标 Writer 内部有 buffer比如 bufio.Writer要记得在关键节点调用 Flush()否则计数会滞后用 context.Context 控制超时与取消别等“卡住”的导入自己醒数据导入常卡在慢 SQL、网络抖动、大文件解压上。靠轮询 bytes 计数器判断“卡死”不可靠——可能只是当前 chunk 恰好小。真正该响应的是外部信号context.WithTimeout 或 context.WithCancel。容易踩的坑是把 context 只传给最外层函数但底层数据库驱动如 pgx或解析库如 gocsv没接收到。结果 cancel 了 context导入还在跑。立即学习“go语言免费学习笔记深入”所有涉及 I/O 的调用链从 http.Get 到 db.Exec都必须显式传入 ctx批量插入时别用单个大事务包全量按每 1000 行拆成子事务并在每个子事务开始前检查 ctx.Err() ! nil如果用 encoding/csv它的 Read() 不接受 context得自己套一层带超时的 io.LimitReader 或用 time.AfterFunc 配合 channel selectruntime.GC 和内存暴涨无关但 bufio.Scanner 默认 64KB 缓冲会吃掉大文件导入的性能导入大 CSV 或 JSONL 文件时程序 RSS 内存飙升第一反应常是“GC 没触发”其实 Go 的 GC 会自动工作。真正的问题常出在缓冲策略上默认的 bufio.Scanner 用 64KB 缓冲读行遇到超长行比如某字段含 base64 图片会自动扩容一次分配几 MB反复几次就 OOM。 文心快码 文心快码Comate是百度推出的一款AI辅助编程工具