SQL注入发生在将用户输入拼接到SQL语句中的任何位置，尤其是用format()、%或+拼接时；必须使用参数化查询，并对表名、字段名等结构化部分做白名单校验。
SQL注入到底在哪儿发生
不是所有拼接字符串的地方都危险，但所有用 format()、% 或 + 拼接用户输入进 SQL 语句的位置，都是高危点。比如 SELECT * FROM users WHERE name = '{}'".format(request.args.get('name')) —— 这种写法只要用户传入 ' OR '1'='1，就直接绕过验证。
本质问题不是“用了原生 SQL”，而是“把不可信数据当代码执行”。ORM 也不是银弹：手写 filter("name = '{}'".format(...)) 同样会中招。
原生 SQL 必须用 execute() 的参数化接口
Python DB-API（如 sqlite3、psycopg2、pymysql）都支持占位符，但语法不统一，混用就会出错：
-
sqlite3只认?或:name，不支持%s -
psycopg2只认%s，且必须用元组或字典传参，不能用列表 -
pymysql支持%s，但不支持命名参数%(...)s（除非开启named=True）
错误示例：cursor.execute("SELECT * FROM user WHERE id = %s", [user_id]) —— 在 psycopg2 中会报 TypeError: not all arguments converted，因为期望元组，给了列表。
立即学习“Python免费学习笔记（深入）”；
正确写法（以 psycopg2 为例）：cursor.execute("SELECT * FROM user WHERE id = %s", (user_id,))
Django ORM 不等于自动免疫
Django 查询集默认安全，但三个地方容易翻车：
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
-
extra()和raw()：直接执行原始 SQL，参数必须手动用params=...传入，不能拼接 -
filter(**{field_name: value})：如果field_name来自用户输入（比如搜索字段名），会触发动态字段注入 -
Q对象组合时用了eval()或字符串格式化构造表达式
典型错误：User.objects.filter(**{request.GET.get('sort_by', 'id'): 'asc'}) —— 用户传 sort_by=__dict__ 就能读取内部对象结构。
安全做法：白名单校验字段名：allowed_fields = {'id', 'name', 'email'}; field = request.GET.get('sort_by'); if field not in allowed_fields: field = 'id'
Flask-SQLAlchemy 的 text() 是个隐性陷阱
db.session.execute(text("SELECT * FROM user WHERE name = :name"), {"name": name}) 看似参数化，但只要把变量插进 text() 字符串里，就失效了：
危险写法：text(f"SELECT * FROM user WHERE name = '{name}'") 或 text("SELECT * FROM user WHERE " + condition) —— 占位符根本没机会生效。
真正起作用的只有两件事：一是 text() 内部纯静态 SQL，二是所有动态值必须通过第二参数字典/元组传入。连表名、字段名、ORDER BY 方向这些都不能参数化，得靠白名单或正则校验。
性能提示：频繁调用 text() 不影响 SQL 编译缓存，但每次都要解析字符串；不如优先用 Query API，只在真需要动态 SQL 时才用。
复杂点在于：SQL 注入不只发生在查询，INSERT/UPDATE/DELETE 同样危险；而很多开发者只盯着 SELECT 防御。字段名、表名、排序方向、LIMIT 偏移量——这些看似“结构”的部分，一旦来自用户输入，就得单独设防。
