go中String是值类型但底层只读，赋值复制header而非数据；不可变性由语言设计保证，转换为[]byte再转回会创建新字符串，拼接应避免+=以防o(n²)性能问题。
string 在 Go 中确实是值类型，但它的底层结构不全是值语义
Go 的 string 类型在赋值、传参时表现得像值类型：每次复制都生成新变量，修改一个不会影响另一个。但这只是表象——string 实际是只读的 header 结构（含指针和长度），指向底层只读字节数组。所以“值类型”不等于“完全在栈上复制全部数据”。
常见错误现象：str1 := "hello"; str2 := str1; str1 = "world" 后，str2 仍是 "hello"，看起来像深拷贝；但若误以为能通过反射或 unsafe 修改底层字节，就会触发 panic 或未定义行为。
- 使用场景：适合做 map key、函数参数、并发安全的共享只读数据
- 性能影响：小字符串复制开销小；大字符串（如几 MB 的 json）复制 header 很快，但底层数据仍共用——只是你无法改它
- 注意：不能用
unsafe.String或反射绕过不可变性来“修改”字符串，Go 1.20+ 对这类操作更严格，会直接 crash
为什么 string 不可变？不是语法限制，而是运行时保护
Go 没有禁止你写 str[0] = 'H' 这种语法，而是根本没提供这种索引赋值操作符——string 类型不支持 [] 写入，只支持读取（str[i] 返回 byte）。这是语言层面的设计选择，不是编译器偷懒。
容易踩的坑：有人试图用 []byte(str) 转换后修改，再转回 string，这看似“修改了字符串”，实则是创建了全新字符串。原 string 值没变，只是你换了引用。
立即学习“go语言免费学习笔记（深入）”；
- 转换示例：
b := []byte("abc"); b[0] = 'x'; s := string(b)→s是"xbc"，但原始字符串常量仍存在且不变 - 内存影响：每次
string(b)都分配新底层数组，频繁转换 + 大数据 = GC 压力 - 兼容性：该转换在所有 Go 版本中行为一致，但 Go 1.22 开始对
unsafe.String的使用加了更多 runtime 检查
拼接大量字符串时，别依赖 +=，哪怕它看起来像“修改”
+= 对 string 是语法糖，每次执行都等价于 s = s + t，即创建新字符串并复制全部内容。时间复杂度 O(n²)，不是 O(n)。
错误直觉：“我一直在改同一个变量名，应该复用了内存吧？”——不，变量名不变，但背后的数据块每次都在变。
- 正确做法：小量拼接（+ 无妨；中量（日志组装）用
strings.Builder；大量（模板渲染）考虑bytes.Buffer - 性能对比：10KB 字符串拼接 100 次，
+=可能分配数 MB 临时内存，strings.Builder控制在 ~100KB 内 - 注意：
strings.Builder.String()返回的是新字符串，builder 底层字节数组会被 reset，不共享
map[string]T 的 key 安全性，来自不可变性而非哈希稳定性
很多人以为 string 能当 map key 是因为它的 hash 值固定，其实核心原因是：只要它不可变，那从创建到被用作 key 的整个生命周期里，其内容、长度、底层数据都不会变——所以 hash 值天然稳定，无需 runtime 额外校验。
容易忽略的点：如果你把一个 string 作为 key 插入 map，然后用 unsafe 强行篡改其底层内存（极端情况），map 查找就会失效甚至 panic。这不是设计漏洞，而是你绕过了语言安全边界。
- 真实场景中，只要不用 unsafe / cgo 打破规则，
stringkey 就绝对可靠 - 对比
[]byte：不能当 map key，因为它是可变的；即使内容相同，两次[]byte{1,2}也是不同 key - 兼容性提示：Go 不保证不同版本间
string的内部 layout，所以不要用unsafe.Sizeof算偏移去解析它
事情说清了就结束。真正难的不是记住“string 不可变”，而是写代码时下意识避开那些假装在修改它的惯性操作——比如反复 +=、用 reflect 尝试写入、或者以为 string(b) 是零拷贝转换。