Django ORM 默认防 SQL 注入，但 raw()、extra()、cursor.execute() 等绕过 ORM 的操作必须显式参数化；LIKE 等需手动转义；动态表名、字段名、排序等非值参数须白名单校验。
用 Django ORM 就不会 SQL 注入？
绝大多数情况下，是的——但前提是别绕过 ORM 的参数化机制。Django 的 filter()、get()、exclude() 等 QuerySet 方法默认使用参数化查询，底层交给数据库驱动做绑定变量处理，原始 SQL 中的值永远不会拼接到字符串里。
容易踩的坑是：以为“用了 Django”就绝对安全，结果在不该用字符串格式化的地方硬塞变量。
- 别用
f"SELECT * FROM user WHERE name = '{name}'"或"WHERE name = '%s'" % name - 别用
extra(where=[f"name = '{name}'"])——where参数不自动转义 - 别用
raw()时直接插变量：User.objects.raw("SELECT * FROM auth_user WHERE username = '%s'" % username)
Django raw() 和 extra() 怎么安全传参？
raw() 和 extra() 是 ORM 中少数允许写原生 SQL 的入口，也是 SQL 注入高发区。它们都支持显式参数绑定，但语法不同、行为有差异。
用 raw() 必须用 params 关键字传元组或字典，且只认 %s 占位符（PostgreSQL/SQLite/MySQL 都兼容）：
User.objects.raw("SELECT * FROM auth_user WHERE username = %s AND is_active = %s", params=["alice", True])
extra() 的 where 不接受 params，但 tables、joins 等也不该由用户输入控制；真要动态条件，应改用 Q 对象或把过滤逻辑移到 filter() 中。
-
raw()的params是唯一安全方式，%s不能换成{}或:name -
extra(where=...)里的字符串如果含用户输入，必须手动调用connection.ops.adapt_unknown_value()（不推荐，难维护） - SQLite 下
raw()不支持命名参数（如%(name)s），统一用位置参数%s
自定义 Manager 或 raw SQL 中怎么处理 LIKE 模糊匹配？
LIKE 查询常被忽略转义问题：用户输入的 %、_ 会被数据库当通配符执行，这不是注入，但属于逻辑漏洞（比如搜 %admin% 匹配到所有用户名含 “admin” 的记录）。Django 不自动处理 LIKE 转义，得手动加 escape 字符。
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
正确做法是用 __contains、__icontains 等字段查找，它们由 ORM 自动转义并生成带 ESCAPE 的 SQL；若必须用 raw()，需显式指定 escape：
User.objects.raw("SELECT * FROM auth_user WHERE username LIKE %s ESCAPE '\'", params=["\%alice\%"])
-
__search（全文索引）和__regex同样不自动转义用户输入，需预处理 - 用
connection.cursor()执行原生 SQL 时，也必须走cursor.execute(sql, params)，不能用.format()或%拼接 - PostgreSQL 的
ILIKE和 MySQL 的LOWER()包裹也不能绕过参数绑定
第三方包或数据库视图会不会绕过 ORM 防护？
会。只要最终执行的是拼接出来的 SQL 字符串，ORM 的防护就失效。典型场景包括：用 django-sql-explorer 允许用户写查询、用 django-pivot 动态生成报表 SQL、或对接 PostgreSQL 视图时在 view definition 里硬编码了用户字段名。
这些地方的“输入”不是 Django 的 request.GET，而是配置项、模型字段名、排序字段（order_by 参数）、甚至分表后缀。它们不经过 QuerySet 的参数化流程，必须单独校验。
- 排序字段必须白名单校验：
if sort_field not in ["username", "email", "date_joined"]:再用order_by(sort_field) - 动态表名/字段名不能来自 request，应映射为内部枚举或配置键
- 用
cursor.execute()时，哪怕只传一个整数 ID，也要放进params元组，不要写成f"WHERE id = {id}"
最危险的不是不懂怎么防，而是忘了哪段代码没走 QuerySet —— 尤其是老项目里混着 raw SQL、cursor、和手写的管理命令。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
