conf/app.conf 必须位于项目根目录且路径准确，Beego 不自动向上查找；配置分节需用双冒号显式指定如"dev::httpport"；Int()等类型转换失败时静默返回零值，须手动校验。
conf/app.conf 文件必须存在且路径正确
Beego 默认只读取项目根目录下 conf/app.conf，不会自动向上查找或 fallback 到其他位置。如果文件缺失或路径写错（比如放在 config/ 或 etc/），beego.AppConfig 会静默失败，所有 String()、Int() 调用都返回零值或空字符串，但不报错。
常见错误现象：beego.AppConfig.String("httpport") 返回空字符串，导致服务监听在默认 8080 而非配置的 9000；beego.AppConfig.String("mysqluser") 返回空，连接数据库时认证失败。
- 确认文件真实存在于
conf/app.conf（注意是小写 conf，不是 Config 或 configuration） - 确保项目在
$GOPATH/src/yourapp下启动，否则 Beego 可能无法定位 conf 目录 - 不要用 symlinks 指向 conf 目录——Beego 的文件读取逻辑不处理符号链接解析
配置分节（section）和作用域语法要严格匹配
Beego 支持 [dev]、[prod] 等分节，但读取时必须显式带标签前缀，例如 beego.AppConfig.String("dev::httpport")。漏掉双冒号 :: 或写成单冒号 : 都会导致读取失败，返回空。
更隐蔽的问题是：若当前 runmode = dev，但代码里调用的是 beego.AppConfig.String("prod::httpport")，它仍会尝试读取，只是该 key 不存在——Beego 不做 runmode 自动路由，全靠你手动拼接。
- 获取当前运行模式用
beego.AppConfig.String("runmode")，再动态拼接 section 名 - 全局变量（如
appname）可直接读，无需 section 前缀；但一旦被包进[dev]里，就必须加dev:: - 分节内不能嵌套，
[dev.mysql]是非法语法，Beego 会跳过整段
类型转换函数必须与实际值兼容
beego.AppConfig.Int("httpport") 看似简单，但只要配置值含空格、字母或单位（如 httpport = "8080 " 或 httpport = 8080ms），就会返回 0 并静默丢弃错误。它不抛 panic，也不记录 warning，极易埋下线上隐患。
尤其注意浮点型和布尔型：Beego 没有原生 Bool() 方法，String() 返回 "true" 后需手动比较；Float64() 对 "1.5e2" 这类科学计数法也常失败。
- 始终对
Int()/Float64()的返回值做有效性校验，比如if port - 布尔配置建议统一用字符串枚举：
enable_cache = "on"，然后用strings.EqualFold(appConfig.String("enable_cache"), "on") - 避免在配置中使用注释行以
#开头——Beego 的 parser 会把整行当 key-value 解析，导致后续键值偏移
热重载不刷新 AppConfig 缓存
开发时用 bee run 修改 conf/app.conf 后，Beego 不会自动 reload 配置。你看到的仍是进程启动时加载的旧值。这是最常被忽略的“配置没生效”原因。
根本原因是 beego.AppConfig 在 init() 阶段完成一次性加载，之后所有 String()、Int() 都是从内存 map 中取，不重新读文件。
- 修改配置后必须手动重启
bee run，Ctrl+C 再执行一次 - 若需运行时重载，得自己实现：监听文件变更，调用
beego.LoadAppConfig("ini", "conf/app.conf")强制重载 - 别依赖
bee run -d的自动编译——它只 watch .go 文件，完全不监控 .conf
配置项解析发生在框架初始化极早期，一旦错过时机就无法补救。哪怕只多一个空格、少一个冒号，都可能让整个服务连不上数据库或监听错端口——这些细节不报错，却直接决定程序是否可用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
