查询性能安全规范 当代码涉及数据库或远程服务的批量查询时，防止 N+1、IN 子句过长、递归无界等高频性能陷阱。 与 配合：本 skill 关注「查询效率」，租户隔离遵循后者。 --- 陷阱 #1: 循环内调用单条查询 → N+1 场景 : 内部直接调用 或同等单条远程调用 问题根因 每次循环触发一次 SQL/HTTP，N 个元素就是 N 次往返。100 元素 = 100 次 SQL，1000 元素就是 1000 次。本地开发数据少看不出来，生产环境直接拖垮接口。 嗅探信号 只要在 service / handler 方法里看到以下任一模式，立即怀疑 N+1： 正确做法 「 先批量拿 → 落到 Map → 循环里查 Map 」三步走： Repository 必须提供的批量方法 | 单条方法 | 必须配套 | 用途 | |---------|---------|------| | | / | 已知主键集合 | | | | 多租户场景批量 | | | | 已知外键集合 | 新增带 IN 的方法时 必须 和单条方法成对出现，避免上层不得不写 N+1。 隐式 N+1：循环内调 DTO 转换函数 最坑的一种 N+1 —— / / 这类辅助方法看起来"一个函数搞定一切"，但内部可能藏着 4-5 次 ，循环里调一次就是 N×K 次 SQL。 修复策略 策略 A：两阶段处理 （推荐，适合"先筛选…