为什么 Java 程序员学 Go 会踩这些坑
总体结论
Java 程序员不是不懂 Go 语法，而是下意识地在用 JVM 思维写 Go。
Go 不会“兜底”，它会直接让错误以性能、并发 Bug、内存问题的形式暴露出来。
一、根因：两种语言在“责任边界”上的根本不同
责任是谁的？
| 维度 | Java | Go |
|---|---|---|
| 内存布局 | JVM | 开发者 + 编译器协作 |
| 对象生命周期 | GC 全托管 | 显式感知 |
| 并发安全 | 框架兜底 | 默认不安全 |
| 性能兜底 | JVM 优化 | 你自己负责 |
Java：“你写业务，剩下交给 JVM”
Go：“我给你工具，后果你自己承担”
二、第一类大坑：把 Go 当成“没有类的 Java”
坑 1：struct 被当成 Java Object 使用
func update(u User) { u.Name = "ada" }
Java 心智：
“传的是对象，应该改得动”
Go 现实：
User是值整体拷贝
外部完全不变
工程后果
修改无效
Debug 极其隐蔽
性能无意识劣化（大 struct 拷贝）
正确方式
func update(u *User) { u.Name = "ada" }
Go 要你明确表达共享还是拷贝
三、第二类大坑：误判“是否有拷贝成本”
Java 程序员的默认假设
void f(User u) {}
传参几乎“零成本”
没有结构体大小概念
Go 的真实世界
type Big struct { Data [4096]byte } func f(b Big) {}
这是一次4KB 的内存复制。
工程后果
QPS 降低
GC 压力上升
pprof 看到大量 memcpy
Go 要求你对数据大小有感觉
四、第三类大坑：逃逸分析完全没概念
Java 世界
所有对象几乎都在堆上
逃逸是 JVM 的事
Go 世界
func build() *User { u := User{} return &u }
看似栈变量
实际逃逸到堆
Java 程序员常见误区
到处返回指针
到处
new到处
&
工程后果
GC 次数暴涨
延迟不稳定
吞吐下降
工程建议
go build -gcflags="-m"
这是 Go 工程师的基本功，Java 工程师往往忽略
五、第四类大坑：并发模型“看起来简单，其实更危险”
Java
synchronized
volatile
并发包极其成熟
默认“稍微安全”
Go
go f()
启动 goroutine毫无成本
数据竞争默认存在
典型踩坑代码
for _, v := range arr { go func() { fmt.Println(v) }() }
Java 程序员低估了闭包 + 并发的杀伤力
六、第五类大坑：接口被当成“Java interface”
Java 接口
显式 implements
类型层级清晰
Go 接口
type Writer interface { Write([]byte) error }
隐式实现
值 / 指针接收者决定是否实现接口
常见坑
func (u User) Write(...) {}
和
func (u *User) Write(...) {}
是否实现接口，完全不同
七、第六类大坑：异常与错误处理的文化冲突
Java 思维
try / catch
异常冒泡
框架统一兜底
Go 现实
if err != nil { return err }
Java 程序员常见反应：
“太啰嗦”
“不优雅”
但工程现实是：
Go 把异常路径显式化，逼你思考失败场景
八、第七类大坑：误判 Go 的“简单 ≠ 初级”
Java 程序员容易低估 Go：
语法少
没有泛型（过去）
没有复杂 OO
但实际上：
Go 把复杂度从“语言”转移到了“工程决策”
九、一句话总结（非常重要）
Java 程序员踩坑，不是因为 Go 难，而是 Go 不再替你做决定。
十、给 Java 架构师的迁移建议（务实）
先学内存模型，再学语法
struct 默认当成值
指针是性能工具，不是习惯
并发先想“是否共享”，再想“怎么并发”
pprof / race / escape analysis 是必备工具