go-cleanarch是静态检查CLI工具，非Go包，不参与编译；安装后需确保$GOBIN在$PATH中，于项目根目录显式执行，严格校验标准层名与路径格式，支持命令行参数自定义映射但无配置文件。
go-cleanarch 不是用来“运行”或“集成”的库，它是个静态检查 CLI 工具——直接执行就能发现 import 路径越界、层间依赖倒置等硬伤。
go-cleanarch 安装后为什么 run 不起？
它不是 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 对目录命名和层级非常敏感，不是“大概像就行”，而是严格匹配预设规则：
- 它默认只识别标准层名：
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等层，不能只在根模块放一层
如何让 go-cleanarch 适配你已有的 Clean 架构目录？
它支持自定义层名映射，但必须通过命令行参数显式传入，没有配置文件：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 例如你实际用的是
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类配置——这点容易被误以为“没生效”
检查结果为 0 代表架构干净？别太早放心
它只验证 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 只帮你守住第一道门，门后的活还得自己干。
