go字符串字面量固化在.rodata只读段，os级内存保护使其不可修改；相同字面量data指针相同，但==比较基于内容而非地址。
Go 字符串常量不分配在堆上，也不参与 GC，而是固化在二进制的 .rodata 段中——这意味着你无法修改它，不是语言限制，是操作系统直接拒绝写入。
字符串字面量地址为什么每次运行都一样？
因为 "hello" 这类字面量在编译时就被写死到可执行文件的 .rodata 节区，加载时被 mmap 为只读内存页，虚拟地址固定。多个地方引用同一字面量，reflect.StringHeader 中的 Data 字段通常指向同一地址。
- 可通过
unsafe.String+reflect.StringHeader观察到相同字面量的Data指针相等 - 但
==比较仍基于内容，不是靠指针，所以不要用reflect.ValueOf(s).Pointer()判等 - 若你在不同包里定义相同字面量（如
"config"），链接器可能合并，也可能不合并——取决于构建模式和符号可见性，不可依赖
为什么 unsafe 修改字符串字面量会 panic？
不是 Go runtime 主动拦截，而是 OS 层面的内存保护：尝试写 .rodata 页触发 SIGSEGV（Linux/macOS）或 ACCESS_VIOLATION（Windows）。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 典型错误代码：
s := "abc"; hdr := (*reflect.StringHeader)(unsafe.Pointer(&s)); b := (*[3]byte)(unsafe.Pointer(hdr.Data)); b[0] = 'x'→ 立即崩溃 - 即使调用
mprotect手动改页权限，也会破坏 runtime 对字符串只读性的假设，可能导致 GC 错误或并发读异常 - 真正能安全操作底层字节的，只有通过
[]byte构造的字符串（如string([]byte{'a','b','c'})），其底层数组在堆上，页属性可写
const s = "x" 和 var s = "x" 的内存行为差异
前者是编译期常量，不占运行时内存槽位；后者是变量，值仍来自 .rodata，但变量本身有可寻址栈/堆位置。
-
const s = "x"：不能取地址，&s编译报错cannot take the address of s -
var s = "x"：变量s是一个string类型值（16 字节结构体），其Data字段指向.rodata，但&s是合法的——你拿到的是结构体地址，不是底层字节数组地址 -
var s = "x"; b := []byte(s)：这次拷贝发生在堆上，b可修改，但原s不变
拼接字符串时如何避免意外逃逸到堆？
只要表达式含变量，哪怕只是 "prefix" + localVar，整个结果就逃逸到堆——因为编译器无法在编译期确定长度和内容。
-
fmt.Sprintf("%s%s", a, b)开销大：解析格式串 + 堆分配 + 多次拷贝；纯拼接优先用+ -
strings.Builder预分配很重要：b := strings.Builder{}; b.Grow(128)可避免扩容 realloc -
strconv.Itoa(n)每次都新分配；高频场景建议缓存常见数字字符串，或用itoa（标准库内部优化版）替代
真正容易被忽略的是：字符串“只读”仅约束合法 Go 代码行为；一旦用 unsafe 越界，就脱离了内存模型保证——崩溃是幸运的，静默数据损坏更危险。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
