Flask中query.paginate()返回Pagination实例，需用items、page、pages等属性获取数据和分页信息；空结果但总数非零因per_page过大或数据不足；OFFSET分页性能差，大数据量应改用游标分页。
Flask 中 query.paginate() 返回的对象怎么用
它不是个普通字典或列表，而是一个 Pagination 实例，自带分页元信息和数据访问接口。直接遍历它（比如 {% for item in pagination %}）拿到的是当前页的数据，但想取总页数、当前页码、是否有下一页，得调它的属性。
-
pagination.items：当前页的模型实例列表（不是原始 SQL 结果，是 ORM 对象） -
pagination.page：当前页码（从 1 开始） -
pagination.pages：总页数（整数，向下取整） -
pagination.has_next/pagination.has_prev：布尔值，判断是否能翻页 -
pagination.next_num/pagination.prev_num：下一页/上一页的页码（注意：可能为None）
为什么 query.paginate(page=1, per_page=10) 有时返回空结果，但总数不为 0
常见于数据库刚初始化或测试数据不足时：你设了 per_page=10，但第 1 页实际只有 3 条，这没问题；但如果总记录数 pages 是 1，items 就是全部数据。真正出问题的情况是——传入了非法 page 值（比如 page=0 或负数），Flask-SQLAlchemy 默认会静默转成 page=1，但若 error_out=True（默认），则抛 404 Not Found 异常。
- 默认行为：
error_out=True→ 页码越界直接 404（适合生产环境） - 调试时可临时设
error_out=False→ 越界返回空items，但pages=0、page=1，容易误判 - 永远检查
pagination.items是否为空，而不是只看pagination.total
模板里怎么安全生成上一页/下一页链接
别硬拼 URL，用 url_for() 构造，并把当前页码作为参数传进去。关键点是：链接里的 page 参数必须是整数，且要保留原请求的其他查询参数（比如搜索关键词 q=xxx）。
- 用
request.args.to_dict()在视图中把查询参数传给模板（注意过滤掉page） - 模板中用
{{ url_for('list_view', page=pagination.prev_num, **args_without_page) }} - 如果没上一页，
pagination.prev_num是None，链接应禁用或隐藏，别让它指向/list?page=None - 避免在 URL 中重复出现
page：确保传给url_for的字典里没有残留的page键
paginate() 的 max_per_page 和性能隐患
max_per_page 不是默认值，而是上限保护——当用户手动传入超大 per_page（如 ?page=1&per_page=10000），它会被截断。但很多人忽略的是：即使设了 per_page=20，如果表有千万级数据，OFFSET 查询仍会变慢（MySQL/PostgreSQL 都存在这个问题）。
- 小项目够用，但数据量 > 10w 行后，
OFFSET分页延迟明显上升 -
paginate()底层用的是LIMIT + OFFSET，无法利用索引跳过前面 N 行 - 真要优化，得换游标分页（cursor-based），靠上一页最后一条记录的 ID 或时间戳做条件，但
paginate()不支持 - 至少加个
max_per_page=100防恶意请求，别让用户一次拉走全部数据
page 参数校验、URL 参数继承、空结果处理、大数据量下的性能退化，这几处最容易漏掉或后期才暴露。 
