linq中leftjoin需用groupjoin+selectmany模拟，关键步骤是groupjoin后调用defaultifempty()并正确处理null；key比较需保证相等性，ef core翻译可能影响性能，空值访问须显式判空。
LeftJoin 在 C# LINQ 中没有直接语法，得用 GroupJoin + SelectMany 模拟
LINQ 的 join 关键字默认是内连接，写不出左连接。想让左表所有记录都出来、右表没匹配的填 null，必须组合两个操作：先 GroupJoin 把右表按 key 分组挂上去，再用 SelectMany 展开并提供默认值。
常见错误是漏掉 DefaultIfEmpty() —— 没它，GroupJoin 结果里右表为空的分组就直接被跳过了，结果还是内连接。
-
GroupJoin第三个参数是右表的 key selector，第四个是结果选择器（注意这里要返回一个匿名类型或元组，把左右数据都包进去） -
SelectMany的第二个参数必须是(left, right) => right这种形式，不能直接传right；第三个参数才是把 left 和 right 合成最终结果的 lambda - 如果右表可能有多个匹配项，
DefaultIfEmpty()会补一个 null 元素，所以right在 lambda 里是可空类型（比如RightType?或IEnumerable<righttype></righttype>）
var result = leftList.GroupJoin(
rightList,
l => l.Id,
r => r.LeftId,
(l, rightGroup) => new { Left = l, Rights = rightGroup })
.SelectMany(
x => x.Rights.DefaultIfEmpty(),
(x, r) => new { x.Left, Right = r });
用 Join + DefaultIfEmpty 实现左连接时，null 值字段容易引发 NullReferenceException
展开后的 Right 是 null，但很多人直接链式调用 r.Name.Length 这类属性，运行时崩。这不是 LINQ 写错了，是后续使用没做空判断。
典型场景：查用户列表及其最新订单，订单可能为空，但代码里直接写 u.Order.Status 就挂了。
- 最稳妥是在 select 匿名对象时就做空转换，比如
Status = r?.Status ?? "无订单" - 如果要用导航属性风格，建议定义一个包装类，用可空引用类型（
string?）和 null 合并操作符（??）显式控制 - 别依赖 IDE 提示——C# 编译器对 LINQ 表达式树里的 null 流程分析有限，静态检查常失效
EF Core 中 LeftJoin 性能比原生 SQL 差，尤其大数据量时
EF Core 6+ 虽支持 GroupJoin 翻译成 LEFT JOIN，但实际生成的 SQL 可能带子查询或多次扫描，不像手写 SQL 那样可控。
使用场景：需要关联三张以上表、且其中某张表只是辅助信息（如日志、配置），又不想发多条查询。
- 用
AsSplitQuery()可避免笛卡尔积爆炸，但会发多条 SQL —— 对网络延迟敏感的场景反而更慢 - 若右表有 where 条件（比如只取「状态为 Active 的订单」），务必把条件写在
GroupJoin的右表源上（rightList.Where(r => r.Status == "Active")），而不是放在最后的 select 里，否则 EF 可能无法下推 - 复杂关联建议直接用
FromSqlRaw或视图映射，LINQ 抽象层在这里不是银弹
用 LINQ to Objects 做左连接时，key selector 必须保证相等性语义正确
内存集合的 GroupJoin 依赖 Equals 和 GetHashCode。如果 key 是自定义类，没重写这两个方法，哪怕字段值一样也会匹配失败，左连接变成全 null。
常见于 DTO 或匿名对象混用：比如左表用 new { Id = 1 }，右表用 new { Id = 1, Name = "a" }，虽然 Id 相同，但匿名类型不同，比较结果为 false。
- key 最好用简单类型（
int、string、Guid），避免嵌套对象或匿名类型 - 必须用类当 key 时，确保实现了
IEquatable<t></t>并重写GetHashCode - 调试时可临时加
.ToList()强制执行，用断点看rightGroup里到底有没有元素，比猜快得多
左连接看着只是多一行 DefaultIfEmpty()，但 key 的相等性、null 的传播路径、ORM 的 SQL 翻译边界，这三个地方任一出问题，结果就静默错位——尤其线上查不到数据时，最容易怀疑数据问题，其实卡在 GroupJoin 的 key 比较逻辑里。
