Go多线程写CSV时突发short write写入错误的解决方法

所有异常现象都源于未对共享的csv.Writer实例做并发互斥控制，不存在无征兆的随机bug，你跑了数百条记录没出错只是并发冲突的触发概率问题，撞上一次就会出现持续性故障。
具体对应你观察到的现象拆解：

• 看到的“重复写入、内容截断”不是真的重复写了同一条记录，是并发交叉写入内存缓冲后的错位残片：两个goroutine同时调用Write方法时，会共享Writer内部的内存缓冲，写入指针会被交叉抢占，最后拼接出来的CSV行是被冲掉前半段、错位拼接的残段，就出现了你看到的ssage2,207这类内容，看起来像重复行，实际是并发覆写的结果。
• 触发的short write本质是并发修改了Writer的内部状态：csv.Writer不是无状态的写入通道，它在拼接CSV格式时，会在内部维护待写入行的长度、转义偏移量、缓冲指针这些状态。并发调用时两个goroutine会同时修改这些状态值，导致最后计算出来的待写入长度和缓冲内实际的内容长度不匹配，触发底层bufio包的短写入校验错误。
• 一旦报错就持续无法恢复，是因为csv.Writer没有设计可恢复的错误模式：内部状态和实际缓冲一旦被并发打乱，后续不管再调用多少次Write、Flush，状态计算永远和实际内容错位，每次写入都会触发相同的错误，只有重启程序重建Writer实例，才能让状态回到正常水平。

你提到的“写入入口仅触发一次、不存在多入口调用”的判断不成立：只要你的写入逻辑被多个业务goroutine异步触发，哪怕所有调用都走同一个函数入口，没有互斥锁的情况下就是并发访问共享资源，和代码里有几个写入入口没有关系。

• 给所有Writer操作加全局互斥锁，强制串行执行写入流程：
  锁的范围必须完整覆盖Write和Flush两个操作，不能只锁Write环节，否则两个goroutine会在一个写完还没Flush的间隙，抢占进入打乱缓冲。参考修正后的代码：

  // 初始化阶段定义全局锁
  var csvWriteLock sync.Mutex
  
  // 替换原有写入逻辑
  output := []string{time.Message, strconv.FormatInt(time.Duration, 10)}
  csvWriteLock.Lock()
  err := writer.Write(output)
  if err != nil {
      fmt.Println("An error encountered ::", err)
      fmt.Println("writer.Write error")
      logMessage(err.Error())
  }
  flushErr := writer.Flush()
  if flushErr != nil {
      logMessage(flushErr.Error())
  }
  csvWriteLock.Unlock()
  

• 不要忽略返回的错误：csv.Writer的Flush方法本身也会返回写入错误，之前的代码只捕获了Write的错误，没有校验Flush的返回值，会遗漏很多缓冲层面的写入异常。
• 遇到写入错误后不要继续持有当前Writer实例：一旦拿到错误，说明当前Writer的内部状态已经损坏，要重新初始化Writer、绑定文件句柄，不能继续用损坏的实例写后续内容，否则会持续触发同类错误。

*注意：Go标准库的csv.Writer本身不是并发安全的，官方没有设计内部锁逻辑，所有并发场景下的使用，必须由调用方自行保证串行化访问。

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