最常见原因是当前工作目录与预期不符，os.Open基于os.Getwd()而非源文件位置解析路径；应先打印os.Getwd()确认，再用os.Executable()或filepath.Abs+os.Args[0]推导可执行目录并拼接绝对路径。
为什么 os.Open 报错 “no such file or directory”
Go 程序启动时找不到配置文件，最常见原因是当前工作目录（os.Getwd()）和你预期的路径不一致。比如你双击运行二进制、用 systemd 启动、或在 IDE 里调试时，当前目录可能是用户主目录、/、或项目根目录之外的任意位置——而 Go 不会自动从可执行文件所在目录去查配置。
实操建议：
- 先打印
os.Getwd()确认当前路径，别猜 - 避免硬写相对路径如
"config.yaml"或"./config/config.toml" - 优先用绝对路径，或基于可执行文件位置推导路径
- 用
filepath.Abs(filepath.Dir(os.Args[0]))获取二进制所在目录，再拼接配置文件名
如何可靠获取可执行文件所在目录
os.Args[0] 是启动命令的第一段（通常是二进制路径），但它可能不含目录（比如只写了 "myapp"），也可能被软链接指向。稳妥做法是先 filepath.EvalSymlinks，再取其父目录。
示例代码片段：
立即学习“go语言免费学习笔记（深入）”；
exePath, err := os.Executable()
if err != nil {
log.Fatal(err)
}
exeDir, err := filepath.EvalSymlinks(filepath.Dir(exePath))
if err != nil {
log.Fatal(err)
}
configPath := filepath.Join(exeDir, "config.yaml")
_, err = os.Stat(configPath)
if os.IsNotExist(err) {
log.Fatalf("config not found at %s", configPath)
}
注意：os.Executable() 在某些环境（如 Windows 下通过 cmd /c 调用、或某些容器场景）可能返回空或错误，此时需 fallback 到 os.Args[0] + filepath.Abs 组合。
使用 viper 时仍报找不到配置的常见原因
viper 默认不会自动搜索配置文件位置，它只按你显式设置的路径或搜索路径列表去找。如果你调用了 viper.ReadInConfig() 却没提前设好路径，它只会查默认名（config）+ 默认格式（json/yaml/toml）+ 当前目录，非常容易失败。
实操建议：
- 显式调用
viper.SetConfigFile("/absolute/path/to/config.yaml")最省心 - 若要用自动发现，必须提前调用
viper.AddConfigPath("/path/to/config/dir")，且确保该路径存在 -
viper.SetConfigName("app")和viper.SetConfigType("yaml")要匹配真实文件名和扩展名 - 检查
viper.ReadInConfig()返回的 error，不要忽略它——viper.ConfigFileNotFoundError是常见提示
打包进二进制后配置文件消失怎么办
用 go build 编译后，外部配置文件不会自动打进二进制。如果想“自带配置”，有两条路：
一是用 embed（Go 1.16+）把配置文件编译进程序：
import _ "embed"
//go:embed config.yaml
var configData []byte
func loadConfig() (*Config, error) {
return yaml.Unmarshal(configData, &cfg)
}
二是改用 packr 或 statik 等第三方工具（但 embed 更轻量、标准、无额外依赖）。
注意：embed 只支持读取已知静态文件，无法动态更新；若需热重载配置，还是得走外部文件 + 监听机制（如 fsnotify）。
最容易被忽略的一点：开发时用 go run main.go，embed 的路径是相对于 go run 所在目录的；而 go build 后运行，embed 内容已固化——这两者行为一致，但开发者常误以为需要额外处理路径。
