应重新用vs code直接打开含go.mod的项目根目录；确认go.mod存在且含module和go版本声明；若仍不识别，执行go: restart language server；导入本地子模块须用完整模块路径，不可用相对路径或短名。
VS Code 打开项目后提示 “No modules found” 怎么办
这不是环境变量没配好，而是工作区没对准模块根目录。VS Code 的 Go 插件（gopls）只在当前打开路径下扫描 go.mod，如果打开的是父级文件夹（比如 ~/projects），而项目实际在 ~/projects/myapp 里，gopls 就找不到模块。
解决方法很简单：
- 关闭当前窗口，重新用 VS Code 直接打开含
go.mod的那一层目录（即项目根） - 确认
go.mod文件存在且内容完整：至少有module example.com/myapp和go 1.23两行 - 如果
go.mod只有module example.com/myapp，运行go mod tidy补全依赖和版本声明 - 仍不识别？按
Ctrl+Shift+P→ 输入Go: Restart Language Server强制重载gopls
导入本地子模块时 import 路径报错 “cannot find package”
常见现象是：项目结构为 ./cmd/main.go 和 ./internal/utils/utils.go，在 main.go 里写 import "utils" 或 import "./internal/utils"，结果编译失败。根本原因不是路径写法错，而是没用模块路径导入。
Go Modules 下所有 import 必须以 module 声明的前缀开头：
- 假设
go.mod第一行是module github.com/you/project，那正确导入是import "github.com/you/project/internal/utils" - 不能省略前缀，也不能用相对路径（如
./internal/utils）或短名（如utils） - 子目录（如
cmd或internal）本身不构成模块，只是包目录，必须通过完整模块路径引用
想调试本地修改的依赖库，replace 怎么写才生效
replace 是临时替换远程模块为本地代码的唯一安全方式，但写错就完全不生效。最常踩的坑是路径错误或目标缺失 go.mod。
正确写法要满足三个条件：
-
replace右侧必须是相对于当前go.mod的相对路径（如../myutils）或绝对路径（如/home/user/myutils），不能用~/myutils - 被替换的本地目录（如
../myutils）必须已有go.mod文件；没有的话，进去执行一次go mod init github.com/you/myutils -
replace不会自动传播给下游模块，只影响当前项目构建；发布前应删掉它，改用require github.com/you/myutils v0.2.0
go env GO111MODULE=auto 导致同一命令行为不一致
这是编辑器里依赖解析出问题的隐藏元凶。当 GO111MODULE=auto 时，go run 在 $GOPATH/src 下会退化为 GOPATH 模式，在别处又启用 Modules —— 同一个命令，在不同路径下可能走两套完全不同的包查找逻辑。
必须强制设为 on：
- 运行
go env -w GO111MODULE=on - 检查 shell 配置文件（如
~/.zshrc）是否残留了export GO111MODULE=off，删掉 - 重启终端或执行
source ~/.zshrc，再验证go env GO111MODULE输出是否为on
模块路径和 import 语句的对齐，比语法错误更难排查——因为编译器不会说“你 module 写错了”，只会模糊报“package not found”。盯住 go.mod 第一行和每一行 import 开头是否完全一致，是最有效的排查起点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
