c.param() 报 undefined 通常因 gin 版本过低（需 v1.9+）或路由未正确定义为 /user/:id 形式，且 import 必须为 "github.com/gin-gonic/gin"。
go mod tidy 后 still get undefined identifier
这通常不是依赖没拉下来，而是符号根本没被 Go 编译器“看见”。go mod tidy 只管依赖树和 go.sum，不解决 import 路径错、包名错、大小写错这类基础问题。
- 检查
import语句路径是否与目标模块的go.mod中声明的 module path 完全一致（包括大小写和斜杠方向） - 确认你要用的符号（函数/类型/常量）首字母大写——小写字母开头的标识符仅在定义它的包内可见
- 如果引用的是本地模块，确保
replace指向的是含go.mod的目录根，而不是子目录或src下的旧式路径 - 运行
go list -m all看实际加载的模块列表，确认目标模块版本已出现在其中
c.Param() 报 undefined 是 Gin 版本或路由定义问题
c.Param() 不是所有 Gin 版本都默认可用，也不是所有路由都能调用它。它只对带命名路径参数的路由生效，且要求 Gin v1.9+（旧版需手动启用）。
- 确保路由注册时用了冒号语法：
r.GET("/user/:id", handler)，而不是/user?id=123 - 检查
import是否为官方 Gin：必须是"github.com/gin-gonic/gin"，不能是 fork 或拼写错误的路径 - Gin v1.8 及更早版本中，
c.Param()依赖gin.Context的完整实现，若项目混用了 vendor 和 modules，可能加载了不兼容的中间版本 - 临时验证方式：在 handler 里打印
c.FullPath()，看是否匹配你注册的带:的路由模式
undefined type 来自循环 import 或包路径错位
Go 不允许循环 import，一旦发生，编译器会静默丢弃部分类型定义，导致下游报 undefined type，但错误位置往往离真实源头很远。
- 用
go mod graph | grep your-package-name查依赖流向，重点找双向箭头或重复出现的包名 - 常见陷阱：A 包导出一个 struct，B 包定义了该 struct 的 method，然后 A 又 import B —— 这构成隐式循环
- 解决优先级：先尝试把共用类型提到第三个包（比如
models），再让 A/B 分别 import 它；其次考虑用 interface 解耦 - 不要依赖 IDE 自动 import——它有时会补全成
github.com/xxx/yyy/v2，而实际模块声明是v3，版本后缀不匹配即等同于不同包
IntelliJ IDEA 里标红但 go build 正常
这是符号索引未同步，不是代码问题。IDE 的 Go 插件（尤其老版本）常因缓存或 gopls 初始化失败，导致 import 能解析、但具体符号找不到。
- 先执行
File → Invalidate Caches and Restart → Invalidate and Restart，强制重建索引 - 确认 Settings → Languages & Frameworks → Go → Go Modules 中勾选了
Enable Go Modules integration - 检查 Project SDK 是否指向真实 Go 安装路径（不是 symlink 或 /usr/bin/go），gopls 需要读取
$GOROOT/src - 若项目含
replace，确保 IDEA 已识别该替换——可在go list -m -f '{{.Replace}}' your-module输出非空后，重启 IDE
replace 指向了没 go.mod 的目录，或者 import 路径里多了一个 v2 却没在对应模块里声明，这种错不会报“找不到模块”，只会安静地让符号消失。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
