go编译器默认不报错也不警告死代码，因其dce仅在ssa阶段保守移除确定不可达的基本块和不活跃值，不处理panic后语句、未调用函数等，需依赖deadcode等专用工具检测。
Go 编译器默认不报错也不警告死代码
死代码（比如 panic 后面的语句、不可达分支、未调用的函数）在 Go 中不会触发编译错误或警告。这和未使用的导入（import）、未使用的变量（var x int）完全不同——后者会直接编译失败。
原因很实际：控制流分析成本高，尤其涉及运行时行为（如 panic、os.Exit、反射调用）时，静态判断“是否可达”容易误判。Go 选择把这事交给专用工具，而不是拖慢每次 go build。
-
panic("done")后的代码会被编译进二进制，但永远不会执行 - 未被任何路径调用的导出函数（如
func Helper() {}），只要被其他包 import 过，就可能保留 - 非导出函数（首字母小写）若完全未被本包内引用，则大概率被死代码消除阶段移除
死代码消除只作用于不可达的基本块和不活跃值
Go 编译器的死代码消除（DCE）发生在 SSA 中间表示阶段，位于 src/cmd/compile/internal/ssa/deadcode.go。它不是简单地删掉“看起来没用”的函数，而是基于控制流图（CFG）和数据流分析做两件事：
- 先用 DFS 找出所有从
Entry块可达的基本块（ReachableBlocks），不可达块整块删除 - 再在可达块内跑
liveValues分析，识别哪些寄存器/变量值后续不会再被读取，删掉对应计算 - 注意：DCE 不处理“语义上无副作用但语法上可达”的代码，比如
x := 1; _ = x—— 它仍会保留赋值，除非整个x被证明未被使用且无副作用
如何验证某个函数是否被真正消除？
最可靠的方式是关掉优化后对比符号表，而不是靠 go build 是否成功：
- 正常构建：
go build -o demo ./...→ 二进制里很可能找不到未调用函数的符号（已被 DCE 或内联吞掉） - 关闭优化再查：
go build -gcflags="-l -N" -o demo ./...→ 强制禁用内联和优化，再用go tool nm demo | grep 'YourFuncName' - 如果禁用优化后仍查不到该函数，说明它确实没被任何调用链引用，已被 DCE 移除
- 如果禁用后能查到，但默认构建查不到，大概率是被内联了（可用
-gcflags="-m"确认）或被更早的链接期裁剪（如依赖包中未导出函数）
想主动清理未使用函数？别依赖编译器，用 deadcode 工具
Go 编译器的 DCE 是“保守安全”的：它只删确定不可达的代码，不删“可能被反射、插件、测试或外部调用”的函数。所以工程里大量未使用的导出函数（func ExportedHelper()）会一直留在二进制里，增大体积、暴露接口。
这时得靠外部工具：
- 安装：
go install golang.org/x/tools/cmd/deadcode@latest - 运行：
deadcode ./...→ 列出所有未被调用的函数（包括导出和非导出） - 注意：
deadcode无法识别通过reflect.Value.Call、plugin或unsafe调用的函数，需手动加//deadcode:ignore注释忽略 - CI 中建议配合
go vet和staticcheck一起跑，避免误删测试辅助函数
真正容易被忽略的是：DCE 只发生在单个编译单元内，跨包调用依赖导入路径和符号可见性；而 deadcode 是静态扫描，不执行，所以它看到的“未使用”，比编译器实际裁剪的范围更广也更粗糙。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
