Go项目编译不报错却找不到可执行文件，是因为go build默认将二进制输出到当前工作目录而非模块根目录；多级目录下需用go build -o指定路径或在正确目录执行，且模块路径必须与import路径一致。
Go 项目编译不报错但找不到可执行文件？多半是没搞清 go build 的输出行为，尤其在多级目录结构下。
go build 默认不输出到当前目录
很多人在 src/github.com/user/project/cmd/app 这类嵌套路径下执行 go build，发现命令没报错，但当前目录里没有生成 app 可执行文件——因为 go build 默认把二进制写在当前工作目录，而 Go 模块根目录（含 go.mod）未必是当前目录。
- 如果当前在
cmd/app目录，且该目录下有main.go，go build会生成可执行文件在./app（Linux/macOS）或./app.exe（Windows） - 如果当前在项目根目录（即
go.mod所在目录），执行go build ./cmd/app才会把结果放在当前目录；若只写go build，它只会编译当前包（通常是库包），不生成可执行文件 - 想明确控制输出位置，必须用
-o参数：go build -o ./bin/app ./cmd/app
多级目录下 go run 的路径限制
go run 要求目标必须是 main 包，且不能跨模块边界运行。常见失败场景：
- 在
cmd/app目录执行go run .：可行，前提是该目录下有main.go且package main - 在项目根目录执行
go run cmd/app：可行，Go 会自动定位到cmd/app/main.go - 在
internal/service目录执行go run ..或go run ./...：失败，go run不支持递归查找main函数，也不允许运行非main包 - 如果
cmd/app依赖internal/下的代码，只要模块路径正确、go.mod已声明依赖，go run cmd/app就能正常编译运行
GOPATH 模式已淘汰，别再手动建 src/pkg/bin
Go 1.16+ 默认启用模块模式（GO111MODULE=on），GOPATH 仅用于存放 go install 安装的二进制工具（如 dlv、gopls），不再约束项目源码位置。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 项目可以放在任意路径，只要包含
go.mod文件，就视为一个模块 - 旧教程里强调的
$GOPATH/src结构已无必要；强行套用反而导致go get失败或版本混乱 -
go install命令现在只接受模块路径（如github.com/user/project/cmd/app@latest），不再支持相对路径或本地目录 - 若仍看到
cannot find module providing package错误，大概率是当前目录没go.mod，或go.mod里没声明对应 import 路径
go build 编译多 cmd 子目录的典型流程
一个标准模块通常有多个可执行入口，比如 cmd/api、cmd/cli、cmd/admin。统一构建需分步操作：
- 确保项目根目录有
go.mod，且每个cmd/*目录下都有独立的main.go和package main - 批量构建所有
cmd：执行go build -o ./bin/ ./cmd/...（注意末尾/...表示递归匹配子目录） - 单个构建并指定名称：
go build -o ./bin/myapi ./cmd/api - 避免用
go build ./...：它会尝试编译所有包（包括internal、pkg），遇到非main包直接报错 - 交叉编译时加
GOOS/GOARCH，例如：GOOS=linux GOARCH=amd64 go build -o ./bin/app-linux ./cmd/app
真正容易被忽略的是：模块路径（module github.com/user/project）和实际 import 路径必须一致；哪怕目录结构完全正确，只要 go.mod 里写的模块名和代码中 import 的路径对不上，go build 就会静默失败或报错找不到包。
