LINQ to SQL 和 LINQ to Entities 的核心区别在于：前者是仅支持 SQL Server 的轻量级遗留 ORM，后者是 Entity Framework（EF6/EF Core）中基于表达式树翻译的查询机制，支持多数据库且持续演进。
它们不是同一套东西，也不是版本迭代关系：LINQ to SQL 是 .NET 3.5 引入的轻量 ORM，只支持 SQL Server；LINQ to Entities 是 Entity Framework（EF）早期版本（EF 1/4）中对 ObjectContext 查询的统称，底层翻译成 Entity SQL，支持多种数据库。现在所谓“LINQ to Entities”实际指 EF6 中基于 DbContext 的查询 —— 即你写 db.Users.Where(x => x.Age > 18) 这类代码时真正执行的机制。
为什么 IQueryable 在两者里都“不立即执行”
因为它们都依赖表达式树（Expression）而非委托（Func）。查询逻辑被构造成可翻译的树结构，直到调用 .ToList()、.First() 或遍历（foreach）时才触发 SQL 生成和执行。
常见错误现象：
- 在
IQueryable上调用不支持的 .NET 方法（如string.IsNullOrEmpty()在 EF6 中部分支持，但DateTime.ToUniversalTime()通常不支持），会抛出NotSupportedException: The specified method is not supported. - 误以为
.AsEnumerable()只是“转类型”，其实它把查询提前拉到内存，后续操作全在客户端执行 —— 小数据看不出问题，大数据直接 OOM 或慢得离谱。
SQL 生成差异：从 Where 条件看实际影响
同一个 lambda 表达式，在 LINQ to SQL 和 EF6 的 LINQ to Entities 中可能生成完全不同的 SQL，尤其涉及导航属性、空值比较、日期函数时。
例如：
users.Where(u => u.Orders.Any(o => o.Total > 100))
在 LINQ to SQL 中可能生成 EXISTS (SELECT ...) 子查询；EF6 默认也类似，但若启用 UseDatabaseNullSemantics = true，空值比较行为会变（比如 u.Name == null 是否翻译为 IS NULL）。
关键参数差异：
-
DataContext.Log（LINQ to SQL）可设为Console.Out查看生成 SQL - EF6 中需配置
DbContext.Database.Log = Console.Write - EF Core 改用
DbContextOptionsBuilder.UseSqlServer(...).LogTo(Console.WriteLine)
现在该选哪个：迁移成本与兼容性现实
LINQ to SQL 已被微软标记为“legacy”，自 .NET Core 起彻底移除，没有跨平台能力，也不再更新。EF6 虽仍支持 .NET Framework，但已停止功能开发。所有新项目应直接使用 EF Core。
容易被忽略的点：
- EF Core 的 LINQ 实现更严格：很多 EF6 能翻译的表达式（如某些
DateTime操作、嵌套Select）在 EF Core 中默认不支持，必须显式用EF.Functions或改写为客户端评估（加.AsEnumerable()） - “LINQ to Entities”这个术语本身在 EF Core 文档中已被弱化，官方统一称“LINQ queries with EF Core”，但底层机制仍是表达式树翻译
- 如果你维护老系统，别指望 LINQ to SQL 和 EF6 查询能无缝互换 —— 导航属性加载策略（
LoadWithvsInclude）、延迟加载开关位置、实体跟踪方式全都不一样
