Enumerable 在内存执行，Queryable 延迟执行并翻译为 SQL；前者用 Func，后者用 Expression；AsEnumerable() 切换至内存计算，AsQueryable() 不触发数据库查询。
Enumerable 和 Queryable 的核心区别不在“写法”，而在“执行时机”和“执行位置”——前者在内存里跑，后者把逻辑发给数据库跑。
Where 方法接收的参数类型不同
这是最直接、最容易踩坑的差异点。两个 Where 看起来一样，但签名完全不同：
-
Enumerable.Where<T>(this IEnumerable<T> source, Func<T, bool> predicate)—— 接收的是Func，即编译后直接可执行的委托 -
Queryable.Where<T>(this IQueryable<T> source, Expression<Func<T, bool>> predicate)—— 接收的是Expression<Func<T, bool>>，即一棵可被解析、翻译的表达式树
这意味着：如果你对 IQueryable<User> 写了 u => u.Name.Contains("a") && DateTime.Now.Year > 2020，前半段能转成 SQL，后半段（DateTime.Now）不能——EF 会抛出 System.NotSupportedException: The specified method 'DateTime get_Now()' is not supported in LINQ to Entities.。
IQueryable 延迟执行但不等于“不加载数据”
很多人误以为 IQueryable 调用 Where 后就“什么都没发生”，其实它只是没发 SQL；一旦你调用 ToList()、First()、Count() 或遍历（foreach），EF 就会把整个表达式树翻译成 SQL 并执行。
- 连续链式调用
Where→OrderBy→Take(10)，只生成一条 SQL，含WHERE、ORDER BY、LIMIT - 但如果中间插了一句
.AsEnumerable()，后续所有操作（比如.Where(x => x.Age > 30)）就会强制拉全量数据进内存再过滤——哪怕数据库里有 100 万条记录 -
IQueryable.Count()发 SQL 的COUNT(*)；IEnumerable.Count()是先ToList()再取List.Count，开销天壤之别
AsEnumerable() 和 AsQueryable() 不是“转换类型”，而是“切换执行上下文”
这两个方法名字有误导性，它们并不做安全类型转换，而是显式告诉编译器：“接下来请用 Enumerable 类的方法”或“请当成 IQueryable 处理”。
-
list.AsEnumerable()：把List<T>强制视为IEnumerable<T>，后续所有 LINQ 操作走内存计算（Func版本） -
db.Users.AsQueryable()：对已有的内存集合（如List<User>）包装成IQueryable<T>，但底层仍是内存枚举——它不会 magically 变成数据库查询，只是允许你写Expression语法（实际仍走Enumerable逻辑） - 常见误用：
db.Users.ToList().AsQueryable().Where(...)—— 这等于先查全表到内存，再假装“能翻译 SQL”，毫无意义
性能差异往往藏在 ToList() 和 foreach 的那一瞬间
真正决定是“查 10 行”还是“查 10 万行再筛 10 行”的，不是 Where 写在哪，而是你第一次真正消费结果时，手上的变量类型是什么。
- 写
var q = db.Users.Where(u => u.Status == 1);—— 此时q是IQueryable<User>，无 SQL - 写
var list = q.ToList();—— 此刻才发 SQL，且只查满足条件的数据 - 写
var list = db.Users.ToList().Where(u => u.Status == 1);—— 先发SELECT * FROM Users，再内存过滤
尤其要注意 EF Core 中 Include + AsEnumerable 的组合：它会让关联表也全量加载，极易触发 N+1 或内存爆掉。
