Go编译器在编译期严格检查语法和类型，拦截括号缺失、返回值不匹配、未使用变量/导入、重复字段、非导出标识符访问及隐式类型转换等错误，但不检查运行时panic、死代码、竞态、安全漏洞等。

Go 编译器在编译阶段会做**严格的静态语法和类型检查**，但不会执行运行时逻辑（比如空指针解引用、除零），也不会做完整的死代码分析或跨包的符号可达性推导。它属于“编译即检查”风格，错误会在 go build 或 go run 时立即报出，不生成可执行文件。

哪些语法错误会在编译期被拦截

Go 的 gc 编译器（默认）在解析（parsing）和类型检查（type checking）阶段就拒绝非法结构。常见拦截项包括：

• if 后面缺少括号：if x > 0 { ... } 合法，if x > 0 { ... } 少括号会报 syntax error: unexpected {
• 函数返回值数量/类型不匹配：比如声明为 func() (int, error) 却只写了 return 42
• 未使用的变量或导入：哪怕只是 var x int 或 import "fmt" 没调用，也会触发 declared and not used
• 重复的 struct 字段名：type T struct { X int; X string } → duplicate field X
• 非导出标识符跨包访问：main.go 中尝试读取 other/pkg.x（小写 x）→ cannot refer to unexported name other/pkg.x

类型系统相关的强制检查

Go 的类型检查非常激进，连隐式转换都禁止，所有类型必须显式一致或满足接口契约：

• 整数类型不能混用：var i int32 = 1; var j int64 = i 报错，必须写 int64(i)
• 字符串与字节切片不自动互转：string([]byte{97}) 合法，但 fmt.Println([]byte("a")) 会输出切片地址（不是内容），而如果误写成 fmt.Println(string("a")) 会直接编译失败（cannot convert "a" (untyped string constant) to string）
• 接口实现是隐式的，但编译器会严格校验：只要某个类型没有实现接口全部方法，赋值就会失败，例如 io.Writer 要求有 Write([]byte) (int, error)，少一个参数或改名就报错

哪些“看起来错”的事其实能过编译

编译器不管语义合理性，只管语法和类型规则是否合规：

• 无限循环：for {} 或 for true {} 完全合法，不报错也不警告
• 不可达代码：return; fmt.Println("dead") 中的 fmt.Println 会被标记为 unreachable（由 go vet 提示，但 go build 不拦）
• 空 select：select{} 会永久阻塞，但语法正确，编译通过
• 未初始化的变量（零值安全）：var s []int 是合法的 nil 切片，不报错；只有 len(s) 或 append 等操作才可能 runtime panic

编译阶段不做的检查

这些需要靠工具链其他环节或人工保障：

• 竞态条件：需运行 go run -race
• 内存泄漏或 goroutine 泄漏：无静态分析能力，得靠 pprof 或 runtime.GoroutineProfile
• SQL 注入、XSS、硬编码密钥等安全问题：不在编译器职责内，依赖 staticcheck、gosec 等 linter
• 循环 import：编译器会报错，但“间接循环”（A→B→C→A）在模块模式下可能绕过，靠 go list -f '{{.Imports}}' pkg 手动查

package main

import "fmt"

func main() {
	var x int
	_ = x // 避免 "declared and not used"
	fmt.Println("ok")
}

真正容易忽略的是：Go 编译器对「包级作用域」的检查比函数内更严格——比如包级变量初始化表达式中不能引用尚未声明的标识符，即使它们在同一文件里且后续会定义。这种顺序敏感性不像函数体内那样宽松，稍不注意就会触发 undefined: xxx。