ci中必须阻断不合规代码而非仅告警；应启用revive的-set_exit_status和staticcheck的--fail-on=unused；评审需聚焦可工具验证的idiomatic go关键点，如defer关闭文件、error包装、channel关闭责任等。

直接看 go vet、golint（或 revive）、staticcheck 三类工具在 CI 中是否真实拦截问题，而不是仅做报告——这是判断规范执行是否落地的最硬指标。

CI 流水线里有没有真正阻断不合规代码？

很多团队把 linter 配置成“只告警不报错”，导致 PR 合并时忽略 warning。这等于评审规则形同虚设。

• golint 已被官方弃用，建议切换到 revive 并启用 -set_exit_status 参数，让违反规则的检查直接返回非零码
• staticcheck 默认不阻断，需显式加 --fail-on=unused 等策略，否则 func unusedFunc() 这类死代码永远进主干
• CI 脚本中要检查命令退出码，不能只靠 echo "lint done" 就算通过

评审清单是否覆盖 Go 惯用法（idiomatic Go）关键点？

规范不是越细越好，而是要卡住那些容易引发 runtime bug 或维护成本飙升的点。

Colly Golang Web Scraper and Crawler Framework

Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。

下载

• 是否强制 defer file.Close() 而非裸写 file.Close()？漏掉 defer 是资源泄漏高频原因
• 是否禁止 if err != nil { return err } 后还继续用该变量？常见于未校验 os.Stat 结果就直接传给 os.Chmod
• channel 使用是否明确关闭责任方？for range ch 在 sender 不 close 时会永久阻塞，必须在发送端关
• error 是否都用 fmt.Errorf("xxx: %w", err) 包装而非拼接字符串？否则 errors.Is() 失效

人工评审是否聚焦可验证行为，而非风格偏好？

把 “函数名用 GetUserByID 还是 FindUserByID” 当评审重点，会稀释对真实风险的关注。

• 评审意见必须能映射到具体工具可检测项：比如指出 “这里没处理 context.DeadlineExceeded”，对应 staticcheck 的 SA1019 规则
• 拒绝模糊表述如 “这个逻辑不够清晰”，应改为 “processData 函数超过 40 行且含三层嵌套，建议拆分为 validateInput + transform”
• 所有要求添加的 json: tag、omitempty、yaml: 必须在 PR 描述中注明字段用途，否则易变成无意义补全

真正难的不是列一百条规则，而是确保每一条都能被工具验证、被新人快速识别、被 reviewer 一句话指出具体位置和改法——否则清单只会堆在 Confluence 里吃灰。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！