Iris仅原生支持iris.YAML加载YAML配置，路径须显式指定、字段名严格匹配PascalCase结构体、环境变量需手动替换；不支持JSON加载，snake_case或${VAR}语法均无效。
Iris 不内置 JSON 配置加载能力，YAML 加载也仅限 iris.YAML 一种方式，且必须手动处理路径、字段名和环境变量 —— 直接用它读 JSON 会 panic，硬塞 YAML 但字段名写错或含 snake_case 则静默失效。
iris.YAML 只能读 YAML，不能读 JSON
调用 iris.YAML("./config.yml") 是 Iris 唯一原生支持的配置加载入口，它底层用的是 gopkg.in/yaml.v2（旧版），不识别 .json 后缀。如果你传入 "./config.json"，会直接报错：yaml: unmarshal errors ... cannot unmarshal object into Go struct。
- 别试图把 JSON 文件改后缀成
.yml混过去 —— JSON 的花括号语法会被 YAML 解析器当成非法映射 - 要读 JSON，必须自己用
json.Unmarshal+os.ReadFile，再手动赋值给iris.Configuration{...} - 推荐封装一个
LoadJSONConfig函数，和iris.YAML并列使用，避免混淆
YAML 字段名必须严格匹配 iris.Configuration 结构体
Iris 的配置结构体字段是 PascalCase，比如 DisableStartupLog、FireMethodNotAllowed。YAML 中写成 disable_startup_log: true 或 firemethodnotallowed: true 都不会生效，也不会报错，只是被忽略。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 字段名区分大小写，
timeformat和TimeFormat是两个东西 - 不支持
json:标签 fallback，yaml:标签也无效 —— iris.YAML 不走 struct tag 反序列化，而是硬匹配字段名 - 多出的字段（如
database_url: "..."）会被完全跳过，别指望它自动注入到全局变量里
环境变量不能在 YAML 里写 ${PORT}，得提前替换
YAML 文件里写 Addr: ":${PORT}" 是无效的。Iris 不做任何字符串展开，${PORT} 就是字面量字符串，最终监听地址变成 ":${PORT}"，启动失败。
- 最简方案：不用 YAML 存端口，直接
iris.Addr(":" + os.Getenv("PORT")) - 若坚持用 YAML，先用
os.ExpandEnv处理原始内容，再喂给yaml.Unmarshal（注意：不能喂给iris.YAML，它不接受 []byte） - 别在 YAML 里混业务配置（如 MySQL 地址）—— 它只管 Iris 自身行为开关，数据库连接该用单独的 config struct 管理
真正容易被忽略的是：YAML 配置只作用于 iris.New() 初始化阶段
你改了 TimeFormat，它只影响 iris.Application 内部日志和时间输出格式；设了 DisableStartupLog: true，也只是关掉那行 “Now listening on...”；但它对中间件、路由注册、数据库初始化这些后续操作毫无影响。
换句话说：YAML 不是你的应用配置中心，只是 Iris 引擎的“启动参数表”。业务逻辑需要的配置（比如 Redis 地址、JWT 密钥），得另起一套机制加载，别贪图省事全塞进同一个文件里 —— 否则调试时根本分不清哪条配置生效了、哪条被 Iris 忽略了。
