Go中无法通过指针修改常量，根本原因是OS内存保护机制将只读数据段（如.rodata）设为PROT_READ，写操作触发SIGSEGV；const是编译期概念，不占运行时内存槽位，真正可修改的是var声明的变量。
Go 语言中无法通过指针修改常量 —— 不是语法限制，而是底层内存保护机制在起作用。
为什么 &constValue 能编译通过，但修改会崩溃或无效？
Go 允许对具名常量（如 const x = 42）取地址，仅当它被“隐式转换为变量”时才可能成功。实际上，绝大多数常量（尤其是未赋值给变量的字面量）根本不会分配可寻址的内存地址；而一旦你写成 const x = 42; p := &x，编译器通常会拒绝：因为 x 是不可寻址的。真正能取地址的，往往是那些“看起来像常量但实为字面量变量”的情况，比如函数内临时初始化的 var y = 42（非 const）。如果你绕过编译器检查（例如用 unsafe 强转），运行时大概率触发 signal SIGSEGV: segmentation violation —— 因为 Go 运行时把某些只读数据段（如字符串字面量、全局常量池）映射为 PROT_READ，写操作直接被 OS 拦截。
- 常见错误现象：
invalid operation: cannot take address of ...（编译失败），或运行时报fatal error: unexpected signal ... code=0x2 addr=0x... - 真正能取地址的“常量”极少，基本只存在于局部
var+ 字面量初始化的边界场景 - Go 的
const是编译期概念，不占运行时内存槽位；所谓“修改常量”，本质是试图篡改只读页，OS 层面不允许
用 unsafe.Pointer 强行修改字符串字面量会发生什么？
字符串字面量（如 "hello"）在 Go 中存储于只读数据段（.rodata），其底层 string 结构的 data 字段指向该区域。哪怕你用 unsafe 获取其地址并尝试写入，也会立即触发段错误。
- 示例：
s := "hello"; hdr := (*reflect.StringHeader)(unsafe.Pointer(&s)); b := (*[5]byte)(unsafe.Pointer(hdr.Data)); b[0] = 'H'→ 运行时 panic - 不同平台表现一致：Linux/macOS 报
SIGSEGV，Windows 报ACCESS_VIOLATION - 即使成功绕过（如用
mprotect手动改页权限），也会破坏 runtime 对字符串的假设，导致 GC 或其他 goroutine 行为异常
哪些值看似“常量”实则可修改？如何区分？
关键看是否真由 const 声明、是否被编译器优化进只读区、以及是否被赋值给可寻址变量。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
-
const pi = 3.14159→ 不可取地址，不可修改 -
var pi = 3.14159→ 可取地址，可通过指针修改（p := π *p = 3.14） -
const s = "hi"; var t = s→t是新分配的可写字符串，&t可安全操作底层字节（需unsafe+reflect配合） - 全局包级
var即使初始值是字面量，也分配在数据段（可读写），不是只读区
想实现“运行时可配置的常量”，该怎么做？
这不是 hack 内存的问题，而是设计模式问题。真正的解法是放弃“修改常量”的执念，改用可控的可变状态。
- 用
sync.Once+atomic.Value实现只初始化一次的可读变量 - 导出一个包级
var Config struct{...}，启动时加载，后续只读访问（配合go:linkname或封装 getter 防误改） - 需要热更新？用
atomic.Pointer指向新配置结构体，避免锁 - 绝对不要用
unsafe改只读数据 —— 它既不可靠，也不跨版本兼容，更会让静态分析工具和 race detector 失效
最易被忽略的一点：Go 的“常量不可变”不是语言强制的逻辑约束，而是操作系统内存页保护与编译器优化共同形成的事实。试图绕过它，等于在沙上建塔——编译器可能帮你优化掉你的 unsafe 代码，runtime 可能因数据损坏提前退出，而调试时看到的现象还高度依赖具体 Go 版本和构建参数。
