Go反射可读私有字段但禁止修改，因编译器依赖导出状态做优化；强行修改需unsafe或UnsafeAddr，但破坏GC、跨版本不稳定，属未定义行为。

反射能读私有字段，但不能直接改

Go 的 reflect 包允许你读取结构体中未导出（小写开头）字段的值，哪怕跨包——只要该结构体实例本身可访问。但一旦尝试用 SetString、SetInt 等方法修改，就会 panic：reflect.Value.SetString using unaddressable value 或更明确的 cannot set unexported field。

• reflect.ValueOf(obj).FieldByName("name") 返回的 reflect.Value 对未导出字段始终是 CanSet() == false
• 即使传入指针并调用 .Elem()，字段本身未导出 → 仍不可设
• 读取完全没问题：nameField.String()、nameField.Interface() 都可用
• 这个限制从 Go 1.7 起被硬编码进运行时，不是 bug，是设计

想改私有字段？只有两种路，都不干净

生产代码里不该出现这种需求，但如果真在测试、调试或 hack 场景下必须改，目前只有两条技术路径，且都带明显副作用：

• 用 unsafe 直接操作内存：通过 unsafe.Offsetof 定位字段地址，再用 (*string)(unsafe.Pointer(...)) 强转并赋值。它绕过了所有类型检查，但会破坏 GC 假设（比如 string header 被篡改）、引发崩溃，且不同 Go 版本字段偏移可能变化
• 反射 + UnsafeAddr 组合技：对可寻址的字段调用 field.UnsafeAddr()，再用 reflect.NewAt 构造新 reflect.Value，最后 Set。这比纯 unsafe 稍“规范”，但本质仍是未定义行为，go vet 和静态分析工具会报警

package main

import (
	"fmt"
	"reflect"
	"unsafe"
)

type User struct {
	name string
	age  int
}

func main() {
	u := &User{name: "Alice", age: 25}
	v := reflect.ValueOf(u).Elem()
	nameField := v.FieldByName("name")

	// ❌ 常规方式失败
	if !nameField.CanSet() {
		fmt.Println("CanSet returns false — can't use SetString")
	}

	// ✅ unsafe 方式（仅演示，勿用于生产）
	namePtr := (*string)(unsafe.Pointer(
		uintptr(unsafe.Pointer(u)) + unsafe.Offsetof(u.name),
	))
	*namePtr = "Bob"

	fmt.Printf("%+v\n", *u) // {name:"Bob" age:25}
}

为什么 Go 死守这条线？不只是“封装”二字

这不是教条主义。Go 编译器和运行时依赖字段导出状态做大量优化：内联判断、GC 扫描范围、struct layout 稳定性、甚至逃逸分析。一旦允许外部随意改私有字段，这些底层保障就全失效了。

• 编译器可能把未导出字段优化掉（如全常量推导），unsafe.Offsetof 就会指向错误内存
• GC 不扫描未导出字段的指针引用 — 若你用 unsafe 往里塞了个新字符串，旧字符串可能提前被回收
• 测试中依赖私有字段修改，等于把实现细节写进用例，重构时必然断裂

真正该做的：换设计，而不是绕规则

遇到“必须改私有字段”的场景，99% 是接口或结构体职责没划清。与其花时间 debug unsafe 偏移计算，不如花 5 分钟调整设计：

• 把字段改成导出（首字母大写），加文档说明“仅供内部使用”
• 提供一个包内可见的 setter 方法，比如 setInternalName()，测试时导入同一包即可调用
• 用函数变量暴露逻辑：var internalNameSetter = func(u *User, s string) { u.name = s }，测试文件里重赋值
• 如果是测试需要初始化，考虑用构造函数或选项模式（functional options）预设私有状态

反射读私有字段本身不危险，但任何试图写它的操作，都在和 Go 的内存模型与编译器博弈 — 赢面很小，代价很高。