写完一段代码，按下回车，几秒内就生成可执行文件——这是很多刚接触 Go 的开发者最直观的感受。那它到底快不快？快在哪？我们不讲理论，直接上真实场景。
三台机器，同一段“Hello World”
在一台普通笔记本（i5-8250U / 16GB / SSD）上，分别用 Go、C、Java 和 Python 编译/运行最简版本的输出程序：
package main
import "fmt"
func main() {
fmt.Println("Hello, 电脑资讯读者")
}执行 time go build -o hello hello.go，耗时约 0.18 秒；
同样逻辑的 C 程序（gcc -o hello hello.c），耗时约 0.25 秒；
Java（javac Hello.java && java Hello），仅编译就 0.42 秒，还不算 JVM 启动；
Python 则根本没“编译”这一步，但每次运行都要解释执行，启动+输出约 0.08 秒——快是快，但没法打包成单文件分发。
为什么 Go 编译这么利索？
它不玩虚的：没有头文件依赖扫描，不搞复杂的模板实例化，也不做 JIT 预热。Go 编译器从源码直接生成机器码（或静态链接的 ELF 文件），中间不经过字节码层，整个流程像一条直道——词法分析 → 语法分析 → 类型检查 → SSA 优化 → 机器码生成 → 链接。
举个例子：你改了 main.go 里一行日志，重新 go build，它只重新编译改动模块及其直接依赖，不会把整个 vendor 目录再扫一遍。这点比某些 C++ 项目动辄等一分半钟强太多。
快，但不是万能的
如果你写的是带大量 CGO 调用的程序（比如深度集成 OpenCV 或硬件 SDK），编译速度会明显下降——因为要等 C 编译器跑完；
如果项目用了上百个第三方模块，首次 go mod download 可能卡几秒，但那是网络和缓存的事，跟编译器本身无关；
另外，“快”不等于“不优化”。加 -ldflags="-s -w" 可去掉调试信息，体积小一半，编译时间几乎不变；想进一步提速？用 go build -a 强制重编所有依赖（一般没必要）。
日常开发中怎么用这个优势？
写 CLI 工具？改完代码，go build && ./tool 一气呵成，比反复切终端跑 Python 脚本还顺滑；
做微服务？本地改接口、build、docker build、docker run，整个循环压到 3 秒内；
甚至有人拿 Go 写临时脚本：保存为 rename.go，go run rename.go *.jpg，不用装任何依赖，也不用担心目标机有没有 Python 环境。
快，不是为了炫技，而是让“写→试→改”的节奏不被打断。就像炒菜时锅气足，火候到了，翻两下就出锅——Go 编译，就是这口锅。