strings.Builder 和 bytes.Buffer 并发写必然出错，因其方法直接读写内部字段，导致竞态、数据覆盖或脏读；必须隔离写路径或改用无共享模型（如 chan + 单 goroutine）。
直接并发写同一 *strings.Builder 或 bytes.Buffer 必然出错，不是“要不要加锁”的问题，而是必须隔离写路径或改用无共享模型。
为什么 strings.Builder 和 bytes.Buffer 并发写会崩溃或丢数据
这两个类型本身**不声明任何并发安全保证**：strings.Builder 的 WriteString()、Grow()、Reset()，以及 bytes.Buffer 的 Write()、String()、Bytes() 等方法，都直接读写内部切片和长度字段。多个 goroutine 同时调用时，会出现：
- 竞态写
buf.len导致长度错乱（如len=5时两个 goroutine 都执行len++，结果变成 6 而非 7） - 写入位置重叠：goroutine A 正在拷贝字符串到
buf.buf[5:10]，B 同时往buf.buf[5:8]写，内容被覆盖 -
String()返回截断或脏数据（因底层[]byte正被其他 goroutine 修改） -
go run -race明确报出Read at 0x... by goroutine N和Write at 0x... by goroutine M
sync.Mutex 加锁的三个实际约束条件
加锁不是贴个 mu.Lock() 就完事。以下任一违反，就等于没锁：
- 锁变量必须是包级变量或结构体字段 —— 函数内
var mu sync.Mutex每次调用都新建一把锁，完全无效 - 所有写操作（包括
builder.WriteString()、builder.Reset()、buf.Write()、buf.String()）必须包裹在同一把锁下 - 锁内禁止做任何可能阻塞或 panic 的操作：比如
time.Now().Format()、json.Marshal()、http.Get()；否则会拖慢所有写请求，甚至导致死锁
正确示例：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
var buf bytes.Buffer
var bufMu sync.Mutex
<p>func appendLine(s string) {
bufMu.Lock()
defer bufMu.Unlock()
buf.WriteString(s)
buf.WriteByte('\n')
}
比 Mutex 更适合高频拼接的方案：chan + 单 goroutine 模式
当写请求密集（如日志行拼接、HTTP 响应体组装），Mutex 排队会成为瓶颈。此时应放弃“保护共享缓冲区”，转为“消除共享”：
- 用
chan string或chan []byte收集写入内容，由**唯一 goroutine** 顺序追加到本地bytes.Buffer或写入文件 - 该 goroutine 可自然批量处理、加
bufio.Writer、控制Flush()频率，还能统一加时间戳或序列号 - 发送方无需等待 I/O，只要 channel 不满即可快速返回；channel 缓冲设为 64 或 128，避免背压失控
- 注意：若需最终获取完整字符串，不能在发送后立刻调
buf.String()—— 必须通过响应 channel 或sync.WaitGroup等待写 goroutine 提交完成
容易被忽略的陷阱：Reset() 和 Bytes() 的并发风险
即使你只在锁里调 Write()，但若其他 goroutine 在锁外调 Reset() 或 Bytes()，依然会触发竞态：
-
Reset()会直接置b.len = 0，若此时另一个 goroutine 正在锁内执行b.Write()，就可能写到已被清零的底层数组中 -
Bytes()返回的是底层数组引用，若之后有 goroutine 修改该 buffer，原 slice 内容会静默变化 - 解决方案：要么把
Reset()和Bytes()也纳入锁保护；要么改用buf.Bytes()[:buf.Len()]复制一份再用；更推荐每次需要时新建bytes.Buffer实例（小对象 GC 压力极低）
