asnotracking()是高并发中等数据量下必选项，须置于iqueryable链早期、select/tolist之前，配合select投影可提速3–5倍并避免笛卡尔积、n+1及内存暴涨。
只读查询不加 AsNoTracking()，基本等于主动给数据库和内存加压。 它不是“可选优化”，而是高并发、中等以上数据量场景下的必做项。配合投影（Select），两者叠加能稳定带来 3–5 倍查询提速，且避免笛卡尔积、N+1、内存暴涨等连锁问题。
AsNoTracking() 必须加在哪儿？顺序和位置很关键
它必须出现在 IQueryable 链的早期，越靠前越好——不能等到 ToList() 之后再补，那完全无效。
-
AsNoTracking()要放在Where、OrderBy之后，但一定在Select或ToList()之前；否则 EF Core 可能仍会为中间结果建追踪快照 - 如果用了
Include，AsNoTracking()必须放在Include后面，否则关联实体仍会被追踪（EF Core 6+ 行为） - 全局配置（
UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking)）适合纯只读服务，但一旦需要更新，就得显式加AsTracking()，别图省事全关了
投影 Select 比 Include 更快，但容易漏字段或类型不匹配
用 Select 投影到匿名类型或 DTO，本质是让 EF Core 生成 SELECT [col1], [col2] 而非 SELECT *，直接减少网络传输、反序列化开销和内存驻留。
- 别写
.Select(x => x)—— 这等于没投，EF Core 仍加载完整实体并尝试追踪 - 导航属性不能直接
.Select(x => new { x.Name, x.Owner.Name })，除非Owner已被Include或用Join显式关联；否则触发客户端求值（Client Evaluation），查 1000 条就可能把整张 Owner 表拖进内存 - DTO 类型需有无参构造函数，且属性名/类型要与查询字段严格匹配；用
new MyDto { ... }比new { ... }更易维护，也避免 API 响应结构漂移
N+1 和笛卡尔积常藏在看似正确的 Include 里
一个 Include(x => x.Items) 看似干净，但如果 Items 是集合，又同时 Include(x => x.Tag)，EF Core 默认生成单条 JOIN SQL —— 此时若主表 100 行、每行平均 5 个 Items、每个 Item 关联 1 个 Tag，结果集就是 100 × 5 = 500 行，Tag 字段重复 500 次，不是 100 行。
- 优先用
AsNoTracking().Select(...)替代多级Include，尤其当只需子表个别字段时 - 真要加载完整关联结构，启用 Split Queries（
AsSplitQuery()），让 EF Core 发起 2–3 次简单查询，避免 JOIN 膨胀；但它不支持所有数据库（如 SQLite 不支持） - 检查日志输出的实际 SQL：如果看到
FROM Orders o LEFT JOIN OrderItems i ON ... LEFT JOIN Products p ON ...且返回行数远超主表，基本就是笛卡尔积了
最常被忽略的点：性能提升不是来自某一行代码，而是组合策略的协同效应——AsNoTracking() 省内存，Select 减传输，SplitQueries 或 Join 控制膨胀，三者缺一，优化就打折。别只改一处就以为完事了。
