因为 yield return 生成 IEnumerable，而 async 方法返回 Task 或 Task，两者状态机机制冲突，编译器报错 CS1983；C# 8+ 应改用 async IAsyncEnumerable 实现异步分页。
yield return 为什么不能用在 async 方法里
因为 yield return 生成的是 IEnumerable<t></t>，而 async 方法返回的是 Task<t></t> 或 Task<ienumerable>></ienumerable> —— 两者状态机实现机制冲突，编译器直接报错 CS1983。
常见错误现象：error CS1983: The return type of an async method must be void, Task, Task<t>, or a task-like type</t>，哪怕你只加了个 async 关键字，没写 await 也会触发。
- 如果真要异步分页（比如每次从数据库拉一页），得用
IAsyncEnumerable<t></t>+yield return+async方法（C# 8+） - 旧项目用 .NET Framework 或 C# 7 及以下？别硬套
async，改用同步分页 + 外层异步包装（如Task.Run(() => GetPage(...))） -
IAsyncEnumerable<t></t>不支持 LINQ 的全部操作（比如.Count()、.ToList()会强制枚举），别在 yield 方法里直接调.Where(...).First()
分页 yield 实现时，skip/take 逻辑别写在 yield 方法内部
很多人把 skip 和 take 放进 yield 方法体里，以为“一次调用就能返回第 n 页”，结果发现性能崩了：每调用一次都重新枚举整个源集合，第 100 页就要跳过前 990 条。
正确做法是让分页参数由调用方控制，yield 方法只负责“按需吐数据”，不承担定位职责。
- 错误示范：
foreach (var item in source.Skip((page - 1) * size).Take(size)) { yield return item; }——source是IEnumerable<t></t>时，Skip每次都从头遍历 - 正确思路：yield 方法返回完整序列，分页交给调用方（
data.Skip(...).Take(...)），或底层用支持游标的存储（如 EF Core 的AsNoTracking().Skip().Take()直接下推到 SQL） - 如果源是数组或
List<t></t>，Skip/Take开销小；但如果是文件流、网络响应、或自定义IEnumerable（比如逐行读大文件），务必确认它是否支持高效随机访问
IAsyncEnumerable 分页的最小可用写法（C# 8+）
想真正异步分页又不想提前加载全部数据，IAsyncEnumerable<t></t> 是目前最干净的解法。它配合 yield return 和 await，能实现“请求一页、拉一页、吐一页”。
注意：必须引用 System.Runtime.CompilerServices，且方法签名必须是 async IAsyncEnumerable<t></t>，不能是 Task<iasyncenumerable>></iasyncenumerable>。
async IAsyncEnumerable<string> ReadLinesAsync(string path, int pageSize = 100)
{
await foreach (var line in File.ReadLinesAsync(path))
{
// 这里可以加 await 调用其他异步服务
yield return line.Trim();
// 注意：不要在这里做 skip/take，那是消费者的事
}
}- 调用时用
await foreach (var x in ReadLinesAsync(...))，不是foreach - EF Core 6+ 的
ToListAsync()有重载支持pageSize，但它仍是先取全量再内存分页；真要服务端分页，还是得靠AsNoTracking().Skip().Take()+IAsyncEnumerable<t></t> - ASP.NET Core 中返回
IAsyncEnumerable<t></t>默认启用 streaming，但客户端若不保持连接（比如浏览器直接刷页面），可能中断
延迟加载集合时，别让 yield 方法持有外部可变状态
yield 方法本质是编译器生成的状态机，它会捕获闭包里的变量。如果这些变量在 yield 过程中被外部修改，行为不可预测。
典型翻车场景：循环中反复调用同一个 yield 方法，但传入的参数变量被复用（比如 for 循环里的 i），结果所有迭代项都返回最后一轮的值。
- 错误写法：
for (int i = 0; i —— 看似没问题，但若这个 <code>i是外部传入并可能变更的引用，就危险 - 安全做法：在 yield 方法内立即求值，或用局部变量封住（
var localI = i; yield return $"Item {localI}";） - 尤其注意 Entity Framework 中延迟加载导航属性，如果
yield return entity.Children，而entity的上下文已释放或被修改，枚举时直接抛ObjectDisposedException
复杂点在于：yield 的延迟性会让问题延迟暴露——编译通过、单元测试也过，但上线后某次并发请求里状态错乱，查起来特别费劲。
