最可靠方式是遍历所有ast.callexpr节点，检查其fun是否为名为"panic"的ast.ident且obj为内置函数，跳过init函数及测试文件等安全上下文，结合函数签名（如*gin.context）定位业务代码中非法panic调用。
如何用ast检测代码中显式调用panic函数
直接匹配ast.CallExpr节点，检查其Fun是否为标识符panic，且位于当前包作用域内——这是最可靠、开销最小的静态识别方式。
注意：该方法只捕获形如panic("msg")或panic(err)这类直接调用，不覆盖panic被别名化（如var p = panic）、通过接口调用或反射触发的场景，那些属于运行时行为，ast无能为力。
- 遍历所有
*ast.CallExpr节点，用ast.IsIdent判断call.Fun是否为*ast.Ident - 确认该
*ast.Ident的Name等于"panic" - 检查其
Obj是否为nil或指向内置函数（obj.Kind == ast.Builtin），避免误判同名变量 - 跳过在
func init()里对panic的调用——这类通常合法，用于强制校验初始化约束
为什么go vet不报panic但你可能需要自己扫
go vet默认不检查panic调用，因为它不违反语言规则；但业务代码中若在 handler 或循环内频繁出现panic，大概率是把error误当panic用了。这时需自定义扫描逻辑。
典型误用场景包括：panic(fmt.Errorf(...))代替return fmt.Errorf(...)、在参数校验失败时panic而非返回400错误响应。
- 结合
ast.Inspect遍历到*ast.ReturnStmt附近，若发现紧邻*ast.CallExpr调用panic，可标记为可疑 - 过滤掉已知安全上下文：如
main函数末尾、init函数、测试文件（_test.go） - 对
http.HandlerFunc或gin.HandlerFunc签名的函数体做重点扫描，这些地方panic几乎总是 bug
panic调用被包裹后ast还能识别吗
不能。一旦panic被赋值给变量、作为参数传入高阶函数、或通过reflect.Value.Call执行，ast树上就只剩普通函数调用或反射操作节点，原始语义已丢失。
例如doPanic := panic; doPanic("x")中，ast看到的是变量doPanic的调用，不是panic本身；run(func() { panic("x") })里，panic藏在闭包内部，外层ast节点只显示run调用。
- 这种写法本身也违背 Go 习惯——
panic应直白可见，不隐藏、不传递、不复用 - 若项目真存在这类模式，需配合
go tool trace或运行时日志（如runtime.Caller）定位源头 - 静态扫描可加告警：发现
panic被赋值给非func(...)类型变量，或出现在map/slice字面量中，即视为可疑
线上环境禁止panic的硬性检查怎么落地
在 CI 阶段插入自定义 AST 扫描器，失败则阻断构建。关键不是“有没有panic”，而是“有没有不该出现的panic”。
比如 Gin 项目中，允许init里panic（配置加载失败），但禁止在任何func(c *gin.Context)里出现；又比如 CLI 工具，允许main里panic（快速失败），但禁止在子命令RunE函数中使用。
- 提取函数签名：用
ast.Inspect找到所有*ast.FuncDecl，检查recv和params是否含*gin.Context或*cobra.Command - 对匹配函数体做深度遍历，一旦发现
panic调用立即报错，并附带文件路径+行号 - 允许按目录/文件名白名单绕过，如
internal/pkg/errors/panic.go可存封装工具函数，但必须确保其内部不触发真实panic
真正难防的从来不是panic本身，而是它被藏在第三方库回调、模板渲染、或encoding/json等标准库深处——那些地方你连ast都扫不到，只能靠运行时 recover + 栈帧分析兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
