go run不是解释器，每次执行都会重新编译并立即运行临时二进制，因此“卡顿”实为编译耗时；报“no buildable Go source files”主因是缺失package main或func main()，需确保首行为小写package main且main函数唯一存在于main包内。
go run 不是解释器，它每次都在重新编译——所以你感觉“卡”，不是终端卡，是编译花的时间。
go run main.go 报 “no buildable Go source files” 怎么办
这通常不是路径错了，而是文件里缺了 package main 或 func main()。Go 对入口要求严格：
- 第一行必须是
package main（全小写，不能有空格或大小写错误） - 必须有且仅有一个
func main()，且必须在main包内（不能写在utils包里） - 如果文件名是
server_test.go或带_test后缀，go run会直接跳过它 - 检查是否误用了
import "."或import "./xxx"——Go 不支持相对路径导入，运行时 panic 是早晚的事
多文件项目用 go run *.go 为什么在 Windows 上失败
因为 cmd.exe 不展开 * 通配符，go run *.go 会被字面传给 go 工具，而 Go 在 Windows 上找不到叫 *.go 的文件。
- Windows 用户请显式列出：
go run main.go handler.go utils.go - macOS/Linux 用户可用
go run *.go，但注意它会包含所有.go文件（包括你忘了删的临时测试文件） - 更稳妥的做法是
go run .：它按模块结构自动识别整个包，不依赖文件名顺序，也跳过_test.go - 如果项目用了子模块（如
myproject/api），go run .只跑当前目录，要跑子包得进对应目录或写go run api/*.go
go run 编译慢、调试断点不准，怎么调优
默认行为是优化优先，对调试不友好。关键参数就两个：
立即学习“go语言免费学习笔记（深入）”；
- 加
-gcflags="-l"禁用函数内联，让源码行和机器指令对齐，断点能打准 - 加
-ldflags="-s -w"去掉符号表和调试信息，可小幅提速（尤其对含 CGO 的项目） - 别长期开着
-gcflags="-l"：它会让编译变慢，且生成的二进制无法做性能分析（pprof 失效） - 如果频繁改代码又反复
go run，说明已超出脚本范畴——该切到go build -o app && ./app了
GOOS=linux go run main.go 为什么没用
go run 完全忽略 GOOS/GOARCH 环境变量。它只面向当前系统构建并立即执行，交叉编译是 go build 的事。
- 想在 macOS 上生成 Linux 二进制？只能用
GOOS=linux go build -o app-linux - 但注意：一旦设了
GOOS=linux，所有依赖包都必须支持 Linux 平台，否则可能静默跳过某些文件，或运行时 panic（比如用了 Windows-only 的 syscall） - 常见陷阱：本地开发用
net包 + macOS，交叉编译到 Linux 后 DNS 解析失败——得加-tags netgo强制纯 Go 实现 - 如果你真需要跨平台快速验证逻辑，建议用 Docker：
docker run --rm -v $(pwd):/src -w /src golang:1.26 go run main.go
最常被忽略的一点：go run 的临时编译产物虽然自动清理，但它仍会读取 go.mod 锁定的版本、尊重 vendor/ 目录、受 CGO_ENABLED 控制——它不是“绕过构建系统”的捷径，而是构建系统的一个受限视图。
