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 - 嵌套结构易写错括号，尤其在长配置中容易漏掉
}或]
这些不是“性能问题”，而是日常协作和维护中的真实摩擦点。
立即学习“Python免费学习笔记（深入）”；
为什么不用 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 <3.11）和 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)
什么时候该坚持用 json/yaml？
别为了“新”而换。以下情况仍推荐原方案：
- 你的配置要被前端 JS 直接消费 → 必须用 JSON（浏览器原生支持）
- 项目已大量使用 YAML（如 GitHub Actions、K8s manifests），团队熟悉且流程固化 → 继续用
yaml.safe_load更省心 - 需要运行时修改并写回配置文件 →
tomllib不行，tomli也不行，得上tomlkit或pyyaml（带 dump）
TOML 的优势不在“全能”，而在“专注”：它把配置文件该干的事（声明式、可读、类型清晰、不易误写）做到了极致。用对地方，比盲目替换更有效。
