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 里改个配置要先查文档确认字段嵌套规则。
ECTouch是上海商创网络科技有限公司推出的一套基于 PHP 和 MySQL 数据库构建的开源且易于使用的移动商城网店系统！应用于各种服务器平台的高效、快速和易于管理的网店解决方案，采用稳定的MVC框架开发，完美对接ecshop系统与模板堂众多模板，为中小企业提供最佳的移动电商解决方案。ECTouch程序源代码完全无加密。安装时只需将已集成的文件夹放进指定位置，通过浏览器访问一键安装，无需对已有
立即学习“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推荐加载方式（安全 + 类型保留）
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 —— 这些问题，换什么格式都绕不开。
