为什么 Java 程序员学 Go 会踩这些坑

总体结论

Java 程序员不是不懂 Go 语法，而是下意识地在用 JVM 思维写 Go。
Go 不会“兜底”，它会直接让错误以性能、并发 Bug、内存问题的形式暴露出来。

一、根因：两种语言在“责任边界”上的根本不同

责任是谁的？

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 架构师的迁移建议（务实）

1. 先学内存模型，再学语法

2. struct 默认当成值

3. 指针是性能工具，不是习惯

4. 并发先想“是否共享”，再想“怎么并发”

5. pprof / race / escape analysis 是必备工具