启用 var-naming 规则需在 .revive.toml 中显式声明 [rule.var-naming]，设 severity 为 warning/error，并通过 arguments 传入正则（仅校验非导出标识符）；确保文件位于项目根目录、未被禁用、无 BOM/Tab，且 golangci-lint 日志显示配置已加载。
revive 的 var-naming 规则怎么启用和调参
revive 是目前 Go 项目中主流的命名风格检查工具，var-naming 规则是它用来校验局部变量、参数、字段等命名是否符合团队约定的核心规则之一。它不依赖 gofmt 或 goimports，而是基于 AST 分析变量作用域和声明位置，支持正则匹配、大小写策略和上下文判断。
启用前需确认：revive 已在 .golangci.yml 的 linters.enable 列表中，且未被 disable 覆盖；同时项目根目录存在有效的 .revive.toml 配置文件（注意：golangci-lint 会自动加载该文件，无需额外配置路径）。
-
[rule.var-naming]必须显式声明，否则默认不启用 - severity 推荐设为
"warning"或"error"，设为"info"时 golangci-lint 默认不显示 - arguments 支持传入正则表达式，例如
["^[a-z][a-z0-9]*$"]强制小驼峰，但注意：该正则只校验「非导出」标识符；导出名由exported规则单独控制 - 若想统一要求所有变量（含导出）都走同一正则，得同时配
[rule.exported]并给相同arguments
为什么 .revive.toml 里配了还是没报错
常见现象是修改了 .revive.toml 中的 var-naming 规则，但 golangci-lint run 依然不报任何命名问题——这通常不是规则失效，而是配置未被加载或规则被覆盖。
-
.revive.toml文件必须放在项目根目录（与go.mod同级），golangci-lint 不会向上递归查找 - 检查
.golangci.yml是否在linters.disable中写了- revive，或在linters-settings.revive下误加了disable: true - 运行时加
-v参数看日志：golangci-lint run -v，输出里应有类似revive: config loaded from ".revive.toml"的提示；若没有，说明文件未被识别 - revive 默认只检查
.go文件，如果目标变量在_test.go里，而配置中又设置了run.skip-files匹配了测试文件，则会被跳过
golangci-lint 中 revive 和 gofmt 的命名处理边界在哪
很多人混淆 gofmt 和 revive 对命名的干预能力——它们完全不重叠：gofmt 从不修改变量名，只调整空格、换行、import 排序；revive 可以报错，但默认也不改名（即使加 --fix 参数，var-naming 规则也**不支持自动修复**）。
-
gofmt -w不会把myVariable改成myvariable，也不会拒绝编译 -
revive --fix对var-naming无效；它仅对少数规则如indent-error-flow、empty-block等提供 fix 能力，且需在.revive.toml中将对应规则设为severity = "error" - 真正能“自动改名”的方案只有手动写脚本 +
go/ast解析，或用 IDE 的重命名功能（如 VS Code 的 F2）；CI 中只能靠revive卡住不合规范的提交
团队落地时容易忽略的三个细节
命名规范最难的不是配置，而是让所有人写的代码都进同一条流水线。实际踩坑最多的是以下三点：
- CI 中运行
golangci-lint run时未指定配置路径，导致 fallback 到默认启用集（不含 revive），应显式加--config=.golangci.yml -
.revive.toml里用了 tab 缩进或 UTF-8 BOM 头，revive 会静默失败（无报错，但规则不生效），务必用空格缩进、无 BOM 的纯文本 - 有人在
init()函数里写var DB *sql.DB，认为这是“全局变量”就该大写；但 revive 的var-naming把它识别为包级变量（不是局部），走的是exported规则逻辑——这种边界 case 必须在文档里写清楚
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
