答案是当前目录不在go.work所在根目录下导致工作区未生效。go只在含go.work的当前目录启用工作区模式，进子目录后退化为单模块模式，故报“module xxx is not in main module”；所有命令须在根目录执行，且ide需正确识别该目录为工作区起点。
go build 报 “module xxx is not in main module” 不是模块写错了，而是工作区根本没生效。
go.work 没被识别？检查当前目录和执行路径
这个错误只说明一件事：你不在 go.work 所在的根目录下运行命令。Go 工具链不会递归向上找 go.work，它只认当前目录或其父目录里有没有该文件——而且仅当它就在当前目录时才启用工作区模式。
- 执行
ls go.work，必须有输出；如果没有，说明你 cd 进了子模块目录（比如./api或./cmd/app），不是根目录 - 所有命令（
go build、go test、go list -m all）必须在含go.work的目录下执行，不能进子目录再跑 -
go work use ./api中的路径必须是相对路径，且以.开头；写成api或/full/path/api都会失败 - 删掉子模块
go.mod里的replace行——工作区模式下它会被忽略，反而干扰本地改动同步
IDE 里 gopls 报 “no module found”？工作区和编辑器打开方式不匹配
VS Code 或 GoLand 显示类型为空、跳转失效、import 不补全，90% 是因为编辑器把整个仓库当单个文件夹打开，而 gopls 实际需要的是模块根（含 go.work 的目录）作为工作区起点。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- VS Code：不要用 “Open Folder” 直接打开仓库根；改用 “File → Add Folder to Workspace…” 逐个添加
./main、./lib等子模块目录，再在设置里加"go.toolsEnvVars": { "GOFLAGS": "-mod=mod" } - GoLand：右键点击含
go.work的目录 → “Mark Directory as → Go Module Root” - 开命令面板，运行 “Go: Toggle Logs”，确认
gopls启动时的working directory确实是go.work所在路径 - 如果用了 Multi-root Workspace，务必关闭 “Auto-add modules on open”，否则每个子目录单独初始化，直接绕过
go.work
go version 和 go.mod 版本不一致？别改 go.mod，切 Go 二进制
go: cannot use go 1.21.6 with go 1.22 mod 不是警告，是构建早期硬拦截。Go 不会降级兼容，也不会自动升级你的 Go 安装——它只看你当前 go 命令的版本是否 ≥ go.mod 第一行声明的版本。
- 检查
go version输出，再看go.mod第一行（如go 1.22），两者必须满足 ≥ 关系 - 切换方式优先用
gvm use go1.22.3（自动写.gvmrc），或手动设GOROOT=/path/to/go1.22.3+PATH=$GOROOT/bin:$PATH - 验证
go env GOROOT输出是否与预期一致，避免软链接残留或 PATH 顺序错乱 - 新版 Go（1.17+）已不依赖全局
GOROOT，手动设反而容易卡死切换逻辑——Linux/macOS 彻底删掉export GOROOT=行，Windows 别在系统变量里设
真正麻烦的从来不是多版本共存，而是工作区边界模糊、IDE 路径误判、以及把 go.mod 的 go 指令当成建议而非约束。只要确保 go.work 在根、命令在根、IDE 认准根、Go 二进制版本 ≥ 声明值，模块混乱就只是路径问题，不是版本问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
