本文介绍使用 peewee 的 prefetch() 函数一次性预加载关联模型（如销售单及其商品），彻底规避模板渲染中因循环访问外键引发的 n+1 查询问题，将查询复杂度从 o(n+1) 降至 o(1)。
在使用 Peewee 构建 Web 应用时，一个常见且隐蔽的性能陷阱是 N+1 查询问题：当通过外键关系遍历关联对象（例如 sales.items → item.item_name）时，若未显式预加载关联数据，Peewee 默认会在每次访问 it.item 时触发一次独立的 SELECT 查询——导致 1 次主查询 + n 次子查询，严重拖慢响应速度。
你当前的代码：
sales = Sales.get(Sales.sales_id == sales_id) # 1 次查询
# 模板中 {% for it in sales.items %}{{ it.item.item_name }}{% endfor %}
# → 每次 it.item 触发 1 次 Item 查询 → n 次额外查询即使尝试手动 JOIN（如 Sales.select().join(SalesItem).join(Item)），也无法直接解决：因为 sales.items 是反向关系（backref='items'），返回的是 SalesItem 实例集合，而 it.item 仍是未加载的 ForeignKeyField，仍会懒加载。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
✅ 正确解法：使用 peewee.prefetch() 进行分步预加载（而非单条 JOIN SQL）。它通过 2–3 次批量查询（而非嵌套循环查询），高效填充关联对象：
from peewee import prefetch
def html_get(request, sales_id):
# 步骤 1：获取目标 Sales 对象（1 次查询）
sales_query = Sales.select().where(Sales.sales_id == sales_id)
# 步骤 2：预加载所有关联的 SalesItem，并连带预加载其关联的 Item（1 次 JOIN 查询）
sales_with_items = prefetch(
sales_query,
SalesItem.select().join(Item) # 显式指定要加载 Item 字段
)
return templates.TemplateResponse('view_sales.html', {'sales': sales_with_items})? 关键说明：
- prefetch() 内部执行 两阶段查询：先查 Sales，再用 IN 子句批量查 SalesItem（含 JOIN Item），最后将结果按外键关系自动挂载到 sales.items 和 sales.items[i].item 上；
- 模板中可安全使用 {{ it.item.item_name }}，不再触发任何额外查询；
- 若需加载多级关联（如 Item.category），可继续扩展：prefetch(sales_query, SalesItem.select().join(Item).join(Category))；
- ⚠️ 注意：prefetch() 要求主查询必须是 select()（不能用 get()），且需确保外键字段已正确配置（如 SalesItem.sales 指向 Sales）。
✅ 最终效果：无论一个销售单包含多少商品，整个视图仅执行 2 次 SQL 查询（常数级），彻底告别 N+1，大幅提升并发性能与用户体验。
