golangci-lint 在子模块根目录执行失败，根本原因是其启动时以当前目录为模块根解析 go.mod，若子模块未被主模块 require/replace、GO111MODULE 未启用或 GOPROXY 缺失，将导致 go list 解析失败，进而报“no Go files”或“cannot find module”，即使该目录存在合法 go.mod。
golangci-lint 默认不跨模块扫描，直接在子模块目录下运行 golangci-lint run 就能生效——但前提是该子模块有独立的 go.mod 且已正确初始化配置。
为什么在子模块根目录执行会失败？
常见现象是报错 no Go files in current directory 或 cannot find module providing package。根本原因不是路径问题，而是：
-
golangci-lint启动时默认以当前工作目录为模块根，尝试解析go.mod；若子模块未被主模块replace或require，或未启用GO111MODULE=on，它就看不到该模块的依赖边界 - 即使子模块有
go.mod，若当前 shell 没设置GOPROXY（如GOPROXY="https://goproxy.cn"），go list阶段可能卡住或失败，导致 lint 中断 - 某些 linter（如
staticcheck）需要完整类型信息，若子模块依赖未 resolve，会静默跳过或报错
多模块工程中正确扫描子模块的三种方式
核心原则：让每个子模块“自洽”地被识别为独立构建单元。
- 进入子模块目录后，先确认
go list -m能输出模块名（非command-line-arguments），否则检查go.mod是否存在、内容是否合法（含module github.com/xxx/yyy） - 显式指定配置文件：
golangci-lint run -c ../.golangci.yml（若共享父级配置）或在子模块内放独立的.golangci.yml；不加-c时它只向上查找，不会跨目录继承 - 避免用
golangci-lint run ./submodule/从父目录调用——这会让工具把子模块当普通目录处理，不触发模块感知逻辑；必须cd submodule && golangci-lint run
CI 中批量扫描多个子模块的实操写法
GitLab CI / GitHub Actions 里不要硬编码路径，用 go list 动态发现：
find . -name "go.mod" -exec dirname {} \; | while read moddir; do
echo "Running lint in $moddir";
cd "$moddir" && GOPROXY="https://goproxy.cn" golangci-lint run --timeout=3m || exit 1;
cd - > /dev/null;
done
关键点：
-
find . -name "go.mod"比手动列目录更可靠，尤其当子模块嵌套或命名不规范时 - 每次
cd后显式设GOPROXY，防止因环境变量缺失导致go list失败 -
--timeout=3m必须设，子模块若含大量生成代码或 vendor，容易超时（默认 1m）
容易被忽略的坑：replace 和本地依赖
若主模块用 replace example.com/lib => ./lib，而你在 ./lib 子模块单独跑 golangci-lint，它不会自动加载主模块的 replace 规则——这意味着：
- 子模块内引用的
example.com/lib/internal若实际来自主模块路径，go list可能找不到，报imported and not used类误报 - 解决方案只有两个：要么在子模块的
go.mod中也加相同replace；要么暂时删掉replace，用require+go get拉取真实版本再扫 - 另一个绕过方式是加
--build-tags=ci并在代码里用//go:build ci控制 import，但这属于侵入式改造，慎用
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
