GET articles/_search
{"_source": ["id", "title"], "size": 20,
"query": {"match_all": {}}}
一个 60GB 的索引，_disk_usage 显示 _source 占 44GB。接口只需要 id 和 title，命中一万条时响应体 90MB，网关直接超时。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：_source 存的是写入时的整条 JSON，默认所有字段都保留。查询只要两个字段，取回阶段仍要把整条 _source 读出来再过滤，网络和堆都付全量代价。关掉 _source 又会影响 update 和 reindex。
「_source 体积」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。权限不要一口气开到最大，先加到够用再往上试，范围小才好收。
把复现步骤压到三条以内，交给同事也能跑出来，才算真的定位清楚。改动写完就同步给同事，下一个人踩同一个坑，成本还是你的。
处理上按这个顺序：查询加 _source includes 只取需要的字段；写入侧对超大字段做裁剪 别把整段 HTML 塞进来；固定字段可以开 store 用 stored_fields 取；关 _source 前确认没有 update by query 和 reindex 依赖。
确认没问题再收工，同样一万条响应体从 90MB 降到 4MB，接口耗时回到一秒内。