如何实现详情页筛选记录集的上/下条按钮跳转功能

核心要保证详情页计算导航用的筛选规则、排序规则和列表页DataTable加载数据用的规则完全一致，不要单独维护两套逻辑，避免出现导航范围和列表筛选结果不匹配的问题，具体实现步骤如下：

• 第一步：抽离公共的筛选、排序逻辑
  不要把筛选逻辑散落在列表接口里，单独抽成可复用的方法，同时接收前端DataTable传递的所有筛选参数、排序参数，返回应用了所有规则的IQueryable结果，列表页加载数据、详情页计算导航都调用这一个方法，从根源上避免规则不一致。
  示例代码：

  // 筛选参数类，和前端DataTable传参一一对应
  public class AppListFilter
  {
      public string Keyword { get; set; }
      public int? Status { get; set; }
      public DateTime? StartCreateTime { get; set; }
      public DateTime? EndCreateTime { get; set; }
      // 排序字段、排序方向和前端DataTable的排序配置对齐
      public string SortField { get; set; } = nameof(Application.AppNumber);
      public bool IsAsc { get; set; } = true;
  }
  
  // 公共查询方法，全链路复用
  private IQueryable<Application> BuildAppListQuery(AppListFilter filter)
  {
      var query = _db.Applications.AsQueryable();
      // 逐行加筛选条件，和列表页逻辑完全一致
      if (!string.IsNullOrWhiteSpace(filter.Keyword))
      {
          query = query.Where(a => a.AppName.Contains(filter.Keyword) || a.AppNumber.ToString().Contains(filter.Keyword));
      }
      if (filter.Status.HasValue)
      {
          query = query.Where(a => a.Status == filter.Status.Value);
      }
      if (filter.StartCreateTime.HasValue)
      {
          query = query.Where(a => a.CreateTime >= filter.StartCreateTime.Value);
      }
      if (filter.EndCreateTime.HasValue)
      {
          query = query.Where(a => a.CreateTime <= filter.EndCreateTime.Value);
      }
      // 动态拼接排序逻辑
      query = filter.SortField switch
      {
          nameof(Application.CreateTime) => filter.IsAsc ? query.OrderBy(a => a.CreateTime) : query.OrderByDescending(a => a.CreateTime),
          _ => filter.IsAsc ? query.OrderBy(a => a.AppNumber) : query.OrderByDescending(a => a.AppNumber)
      };
      // 追加主键作为次排序，避免排序字段值重复时顺序混乱
      query = query.ThenBy(a => a.Id);
      return query;
  }
  

  列表页从DataTable拿到筛选、排序参数后，直接调用这个方法拿到查询，再做分页处理返回给前端就行。跳转到详情页的时候，把当前的筛选参数一起传递：可以拼在详情页路由的query参数里，也可以存在短时效的服务端缓存里，传一个缓存key到详情页，避免URL过长。

• 第二步：基于公共查询计算导航ID
  详情页拿到传递过来的筛选参数后，调用同一个公共方法拿到筛选排序后的结果集，再基于当前记录的位置找上一条、下一条即可，替换你原来全量查询的数据源就行：

  // 拿到和列表页完全一致的筛选排序结果
  var filteredQuery = BuildAppListQuery(currentFilter);
  // 当前记录的排序字段值、主键值，用来做位置判断
  var currentAppNumber = application.AppNumber;
  var currentId = application.Id;
  
  // 找上一条：排在当前记录前面的最后一条
  ViewBag.PreviousId = filteredQuery
                          .Where(a => a.AppNumber < currentAppNumber || (a.AppNumber == currentAppNumber && a.Id < currentId))
                          .OrderByDescending(a => a.AppNumber)
                          .ThenByDescending(a => a.Id)
                          .Select(a => a.Id)
                          .FirstOrDefault();
  
  // 找下一条：排在当前记录后面的第一条
  ViewBag.NextId = filteredQuery
                      .Where(a => a.AppNumber > currentAppNumber || (a.AppNumber == currentAppNumber && a.Id > currentId))
                      .OrderBy(a => a.AppNumber)
                      .ThenBy(a => a.Id)
                      .Select(a => a.Id)
                      .FirstOrDefault();
  

  如果你的排序字段是动态变化的，只需要把上下条判断里的AppNumber换成对应排序字段，排序方向跟着调整就行。

• 避坑说明

  • 不要在跳详情的时候把整个筛选后的ID列表全量传到前端或者存起来：数据量大的时候会有明显的性能问题，多标签页打开时还容易出现状态串扰。直接在详情页用相同条件查库的方案最轻量，两个查询都能走数据库索引，响应速度在毫秒级。
  • 一定要加主键作为第二排序判断条件：只要业务字段存在重复值的可能（比如同名应用、同创建时间的记录），不加次排序就会出现导航跳错、漏记录的问题。
  • 如果筛选条件包含敏感信息，不要直接明文放在URL里，优先存在服务端缓存，只传非敏感的缓存key即可，缓存设置5-10分钟的过期时间就足够用户浏览详情使用。

内容的提问来源于stack exchange，提问作者user17824052