AsNoTracking()必须加在IQueryable链中Where、OrderBy之后且Select或ToList()之前，Include后（EF Core 6+），否则无效或关联实体仍被追踪。
只读查询不加 AsNoTracking()，等于主动给内存和数据库加压。 它不是“锦上添花”，而是中等以上数据量、高并发场景下的必做项——加错位置、加晚了、或和 Include 顺序搞反，效果直接归零。
AsNoTracking() 必须加在哪儿？顺序错了就白加
它必须出现在 IQueryable 链早期，且严格满足：在 Where、OrderBy 之后，但在 Select 或 ToList() 之前。EF Core 6+ 中若用了 Include，AsNoTracking() 还得放在 Include 后面，否则关联实体仍被追踪。
-
context.Users.Where(u => u.IsActive).AsNoTracking().Select(u => new { u.Id, u.Name }).ToList()✅ 正确 -
context.Users.AsNoTracking().Where(...).ToList()✅ 可接受（但不如上者精准） -
context.Users.Where(...).ToList().AsNoTracking()❌ 无效——此时已加载并追踪完毕 -
context.Users.Include(u => u.Profile).AsNoTracking().ToList()❌ Profile 仍被追踪（EF Core 6+ 行为） -
context.Users.AsNoTracking().Include(u => u.Profile).ToList()✅ Profile 不再追踪
Select 投影比 Include 快，但字段漏一个就报错
用 Select 投影到 DTO 或匿名类型，本质是让 EF Core 生成 SELECT col1, col2，而非 SELECT *。这直接减少网络传输、反序列化开销和内存驻留。
- 别写
.Select(x => x)—— 这等于没投，EF Core 仍加载完整实体并尝试追踪 - 导航属性不能直取：
.Select(x => new { x.Name, x.Owner.Name })会触发客户端求值（Client Evaluation），查 1000 条可能把整张 Owner 表拖进内存 - 要安全访问 Owner.Name，要么先
Include(x => x.Owner)，要么改用Join显式关联 - DTO 类型必须有无参构造函数，且属性名/类型与查询字段严格匹配；
new MyDto { Id = x.Id, Name = x.Name }比new { }更稳定、易维护
笛卡尔积和 N+1 常藏在看似干净的 Include 里
一个 Include(x => x.Items) 看似简洁，但如果 Items 是集合，又同时 Include(x => x.Tag)，EF Core 默认生成单条 JOIN SQL。主表 100 行 × 每行平均 5 个 Items × 每 Item 关联 1 个 Tag → 实际返回 500 行，Tag 字段重复 500 次。
- 优先用
AsNoTracking().Select()替代多级Include，尤其当只需子表个别字段时 - 真要加载完整结构，启用
AsSplitQuery()，让 EF Core 发起多次简单查询（如 2 次 SELECT），避免 JOIN 膨胀 -
AsSplitQuery()不支持 SQLite 等部分数据库，上线前务必验证 - 检查日志输出的实际 SQL：如果看到
FROM Orders o LEFT JOIN OrderItems i ON ... LEFT JOIN Products p ON ...且返回行数远超主表，基本就是笛卡尔积
最常被忽略的点是：全局设 UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking) 看似一劳永逸，但一旦某处需要更新实体，就必须显式加 AsTracking() —— 很多人忘了加，结果修改不生效，排查起来极隐蔽。
