欢迎关注公众号：【冬瓜白】

一次 ES 源码探索引发的思考

起因

最近在验证一个技术结论时，有一次比较典型的 AI 辅助源码分析过程，正好借此聊聊 AI 时代源码学习这个话题。

问题很简单，我就想确定：ES 7.15.1 在处理 _count API 时，是否会将其转换为搜索请求，并设置 trackTotalHits(true)？

按照传统方式，验证这个结论需要：下载 ES 源码 → IDE 搜索相关类 → 逐行阅读代码 → 画流程图整理笔记 → 验证结论。预计耗时 2-3 小时。

这次用 AI 对话式探索，10 分钟搞定，效率提升 10 倍以上。

对话过程

完整的对话记录在这里，简单复盘一下关键节点。

第一步：直接提问

我问 AI：“ES 7.15.1 服务端在处理 _count API 时，内部会将其转换为搜索请求，并设置 trackTotalHits(true) 吗？”

AI 给出了肯定的回答，并指出关键源码在 RestCountAction.java。

第二步：要求证据

我追问：“有官方文档地址吗？”

AI 给出了几个链接，包括 GitHub 源码地址。

第三步：批判性验证

我继续追问：“文档的哪些内容可以证明这个结论呢，要严谨分析，有理有据。”

AI 给出了源码级别的证据：

// RestCountAction.java 第56行
SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder().size(0).trackTotalHits(true);

第四步：发现矛盾

这时候我发现了一个问题，于是追问：“这是在 count api 里面，但 search api 里面并没有设置。”

我给出了 RestSearchAction.java 的链接，指出第 266 行附近只是创建了 SearchSourceBuilder，并没有显式设置 trackTotalHits。

第五步：AI 修正

AI 承认了这个差异，并找到了 SearchContext.java 中的默认值定义：

public static final int TRACK_TOTAL_HITS_ACCURATE = Integer.MAX_VALUE;  // 2147483647
public static final int TRACK_TOTAL_HITS_DISABLED = -1;
public static final int DEFAULT_TRACK_TOTAL_HITS_UP_TO = 10000;         // 默认值

最终结论：

• _count API → 显式设置 trackTotalHits(true) → Integer.MAX_VALUE
• _search API → 不设置，使用默认值 10000

这就解释了为什么 _count 能返回精确计数，而 _search 默认只统计到 10000。

几点思考

1. AI 不是万能的，批判性思维依然重要

如果我在第三步就停下来，完全相信 AI 的回答，那我就会错过 _search API 的对比分析。正是因为我追问了"search api 里面并没有设置"，才真正理解了两个 API 的设计差异。

AI 可以帮你快速定位，但验证和判断还是得靠自己。

2. "抓大放小"的理念没变，工具变了

我之前在"自己动手"系列中提过一个观点：系统性地完整学习一个框架是一项耗时且耗力的任务，而且学习的知识很容易被忘记，也很容易走进死胡同。很多框架经过长时间的迭代，内部会有各种封装和抽象，开发人员很难快速理解框架的核心逻辑。

所以我的目标一直是抓大放小，快速理解框架的设计原理和工作机制。

以前实现这个目标的方式是"自己动手实现一个简化版"，现在多了一个选择：用 AI 快速定位关键代码，把时间花在理解设计上。

比如这次探索，真正有价值的不是知道 trackTotalHits(true) 在哪一行，而是理解：

• 为什么 ES 要把 _count 转换为 _search？（复用设计）
• 为什么 _count 要显式设置 trackTotalHits(true)？（保证精确计数）
• 为什么 _search 默认只统计 10000？（性能权衡）

这些"为什么"才是设计思想，才是真正有价值的东西。

3. 对比学习很高效

这次最大的收获，是通过对比 _count 和 _search 的实现差异，理解了 ES 在精确性和性能之间的权衡。

API	trackTotalHits	行为
_count	Integer.MAX_VALUE	精确统计所有匹配文档
_search	10000（默认）	最多精确统计 10000 条

这种对比，比单独看一个 API 的实现要有价值得多。

4. 源码学习方式变了，目标没变

有人可能会问：既然 AI 这么强，还需要读源码吗？

我的答案是：需要，但方式变了。

以前是"逐行阅读"，现在是"问题驱动 + AI 定位 + 批判验证"。

以前的目标是"记住实现细节"，现在的目标是"理解设计权衡"。

其实这个目标一直没变，只是以前我们不得不花大量时间在"找代码"这个体力活上。现在 AI 把这部分自动化了，让我们有更多时间做"理解设计"这个脑力活。

一个实用的方法

基于日常实践，总结一个简单的流程：

1. 问题驱动：带着具体问题去探索，不要漫无目的地"学源码"
2. AI 快速定位：让 AI 给出关键源码位置和核心代码片段
3. 批判性验证：不盲信 AI，主动寻找反例和矛盾
4. 对比扩展：找相关实现对比，理解设计权衡

这次探索 ES 源码，从提问到得出结论，大概 10 分钟。如果用传统方式，至少 2-3 小时。

效率提升是一方面，更重要的是，通过对比 _count 和 _search 的实现，我对 ES 的设计理解更深了。

总

AI 时代，源码学习不是变得不重要，而是学习方式变了。

"抓大放小，理解设计思想"这个核心理念没变，变的是实现这个目标的工具和效率。

AI 是放大器，不是替代品。好的架构师用 AI 后效率提升 10 倍，但前提是你得有批判性思维，能验证 AI 的回答，能理解设计权衡。

关键在于：AI 帮你节省的时间，要用来做更深度的思考，而不是偷懒。

---

References

• 完整对话记录

• ES 7.15 RestCountAction 源码

• ES 7.15 RestSearchAction 源码

• ES 7.15 SearchContext 源码

• 自己动手写一个 Arthas 在线诊断工具&系列说明

• 自己动手写分布式任务调度框架

• 自己动手写 Java 虚拟机（二）-查找 Class 文件

• 自己动手调试 JDK（CLion）