我有一个关于 Django 的分页器模块如何工作以及如何优化它的问题。我从互联网上的不同 API 获得的信息中列出了大约 300 个项目。我正在使用 Django 的分页器模块为我的访问者显示列表，一次显示 10 个项目。分页不像我想要的那样工作。看来分页器必须先获取所有 300 个项目，然后才能拉出每次更改页面时需要显示的 10 个项目。例如，如果有 30 个页面，那么到第 2 页需要我的网站再次查询 API，将所有信息放在一个列表中，然后访问访问者浏览器请求的十个。我不想继续在 API 中查询我在每次翻页时已经拥有的相同信息。
现在，我的视图有一个函数，它查看 get 请求并根据查询查询 API 以获取信息。然后它将所有这些信息放入一个列表并将其传递给模板文件。因此，每当有人翻页时，总是会加载此函数，从而导致再次查询 API。
我应该如何解决这个问题？
谢谢您的帮助。
在这种情况下，分页器需要完整的列表才能完成其工作。
我的建议是定期更新提要的缓存，然后将该缓存用作分页器模块的输入。对每个请求执行密集或冗长的任务总是一个坏主意。如果不是因为用户将体验到页面加载时间，请考虑您的服务器的攻击漏洞。
您可能想查看Django 的低级缓存 API，它允许您将提要结果存储在一个键下的全局可访问位置，您以后可以使用它来检索缓存并为每个页面请求分页。
在选择行之前，ORM 不会加载数据：
query_results = Foo(id=1) # No sql executed yet, just stored.
foo = query_results[0] # now it fires
或者
for foo in query_results:
foo.bar() # sql fires
如果您使用的是在初始化时加载结果的自定义数据源，则分页将无法按预期工作，因为将立即获取所有提要。您可能想要子类化__getitem__或__iter__进行实际提取。然后它将与 Django 期望加载结果的方式一致。
分页将需要知道有多少结果来执行 has_next() 之类的操作。count(*)在 sql 中，获得带有索引的 a 通常很便宜。因此，您还想知道会有多少结果（或者只是估计是否太贵而无法确切知道）。