revive 不支持在 TOML 中写 Go 代码定义新规则，必须用 Go 实现 analysis.Analyzer 并重新编译 revive 二进制；TOML 仅能开关或配置已有规则，自定义逻辑需遍历 AST 并依赖类型系统（如 TypesInfo）进行语义判断。
revive 不支持直接在 TOML 里写 Go 代码实现自定义规则；必须用 Go 编写独立的 analysis.Analyzer，再通过插件方式集成。 这是新手最容易卡住的地方——误以为改配置就能加新规则。
为什么 revive 的自定义规则必须写 Go 代码
revive 的规则本质是基于 golang.org/x/tools/go/analysis 框架的静态分析器。TOML 只能开关、调参已有规则（比如 [rule.cyclomatic]），不能定义新语法逻辑。要检查“函数第一个参数不是 context.Context”，就必须遍历 AST 中的 ast.FuncDecl，提取 FuncType.Params.List 并比对类型——这只能靠 Go 实现。
常见错误现象：
- 在
revive.toml里尝试写[rule.context-first-param]并期望生效 → 静默忽略，无任何报错或提示 - 把自定义规则文件放在项目目录下，但没编译进 revive 二进制 → 运行时提示
unknown rule
编写自定义 analyzer 的最小可行步骤
以检测“导出函数返回未导出类型”为例（对应原生 unexported-return 规则的反向逻辑）：
立即学习“go语言免费学习笔记（深入）”；
创建 contextparam/analyzer.go：
package contextparam
import (
"golang.org/x/tools/go/analysis"
"golang.org/x/tools/go/analysis/passes/inspect"
"golang.org/x/tools/go/ast/inspector"
"go/ast"
)
var Analyzer = &analysis.Analyzer{
Name: "contextparam",
Doc: "check if first param of exported func is context.Context",
Requires: []*analysis.Analyzer{inspect.Analyzer},
Run: run,
}
func run(pass *analysis.Pass) (interface{}, error) {
inspect := pass.ResultOf[inspect.Analyzer].(*inspector.Inspector)
nodeFilter := []ast.Node{(*ast.FuncDecl)(nil)}
inspect.Preorder(nodeFilter, func(n ast.Node) {
fn := n.(*ast.FuncDecl)
if !ast.IsExported(fn.Name.Name) {
return
}
if fn.Type.Params == nil || len(fn.Type.Params.List) == 0 {
return
}
firstParam := fn.Type.Params.List[0]
if len(firstParam.Names) == 0 {
return
}
// 这里需用 pass.TypesInfo.TypeOf() 查实际类型，但注意：必须声明 Requires
// 否则 TypesInfo 为 nil → 常见坑点
})
return nil, nil
}
关键实操要点：
- 必须在
Requires字段显式声明依赖inspect.Analyzer，否则pass.ResultOf拿不到inspector.Inspector - 查类型要用
pass.TypesInfo.TypeOf(node)，但TypesInfo默认不启用 → 需额外引入golang.org/x/tools/go/types/typeutil并在Requires加typeutil.Analyzer - 规则名（
Analyzer.Name）会成为命令行参数，例如revive -enable contextparam ./...
如何让 revive 加载你的自定义规则
revive 本身不提供动态加载机制，必须重新编译一个带插件的二进制：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
新建 main.go（和官方 cmd/revive/main.go 结构一致）：
package main
import (
"github.com/mgechev/revive/lint"
"github.com/yourname/yourrepo/contextparam" // 替换为你自己的包路径
)
func main() {
lint.Run(
lint.WithRules(
// 注册原生规则（必须）
lint.StdRules()...,
// 注入自定义规则
&lint.Rule{
Name: "contextparam",
Analyzer: contextparam.Analyzer,
},
),
)
}
然后构建：
go build -o revive-custom ./main.go
运行时启用：
./revive-custom -enable contextparam -config revive.toml ./...
容易踩的坑：
- 忘记导入
github.com/mgechev/revive/lint→ 编译失败，提示找不到lint.Run - 规则名拼写不一致（比如 TOML 里写
[rule.context-param]，但代码中Name: "contextparam"）→-enable无效 - 没加
lint.StdRules()→ 所有原生规则消失，只剩你自己的规则
调试自定义规则时最常遇到的类型解析问题
想判断参数是否为 context.Context，不能只看 AST 中的 *ast.Ident 名字，因为可能来自别名或嵌套导入。正确做法是：
先确保 Requires 包含 typeutil.Analyzer，然后：
if typ := pass.TypesInfo.TypeOf(firstParam.Type); typ != nil {
if named, ok := typ.(*types.Named); ok {
obj := named.Obj()
if obj != nil && obj.Pkg() != nil && obj.Pkg().Path() == "context" && obj.Name() == "Context" {
// 匹配成功
}
}
}
注意点：
-
pass.TypesInfo.TypeOf()对非类型节点（如ast.StarExpr）可能返回nil，需做空值判断 - 导入别名（
ctx "context"）会导致obj.Pkg().Path()是"context"，但obj.Name()是"Context"—— 路径和名字必须分开校验 - 未启用
typeutil.Analyzer时，pass.TypesInfo全为nil，这是最隐蔽也最常发生的调试障碍
复杂点在于：AST 遍历只是起点，真正可靠的语义判断必须依赖类型系统，而类型系统需要显式启用、正确传递、小心解包。漏掉任一环，规则就变成“看起来在跑，实际没效果”。
