几年前写过一篇 如何使你的代码达到 awesome-go 的入选标准。几年过去了，标准和工具都有所变化。
linter 已经换了两代，刚开始是散乱的 golint，go vet，staticcheck，后来出现了 gometalinter，把散乱的工具集集成到一起。
gometalinter 时代，我把这个工具集成到了当时组内所有项目 Makefile 里，合并代码前要求提交者自行执行 make lint 来检查不符合规范的代码并修正，可惜 Makefile 里的命令没有强制约束，某些没有追求的程序员根本不把君子之约当回事，所以难以执行下去。没办法，只要一个人不在乎，就会影响到后来加入的工程师，所有人对自己的要求都会一步一步降低。破窗效应了解一下。
后来我将上线前代码扫描阻断的需求提给效能平台，也被当成低优先级的不重要需求。直到今年离职依然没有能很好地把这些工具集成至上线流程。所以可以想见直至今时今日，大概前东家的工程师们还在不断地碰到各种 err 不处理静默失败，或者 http body 不 close，内存泄露之类的问题。一定每隔一段时间就有人跳出来写诸如《记一次线上内存泄露问题的定位》的弱智文章，并只在文章中炫技，不解决本质问题。
相反，开源社区这几年发展挺快。后来有了比 gometalinter 更流畅，速度更快的 golangci-lint，有了 golangci-lint.com(这个黄了)，现在有了 github action。所以在接收 PR 的时候，有了可以自动审核代码规范和阻断的手段。golangci-lint 官方有 golangci-lint-action，还有功能差不多的 reviewdog。
所以如果你在维护有节操的开源项目的话，可以考虑给你的项目加个 github action 了，试用下来，感觉 reviewdog 是最简单直观的，官方的那个 golangci-lint action 不知道为什么我配的一些参数始终不生效，下面是我的 reviewdog 的配置，和默认的模板配置也没差多少：
name: reviewdog
on: [pull_request]
jobs:
golangci-lint:
name: runner / golangci-lint
runs-on: ubuntu-latest
steps:
- name: Check out code into the Go module directory
uses: actions/checkout@v1
- name: golangci-lint
uses: reviewdog/action-golangci-lint@v1
with:
golangci_lint_flags: "--enable-all --timeout=10m --exclude-use-default=false"
workdir: pkg # 这个如果你的项目没有什么特殊情况，也是不需要设置的
有 PR 提交后会自动执行相应的扫描，并打上 comment：
