go中string不可变是因为其底层指向只读内存，赋值仅复制header而非数据，故s[0]='h'编译报错；修改需转[]byte再转回，或用strings.builder，子串会阻止原字符串内存回收。
string 为什么不能直接改 s[0] = 'H'
因为 Go 的 string 底层是只读的 —— 它由一个 uintptr 指针（指向字节数组首地址）和一个 int 长度组成，而这个指针指向的内存区域在运行时被标记为只读（尤其对字面量、编译期构造的字符串）。尝试写入会触发 panic：invalid operation: cannot assign to s[0]（编译期报错），不是运行时崩溃，是语言强制约束。
- 这不是“没实现”，而是设计选择：保证并发安全、避免意外共享修改、简化 GC 判断
- 哪怕你用
unsafe.String或reflect.StringHeader强转，只要底层内存来自只读段（比如"hello"），写操作仍会 segfault 或被 runtime 拦截 - 真正能绕过只读限制的极少数场景（如 malloc 后手动构造
string），也极易引发未定义行为，生产环境绝对禁止
想改字符串内容，实际该怎么做
必须创建新字符串。没有“就地修改”路径，只有拷贝 + 构造。
- 单字符替换：用切片拼接，
newS := "H" + s[1:]；注意 UTF-8 下s[0]可能只是某个汉字的第一个字节，直接切可能破坏编码 - 批量修改（如转小写）：先转
[]byte，改完再转回string，例如b := []byte(s); bytes.ToLower(b); s = string(b)—— 这里发生了两次内存拷贝（string→[]byte和[]byte→string） - 需要频繁修改？别用
string当容器，换strings.Builder或bytes.Buffer累积，最后一次性builder.String()
string 和 []byte 转换为什么总被说“开销大”
因为每次转换都涉及内存分配与数据拷贝，不是“共享底层数组”的零成本操作。
-
[]byte(s)：从只读内存复制一份可写副本，长度多少拷多少字节 -
string(b)：同样复制b的当前内容到新分配的只读内存块 - 子串（如
s[2:5]）除外：它复用原string底层数组，不拷贝，但会阻止原字符串内存被 GC（“内存泄漏”常见源头） - 如果只是做查找、比较、切分，Go 运行时有优化，不一定真拷贝；但一旦你拿到
[]byte并写入，拷贝就逃不掉
什么时候会误以为 string 是“指针类型”
因为赋值快、看起来像引用传递，但其实它是值类型 —— 只是值里包含一个指针。
-
s1 := "hello"; s2 := s1：只复制了stringHeader{data: 0xabc, len: 5}这两个机器字，没动底层数组 - 所以
s1和s2共享同一片只读内存，这也是为什么它们能安全并发读 - 但这也意味着：哪怕你只取一个子串
s3 := s1[1:]，只要s3还活着，整个原始字符串占用的内存都释放不了 - 大字符串提取小片段后长期持有，是 GC 压力的隐形推手，比拼接更隐蔽
[]byte、用 Builder、避免长生命周期子串），都是在尊重这个契约的前提下找最稳的出口。最常被忽略的，其实是子串对 GC 的拖累 —— 它不报错、不慢、甚至测不出来，直到线上内存悄悄涨上去。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
