正确顺序是进空目录后执行 go mod init，再创建目录结构；go.mod 不感知手动建目录，vscode gopls 仅识别真实存在的文件和路径。
go mod init 必须在建目录前执行
很多人先 mkdir 再 go mod init，结果 go build 报 no Go files in ./cmd/xxx —— 根本原因是 go mod init 生成的 go.mod 文件不感知后续手动创建的目录结构，工具链无法推导 import 路径。
正确顺序只有一条：进空目录 → go mod init example.com/myapp → 再 mkdir -p cmd/myapp internal/handler pkg/utils。VSCode 的 gopls 只认真实存在的 go.mod 和已创建的目录层级，不会帮你“脑补”结构。
-
go mod init的 module 名建议用真实域名（哪怕本地开发），否则go get或replace指令会失效 - 别跳过
touch cmd/myapp/main.go——cmd/下任意子目录若无main.go或 package 不是main，go build ./cmd/myapp直接失败 -
internal/目录名拼错（比如写成internals）不会报错，但失去 Go 的跨模块导入限制语义，等于白加
VSCode Snippets 适合补单个文件，不是项目骨架
想用 rfc 片段快速生成 React 组件？可以。但指望它生成 src/、public/、tsconfig.json 全套结构？不行。Snippets 是行级/文件级补全，不是项目初始化工具。
真正能生成骨架的是外部脚手架：npx create-react-app myapp、npm create vite@latest myapp -- --template react，VSCode 只负责打开生成后的目录并加载配置。
- Snippets 的价值在“高频小结构”：
useState、useEffect、HTTP handler 模板、Go test 函数骨架 - 自定义 Snippets 必须配
scope（如"scope": "typescriptreact"），否则在 .js 文件里也触发，容易污染 - 团队共用 Snippets 建议存为
.vscode/snippets/并提交 Git，避免靠记忆或口头传递
别依赖插件生成 Go 工程结构
VSCode 插件如 “Go: Generate Module” 或某些社区模板，常硬编码 src/ 目录、把 main.go 放 root、忽略 internal/ 的语义约束——这些结构跑 go run . 可能成功，但 go build ./cmd/xxx 或依赖替换时必然出问题。
Go 官方没定义“标准目录”，但 cmd/、internal/、pkg/ 是经 go list、go build、go mod 长期验证的约定，不是风格偏好。
- 第三方模板若含
src/，直接删掉——Go 1.11+ 的 module 模式下，src/是过时概念 - 插件生成的
main.go若在根目录且 package 是main，它只能go run .，无法被go build ./cmd/xxx引用，破坏可执行入口分离原则 - VSCode 的
Go: Verify Go Tools（Ctrl+Shift+P）只校验gopls和go版本兼容性，不检查目录结构是否合规
调试插件时，package.json 的 engines.vscode 很关键
用 yo code 初始化的插件，package.json 里默认写 "engines": {"vscode": "^1.80.0"}。如果你本地 VSCode 是 1.75.0，调试窗口里 sample.helloWorld 命令根本不会注册，命令面板搜不到——这不是代码问题，是版本锁死。
这个字段不是摆设，它控制插件能否被加载。VSCode 启动时先读 engines.vscode，不匹配直接跳过激活。
- 开发阶段建议设宽松范围：
"^1.70.0"，避免频繁降级编辑器 - 发布前再收紧，比如
"^1.85.0"，配合新 API 使用 -
vsce package打包时会校验该字段，若本地 VSCode 版本低于要求，打包直接失败，不是警告
实际工程中，最易被忽略的是 internal/ 目录的拼写和 cmd/ 下 main.go 的存在性——它们不报编译错误，却让构建和依赖管理在 CI 环境里静默失败。
