Peewee执行原生SQL必须参数化：execute_sql()需传参而非字符串拼接；raw_query()不支持动态表名列名，须白名单校验；fn/SQL类混入用户输入即危险；事务中执行需注意版本兼容性及ORM状态同步。

用 execute_sql() 执行原生 SQL 时必须参数化

Peewee 的 execute_sql() 不自动做参数绑定，直接拼接字符串等于敞开 SQL 注入大门。比如写 db.execute_sql(f"SELECT * FROM user WHERE name = '{name}'")，只要 name 来自用户输入（表单、URL 参数、JSON body），就极大概率被利用。

正确做法是把值作为第二个参数传入，由 Peewee 底层用数据库驱动的参数化机制处理：

db.execute_sql("SELECT * FROM user WHERE name = ? AND status = ?", name, status)

注意：不同数据库占位符不同 —— SQLite/MySQL 用 ?，PostgreSQL 用 %s，但 Peewee 会根据 Database 实例类型自动适配，你只需统一写 ? 即可（除非显式用了 PostgresqlDatabase 且手动调用底层游标）。

避免在 raw_query() 中拼接字段名或表名

raw_query() 返回的是 Query 对象，常用于复杂查询，但它只对 WHERE / VALUES 部分支持参数化，不接受表名、列名、ORDER BY 字段等动态标识符。

如果必须动态指定表名（比如按租户分表），不能这样写：

raw_query(f"SELECT * FROM {table_name} WHERE id = ?", user_id)  // ❌ 危险

而应提前白名单校验：

• 维护一个允许的表名集合：ALLOWED_TABLES = {"user_v1", "user_v2", "order_2026"}
• 校验：if table_name not in ALLOWED_TABLES: raise ValueError("Invalid table")
• 再拼接：raw_query(f"SELECT * FROM {table_name} WHERE id = ?", user_id)

字段名同理，别信“用户只输字母数字”这种假设 —— Unicode 控制字符、反引号、括号都可能绕过简单正则。

慎用 fn 和 SQL 类构造动态表达式

fn.COUNT() 或 SQL("NOW()") 看似安全，但一旦混入用户输入就失效。例如：

fn.CONCAT("Hello ", user_input)  // ❌ user_input 若为 "World' -- "，可能破坏语义

真正安全的组合是：

• 固定函数模板 + 参数化值，如 fn.DATE_ADD(fn.CURDATE(), fn.INTERVAL(days, 'DAY')) 中 days 是整数变量，会被当作参数传入
• 绝对不用 SQL(f"ORDER BY {sort_field}")，改用白名单映射：sort_map = {"name": "name ASC", "age": "age DESC"}，再 SQL(sort_map.get(sort_by, "id"))

Peewee 的 SQL 类本身不解析内容，它只是原样透传，等价于手写字符串 —— 安全性完全取决于你怎么喂它。

连接池与事务中执行原生 SQL 的额外注意点

在 db.atomic() 或 db.manual_commit() 块里调用 execute_sql()，不会自动参与事务管理，除非你用的是 Peewee 3.14+ 且数据库驱动支持（如 psycopg2）。低版本或 SQLite 可能静默提交。

更隐蔽的风险是：混合 ORM 操作和原生 SQL 时，ORM 的缓存、实例状态不会感知原生修改。例如：

user = User.get(User.id == 1)
db.execute_sql("UPDATE user SET name = ? WHERE id = ?", "NewName", 1)
print(user.name)  // 仍是旧值，ORM 实例未刷新

所以，涉及关键状态变更时，要么全用 ORM，要么执行完原生 SQL 后主动 User.get() 刷新，或用 db.execute_sql() 配合 fetchone() 拿结果，别依赖 ORM 实例的陈旧数据。