Go中值类型并非天生适合函数式编程，而是因按值传递可自然规避副作用、降低意外共享风险，便于模拟纯函数；但切片、map及含指针的struct仍需显式处理才能保障纯度。
Go 语言中值类型（如 int、string、struct{}）本身并不“更适合函数式编程”，因为 Go 并非函数式语言，也没有强制不可变性、高阶函数一等公民、代数数据类型等核心特征。所谓“更适合”，实际是指：在**模拟函数式风格时，值类型能更自然地规避副作用、降低意外共享风险，从而让纯函数写法更容易落地。**
为什么值类型能减少隐式状态污染
函数式编程强调纯函数（相同输入 → 相同输出，无副作用）。而副作用常来自对可变状态的意外修改。Go 中：
-
struct默认按值传递，函数内修改参数副本不会影响调用方 —— 这天然隔离了输入数据 - 对比指针传递：
func f(p *MyStruct)中任何字段赋值都可能改变原始对象，需人工审查是否“破坏纯度” - 即使你写
func transform(s MyStruct) MyStruct，编译器也确保s是独立副本，无需额外防御性拷贝
字符串和切片的特殊性：看似值类型，实则需警惕
string 是只读值类型（底层是 struct{data *byte, len int}），安全；但 []int 是引用类型头（含指向底层数组的指针），按值传递仅复制头，不复制元素。
- 直接修改
func bad(s []int) { s[0] = 99 }会改变原切片内容 —— 这不是纯函数 - 要模拟纯操作，必须显式复制底层数组：
copy(dst, src)或append([]int(nil), src...) - 所以“值类型友好”不自动延伸到所有复合类型；
[]T和map[K]V都需要额外处理才能用于纯函数场景
结构体嵌套指针时，值语义即失效
定义 type User struct { Name string; Profile *Profile } 后，User 虽是值类型，但 Profile 字段仍可被函数内修改并影响外部：
立即学习“go语言免费学习笔记（深入）”；
func updateUser(u User) User {
u.Profile.Age = 30 // 外部 u.Profile.Age 也被改了
return u
}
- 值传递只浅拷贝结构体字段，不递归深拷贝指针所指内容
- 若需真正纯函数行为，要么避免嵌套指针，要么手动深拷贝（如用
github.com/jinzhu/copier），或改用不可变设计（如返回新*Profile） - 这说明：值类型只是起点，不是银弹；纯度必须由开发者主动维护
真正容易被忽略的是：Go 没有运行时保护，值类型带来的“安全假象”可能让人放松对共享可变状态的警惕——尤其在结构体含指针、切片、map、channel 时，表面是值传递，实则仍是引用共享。函数式风格在 Go 里靠约定和纪律，而非语言强制。
