go run 只能直接运行单文件；多文件需显式列出全部或用*.go通配符（非Windows），且必须有package main和func main()，否则报错；临时编译不缓存，效率低于go build。
go run 能直接运行单文件，但多文件必须指定全部
不是所有 .go 文件都能靠 go run main.go 一键跑起来。如果项目拆成了 main.go + handler.go + utils.go，只写 go run main.go 会报错：undefined: someFunc——因为其他文件根本没被加载。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 单文件：直接
go run main.go，最省事 - 多文件同目录：必须列全，比如
go run main.go handler.go utils.go - 想偷懒？用通配符
go run *.go（bash/zsh 支持，Windows cmd 不行） - 注意：
go run会自动忽略_test.go文件，但不会自动排除helper.go这类非测试辅助文件
main 包和 main 函数缺一不可，否则报错“no main module
go run 不是解释器，它仍需构建可执行流程。没有 package main 或缺失 func main()，会直接失败，常见错误信息是：no buildable Go source files in 或更迷惑的 no main module（其实是找不到入口）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 检查第一行是否为
package main（大小写敏感，不能是Package main或package Main） - 确认有且仅有一个
func main()，且在main包内（不能在utils包里写func main()） - 如果用了 Go modules，当前目录下没有
go.mod时，go run会尝试向上查找；但若路径中存在其他go.mod，可能意外进入错误模块上下文
go run 的临时编译产物不缓存，反复执行等于反复编译
每次 go run 都会生成临时二进制并执行，然后立刻删掉。这意味着它比 go build + 手动运行慢，尤其对中大型项目。你感觉“卡了一下”，大概率就是编译花的时间。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 开发调试小脚本（go run 完全没问题
- 涉及 HTTP server、goroutine 密集或依赖 CGO 的场景，启动延迟明显，建议先
go build -o app && ./app -
go run不读取GOOS/GOARCH环境变量做交叉编译（想生成 Windows 二进制？不行），它只面向当前系统构建 - 调试时加
-gcflags="-l"可禁用内联，让断点更准，但别长期开着——影响性能
vendor 和 go.mod 版本约束会影响 go run 行为
有 go.mod 时，go run 严格按其中声明的依赖版本解析，哪怕本地 $GOPATH/src 里有更新的包也不会用。如果 go.mod 锁了旧版 golang.org/x/net，而你代码用了新版 API，就会编译失败。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不确定依赖状态时，先跑
go mod tidy，再go run - 临时绕过模块（比如测试旧代码），可用
GO111MODULE=off go run main.go，但仅限 GOPATH 模式可用，且不推荐 - 用了
vendor/目录？go run默认优先用它，除非加-mod=readonly或-mod=mod - 注意：Go 1.21+ 默认启用
vendoring检查，若vendor/缺文件，go run会直接报错退出
真正容易被忽略的是：当你在子目录里执行 go run ../cmd/app/main.go，Go 仍会以当前目录为工作路径解析 go.mod 和导入路径——不是以 main.go 所在目录为准。这个路径语义偏差，会让很多相对 import 和 embed.FS 踩坑。
