分页涉及客户端参数接收、数据查询裁剪及结果封装，其职责需在 controller 层（参数解析与响应组织）与 service 层（业务感知的分页查询与 totalcount 计算）间清晰划分，而非由单一层独揽。
分页涉及客户端参数接收、数据查询裁剪及结果封装，其职责需在 controller 层（参数解析与响应组织）与 service 层（业务感知的分页查询与 totalcount 计算）间清晰划分，而非由单一层独揽。
在典型的分层架构（如 Spring Boot）中，分页不是单纯的“前端展示需求”，而是横跨表现层与业务层的数据协调过程。其核心职责必须拆解，否则易导致层间耦合、复用性下降或事务/缓存语义错乱。
✅ Controller 层职责：参数接收、校验与响应组装
- 接收并校验分页参数（如 page=1, size=20, sort=createdAt,desc）；
- 将参数转换为统一的分页对象（如 Spring Data 的 Pageable）；
- 调用 Service 方法获取分页结果；
- 封装最终响应（含 content, totalElements, totalPages, number, size 等标准字段）。
@RestController
@RequestMapping("/api/users")
public class UserController {
@GetMapping
public ResponseEntity<PageResponse<UserDto>> getUsers(
@RequestParam(defaultValue = "0") int page,
@RequestParam(defaultValue = "10") int size,
@RequestParam(defaultValue = "id,asc") String sort) {
Pageable pageable = PageRequest.of(page, size, Sort.by(sort));
Page<User> userPage = userService.findUsersWithPagination(pageable);
// 封装为标准化响应体（避免暴露 JPA/PageImpl 内部细节）
PageResponse<UserDto> response = PageResponse.of(
userPage.map(UserDto::from),
userPage.getTotalElements(),
userPage.getTotalPages()
);
return ResponseEntity.ok(response);
}
}✅ Service 层职责：业务逻辑驱动的分页查询与 totalCount 计算
- 接收 Pageable，执行带偏移/限制的数据库查询（如 LIMIT 20 OFFSET 0）；
- 同步执行 totalCount 查询（推荐使用 COUNT(*) 子查询或数据库原生分页 COUNT 支持）；
- 在事务上下文中保障数据一致性（例如：避免分页查询与 count 查询间被其他写操作干扰）；
- 可结合业务规则动态调整分页行为（如：管理员可见全部，普通用户仅查状态为 ACTIVE 的记录）。
@Service
@Transactional(readOnly = true)
public class UserService {
public Page<User> findUsersWithPagination(Pageable pageable) {
// Spring Data JPA 自动处理：生成 LIMIT + COUNT 查询
// ✅ 正确：totalCount 与 content 查询在同一事务/同一数据快照下执行
return userRepository.findAll(pageable);
// ⚠️ 错误示例（手动拼接）：
// List<User> content = userRepository.findByStatus("ACTIVE", pageable); // 仅查数据
// long total = userRepository.countByStatus("ACTIVE"); // 单独 count —— 可能因并发写入导致不一致
}
}⚠️ 关键注意事项
- 不要在 Controller 中计算 totalCount：它依赖数据库状态，必须由 Service 层在事务内完成，确保与分页内容数据强一致；
- 避免在 Service 层解析 HTTP 参数（如 @RequestParam）：这会破坏层边界，降低可测试性与复用性；
- 警惕“假分页”陷阱：若 Service 层先查出全量数据再内存分页（.stream().skip().limit()），将严重拖垮性能；务必下推至数据库；
- 考虑 Cursor-based 分页替代 Offset-based：对海量数据或高并发场景，游标分页（如 last_id > ?）更高效稳定，此时分页逻辑更需 Service 层深度参与。
总结而言，分页不是“属于哪一层”的问题，而是“各层协同完成数据契约”的过程：Controller 是参数的守门人与响应的建筑师，Service 是数据的调度者与一致性守护者。二者各司其职，方能构建健壮、可演进、高性能的分页能力。
