buffalo 不自动加载 config.yml 等自定义 yaml 文件，需手动用 gopkg.in/yaml.v3 解析并初始化全局变量；database.yml 和 .env 有专用处理逻辑，其他配置须在 app.go 中显式读取、反序列化，并避免在 handler 中重复解析或期望热更新。
Buffalo 项目里怎么加载 config.yml 这类自定义配置文件
Buffalo 默认只读 database.yml 和环境变量，不自动加载任意命名的 YAML 配置文件。想用 config.yml 或 app.yml，必须手动解析并注入到应用上下文里。
常见错误现象：直接把 config.yml 放进 config/ 目录，运行时完全没反应；用 viper.Get("xxx") 拿不到值——因为 Buffalo 没集成 Viper，也不调用它。
- Buffalo 的配置加载逻辑集中在
app.go初始化阶段，它只对database.yml做了硬编码支持 - 所有其他配置都得你自己读、自己解析、自己挂到全局变量或
buffalo.App实例上 - 推荐用标准库
gopkg.in/yaml.v3（不是v2），避免 struct tag 解析失败
示例：在 app.go 开头加一段：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
import (
"io/ioutil"
"gopkg.in/yaml.v3"
)
type Config struct {
APIKey string `yaml:"api_key"`
Timeout int `yaml:"timeout_sec"`
}
var AppConfig Config
func init() {
b, _ := ioutil.ReadFile("config/config.yml")
yaml.Unmarshal(b, &AppConfig)
}
为什么不能直接用 buffalo pop 或 env 加载自定义配置
buffalo pop 只管数据库迁移和连接池初始化，.env 文件只被 os.Getenv() 读取，两者都不解析 YAML 结构。你往 .env 里写 CONFIG_API_KEY=xxx 是可以的，但一旦配置项变多、嵌套变深（比如 redis.url、redis.timeout），就很难维护。
-
database.yml被特殊对待，是因为popORM 强依赖它；其他 YAML 文件没有对应模块驱动加载 -
os.Getenv()适合扁平键值，不适合结构化配置（如数组、嵌套 map） - 如果坚持用环境变量，建议用前缀隔离：比如
MYAPP_API_TIMEOUT=30、MYAPP_REDIS_URL=redis://...
在 handler 里安全访问自定义配置的正确姿势
别在每个 actions/*.go 文件里重复 ioutil.ReadFile —— 既慢又容易 panic。配置应该只加载一次，在 app.go 或独立 config/config.go 中完成，并导出为包级变量或通过 buffalo.Context 注入。
- 最简方式：导出一个全局变量
config.AppConfig，handler 直接引用（注意并发安全：只读，不修改） - 更可控方式：在
app.Use()中间件里把配置塞进c.Set("config", AppConfig)，然后 handler 用c.Param("config").(Config)拿 - 避免在 handler 里做
yaml.Unmarshal：IO + 反射开销大，且错误处理分散
真正容易被忽略的是配置热更新。Buffalo 没提供 reload hook，buffalo dev 会监听文件变化并重启进程，但如果你手动改了 config.yml 并期望 runtime 生效，那是不会发生的——必须重启服务。
