Go 多模块仓库测试只跑到一个模块怎么补全

多模块 Go 仓库里，go test ./... 只看到一个模块，通常不是测试框架漏了用例，而是命令的工作目录、go.work 的 use 列表和测试路径没有对齐。补全的关键是：先确认 Go 当前使用的工作区，再把需要联调的模块加入 use，最后按模块执行测试。

不要把 replace 当成“全仓测试开关”。use 决定哪些本地模块属于工作区，replace 只负责把某个依赖改指向另一个来源；CI 最稳妥的做法仍是显式遍历每个模块。

一、先确认 go 命令实际使用的工作区

先在仓库根目录执行下面三条命令。第一条看 Go 找到了哪一个 go.work；第二条把工作区结构展开；第三条列出当前工作区中的主模块。这里不要先改依赖，先把“命令到底看到了什么”确认清楚。

# 查看当前命令实际使用的 go.work；输出 off 表示显式关闭工作区
go env GOWORK

# 展开工作区配置，重点检查 Use 列表
go work edit -json

# 只列出工作区中的主模块，便于和仓库目录逐项对照
go list -m -f '{{if .Main}}{{.Path}} -> {{.Dir}}{{end}}' all

如果 go env GOWORK 返回 off，先检查环境变量或命令前缀；如果返回的路径不是仓库期望的 go.work，说明父目录里可能还有另一份工作区文件。若在模块目录内部执行命令，./... 的自然边界仍然是这个模块，不会因为旁边存在另一个 go.mod 就自动扩大。

二、补齐 go.work 的 use 模块清单

go.work 的 use 指令描述工作区里的主模块。假设仓库有 orders/go.mod 和 shared/go.mod，可以显式加入两个目录：

# 在仓库根目录执行，只加入确实要联调的模块
go work use ./orders ./shared

# 再次列出主模块，确认两个目录都已经进入工作区
go list -m -f '{{if .Main}}{{.Path}}{{end}}' all

如果目录层级稳定，也可以使用 go work use -r . 递归寻找模块。但这个写法会把目录树中符合条件的模块一并加入，仓库里若有实验模块、生成代码目录或不准备联调的子项目，就应改用显式路径。use 的参数指向包含 go.mod 的目录；只加入仓库根，并不等价于把所有嵌套模块都纳入。

三、不要把 replace 当成全仓测试命令

replace 解决的是依赖“从哪里取”。例如把某个版本的依赖改指向本地目录，可以写成下面这样：

// go.work 或 go.mod 中的依赖重定向示例
replace example.com/shared => ./shared

它不会替你枚举仓库中的测试包，也不会把没有写进 use 的模块变成工作区主模块。测试范围和依赖来源是两条不同的线：前者由包模式与当前模块决定，后者由 replace、版本选择和工作区解析共同影响。

因此，全仓测试不要依赖某个根目录的模糊通配符，直接按模块循环更容易定位问题：

# 模块列表是发布仓库的一部分，新增模块时同步维护
modules="orders shared"
for module in $modules; do
  echo "== testing $module =="
  # 每个模块独立展开 ./...，失败时能看到具体模块
  (cd "$module" && go test ./...)
done

四、把多模块测试固定进 CI

本地能通过还不够，CI 应把模块清单和工作区配置一起当作仓库结构维护。一个更谨慎的版本会先确认每个目录确实存在 go.mod，避免目录改名后脚本悄悄跳过：

#!/usr/bin/env bash
set -eu

# CI 只测试明确登记的模块，避免工作目录变化造成漏测
modules="orders shared"
for module in $modules; do
  if [ ! -f "$module/go.mod" ]; then
    echo "missing module file: $module/go.mod" >&2
    exit 1
  fi
  echo "== testing $module =="
  (cd "$module" && go test ./...)
done

落地时保持三处一致：模块目录里有 go.mod，工作区的 use 覆盖需要联调的模块，CI 清单覆盖需要发布的模块。某个模块只作为外部依赖时，可以不放进主模块测试清单，但要在依赖图和发布检查中明确它的版本来源。

相关问题

只写一个 go.work use，能测试子目录里的多个模块吗？

不能直接这样推断。use 指向的是模块目录，嵌套的另一个 go.mod 需要单独加入，或通过 go work use -r 明确递归发现。

把 GOWORK 设置为 off 会发生什么？

Go 会退出工作区模式，命令按当前单模块上下文解析依赖。排查“为什么只测到一个模块”时，先看这个环境变量。

replace 和 use 可以同时存在吗？

可以，但职责不同。use 声明工作区主模块，replace 重定向某个模块版本或模块路径；两者都存在时，应检查是否出现意外覆盖。

为什么 CI 更适合逐模块执行 go test ./...？

因为每个结果都带有明确模块边界，失败日志更容易归因，也不依赖 CI 是否从仓库根目录启动。