go字符串只读是语言设计契约、编译器强制与底层结构限制共同作用的结果：底层为16字节（指针+长度），字面量存.rodata只读段，运行时构造字符串依赖编译器禁止写入，转换[]byte必拷贝，并发读天然安全。
Go语言中字符串是只读的，根本原因不是运行时加锁或内存保护机制，而是语言层设计契约 + 编译器强制约束 + 底层结构限制三者共同作用的结果。你无法用 s[0] = 'x' 修改，不是因为“还没实现”，而是编译器直接拒绝生成这种指令。
string底层结构只有data *byte和len int两个字段
每个 string 值在内存里就是 16 字节（64 位系统）：一个指针 + 一个整数。它不持有数据，只持有一个地址和长度。比如 s := "hello"，s.data 指向的是二进制文件里的 .rodata 段，操作系统映射为只读页。
- 赋值
s2 := s1只复制这 16 字节，不碰底层数组 - 切片
s[1:3]也是新 struct，data指针偏移，但可能仍指向同一块内存 - 你无法通过任何合法 Go 语法写入
s[0]—— 编译器报cannot assign to s[0]，不是运行时报错
字符串字面量默认分配到.rodata只读段
源码里写的 "abc" 这类常量，在编译后被放进只读数据段。进程加载时，这段内存被 mmap 为 PROT_READ，写操作会触发 SIGSEGV。
- 用
unsafe强取StringHeader并改内存，大概率 panic，不是 Go 主动阻止，而是 OS 级保护 - 但注意：
string([]byte{'a','b','c'})构造的字符串，底层字节数组通常在堆上，页属性可读写 —— 此时“只读”纯属语言约定，靠编译器禁止访问来维持 - 也就是说：只读性对字面量是硬保障，对运行时构造的字符串是软契约
[]byte(s) 和 string(b) 必然发生内存拷贝
因为 string 和 []byte 内存布局不兼容：string 没有 cap 字段，而 []byte 有；且前者语义只读，后者可写。Go 必须做深拷贝，否则就可能让你意外改写只读字面量。
-
b := []byte(s)→ 新分配堆内存，把s的字节拷过去，b可写，s不受影响 -
s2 := string(b)→ 再拷一次，生成新的只读字节数组 - 没有“共享视图”这种事；所谓“零拷贝转换”仅存在于某些编译器内部优化（如短字符串小切片），不可依赖
- 频繁修改字符串时，应优先用
strings.Builder，避免反复分配和拷贝
并发读安全不是靠锁，而是靠不可变语义
多个 goroutine 同时读同一个 string 变量完全安全，根本不需要 sync.RWMutex。
- 因为所有传参、赋值、返回，都只是复制那个 16 字节的 struct，各副本彼此独立
- 底层数组永远不会被任何合法 Go 代码修改 —— 即使多个
string共享同一块内存，那块内存本身也不变 - 真正容易被忽略的是：所谓“只读”只约束
string类型行为；一旦用unsafe或反射绕过类型系统，就脱离了 Go 内存模型保证，结果不可预测
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
