golang读取配置文件常用库有viper和ini。viper支持多种格式（如json、yaml、toml等），可自动绑定结构体，适合复杂项目；而ini专注于ini格式，轻量简洁，适合简单场景。1. viper优点包括多格式支持、结构体绑定、配置监听，缺点是学习成本高；2. ini优点为语法清晰、使用轻量，缺点是功能单一、需手动赋值。选择依据：若项目复杂且需多来源配置，选viper；若配置简单且固定为ini，选ini。
在用 Golang 开发应用时，读取配置文件是常见的需求。比如数据库连接信息、服务端口、日志级别等设置，通常都会放在配置文件中，而不是硬编码到程序里。那么问题来了：Golang 如何读取配置文件？有哪些库可以选择？viper 和 ini 这类库又有什么区别？
这篇文章就来聊一聊这个问题。
为什么需要配置文件？
开发一个应用时，我们希望做到“配置与代码分离”。这样做的好处包括：
立即学习“go语言免费学习笔记（深入）”；
- 配置可以灵活修改，无需重新编译代码
- 不同环境（如开发、测试、生产）可以使用不同的配置
- 提高代码可维护性和安全性（比如不把敏感信息写死）
因此，选一个合适的配置管理方式就显得很重要了。
viper：功能全面的通用解决方案
viper 是 Go 社区中非常流行的配置管理库，支持多种配置格式，包括 JSON、YAML、TOML、HCL、envfile 和 Java properties。
优点：
- 支持多种配置格式，扩展性强
- 自动绑定结构体，使用方便
- 可以监听配置变化（适合动态配置）
- 支持从多个来源读取配置（如命令行 flag、环境变量、远程配置中心）
缺点：
- 功能多意味着学习成本略高
- 对于只需要简单 INI 文件的项目来说有点“重”
- 默认行为有时不够直观，需要仔细看文档
示例代码：
type Config struct {
Port int `mapstructure:"port"`
DB string `mapstructure:"db"`
}
var config Config
viper.SetConfigName("config")
viper.SetConfigType("yaml")
viper.AddConfigPath(".")
err := viper.ReadInConfig()
if err != nil {
log.Fatalf("Error reading config file: %v", err)
}
err = viper.Unmarshal(&config)ini：轻量简洁，适合简单场景
如果你的应用只需要读取
.ini格式的配置文件，go-ini 是一个不错的选择。它专注于处理 INI 文件，API 简洁明了。
优点：
- 语法清晰，适合熟悉 INI 格式的人
- 使用起来非常轻量，没有太多额外功能
- 文档和示例都很直接
缺点：
- 只支持 INI 格式，灵活性不如 viper
- 不支持自动绑定结构体（需要手动赋值）
- 没有内置对环境变量、flag 的支持
示例代码：
cfg, err := ini.Load("config.ini")
if err != nil {
log.Fatalf("Fail to read file: %v", err)
}
port, err := cfg.Section("server").Key("port").Int()
db := cfg.Section("database").Key("name").String()viper vs ini：怎么选？
选择哪个库，主要取决于你的项目需求：
-
用 viper 如果：
- 你不确定未来会不会换配置格式
- 需要从多个地方获取配置（如 env、flag、remote 等）
- 希望自动绑定结构体，减少样板代码
- 项目相对复杂或长期维护
-
用 ini 如果：
- 配置很简单，格式固定为 INI
- 你希望保持依赖最小化
- 项目比较小或者只是临时用途
一些细节容易忽略
- viper 的默认配置搜索路径可能不符合预期，建议明确调用
AddConfigPath
- viper 在解析结构体字段时，tag 名默认是字段名的小写形式，也可以通过
viper.SetTagName()
修改 - ini 库虽然不能自动绑定结构体，但可以通过封装简化操作
- 如果你用的是 YAML 或 TOML，viper 更合适；如果是老系统遗留的 INI 文件，ini 更省事
基本上就这些。根据项目的实际需要选择合适的配置库，不需要一味追求功能全，也不必为了轻量牺牲可维护性。
