字符串常量编译期固化于.rodata段且不可修改，运行期生成的字符串则在堆上分配并受gc管理；==比较基于内容而非指针，故相同内容的字符串恒等但指针通常不同。
字符串常量在编译期就固化在只读数据段
Go 的字符串常量（比如 "hello"、`\n\t`）在编译时被写入二进制文件的 .rodata 段，运行时直接映射为只读内存。这意味着：
– 地址固定，多次使用同一字面量通常共享同一底层 data 指针
– 无法修改，任何试图通过 unsafe 写入都会触发 SIGSEGV
– 不参与 GC，因为不分配在堆上
运行期生成字符串（如 fmt.Sprintf 或拼接）总在堆上分配
所有非字面量字符串都由运行时动态构造，底层调用 runtime.makeslice 分配字节空间，并复制内容。关键点：
– 即使内容和某常量完全相同（如 fmt.Sprintf("hello")），也不会复用常量地址，而是新建一块堆内存
– 受 GC 管理：一旦无引用，对应字节数组可能被回收
– string header 中的 data 指针指向堆地址，可通过 unsafe.String 观察到地址每次运行都不同
为什么 == 比较仍能高效成立？
Go 字符串比较不依赖指针相等，而是逐字节比对长度 + 数据（汇编中会先比长度，再用 SIMD 加速批量比对）。所以：
– 常量 "abc" 和运行期生成的 string([]byte{'a','b','c'}) 在 == 下为 true
– 但 reflect.ValueOf(s1).Pointer() == reflect.ValueOf(s2).Pointer() 几乎总是 false（除非巧合复用同一底层数组，比如切片转字符串且未发生扩容）
– 不要依赖指针相等做字符串判等，这是常见误用点
容易被忽略的逃逸与性能陷阱
看似简单的字符串操作可能隐式触发堆分配：
– s := "prefix" + localVar：只要 localVar 是变量，整个表达式逃逸到堆
– strconv.Itoa(n) 每次都新分配，高频调用建议缓存或改用 itoa 优化版
– 使用 strings.Builder 拼接多段时，若初始容量不足，仍会发生多次 realloc；建议用 builder.Grow(n) 预估大小
– fmt.Sprintf 解析格式串开销不小，纯字面量拼接优先用 +，而非 Sprintf("%s%s", a, b)
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
