SQLAlchemy的filter()、filter_by()、where()等ORM查询方法天然防SQL注入，因其底层采用参数化绑定机制，用户输入仅作为独立参数传递而非SQL代码；但动态字段名、表名、排序字段等结构部分必须通过白名单校验，text()原生SQL须严格使用命名占位符及字典传参。
只要不用字符串拼接构造 SQL，FastAPI + SQLAlchemy 异步模式默认就是防注入的；真正危险的操作，往往藏在你自以为“灵活”的地方。
为什么 filter() 和 where() 天然安全
SQLAlchemy 的 ORM 查询方法（如 filter()、filter_by()、where()）底层全部走参数化绑定。用户输入不会被解析为 SQL 代码，而是作为独立参数传给数据库驱动。
- ✅ 安全写法：
session.execute(select(User).where(User.email == email_input)) - ✅ 同样安全（异步）：
await session.execute(select(User).where(User.email == email_input)) - ❌ 危险写法：
text(f"SELECT * FROM users WHERE email = '{email_input}'")—— 直接绕过所有防护 - ❌ 更隐蔽的危险：
session.query(User).filter("email = '" + email_input + "'")—— 字符串拼接在任何位置都算破防
手写 text() 时必须用命名参数
当你必须用 text()（比如动态排序、窗口函数、复杂 JOIN），参数只能通过命名占位符传入，且不能混用位置参数或字符串插值。
- ✅ 正确：
text("SELECT * FROM users WHERE status = :status AND created_at > :since")，再传{"status": "active", "since": dt} - ✅ IN 子句也得守规矩：
text("WHERE id IN :in_list")，传参时必须是{"in_list": tuple(ids)}—— 注意必须是tuple，list会报错 - ❌ 错误：
text("SELECT * FROM users WHERE id IN (" + ",".join(map(str, ids)) + ")")—— 这是典型“白名单幻觉”，看似没单引号，实则照样注入
表名、字段名、ORDER BY 无法参数化，必须白名单校验
SQLAlchemy 不允许对结构部分（如表名、列名、ORDER BY 字段）做参数化，因为它们属于语法结构，不是数据。这部分一旦由用户控制，就必须硬性限制。
- 多租户场景切换 schema：
if tenant_schema not in ["public", "tenant_a", "tenant_b"]: raise HTTPException(400) - 前端传
?sort=created_at&order=desc：if sort_field not in ["created_at", "name", "email"]: sort_field = "created_at" - 别直接
getattr(User, sort_field)—— 除非你确认sort_field已经过白名单过滤 - 字段名拼接进
text()更要警惕：text(f"ORDER BY {sort_field} {order}")是高危操作，必须拆成白名单分支
Pydantic 不是防火墙，约束得写实
Pydantic 能帮你挡掉明显非法输入，但它不自动清理或截断。攻击者仍可传入超长 payload 或嵌套结构触发下游异常，甚至绕过 ORM 层直接打到数据库驱动。
- 显式加约束：
username: str = Field(min_length=2, max_length=50, pattern=r'^[a-zA-Z0-9_]+$') - 语义类型优先：
email: EmailStr、url: HttpUrl（需安装pydantic[email]） - 避免只写
str：空字符串、超长字符串、含 SQL 关键字的字符串都可能在后续逻辑中引发问题 - 注意：Pydantic 验证发生在依赖注入阶段，但 ORM 查询执行前仍需二次校验（比如字段是否真存在于模型中）
最容易被忽略的是动态 SQL 中的结构部分校验——它不像数据参数那样有自动防护，也不像 Pydantic 那样有声明式约束，必须靠人工白名单+显式判断守住最后一道门。
