go字符串底层是值类型stringheader结构体，含data指针和len字段，赋值仅复制头信息不拷贝底层数组；其data指向只读内存，故直接修改会panic，转换为[]byte需拷贝数组，子串复用底层数组可能阻碍gc。
Go 字符串底层是 stringHeader 结构体，不是裸指针
Go 的 string 类型在运行时由两个字段组成：一个指向底层字节数组的 data 指针，和一个记录长度的 len 字段。它被定义为 stringHeader（非导出），但你可以用 unsafe.StringHeader 观察——注意：这不是稳定 API，仅用于理解。
常见错误是认为 string 本身是个指针，于是尝试直接取地址或做指针运算。其实它是个值类型，每次赋值都复制这两个字段（8 或 16 字节），不拷贝底层数组。
-
len(s)返回的是stringHeader.len，不是内存大小，也不含结束符 - 底层数组不可写：
string的data指针指向的是只读内存页（在某些运行时配置下） - 字符串拼接（如
s1 + s2）会分配新底层数组，旧数组若无其他引用会被 GC 回收
为什么修改字符串内容会 panic：无法绕过只读约束
试图通过 unsafe 把 string 转成 []byte 并修改，大概率触发 fatal error: unexpected signal 或静默失败（取决于 Go 版本和内存映射策略）。根本原因不是语法禁止，而是底层字节数组通常位于只读内存段。
典型错误场景：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
(*[len]byte)(unsafe.Pointer(&s[0]))强转后写入 —— 在 Go 1.21+ 大概率 segfault - 把
string转[]byte后改内容，再转回string—— 新字符串和原字符串无关，原串仍不变 - 误以为
string和 C 的char*等价，直接传给需要可写缓冲区的 C 函数
正确做法：需要可变文本，就用 []byte；要传给 C，用 C.CString 或显式分配可写内存。
string 和 []byte 转换开销在哪
转换本身只是复制 stringHeader 或切片头（sliceHeader），几乎零成本；真正开销在于底层数组是否被复用。
-
[]byte(s)：必须拷贝整个底层数组（因为目标可写，不能共享只读内存）→ 时间 O(n)，空间 O(n) -
string(b)：不拷贝，直接用b的data指针和len构造新string→ 时间 O(1)，但该string生命周期受限于b的生命周期（若b被 GC 或重用，string可能读到脏数据） - 从
string构造子串（如s[2:5]）：复用原底层数组，只改data偏移和len→ 零拷贝，但可能阻止原大字符串被 GC（“内存泄漏”假象）
什么时候真的需要关心底层结构
绝大多数业务代码完全不需要碰 unsafe 或内存布局。真要介入，通常只出现在这几个窄场景：
- 高性能序列化/反序列化中避免重复拷贝（如解析 HTTP header 时直接切
string而不转[]byte） - 与 C 交互时需构造临时可写缓冲（必须用
C.CBytes或make([]byte, len)显式分配） - 调试内存占用时发现大量小字符串未释放——其实是子串持有了大底层数组的引用，得用
string(bytes.Clone(b))（Go 1.20+）或手动拷贝截断
别为了“理解底层”而强行用 unsafe；Go 的字符串设计就是让你忘掉指针——除非你卡在纳秒级优化或跨语言边界上，否则它的不可变性就是最安全的默认值。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
