SQLAlchemy的execute()必须用params传参，不能字符串拼接；text()仅是包装器，防注入依赖占位符+驱动预编译，动态标识符（字段名、表名）须白名单校验。
SQLAlchemy的execute()必须用params传参，不能字符串拼接
很多人以为用了SQLAlchemy就自动免疫SQL注入，结果在execute()里写f"SELECT * FROM user WHERE name = '{name}'"，照样中招。SQLAlchemy原生执行不校验SQL结构，只负责把params安全填入占位符——前提是你要真用占位符。
常见错误现象：sqlalchemy.exc.ProgrammingError: (psycopg2.errors.UndefinedColumn) column "admin'--" does not exist，说明后端把用户输入当字段名解析了，已经发生注入尝试。
- 正确写法（命名参数）：
conn.execute(text("SELECT * FROM users WHERE email = :email"), {"email": user_input}) - 错误写法（拼接）：
conn.execute(text(f"SELECT * FROM users WHERE email = '{user_input}'")) - 注意：
text()本身不防注入，它只是包装器；防注入靠的是params字典/元组 + 驱动层预编译
Django ORM的filter()安全，但extra()和raw()是高危区
Django默认查询集（如User.objects.filter(username=user_input)）底层走参数化，无需额外处理。但一旦跳出ORM抽象，风险立刻回归。
典型翻车场景：搜索功能支持按任意字段排序，代码写成User.objects.extra(order_by=[f"{request.GET.get('sort')} ASC"])——攻击者传sort=__dict__就能触发对象属性泄露。
-
extra()和raw()里的SQL字符串，必须用params=传值，且字段名/表名需白名单校验 - 排序字段不能直接来自用户输入，应映射为固定选项：
{"name": "name", "date": "created_at"}.get(sort_param, "id") -
Q对象组合时避免eval()或format()构造表达式，比如Q(**{field: value})中field若可控，等同于动态字段注入
SQLAlchemy Core的select().where()比手写SQL更安全，但别乱用literal_column()
用select(users_table).where(users_table.c.email == bindparam("email"))这类Core写法，SQL结构由Python对象定义，用户输入只进bindparam，天然隔离代码与数据。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
但有人为了“灵活”改字段名，用literal_column(request.GET.get("col"))，这就等于把SQL语法控制权交出去了。
-
literal_column()、table.columns[xxx]、text()中的标识符部分（如表名、字段名）都不受参数化保护 - 结构化部分必须白名单校验：
if col_name not in ["name", "email", "status"]: raise ValueError("Invalid column") - 复杂动态查询优先用Query Builder（如SQLModel的
select()链式调用），而非拼SQL字符串
psycopg2和pymysql驱动对参数格式敏感，传错类型会静默失败
SQLAlchemy底层依赖DB-API驱动，而不同驱动对参数格式要求不同。比如psycopg2只接受元组或字典，传列表会报TypeError: not all arguments converted；pymysql默认不支持命名参数%()s，需显式启用named=True。
更危险的是：某些驱动在参数类型不匹配时会降级为字符串拼接，表面正常实则已失守。
- 统一用字典传参最稳妥：
{"id": 123, "name": "alice"}，兼容所有主流驱动 - 避免混合使用：
execute("WHERE id = %s AND status = %s", [123, "active"])在psycopg2中报错，在pymysql中可能侥幸通过但有隐患 - 上线前用恶意输入（如
' OR 1=1 --）跑一次集成测试，验证是否真被当作字符串值而非SQL片段
参数化不是开关，是贯穿SQL生成全过程的约束。最容易被忽略的，是那些“看起来不像SQL”的地方——排序字段、分组条件、动态表名，它们不走params路径，却一样能执行任意SQL逻辑。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
