go run无输出或卡住的主因是Windows安全软件（如Comodo）拦截其内存内执行，而非代码或环境问题；需关闭Auto-Containment或为go.exe添加信任规则。
go run 是最直接的方式，但实际用起来常卡在路径、包结构或环境上。只要终端能识别 go 命令，就能运行，否则所有操作都无效。
确认 go 命令可用且环境干净
这是前置硬条件，跳过就白忙：
- 在终端执行
go version，必须输出类似go version go1.22.3 darwin/arm64的结果；如果报command not found，说明 PATH 没配对，不是“装了就行” - 执行
go env GOPATH和go env GOROOT，确认路径存在且可读；尤其 macOS/Linux 用户容易因 shell 配置（~/.zshrcvs~/.bash_profile）漏加载 -
GO111MODULE=on建议显式检查：go env GO111MODULE应返回on；若为auto或off，在模块项目里可能无法解析依赖，go run会失败并报no required module provides package
go run 要求 package main + func main() 在同一目录
常见错误是文件放错位置或包名写错：
- 必须有且仅有一个
package main，不能是package cmd、package myapp或空包声明 -
func main()必须定义在同一个目录下的至少一个.go文件中；go run .会自动收集当前目录所有main包文件，但不会递归子目录 - 如果命令逻辑拆在多个文件（如
main.go+handler.go），它们都得是package main，且不能有未使用的导入（import "fmt"却没调fmt.Println会导致编译失败） - 子命令式结构（如
cmd/mytool/main.go）不能靠go run .运行；得明确指定路径：go run ./cmd/mytool
go run . 和 go run main.go 的行为差异
表面一样，底层处理逻辑不同，影响调试和依赖加载：
-
go run main.go：只编译并运行这个文件，忽略同目录下其他.go文件（哪怕它们也是package main）；适合快速验证单文件改动，但容易漏依赖 -
go run .：按模块语义加载整个当前目录，等价于go run $(ls *.go)（排除测试文件），会校验所有main包文件的导入一致性；推荐日常使用 - 两者都不生成二进制，每次执行都重新编译；若想保留可执行文件，改用
go build -o app . - 传递参数时位置固定：
go run . --port=8080，双横线后的内容才传给程序；写成go run . -port=8080可能被go工具本身消费掉
终端集成场景下的典型陷阱
在 VS Code、GoLand 等 IDE 内置终端里运行，问题更隐蔽：
- IDE 终端可能继承错误的 shell 环境（比如 Zsh 配置了 Go，但 IDE 启动时加载的是 Bash）；可在终端里直接运行
echo $SHELL和which go核对 - VS Code 集成终端默认不启用虚拟终端支持（尤其 Windows PowerShell），导致
termui类库初始化失败；需手动运行$host.UI.RawUI.EnableVirtualTerminalProcessing = $true - 用
go run启动 HTTP 服务后 Ctrl+C 退出，有时进程残留（尤其带 goroutine 未 clean up）；建议加signal.Notify捕获中断，而非依赖默认行为 - 别在管道或重定向里用
go run（如go run main.go | less），这会让os.Stdin不可用，bufio.NewReader(os.Stdin)会阻塞或 panic
go.mod 有没有被识别、终端到底用的是哪个 shell 的环境变量——这些细节不验证，go run 就只是个摆设。 
