Go中仅string底层字节不可变，struct等值类型可变；string是只读引用结构，保障安全共享与哈希一致性，而struct赋值仅为内存复制，非语言级不可变。
Go 语言中没有“值类型不可变”这一设计原则——struct、int、string 等值类型本身可被重新赋值，只是在函数传参时按值传递（即拷贝），这常被误读为“不可变”。真正不可变的只有 string 底层字节不可寻址修改（尝试 &s[0] 会编译错误），而其他值类型完全可变。
为什么 string 是只读的，但 struct 不是
string 在 Go 中是只读字节序列的引用结构（头含指针+长度），其底层数据被设计为不可写：任何试图通过下标取地址或 unsafe 强制写入的操作都会触发编译错误或未定义行为。而 struct 是纯内存布局，字段可读可写，赋值只是复制整个内存块。
-
string的不可变性是语义保证，用于安全共享和哈希一致性（如 map key） -
struct赋值后彼此独立，修改副本不影响原值，但这不等于“不可变”，只是无副作用 - 若想模拟不可变 struct，需靠约定（不导出字段 + 只提供构造函数和只读方法），Go 不提供语言级
const struct
值传递带来的性能与理解误区
小对象（如 struct{int,int}）按值传递开销低，CPU 缓存友好；但大 struct（如含 [1024]byte）拷贝成本高，易引发意外性能瓶颈。
- 函数参数接收
MyStruct→ 每次调用都拷贝整个 struct - 接收
*MyStruct→ 避免拷贝，但需注意并发读写风险 - 编译器可能对小 struct 做逃逸分析优化，但不可依赖；应以
go tool compile -S实际验证 - JSON 解析到大 struct 时，如果函数频繁接收该 struct 值，比接收指针慢 2–5 倍（实测常见于日志上下文、HTTP handler 参数）
string 不可变引发的实际约束
因为 string 字节不可改，所有字符串拼接、截断、替换都生成新字符串，底层分配新内存。这带来确定性，也带来 GC 压力。
立即学习“go语言免费学习笔记（深入）”；
-
s += "x"或strings.ReplaceAll(s, "a", "b")都返回新string，原值不受影响 - 高频拼接应改用
strings.Builder，避免重复分配；builder.String()才生成最终 string - 需要原地编辑字节？必须转成
[]byte（可变），操作完再转回string(byteSlice)—— 注意这会额外分配且不共享底层数组 - 从 C/Python 等语言转来的开发者常在此处写出错误假设：“改了 s[0] 就等于改了 string”，实际会编译失败
package main
import "fmt"
func main() {
s := "hello"
// ❌ 编译错误：cannot assign to s[0] (string index is read-only)
// s[0] = 'H'
b := []byte(s) // ✅ 转为可变切片
b[0] = 'H'
s2 := string(b) // ✅ 新 string，b 和 s2 底层数组不共享
fmt.Println(s2) // "Hello"
}
真正容易被忽略的是：不可变性只存在于 string 这一个值类型上；其余值类型（包括自定义 struct）的“不可变感”只是值传递的副产品，而非语言约束。是否可变，取决于你如何定义字段、是否暴露修改入口、是否用指针传递——这些全由程序员控制，Go 不介入。
