toml 是人类可维护、类型明确、无缩进风险的配置首选，tomli/tomllib 专用于只读解析；json 不支持注释且语法严格，yaml 缩进敏感且类型推断易错，二者在特定场景（如前端消费、k8s）仍不可替代。

tomli 不是 JSON 或 YAML 的替代品，它只解析 TOML —— 所以“用 tomli 替代 json 或 yaml”本身是个伪命题。真正该问的是：什么时候该选 TOML + tomli（或 tomllib），而不是 JSON/YAML？

答案很直接：当你需要人类可维护、类型明确、无缩进风险、且不需写入配置的场景时，TOML 是更健壮的选择；而 tomli / tomllib 就是当前 Python 生态里读取它的最优解。

---

为什么不用 json.load() 读配置文件？

JSON 确实是标准库、无需安装、解析快，但它有硬伤：

• 不支持注释 —— 配置文件里加 # 或 // 直接报错
• 键名必须双引号包裹 —— host: "localhost" 合法，host: localhost 是语法错误
• 无法表达原生日期/时间 —— 只能靠字符串约定，比如 "2026-05-02"，后续还得手动转 datetime
• 嵌套结构易写错括号，尤其在长配置中容易漏掉 } 或 ]

这些不是“性能问题”，而是日常协作和维护中的真实摩擦点。

---

为什么不用 yaml.safe_load()？

YAML 可读性好、支持注释、天然嵌套，但有两个不可忽视的风险点：

Wjs Uploading Video

将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。

下载

• yaml.safe_load() 虽然防了代码执行，但对缩进极度敏感 —— 多一个空格、少一个空格，就抛 YAMLError: while parsing a block mapping
• 某些合法 YAML（如带锚点 &ref、别名 *ref）在不同版本 PyYAML 下行为不一致，CI 环境容易出幺蛾子
• 类型推断有时反直觉：数字开头的字符串 0123 可能被当八进制解析成 83，除非加引号

这不是“不能用”，而是你得为可读性额外承担调试成本。

---

tomli / tomllib 该怎么用才不踩坑？

tomli（Python tomllib（Python ≥3.11）功能完全一致，只做解析，不写入。关键使用细节：

• 必须用二进制模式打开文件：open("config.toml", "rb") —— 传文本流会直接报 TypeError: expected bytes, not str
• 不支持注释保留、不支持格式化写回 —— 如果你需要编辑配置并保存（比如 CLI 工具动态改值），得换 tomlkit
• 路径错误时抛的是 FileNotFoundError，但 TOML 语法错误时抛 tomllib.TOMLDecodeError（注意不是 ValueError）
• 日期时间字段（如 deploy_at = 2026-05-02T13:35:00）自动转成 datetime.datetime 对象，无需手动 strptime

兼容写法示例：

try:
    import tomllib
except ImportError:
    import tomli as tomllib
<p>with open("settings.toml", "rb") as f:
config = tomllib.load(f)
</p>

---

什么时候该坚持用 json/yaml？

别为了“新”而换。以下情况仍推荐原方案：

• 你的配置要被前端 JS 直接消费 → 必须用 JSON（浏览器原生支持）
• 项目已大量使用 YAML（如 GitHub Actions、K8s manifests），团队熟悉且流程固化 → 继续用 yaml.safe_load 更省心
• 需要运行时修改并写回配置文件 → tomllib 不行，tomli 也不行，得上 tomlkit 或 pyyaml（带 dump）

TOML 的优势不在“全能”，而在“专注”：它把配置文件该干的事（声明式、可读、类型清晰、不易误写）做到了极致。用对地方，比盲目替换更有效。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！