golang如何使用go-cleanarch检查架构_golang go-cleanarch检查架构使用详解-Golang-PHP中文网

go-cleanarch是静态检查cli工具，非go包，不参与编译；安装后需确保$gobin在$path中，于项目根目录显式执行，严格校验标准层名与路径格式，支持命令行参数自定义映射但无配置文件。

golang如何使用go-cleanarch检查架构_golang go-cleanarch检查架构使用详解

go-cleanarch 不是用来“运行”或“集成”的库，它是个静态检查 CLI 工具——直接执行就能发现 import 路径越界、层间依赖倒置等硬伤。

它不是 Go 包，不参与编译，也不 import 到你的代码里。安装后生成的是可执行文件，必须在项目根目录下显式调用：

安装命令是 go install github.com/roblaszczak/go-cleanarch@latest，成功后会在 $GOBIN（通常是 $HOME/go/bin）生成 go-cleanarch 二进制
确保 $GOBIN 在 $PATH 中，否则会提示 command not found
不要在代码里写 import "github.com/roblaszczak/go-cleanarch" —— 这会导致 go mod tidy 错误引入，污染生产依赖
Windows 用户注意：官方明确说明未测试，常见报错如 fork/exec: operation not supported，建议改用 WSL2 或跳过该工具

go-cleanarch 对目录命名和层级非常敏感，不是“大概像就行”，而是严格匹配预设规则：

初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。

下载

它默认只识别标准层名：domain、application、interfaces、infrastructure（以及别名如 usecases、adapters），如果你用了 internal/model 或 pkg/repo 这类非标准路径，它直接无视，不会报错，但也不会检查
路径必须是 [MODULE_NAME]/[LAYER_NAME] 形式，比如 github.com/your/app/domain ✅，但 github.com/your/app/internal/domain ❌（多了一层 internal 就失效）
如果项目用了 Go Module 的子模块（如 github.com/your/app/auth 和 github.com/your/app/content），每个子模块都得有独立的 domain 等层，不能只在根模块放一层

它支持自定义层名映射，但必须通过命令行参数显式传入，没有配置文件：

例如你实际用的是 internal/core 代替 domain，就加参数：go-cleanarch -domain=internal/core
多个层需全部指定：go-cleanarch -domain=internal/model -application=internal/service -interfaces=internal/api -infrastructure=internal/infrastructure
参数名必须是它内置的 key（-domain、-application 等），不能写成 -layer-domain 或其他变体
每次运行都要带全参数；它不缓存、不读 .cleanarch.yaml 类配置——这点容易被误以为“没生效”

它只验证 import 方向是否符合同心圆规则（外层可 import 内层，反之不行），但不管具体实现质量：

它不会发现 internal/service 里直接用了 sql.NullString —— 这属于 domain 层污染，得靠人工或 linter（如 revive 规则）
它不会拦截 cmd/main.go 里调了 viper.ReadInConfig() —— 只要 import 没跨层，就认为合法
它不检查 interface 是否真被实现、mock 是否覆盖、error 处理是否统一——这些仍是单元测试和 code review 的责任

真正难的从来不是路径合规，而是把数据库类型、HTTP 上下文、第三方 SDK 响应结构从 domain 和 service 里彻底刨干净。go-cleanarch 只帮你守住第一道门，门后的活还得自己干。