1. 一个具体问题
团队使用对象关系映射工具后，不再手写数据库查询。一个页面展示一百条记录却发出一百零一次查询，开发者看到的只是一次列表读取和几次属性访问。工具没有失效，但它隐藏的执行方式正在决定页面速度。
2. 一句话解释
抽象能屏蔽常见细节，却很难完全屏蔽底层的性能、故障和资源限制，边界问题仍需要理解实际机制。
3. 出处与原意
Joel Spolsky 在 2002 年的文章中提出“抽象泄漏定律”，以网络协议等例子说明非平凡抽象会在某些条件下泄漏。它是对工程经验的概括，不是要求每个人在使用工具之前先精通所有底层实现。
4. 原理与机制
抽象通过给出简化模型降低认知负担，例如把远程文件表现为普通文件。但远程访问依然存在延迟、连接中断和权限变化；接口相似不代表物理成本相同。泄漏通常出现在规模、错误或边界输入上，因为简化模型本就省略了这些维度。好的抽象并不承诺消灭底层，而是把通常不需要知道的细节藏起来，同时保留诊断信息和必要的控制入口。错误的做法则是继续叠加包装，把真正原因变得更难观察。
抽象的使用者不必记住全部源码，但应掌握它的成本模型与失败模型。成本模型回答一次调用是否可能触发远程通信或大量复制，失败模型回答超时、部分成功和重试会怎样。维护者可以通过结构化错误、追踪标识与可观察计数提供这些信息。这样既保留简单接口，也让异常情况下有路可走，避免只能靠猜测或完全绕过抽象。
5. 一个完整案例
假设案例：一个订单列表每页展示一百行，ORM 对每行访问客户信息时懒加载一次。开发者先测量数据库查询数与耗时，发现主查询只耗时二十毫秒，附加请求总共耗时两秒。随后改成批量预取客户数据，查询减少到两次，并用同样规模的数据验证结果。团队没有移除 ORM，而是在列表边界明确加载策略，并给监控增加每次请求的查询次数。抽象仍提高日常效率，底层知识用于定位它没有隐藏好的成本。
6. 适用条件与反例
适合分析“接口调用很简单，运行结果却意外”的问题，包括云存储、缓存、远程调用和自动生成代码。不能把所有缺陷都归为必然泄漏；有些只是抽象设计错误，可以修复。也不宜为了防范少见情况，让每个调用者承担全部复杂性。
7. 今天可以尝试的行动
选一个频繁使用的高层接口，写下它隐藏的三个事实：实际发生几次操作、失败会怎样、输入扩大十倍会怎样。找一个可观察指标验证最关键的假设，再把必要限制写入使用说明，让下一次排查有明确入口。