go字符串只读操作并发安全，但转为[]byte后修改会引发数据竞争；因字符串不可变，多协程读取无问题，而append等操作作用于可变底层数组，需加锁或改用strings.builder保障安全。
Go 中字符串本身是并发安全的——只读没问题；但一旦涉及“修改”，实际操作的往往是底层 []byte 切片，这时候就极易触发数据竞争和内存异常。根本问题不在字符串，而在你是否在多协程中无保护地操作其底层数组。
为什么字符串读取安全，但拼接/修改不安全？
字符串在 Go 中是只读结构体，包含指针、长度，不可变。多个 goroutine 同时调用 len(s) 或遍历 s[i] 完全没问题。但只要出现以下任一行为，就脱离了“只读”范畴：
- 用
unsafe.String+unsafe.Slice转成可写切片后修改 - 通过
[]byte(s)转换并追加内容（如append([]byte(s), 'x')） - 把字符串转成
[]byte后传给其他函数，并在多协程中并发写入该切片
这些操作最终都落在底层数组上，而数组是可变的、共享的——append 可能重分配内存，多个 goroutine 同时写同一块地址，就会导致写覆盖、panic: "fatal error: concurrent map writes" 类似错误（虽然不是 map，但 runtime 检测到非法内存访问会直接崩溃）。
常见踩坑场景：append([]byte(s), ...) 在 goroutine 中乱用
典型错误写法：
var shared []byte
func add(s string) {
shared = append(shared, []byte(s)...)
}
如果多个 goroutine 并发调用 add，shared 的底层数组可能被多个协程同时写，或在扩容时被复制，旧指针失效。运行时开启 -race 会立刻报 Data race on slice backing array。
- 错误根源：把字符串转切片后，当作“可并发追加”的共享缓冲区用
- 真正安全的做法是：每次转换都新建切片，或用锁保护整个追加过程
- 更推荐：避免反复转换，改用
strings.Builder（它内部用锁保护，且专为并发拼接优化）
sync.Mutex 保护切片追加是最直接解法
如果你必须维护一个全局 []byte 或 string 构建结果，最稳妥的方式是显式加锁：
var (
mu sync.Mutex
result []byte
)
func appendString(s string) {
mu.Lock()
result = append(result, s...)
mu.Unlock()
}
- 锁粒度要准：只锁
append和赋值这一行，别把len(s)或日志也包进去 - 注意：不能只锁
append内部，因为result = ...这次赋值本身也是对变量的写，必须一起保护 - 性能敏感场景下，可考虑用
sync.Pool预分配切片，减少扩容次数，再配合锁
strings.Builder 是字符串拼接的并发友好替代品
它内部封装了 []byte 和锁，API 简洁且线程安全：
var builder strings.Builder
func appendString(s string) {
builder.WriteString(s) // 内部已加锁
}
// 最终用 builder.String() 获取结果
- 比手动管理
[]byte+sync.Mutex更少出错 - 底层仍会扩容，但所有操作都在锁内完成，不会出现指针悬空或写冲突
- 注意：不要在 goroutine 中复用同一个
strings.Builder实例而不加锁——它的 WriteString 方法是并发安全的，但如果你手动调builder.Reset()后又并发写，就破坏了契约
真正容易被忽略的是：你以为在操作“字符串”，其实 runtime 正在操作一片裸内存；并发安全与否，取决于你是否控制住了那片内存的读写权。别迷信类型名，盯住底层数据结构和谁在写它。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
