项目中dotenv、YAML、INI、CFG及TOML配置文件的选用场景

dotenv #

• 适用项目：Node.js、Python轻量脚本/小型Web项目，尤其依赖环境变量的项目
• 选择依据：
  • 语法就是KEY=VALUE键值对，上手零成本
  • 天生和环境变量绑定，多数主流框架直接支持加载，适合存单个密钥、API密钥这类简单机密
  • 局限是只能存扁平结构，没法搞嵌套或数组
  • 常规操作是把.env加入.gitignore，避免机密泄露，适合本地开发或单环境配置

YAML #

• 适用项目：云原生项目（Kubernetes、Ansible）、复杂后端服务、需要分层配置的项目
• 选择依据：
  • 支持嵌套结构、数组、注释，能清晰组织复杂配置（比如数据库集群地址、多环境参数）
  • 可读性强，适合存带多个字段的结构化机密（比如服务账号的ID、密钥、权限）
  • 注意点：对缩进极度敏感，写错缩进直接解析失败；存机密时要严格限制文件权限（比如仅所有者可读），防止泄露

INI/CFG（含.conf/.cfg/.config） #

• 适用项目：传统桌面应用、老款后端服务、系统级配置（比如Nginx、Apache的.conf）
• 选择依据：
  • 用[Section]分节，适合按模块拆分配置（比如数据库配置一节、日志配置一节）
  • 兼容性拉满，几乎所有编程语言都有解析库，老项目生态成熟
  • 适合存系统级的配置和机密，比如服务器端口、数据库密码，但不支持复杂嵌套，数组处理起来麻烦

TOML #

• 适用项目：Go生态项目、现代后端服务、Rust生态项目，需要兼顾可读性和结构化的场景
• 选择依据：
  • 结合了INI的分节和JSON的结构化，支持嵌套、数组、注释，比YAML更严谨（没缩进陷阱）
  • 原生支持多环境配置（比如[prod]、[dev]小节），适合跨环境的机密存储
  • 规范清晰，不同语言的解析器行为一致，不会出现YAML那种歧义问题

快速选法 #

• 简单扁平机密/靠环境变量驱动的项目：直接上dotenv
• 复杂结构化配置+云原生场景：选YAML
• 老项目维护/系统级配置：用INI/CFG
• 现代项目要严谨结构化：选TOML

内容的提问来源于stack exchange，提问作者LegsNotHand