超大YAML文件直接load会爆内存，因PyYAML默认构建完整AST致对象膨胀；应改用yaml.compose()+CLoader事件解析、ruamel.yaml调优加载，或预处理分块读取。
直接读取超大 YAML 文件（比如几百 MB 甚至 GB 级）时，yaml.load() 或 yaml.safe_load() 几乎必然触发 MemoryError——它会把整个文件解析成嵌套字典/列表树，对象膨胀远超原始文本体积。
为什么 pyyaml 的默认加载器会爆内存
PyYAML 默认使用构建完整 AST 的解析模型：每个键、值、嵌套层级都生成 Python 对象；字符串重复存储（尤其大量相同字段名）、无共享引用、无法流式丢弃已处理节点。一个 200MB 的 YAML 文件，实际内存占用常达 1.5–3GB。
常见错误现象包括：
- 运行中突然抛出
MemoryError，堆栈指向yaml.load()或yaml.safe_load() - 进程 RSS 内存持续飙升，
top显示 Python 占用数 GB 后卡死 - 在容器或 CI 环境中被 OOM Killer 杀掉，日志只留
Killed process
用 yaml.CLoader + yaml.compose() 做事件式解析
不走全量加载路径，改用底层解析器逐节点“组装”结构，跳过中间对象树，手动控制构建逻辑。适用于你只关心部分顶层 key（如 services、resources）的场景。
立即学习“Python免费学习笔记（深入）”；
关键点：
-
yaml.compose()返回单个yaml.Node，不是 dict；需递归遍历其value、children属性 - 必须用
yaml.CLoader（C 实现），纯 Python 的SafeLoader仍会构造大量临时对象 - 不能直接用
yaml.load_all()——它仍是批量加载，不是流式
示例（提取所有顶层 mapping key）：
import yaml from yaml import CLoader <p>def iter_top_level_keys(yaml_path): with open(yaml_path, 'rb') as f: while True: try: node = yaml.compose(f, Loader=CLoader) if node and hasattr(node, 'value') and isinstance(node.value, list): for item in node.value: if hasattr(item, 'key') and item.key: yield item.key.value except yaml.YAMLError: break
用 ruamel.yaml 的 round_trip_load() 配合 preserve_quotes=False
ruamel.yaml 是 PyYAML 的增强替代品，其 round_trip_load() 默认保留注释和格式，但代价是更高内存开销。要降低压力，必须显式关闭冗余特性：
- 设
preserve_quotes=False：避免为每个字符串缓存原始引号信息 - 设
typ='safe'：跳过 round-trip 特性，退化为安全加载器行为 - 禁用
version参数：避免内部做兼容性检查
实操建议：
from ruamel.yaml import YAML
<p>yaml = YAML(typ='safe')
yaml.preserve_quotes = False</p><h1>不要加 yaml.version = ...</h1><p>with open('huge.yaml') as f:
data = yaml.load(f) # 此时内存占用比 PyYAML safe_load 低约 30–40%
注意：ruamel.yaml 仍属全量加载，仅适合「稍大但未到灾难级」的文件（如 ≤100MB）。超过此阈值，必须切回事件式方案。
真正超大文件（>500MB）只能靠预处理 + 分段读取
YAML 本身不支持原生分片，但多数巨型配置文件有规律结构（如 Kubernetes 清单、Ansible playbooks）。这时应放弃「通用 YAML 解析」思路，转为：
- 用正则或行扫描定位
---分隔符，按文档块切分后逐块调用yaml.safe_load() - 对超长 list（如
items:下数千个 entry），用io.StringIO拼接小段再解析，避免一次性读入整段 - 若文件是自生成的，强制约定输出为 JSON Lines 或 YAML stream（每行一个合法 YAML 文档），用
yaml.load_all()流式处理
最容易被忽略的一点：YAML 的缩进敏感性会让任何基于行的切割变得脆弱。务必先用 yaml.scan() 验证分隔位置是否在合法 token 边界，否则解析会静默失败或错位。
