 
大多数开发者能聊一下午微服务。但这三个问题，能看出他们是否真的理解 Go。

几年前，我在面试一位 Go 后端开发候选人。简历很漂亮：“5 年 Go 经验”、“设计过高并发系统”、“精通微服务架构”。

然后我问了一个简单的问题：“Go 的 `make` 和 `new` 有什么区别？”

沉默。一段很长的沉默。

然后是一个经典回答：“`make` 用来创建切片，`new` 用来创建结构体……差不多吧。”

差不多？在 Go 里，“差不多”通常意味着“不清楚”。

那次面试让我意识到一件事：很多开发者成了框架、云平台和架构图的专家，但真正理解 Go 运行时和语言底层机制的人，比想象中少得多。

如果我只用 15 分钟评估一位 Go 开发者，以下三个问题就够了。它们的效果出奇地好。

---

## 1. `make` 和 `new` 到底有什么区别？

这个问题听起来基础，实则不然。

大多数开发者会立即说：“`new` 分配内存，`make` 初始化切片、map 和 channel。”这是对的，但只是表面。

然后我会追问：“那 `new` 返回什么？`make` 返回什么？”

`new(T)` 返回的是 **`*T`**——一个指向类型 T 的零值指针。它只分配内存，不进行任何初始化。`make(T, ...)` 只用于 `slice`、`map` 和 `channel`，返回的是 **`T` 本身**（不是指针），并且会进行内部结构的初始化。

```go
p := new([]int)     // p 是 *[]int，指向 nil 切片
s := make([]int, 5) // s 是 []int，一个长度 5、容量 5 的切片
```

如果有人说“`new` 和 `make` 差不多”，说明他们可能没真正处理过零值设计和类型系统。

还有一个更犀利的问题：“那 `var s []int` 和 `make([]int, 0)` 有什么区别？”

`var s []int` 声明了一个 nil 切片，不分配内存；`make([]int, 0)` 分配了一个空切片（长度和容量都为 0），它不为 nil。两者的行为在 JSON 序列化、`append` 和 `len` 上都有细微差异。

**为什么这很重要？** 因为 Go 的零值设计贯穿整个语言。不理解 `make` 和 `new`，就很难理解 Go 的“零值可用”哲学，也容易写出隐含的内存分配问题。

---

## 2. `defer` 的求值时机和参数捕获

这个问题一下子就能看出一个人是否真的在 Go 里调试过生产问题。

代码很简单：

```go
func main() {
    i := 0
    defer fmt.Println(i)
    i++
}
```

输出是什么？是 `0`。

因为 `defer` 语句**在声明时就对参数求值**，而不是在调用时。

然后我会继续问：“那如果改成闭包呢？”

```go
func main() {
    i := 0
    defer func() { fmt.Println(i) }()
    i++
}
```

输出是 `1`，因为闭包捕获的是变量引用。

再问一个：“下面这段代码有什么问题？”

```go
func readFile() {
    f, err := os.Open("file.txt")
    defer f.Close()
    // 处理文件...
}
```

如果 `os.Open` 失败，`f` 为 `nil`，`defer f.Close()` 会引发 panic。

很多“资深工程师”会写这样的代码，因为在其他语言里这种模式是安全的。但 Go 不是其他语言。理解 `defer` 的求值时机、参数传递方式和 nil 检查，是写出健壮生产代码的基础。

---

## 3. 什么情况下 `channel` 会阻塞？

这个问题考察的是对 Go 并发模型的理解深度。

我会先给一段代码：

```go
ch := make(chan int)
ch <- 42
```

这段代码会**死锁**。因为无缓冲 channel 的发送和接收必须同时准备好。

然后我会问：“那 `make(chan int, 1)` 呢？还会阻塞吗？”

发送不会阻塞，因为缓冲区有空间。但如果再发一次，没有接收者，就会阻塞。

接着我会追问：“什么情况下从 `channel` 读取会阻塞？”

空 channel 读会阻塞。但如果 `channel` 被关闭了呢？读取会立即返回零值。

```go
ch := make(chan int)
close(ch)
v := <-ch   // v = 0，不会阻塞
```

然后我会问一个真正有区分度的问题：“`for range` 遍历 `channel` 什么时候会退出？”

答案是：**当 `channel` 被关闭且所有值都被读取后**。如果 `channel` 没有被关闭，`for range` 会一直阻塞。

到这里，大部分人的信心已经出现了裂缝。

最后我会追问：“如果多个 goroutine 同时向一个无缓冲 channel 发送，但只有一个接收者，会发生什么？”

只有第一个发送会与接收者匹配，其余发送会阻塞，直到有新的接收者出现。这是 Go 的“无缓冲 channel 是同步的”这一特性的直接体现。

---

## 这些问题的共同点

这三个问题：

1. `make` 和 `new` 的区别
2. `defer` 的求值时机和参数捕获
3. 各种场景下 `channel` 的阻塞规则

它们有个共同点：**来自官方 FAQ 和常见误区的精炼**。每一个都有明确的官方文档解释。

它们考察的不是知识点，而是**对 Go 运行时行为的真实理解**。

一个高级工程师，不一定能设计出完美的微服务架构，但一定能准确说出 `defer` 的求值时机。因为后者的理解，决定了前者的代码在凌晨三点会不会出问题。

---

## 为什么现代面试容易失效

很多 Go 面试变成了框架问答：“Gin 怎么用？”、“GORM 的钩子怎么写？”、“如何配置 Viper？”

这些问题有价值，但框架每两年换一轮。基础不会。

一个真正理解**内存模型、并发原语、接口语义**的工程师，可以学习任何框架。反之则不然。

我见过能一天搭出完整 HTTP 服务的开发者，却说不清 `select` 在多个 `channel` 就绪时的行为。

那不是能力问题。那是基础认知问题。

---

## 最后

我认为“资深”不是按年限划分的。我见过 10 年经验的工程师，把同一年的经验重复了 10 次。也见过 3 年经验的开发者，对 Go 的调度器模型如数家珍。

区别在于**好奇心**。

最好的 Go 工程师总是在问：“这下面发生了什么？”那些人是解决最难生产问题的人。

所以，这三个问题你能自信回答吗？

如果不能，不用太担心。大多数人都不能。而这正是它们值得被研究的原因。

几年前，我在面试一位 Go 后端开发候选人。简历很漂亮：“5 年 Go 经验”、“设计过高并发系统”、“精通微服务架构”。

三个 Go 基础问题，帮你筛掉 90% 的“资深工程师”

编程语言

后端

职业发展

Go语言核心技术面试常被三个基础问题筛选：make与new的指针/初始化差异、defer参数求值时机及nil陷阱、无缓冲channel的同步阻塞规则。这些官方FAQ提炼的要点，比框架问答更能验证开发者对内存模型、零值哲学和并发原语的底层理解，是区分资深与年限的关键。

微服务架构

代码解释

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

三个 Go 基础问题，帮你筛掉 90% 的“资深工程师”-腾讯云开发者社区-腾讯云

三个 Go 基础问题，帮你筛掉 90% 的“资深工程师”

三个 Go 基础问题，帮你筛掉 90% 的“资深工程师”

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐