SQL注入本身不是多租户隔离主因，真正漏洞是tenant_id过滤缺失与用户输入未校验的组合；tenant_id必须从可信上下文提取，禁用拼接、原生SQL绕过、异步线程丢失上下文及DBA直连风险。
直接说结论：SQL注入本身不是多租户隔离的主因，真正导致跨租户数据泄露的是 tenant_id 过滤缺失 + 用户输入未校验的组合漏洞。光防注入不加租户约束，等于给锁配了钥匙却忘了装门。
tenant_id 必须从可信上下文提取，绝不能来自用户输入
常见错误是把 X-Tenant-ID 头、URL 参数或 JWT payload 里的 tenant_id 直接拼进 SQL —— 攻击者只要伪造这个值，就能绕过所有“租户意识”。
- 正确做法：只从已认证的会话上下文（如 Spring 的
SecurityContext、Gin 的c.MustGet("tenant_id")）取值 - JWT 场景下，必须校验签名后再取
tenant_id，且需比对请求头中的X-Tenant-ID是否一致（防 token 复用） - MyBatis 中禁止在
原生 SQL 和 @Query(native = true) 是最大盲区
JPA 的 @Query(native = true)、MyBatis 的 <script></script> 标签、Spring JDBC 的 NamedParameterJdbcTemplate 都绕过 ORM 的租户拦截器，成为高频越权入口。
- 所有原生查询必须显式写
WHERE tenant_id = :tenantId，且参数:tenantId必须由中间件注入，不可由前端传入 - 禁用字符串拼接 SQL：
"SELECT * FROM orders WHERE user_id = " + userId→ 永远不用 - PostgreSQL 可配合 RLS 策略兜底：
CREATE POLICY tenant_isolation ON orders USING (tenant_id = current_setting('app.current_tenant_id')::UUID)，但前提是应用层已设SET LOCAL app.current_tenant_id = 'xxx'
异步线程和定时任务会丢失租户上下文
CompletableFuture、@Async、Quartz 任务默认不继承主线程的 ThreadLocal，导致 TenantContext.getTenantId() 返回 null，过滤条件直接失效。
- Spring 环境下，用
@Async前必须配置TaskDecorator手动传递TenantContext - Quartz Job 中，不要依赖全局
ThreadLocal，改用 JobDataMap 显式传入tenant_id - 日志框架（如 Logback MDC）也需同步注入
tenant_id，否则审计日志无法关联租户
DBA 直连和备份恢复是最后一道防线的破口
开发再严谨，DBA 用 psql 登录后执行 SELECT * FROM orders;，或者 ETL 工具导出全表，照样泄露数据。
- MySQL/PostgreSQL 必须启用行级安全（RLS）或视图封装，让
SELECT *默认受限 - 禁止授予
SHOW DATABASES、PROCESS等元数据权限，防止租户发现其他库存在 - 备份脚本需按租户粒度导出，恢复时强制指定
tenant_id上下文，避免误还原到错误 Schema
最危险的不是你忘了加 WHERE tenant_id = ?，而是你加了，却没验证它是否真被用了 —— 比如在事务嵌套、缓存穿透、异常分支里漏掉。每次上线前，用非本租户 ID 调用任意一个带查询的接口，看返回是否为空，比写一百行单元测试更直接。
