IEnumerable<T>在内存中执行查询，IQueryable<T>将查询翻译为SQL在数据库执行；前者适用于本地集合，后者适用于ORM场景，错误调用会导致全表加载。
IEnumerable<T> 和 IQueryable<T> 看起来都是用来遍历数据的接口，但它们背后的行为、执行时机和适用场景差别很大——核心就在于延迟执行（Deferred Execution）如何被触发，以及查询到底在哪儿执行。
执行位置不同：内存 vs 数据库
IEnumerable<T> 表示数据已经在内存中，所有 LINQ 操作（如 Where、Select、OrderBy）都由 .NET 运行时在客户端逐项处理。比如你对 List<Person> 调用 Where，实际是把整个列表拉进内存，再用 C# 代码一条条判断。
IQueryable<T> 则代表一个“可查询的表达式树”，它本身不持有数据，只是记录你写了什么查询逻辑。真正执行发生在调用 ToList()、First()、Count() 这类终结操作时，且通常由底层提供程序（比如 Entity Framework）把表达式翻译成 SQL，在数据库里执行。
- IEnumerable：Where → 在内存里循环过滤
- IQueryable：Where → 生成 WHERE 子句，发给数据库执行
延迟执行的“触发点”不一样
两者都支持延迟执行，但“延迟”的终点不同：
- IEnumerable 的延迟执行终止于第一次枚举（比如 foreach 或 ToList()），之后如果再次遍历，会重新执行整条链（除非你显式缓存结果）
- IQueryable 的延迟执行终止于第一次发送 SQL 并获取结果，但如果没缓存，再次 ToList() 仍会再发一次查询——它不自动缓存结果，也不保证幂等性（比如带 GETDATE() 的 SQL 每次结果可能不同）
写法稍有不慎，就从 IQueryable “掉回” IEnumerable
一旦你在 IQueryable 后调用了无法被翻译成 SQL 的方法（比如自定义函数、DateTime.Now.ToString()、或者 ToList() 之后再 Where），EF 就会把数据全拉到内存，后续操作变成 IEnumerable 行为——这可能导致查出几万条记录只为取前 10 条。
常见陷阱举例：
- db.Users.Where(u => u.Name.Contains(keyword)).ToList().Where(u => u.Age > 18) → 先查全表再内存过滤
- db.Users.Where(u => u.CreatedTime > DateTime.Now.AddDays(-7)) → OK，能转 SQL
- db.Users.Where(u => u.CreatedTime > DateTime.Now.AddDays(-7).Date) → 可能失败或降级，.Date 不总被支持
怎么选？看数据源头和性能需求
基本原则很直接：
- 数据来自数据库（EF Core / NHibernate）→ 优先用 IQueryable，让筛选、分页、排序尽量在服务端做
- 数据已是 List、Array、Dictionary 等本地集合 → 用 IEnumerable，别强行转 IQueryable
- 需要组合多个查询条件且不确定最终是否执行 → 用 IQueryable 更灵活；如果已经确定要立即计算 → ToList() 后用 IEnumerable 更可控
基本上就这些。理解它们不是“谁更好”，而是“谁在哪干活”。延迟执行本身不难，难的是清楚知道那行代码——到底是在内存里跑，还是在数据库里跑。
