应手动用 go mod init 初始化并按 cmd/internal/pkg/api 分层建骨架，因第三方模板常硬编码过时结构、忽略 internal 导入限制或放错 main.go；官方约定经工具链验证，go mod init 必须在建目录前执行。
直接用 go mod init 初始化模块，再按 Go 官方推荐的 cmd、internal、pkg、api 等目录分层建好骨架，比任何插件或模板都可靠、无歧义。
为什么不用第三方模板或 VSCode 插件生成结构
多数插件（如 Go: Generate Module 或社区脚手架）要么硬编码过时结构（比如强塞 src/），要么忽略 internal 的导入限制语义，甚至把 main.go 放错位置导致 go run 失败。Go 官方从不定义“标准工程目录”，但 cmd/ 存可执行入口、internal/ 存私有逻辑、pkg/ 存可复用包——这些是经 go 工具链长期验证的约定，不是风格偏好。
-
cmd/下每个子目录必须含main.go，且package main，否则go build ./cmd/xxx会报no Go files in -
internal/目录名不能拼错（比如写成internals），否则 Go 不会强制阻止跨模块导入，失去封装意义 - VSCode 的
Go: Install/Update Tools里如果装了gopls，它只认真实存在的go.mod和目录层级，不会帮你补结构
手动创建符合官方实践的最小可行结构
在终端中进入项目根目录，逐条执行（别跳步）：
go mod init example.com/myapp mkdir -p cmd/myapp internal/handler internal/repository pkg/utils touch cmd/myapp/main.go internal/handler/handler.go pkg/utils/helpers.go
然后填入最简内容：
-
cmd/myapp/main.go：必须是package main+func main()，否则无法构建为二进制 -
internal/handler/handler.go：用package handler，确保路径与包名一致，避免go list报错 -
go.mod文件里的 module 名建议用真实域名（哪怕本地开发），否则go get或依赖替换会出问题
VSCode 中快速补全和校验的关键点
装好 gopls 后，VSCode 会自动识别结构，但需主动触发校验：
- 按
Ctrl+Shift+P（macOS 是Cmd+Shift+P），输入Go: Verify Go Tools，确保gopls、go版本兼容（1.21+ 推荐） - 右键点击
cmd/myapp目录 →Go: Build Package，看是否输出二进制；失败时先检查main.go是否真在该目录下 - 在
internal/外的任意文件里 import"example.com/myapp/internal/handler"，应被允许；但若在另一个模块里 import 这个路径，go build会直接报错——这是对的，不是 bug
真正容易被忽略的是 go.mod 初始化时机：必须在建任何子目录前运行 go mod init，否则后续 go 命令可能误判模块根路径，导致 go list ./... 漏掉 internal 下的包。
