主因是项目未初始化Go模块，需在根目录执行go mod init并配置正确模块名，再用go get拉取beego/v2依赖，确保导入路径、文件结构与go.mod声明严格一致。
go mod 未初始化是飘红主因
IDE 显示 github.com/beego/beego/v2 等包名下有红线，90% 情况不是 Beego 本身问题，而是项目没走模块化流程。Go 1.11+ 默认启用 go mod，但不会自动创建 go.mod 文件——没有它，go get 下载的包不会被当前项目识别，IDE 自然索引不到。
验证方法：在项目根目录运行 go list -m。如果报错 go: not using modules 或直接无输出，说明模块未激活。
- 执行
go mod init your-module-name（模块名建议与实际导入路径一致，如example.com/myapp） - 再运行
go get github.com/beego/beego/v2@latest，确保依赖写入go.mod - 别用相对路径导入本地包，比如
./controllers—— 必须写成your-module-name/controllers
导入路径写错导致找不到包
Beego v2 的导入路径和 v1 完全不兼容，混用必报错。常见错误包括：
- 误写成旧版路径：
github.com/astaxie/beego→ 正确应为github.com/beego/beego/v2 - 漏掉
/v2后缀，例如github.com/beego/beego→ Go 模块系统会拒绝解析 - 控制器或路由包路径拼错，比如
import _ "myapp/routers"，但实际目录是myproject/routers，路径必须字面匹配
检查方式：打开 go.mod，确认 require 行里 Beego 版本是否带 /v2；再核对 main.go 中所有 import 语句的字符串是否与文件系统路径、go.mod 声明完全一致。
bee 工具命令未生效或 GOPATH 冲突
bee new 创建的项目默认启用模块，但如果你手动新建项目又沿用旧习惯配了 GO111MODULE=off 或设置了 GOROOT/GOPATH，就会触发双模式混乱：go 认为你在用老式 GOPATH 模式，而 IDE 又按模块路径索引，结果两边都找不到包。
- 统一关闭 GOPATH 依赖：运行
go env -w GO111MODULE=on和go env -w GOPROXY=https://goproxy.cn,direct - 删掉项目里可能残留的
GOPATH相关配置（尤其 Goland 的 Project Settings > Go > GOPATH） -
bee工具本身也要用 v2 版本：go get -u github.com/beego/bee/v2，否则生成的脚手架仍可能套用 v1 路径
routers 包未触发 init() 导致路由注册失效
即使包导入无误、代码能编译，运行时仍可能看到日志里反复打印 | GET | / | | notmatch | —— 这不是导入报错，但 IDE 里常伴随控制器类名飘红，因为路由没注册成功，控制器根本没被加载。
根本原因是：Go 不会加载未被引用的包，routers/router.go 里的 init() 函数就不会执行，beego.Router() 也就 never run。
- 必须在
main.go的import块中添加空白导入：_ "your-module-name/routers" - 确保该路径与磁盘上
routers文件夹位置严格对应（大小写、层级、拼写） - 临时加一行
fmt.Println("routers loaded")在routers/init()里，启动时没这行输出就说明导入失败
模块路径、导入字符串、文件系统结构这三者必须咬死对齐，差一个字符都会让整个链路静默中断——这是最隐蔽也最常被忽略的一环。
