go中string不可修改，因其底层是只读字节序列，运行时禁止修改data指向的内存；所有“修改”实为新建string或先转[]byte再转回。
string 在 Go 里为什么改不了？
因为 string 底层是只读的字节序列（struct{ data *byte; len int }），且 Go 运行时禁止通过任何合法方式修改其 data 指向的内存。这不是语法限制，而是运行时保护——哪怕你用 unsafe 强转，也大概率触发 panic 或未定义行为。
常见错误现象：cannot assign to s[0]、cannot take address of s[0]；想用 s[i] = 'x' 直接改字符，编译直接报错。
- 字符串字面量（如
"hello"）存储在只读数据段，硬改会 segfault -
string和[]byte虽然底层结构相似，但语义隔离严格：不能隐式转换，也不能共享可写内存 - 所有“修改字符串”的操作，本质都是新建一个
string或先转[]byte再转回
想改字符串内容，实际怎么操作？
必须先转成 []byte，改完再转回 string。这是唯一安全、标准、可移植的做法。
使用场景：URL 解码后修正非法字符、日志脱敏、协议字段拼接等需要局部字节替换的场合。
立即学习“go语言免费学习笔记（深入）”；
- 转
[]byte是拷贝底层字节，不是共享内存：b := []byte(s) - 修改后转回
string会重新分配并拷贝：s = string(b) - 注意性能：短字符串开销小；长字符串（如 MB 级）反复转换会触发 GC 压力
- 别用
unsafe.String回填——它不检查*byte是否来自只读段，运行时可能崩溃
示例：
str := "hello" b := []byte(str) b[0] = 'H' // ✅ 改 byte 切片 str = string(b) // ✅ 新建 string
哪些“看似修改”其实是假象？
很多写法看起来像在改 string，其实只是变量重赋值或生成新值，原 string 始终没变。
常见错误认知：s += "x" 是在原地追加、strings.Replace 修改了原串、用 range 遍历时改 ch 就等于改了字符串。
-
s += "x"等价于s = s + "x"，每次生成新string，旧的被 GC -
strings.Replace、strings.ToUpper等函数全部返回新string，输入参数不可变 -
for i, ch := range s { s[i] = byte(ch) }编译不过——s[i]不可寻址 - 哪怕把
string赋给另一个变量，比如t := s，两者仍是独立值，改t不影响s
和 []byte 混用时最常踩的坑
开发者容易高估两者的互换成本，或误以为能绕过不可变性。
使用场景：处理二进制协议、解析文本帧、拼接大量字符串前做预处理。
- 从
[]byte转string是 O(1)（Go 1.22+ 对无逃逸小切片做了优化），但前提是该[]byte自身不逃逸、生命周期可控 - 反向转换
string→[]byte一定拷贝，无法避免——除非你明确用unsafe.Slice+unsafe.String，但这要求你完全掌控内存来源（比如自己 malloc 的 buffer），否则极危险 - 传参时别写
func f(s string) { b := []byte(s); /* ... */ }然后期望外部看到变化——函数内改b对调用方的s零影响 - 如果要高频读写，直接用
[]byte当主数据结构，最后一步才转string输出
不可变性不是障碍，是约束条件。真正麻烦的是忘了它存在，然后花半小时调试为什么 s 还是旧值。
