必须用 execute() 而非 query() 防 SQL 注入，因 query() 不保证预编译、易被字符串插值绕过；execute() 强制 PREPARE/EXECUTE 分离，但需满足占位符规范、禁用命名参数、参数为真数组等条件，动态标识符须白名单+正则校验，参数类型须与字段严格对齐。
必须用 execute()，别用 query() 拼接用户输入——这是堵住 SQL 注入最直接有效的动作。
为什么 query() 看似安全实则危险
query() 默认不走服务端预编译，即使你写了 "SELECT * FROM users WHERE id = ?" 并传入数组参数，底层仍可能做字符串插值（尤其在 MySQL 配置宽松或驱动未禁用 permitLocalFileAccess 时）。更典型的是这种写法：query(`SELECT * FROM ${tableName} WHERE id = ?`, [id])——模板字符串拼接表名，? 根本救不了。
常见错误现象：
- 传入
userId = "1 OR 1=1"后查出全表数据 - 错误日志里出现
ER_PARSE_ERROR或静默返回空结果（类型错位导致） - 用
query("INSERT INTO t VALUES (?)", [null])插入失败，但没报错，字段被设为默认值
execute() 的硬性使用条件
execute() 强制触发 MySQL 的 PREPARE → EXECUTE 流程，SQL 结构和参数彻底分离。但它不是“开了就自动安全”的开关，必须满足以下条件：
- SQL 字符串中只允许出现
?占位符，禁止任何模板字符串拼接（包括表名、列名、ORDER BY字段） - 连接选项显式声明
namedPlaceholders: false（虽然默认是false，但显式写出来可防误开） - 首次调用会触发 PREPARE，后续同结构查询复用执行计划——这意味着它天然适合高频重复查询（如登录校验、分页列表）
- 参数数组必须是真实数组，不能是伪数组或单值（比如
[id]正确，(id)是 number，id是 number，都不行）
动态表名/列名只能靠白名单 + 正则兜底
预编译机制天生不支持参数化表名、列名、排序字段。例如 execute("SELECT * FROM ? WHERE id = ?", [tableName, id]) 会把 tableName 当成字符串字面量，查不到数据；ORDER BY ? 同理，MySQL 会报语法错误。
正确做法是白名单校验后拼接，再加一层正则过滤：
- 定义允许的表名：
const allowedTables = ["users", "orders", "products"]; - 严格比对：
if (!allowedTables.includes(userInputTable)) throw new Error("Invalid table"); - 列名映射（避免用户传
created却想查created_at）：const sortMap = { created: "created_at", name: "full_name" }; - 拼接后过正则：
/^[a-zA-Z0-9_]+$/，拒绝反引号、点号、空格、连字符等任何符号
参数类型错位会导致查询无声失败
mysql2 对 JS 类型到 SQL 类型的隐式转换非常敏感。比如把 true 传给 TINYINT(1) 字段没问题，但传给 VARCHAR 字段会变成字符串 "true"，导致 WHERE 条件匹配不到预期记录。
容易踩的坑：
- 前端传
"1"（字符串）给 INT 字段，MySQL 可能隐式转但不报错，结果不可控 - 把
null传给NOT NULL字段，插入失败但 error 可能被忽略 - 时间字段传
Date对象没问题，但传"2026-05-09"字符串可能被截断或格式错误
建议在进 execute() 前做类型归一化：整数用 parseInt()、布尔用 Boolean()、时间用 new Date().toISOString()，并配合数据库字段定义做校验。
真正难的不是写对 execute()，而是所有动态拼接点（表名、列名、WHERE 条件分支、ORDER BY）都得独立过白名单+正则，且每个参数类型都得跟字段定义对齐——漏一个，就等于留一道后门。
