go中传string不复制底层字节数据，仅复制16字节结构体（指针+长度），而[]byte虽同为轻量结构但含cap字段共24字节；字符串字面量共享只读内存，运行时拼接字符串则共享已分配的堆内存，真正导致额外堆分配的是goroutine内隐式转换[]byte(s)操作。
字符串参数在大规模协程启动时，**不会额外分配堆内存，但会复制 stringStruct 结构体（16 字节），且底层字节数据不复制**——前提是字符串来自字面量或已存在的只读内存；若字符串是运行时拼接生成的，则其底层 []byte 已在堆上分配，协程间仅共享指针。
为什么传 string 不等于传 []byte？
Go 中 string 是只读结构体：struct{str *byte; len int}，而 []byte 是可变结构体：struct{data *byte; len, cap int}。传 string 时只拷贝这两个字段（共 16 字节），传 []byte 时也只拷贝这三个字段（24 字节），都不触发底层数据复制。
常见误解是“传 string 会拷贝内容”，实际不会——哪怕你写 go f(s) 启动 10 万个协程，每个协程拿到的只是指向同一块内存的指针和长度。
- 字面量字符串（如
"hello"）存在只读段，所有协程共享 - 动态构造字符串（如
a + b）已在堆上分配，协程间仍共享底层[]byte - 唯一例外：用
unsafe.String或反射绕过安全机制时，才可能意外复制造成泄漏
逃逸分析如何影响 string 参数的分配位置？
编译器通过逃逸分析决定 string 的 header 是否分配在栈上。只要该 string 不逃逸出当前函数作用域，它的 stringStruct 就在栈上；一旦作为参数传给 goroutine，它就必然逃逸——因为 goroutine 可能比当前函数活得久。
这意味着：go worker(s) 中的 s 会被分配在堆上（存其 stringStruct），但**不是复制字符串内容，只是把 16 字节结构体挪到堆上**。
- 可通过
go build -gcflags="-m -l"查看是否逃逸，典型输出：... moved to heap: s - 逃逸的是结构体本身，不是
str指向的字节数据 - 即使逃逸，也不会增加底层字节内存压力，只多 16 字节/协程
大规模启动时真正吃内存的其实是 goroutine 栈，不是 string
每个新 goroutine 默认栈大小为 2KB（可增长至 1MB），而一个 string 参数只引入 16 字节堆开销。当启动 10 万协程时：
- goroutine 栈总开销 ≈ 100,000 × 2KB = ~200MB（未触发扩容时）
-
stringheader 堆开销 ≈ 100,000 × 16B = ~1.6MB - 若传的是
[]byte，header 开销为 24B/个 → ~2.4MB，差别微乎其微
所以优化重点不在 string 本身，而在控制协程数量、复用协程池、或用 runtime/debug.SetMaxStack 限制栈上限（谨慎使用）。
什么时候 string 参数会导致意外堆分配？
真正危险的不是传 string，而是**在 goroutine 内部对 string 做非只读操作并隐式转成 []byte**，比如：
go func(s string) {
b := []byte(s) // 这里才真正分配新内存！
b[0] = 'X' // 修改副本
}(s)
这个 []byte(s) 会分配等长的新底层数组，10 万次就是 10 万份重复内存。
- 避免在 hot path 协程里做
[]byte(s)，尤其当s较长时 - 若必须修改，考虑提前转换并复用
sync.Pool管理[]byte缓冲区 - 用
strings.Builder替代反复拼接，减少中间 string 分配
真正容易被忽略的，是把 string 当作“轻量值”传入协程后，在内部又不经意地转成可变切片——那一行 []byte(s) 才是内存暴增的开关，不是传参本身。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
