当 GOPATH 未正确设置或测试包不在 GOPATH/src 下时，Go 工具链无法解析规范导入路径，转而生成形如 `/path/to/pkg` 的临时路径，导致测试输出、覆盖率文件等出现下划线前缀，影响工具链兼容性。
当 `gopath` 未正确设置或测试包不在 `gopath/src` 下时，go 工具链无法解析规范导入路径，导致测试输出、覆盖率文件等出现下划线前缀，影响工具链兼容性。
Go 在执行 go test ./...（或 go build、go run）时，会尝试将每个包的文件系统路径映射为其规范导入路径（canonical import path）。该映射依赖于 Go 的模块感知逻辑和传统 GOPATH 模式下的目录结构规则。
在现代 Go（1.11+）中，若项目启用 Go Modules（即存在 go.mod 文件），Go 默认以模块根目录为基准解析路径，此时 GOPATH 影响减弱；但若项目未启用模块（无 go.mod）或处于 GO111MODULE=off 模式，Go 将严格回退到 GOPATH 模式：只有位于 $GOPATH/src/<import-path> 下的代码才能被识别为合法包，其导入路径才可被正确推导。
当包路径无法映射到有效导入路径时（例如：代码在 /tmp/cnuss/server 但 GOPATH 未设，或设为错误路径），Go 会生成一个合成路径（synthetic path）：以 _/<absolute-filepath> 格式替代，其中 / 被转义为 _（实际是将绝对路径标准化后用 _ 作为前缀标识）。这就是你在 Ubuntu 容器中看到 _/tmp/cnuss/server 的根本原因——Go 认为这不是一个“可导入”的包，仅作临时构建处理。
✅ 正确做法是确保环境符合 Go 的路径约定：
-
方式一（推荐，适用于模块化项目）：启用 Go Modules 并在项目根目录初始化模块
cd /tmp/cnuss/server go mod init github.com/cnuss/server go test ./...
此时无论 GOPATH 是否设置，Go 均以 go.mod 中的模块路径为准，输出 ok github.com/cnuss/server ...。
-
方式二（兼容 GOPATH 模式）：显式设置 GOPATH 并将代码置于 src/ 子目录
export GOPATH=/tmp/cnuss # 注意：GOPATH 应指向工作区根，非 src 目录 mkdir -p "$GOPATH/src/github.com/cnuss/server" cp -r /tmp/cnuss/server/* "$GOPATH/src/github.com/cnuss/server/" cd "$GOPATH/src/github.com/cnuss/server" go test ./...
⚠️ 注意事项：
- 不要将 GOPATH 设为 /tmp/cnuss/server（即包所在目录本身），而应设为上层工作区（如 /tmp/cnuss），再确保代码位于 $GOPATH/src/github.com/cnuss/server；
- 在 CI 容器中，建议统一使用 go mod 方式，并通过 go env -w GO111MODULE=on 强制启用模块模式；
- 验证当前行为：运行 go env GOPATH 和 go env GOMOD，确认模块是否激活；
- 覆盖率工具（如 gocov、codecov）依赖 go test -coverprofile 输出中的包路径，路径异常将导致报告解析失败——修复路径是解决覆盖率中断的前提。
总结：下划线路径是 Go 对“非规范包位置”的降级标识，而非 bug。根源在于环境配置与 Go 包路径模型不匹配。优先采用 Go Modules 方式组织项目，既符合现代 Go 最佳实践，又能彻底规避 GOPATH 相关路径歧义。
