typing 本身不能防范 SQL 注入，因其仅为静态类型注解、运行时不生效，无法阻止字符串拼接；真正有效的是参数化查询、白名单校验等运行时机制。
typing 本身不能防范 SQL 注入。
类型提示（typing）只是编译期/静态分析用的注解，运行时不生效，对 SQL 执行过程零干预。哪怕你写 def query_user(name: str) -> User:，只要内部还是用 f"SELECT * FROM users WHERE name = '{name}'"，照样被 O'Reilly 或 admin' OR '1'='1 打穿。
真正起作用的是参数化查询机制，类型提示最多只能帮你早点发现“传了个 dict 进去却期望 str”，但拦不住拼接字符串。
为什么 type hint 对防注入完全无效
Python 的类型提示不改变运行时行为：str 注解不会自动转义单引号，Literal["users", "orders"] 不会阻止用户传 "users; DROP TABLE users;"（如果它被拼进 SQL 字符串里）。IDE 或 mypy 可能报错，但程序照常执行、数据库照常被注入。
立即学习“Python免费学习笔记（深入）”；
哪些地方误以为 type hint 有用，实际危险依旧
-
def get_by_id(user_id: int) -> dict:—— 如果内部是cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")，攻击者传user_id=123 OR 1=1（只要函数签名允许任意int子类或 duck-typed 对象），就可能触发注入（尤其当__format__被重载时） -
field_name: Literal["name", "email"]—— 看似安全，但如果代码里写成f"ORDER BY {field_name}"，而field_name实际来自用户请求且未校验，Literal注解在运行时等于不存在 -
TypedDict描述参数结构 —— 无法阻止字段值本身含恶意 SQL 片段，比如{"name": "admin' --"}被直接用于拼接
真正该用什么替代 type hint 来防注入
必须用运行时强制机制：
- 所有用户输入进 SQL 的位置，只走
cursor.execute("WHERE name = ?", (name,))这类参数化路径，?或%s占位符由驱动处理，不是字符串替换 - 动态表名/列名等结构部分，用白名单硬控制：
if field not in ("id", "name", "status"): raise ValueError，别信注解 - ORM 查询必须用原生接口：
User.objects.filter(id=user_id)安全，但User.objects.extra(where=[f"name = '{name}'"])直接失效 - 用
sqlparse或正则做上线前 SQL 模板扫描，查出所有f"..."和.format()中含用户变量的语句
类型提示可以配合 mypy 做早期提醒（比如检测到某函数接受 str 却被传了未清洗的 request.GET），但它只是辅助线索，不是防护层。SQL 注入的防线只有一条：不让任何用户输入以字符串拼接方式进入 SQL 文本。
