f-string在SQL拼接中因定义时即求值导致远程代码执行，根本原因是缺乏结构与数据分离；%s是数据库驱动的参数绑定指令，仅对值安全，表名等标识符须白名单校验。
f-string在SQL拼接中会立即求值，把恶意输入变成可执行代码
根本原因不是f-string本身有问题，而是它在定义时就完成所有表达式计算，数据库收到的是一条“已经长成”的完整SQL字符串，没有任何结构与数据分离机制。攻击者输入的' OR '1'='1、'; DROP TABLE users;甚至__import__('os').system('rm -rf /')，都会在Python解释器层面先执行一遍，再塞进SQL里——这已经超出SQL注入范畴，属于远程代码执行。
常见错误写法及对应危险现象
这些写法看着简洁，但每一种都等于把数据库密码贴在门口：
-
f"SELECT * FROM users WHERE name = '{username}'"→ 输入admin' --直接注释掉后续条件 -
f"INSERT INTO logs VALUES ({user_id}, '{message}')"→ 输入1, 'x'); DROP TABLE logs; --触发堆叠查询 -
f"SELECT * FROM {table_name} WHERE id = %s"→ 表名未校验，table_name为users; DELETE FROM sessions; --时，f-string先执行分号后命令
为什么%s占位符比f-string安全
%s不是Python字符串格式化符号，而是数据库驱动（如pymysql、psycopg2）识别的参数绑定指令。它的执行流程是：先向数据库发送语句骨架（如SELECT * FROM users WHERE id = ?），数据库预编译并生成执行计划；再把用户输入作为纯数据传入，不参与语法解析。即使输入含单引号、分号、SQL关键字，也只被当作文本值处理。
必须注意：%s只对值有效，不能用于表名、列名、ORDER BY字段等标识符位置；且参数必须是元组或列表，单元素别漏逗号——cursor.execute("WHERE id = %s", (user_id,))合法，(user_id)不合法（Python会当成括号运算，不是元组）。
立即学习“Python免费学习笔记（深入）”；
动态表名/字段名必须走白名单硬校验
数据库协议不支持对标识符做参数化，所以任何拼接{table_name}的行为，都必须前置强校验。例如：
ALLOWED_TABLES = {"users", "orders", "products"}
if table_name not in ALLOWED_TABLES:
raise ValueError("Invalid table name")
query = f"SELECT * FROM {table_name} WHERE status = %s"
cursor.execute(query, (status,))
这里{table_name}已脱离用户控制范围，拼接才安全。漏掉这步校验，哪怕后面用%s也毫无意义。
最易被忽略的一点：ORM如SQLAlchemy虽默认参数化，但.text()或execute(text("..."))仍可能绕过防护；自定义SQL字符串里混用f-string和%s，只要有一个变量没走参数化，整条语句就失效。
