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。
git-staged-commit-message
下载
仅从仓库的暂存文件生成 Git 提交消息。当用户要求 Codex 根据暂存更改、缓存差异、Git 索引或已通过 `git add` 添加的文件来编写、起草、创建或建议提交消息时使用；切勿代表用户执行提交操作。
- 明确指定
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 里改个配置要先查文档确认字段嵌套规则。
立即学习“Python免费学习笔记（深入）”；
- 需要数组：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
<h1>推荐加载方式（安全 + 类型保留）</h1><p>with open("config.yaml") as f:
cfg = yaml.load(f, Loader=yaml.CSafeLoader)</p><h1>示例 config.yaml 内容：</h1><h1>database:</h1><h1>host: localhost</h1><h1>port: 5432</h1><h1>ssl: true</h1><h1>features:</h1><h1>- auth</h1><h1>- rate_limit</h1>真正难的不是读配置，而是让不同环境（dev/staging/prod）的配置差异可控、可审计、不泄漏密钥。ini 和 yaml 都只是容器，关键看你怎么组织目录、怎么注入变量、怎么防止 config.yaml 误提交到 Git —— 这些问题，换什么格式都绕不开。
