ini适合简单扁平配置，yaml适合嵌套结构、类型支持及多人协作；选错格式后期维护成本极高。

直接说结论：ini 适合简单、层级扁平的配置（比如工具脚本、小项目开关）；yaml 更适合有嵌套结构、需要类型支持或多人协作的项目（如 Flask/Django 服务、CI/CD 配置）。选错格式，后期改起来比写代码还累。

ini 文件用 configparser 读取时为什么总报 NoSectionError

这不是语法错误，而是 configparser 默认要求文件必须以显式 section 开头（如 [database]），连空行在开头都会导致解析失败。另外，它不支持注释缩进、不识别布尔值或数字类型——debug = true 读出来永远是字符串 "true"。

• 确保第一行是 [section_name]，不能有 BOM 或前置空格
• 用 config.getboolean("section", "debug") 替代直接取值，否则所有值都是字符串
• 避免在 key 后加空格：host = localhost ✅，host =localhost ❌（会把等号当 value 一部分）
• 如果需要默认值，别依赖 get(..., fallback=...) —— 它只对缺失 key 生效，对缺失 section 完全无效

yaml 文件用 PyYAML 加载后字典里全是字符串？

PyYAML 默认使用 SafeLoader，它为了安全会禁用自动类型推断。所以 port: 8000 和 debug: yes 全变成字符串，而不是 int 或 bool。

• 明确指定 Loader=yaml.CSafeLoader（推荐）或 Loader=yaml.FullLoader（仅限可信源）
• 更稳妥的做法是定义数据结构并用 pydantic 或 dataclasses 做校验和类型转换，而不是依赖 YAML 自动识别
• 注意缩进：YAML 对空格敏感，用 2 空格缩进最安全；Tab 字符会导致 ScannerError
• 不要在值里混用单引号和双引号来“转义”——YAML 不是 shell，path: "/home/user" 和 path: '/home/user' 效果一致

什么时候该放弃 ini 改用 yaml？

不是“功能多就上 yaml”，而是当 ini 的局限开始影响开发节奏时——比如你发现自己在 config 里拼接 JSON 字符串、反复写 json.loads(config.get("extra"))，或者同事 PR 里改个配置要先查文档确认字段嵌套规则。

• 需要数组：ini 没法表达 hosts = ["a.com", "b.com"]，只能退化成 host1=a.com\nhost2=b.com
• 需要嵌套结构：数据库配置含 pool 子项、日志配置含 handlers 列表，ini 只能靠命名模拟（log_handler_file_path），可维护性直线下降
• 配置要被其他语言读取：CI 工具、K8s、前端构建脚本普遍原生支持 YAML，但几乎不认 ini
• 团队已有 YAML 规范（如 GitHub Actions、Docker Compose），强行统一格式能减少认知成本

import yaml
推荐加载方式（安全 + 类型保留）
with open("config.yaml") as f:
cfg = yaml.load(f, Loader=yaml.CSafeLoader)
示例 config.yaml 内容：
database:
host: localhost
port: 5432
ssl: true
features:
- auth
- rate_limit

真正难的不是读配置，而是让不同环境（dev/staging/prod）的配置差异可控、可审计、不泄漏密钥。ini 和 yaml 都只是容器，关键看你怎么组织目录、怎么注入变量、怎么防止 config.yaml 误提交到 Git —— 这些问题，换什么格式都绕不开。