go中string赋值不拷贝底层数组，因其是只读视图结构体，仅复制data指针和len字段（共16字节），实现o(1)赋值并允许多string安全共享同一块只读内存。
string 赋值为什么不拷贝底层数组
因为 Go 的 string 是只读结构体，不是数据容器，而是轻量级视图：它只存 data（uintptr 指针）和 len（int），共 16 字节（64 位系统）。赋值如 s2 := s1 仅复制这两个字段，底层字节数组地址不变。
这带来两个关键效果：一是极快（O(1)），二是多个 string 可安全共享同一块只读内存——比如字面量 "hello" 在编译期被放进 .rodata 段，所有引用它的变量都指向同一地址。
- 子串
s[2:4]同样只改data偏移和len，不分配新内存 - 但这也意味着：只要子串还活着，原始大字符串的整块底层数组就无法被 GC 回收
- 动态拼接（如
a + b）或fmt.Sprintf生成的字符串，不会进只读段，而是堆上新分配，不参与共享
为什么 string(b) 必须深拷贝，不能复用 []byte 底层
因为 string 指向只读内存，[]byte 是可写切片；若允许二者共享，写 b[0] = 'x' 就会篡改字符串字面量，破坏整个进程稳定性。Go 运行时强制隔离——string(b) 总是分配新只读内存并拷贝内容，哪怕 b 本身没被修改过。
- Go 1.20+ 更进一步：禁止任何 unsafe 方式绕过该检查，
unsafe.StringHeader强转会直接 panic - 唯一合法零拷贝共享路径是反向：用
unsafe.String(b[:n], n)从[]byte构造只读字符串视图 - 此时
unsafe.String返回的string和b共享底层数组，但你必须确保b生命周期 ≥ 字符串生命周期，否则访问已释放内存
尝试修改 string[0] 会怎样
编译期直接报错：cannot assign to s[0]。这不是运行时限制，而是语言规范硬性约束——Go 不提供“就地修改”语法糖，因为底层内存页被 mmap 为 PROT_READ，写入会触发 segfault。
- 用
unsafe或reflect强转后写入，大概率 panic 或崩溃，尤其对字面量 - 想改内容，只能走标准路径：转
[]byte→ 修改 → 转回string（两次拷贝） - 高频修改场景别用
string当缓冲区，改用strings.Builder或bytes.Buffer，最后调builder.String()
如何验证两个 string 是否共享底层内存
不能靠 ==（比内容）或 &s1 == &s2（比变量地址），得看它们的 data 指针是否相同。可用 reflect.StringHeader 提取，但这是内部实现细节，仅限调试，生产环境禁用。
- 示例：
h := (*reflect.StringHeader)(unsafe.Pointer(&s)); fmt.Printf("%p", h.Data) - 相同字面量（如
"abc"和"abc"）输出地址一致；动态构造（如strings.Repeat("a", 3)）每次地址不同 - 注意：Go 1.21+ 对
unsafe操作更敏感，开启-gcflags="-d=unsafe-mem"会提前拦截非法转换
真正需要零拷贝共享时，只信任 unsafe.String；其余所有转换都默认带拷贝，这是 Go 用确定性开销换内存安全的设计选择。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
