唯一能真正防住SQL注入的是数据库服务端预处理语句，必须使用?占位符绑定参数；表名列名等动态部分须用escapeId()或白名单校验；PDO需禁用模拟预处理并统一UTF8MB4字符集；ORM的raw方法若混入用户输入则完全失效。
唯一能真正防住 SQL 注入的，是让数据库服务端亲自处理参数绑定——也就是必须用预处理语句，且禁用模拟模式。其他所有措施（过滤、转义、WAF、ORM 封装）都是补救，不是防线。
Node.js 里必须用 connection.query() 的 ? 占位符
mysql2 或官方 mysql 包都支持 ? 占位符语法，但它不是“可选优化”，而是强制路径。只要用户输入进 SQL，就必须走这条路。
- ✅ 正确：
connection.query('SELECT * FROM users WHERE id = ?', [userId], callback) - ❌ 危险：
connection.query('SELECT * FROM users WHERE id = ' + userId)—— 即使userId是数字，拼接也等于开门 - ⚠️ 注意：
?只保护值，不能用于表名、列名、ORDER BY字段；这些地方拼接会直接报错或被忽略
动态表名/列名必须用 connection.escapeId() 或白名单
当你不得不切换分表、多租户 schema 或按字段排序时，escapeId() 是唯一靠谱的内置方法——它加反引号并转义内部反引号，防住 user`; DROP TABLE users; -- 这类 payload。
- ✅ 安全：
const sql = `SELECT * FROM ${connection.escapeId(tableName)}` - ❌ 无效：
connection.escape()对表名完全没用，它只转义字符串值 - ? 更稳妥：提前定义允许的表名列表，运行时用
inArray()白名单校验，比依赖转义更可靠
PDO 必须关掉 PDO::ATTR_EMULATE_PREPARES
很多 PHP 项目写了 $pdo->prepare() 和 $stmt->execute()，却仍被注入，就是因为 PDO::ATTR_EMULATE_PREPARES 默认为 true——PDO 在 PHP 层自己拼 SQL + 转义，MySQL 根本没收到预处理指令。
- ✅ 强制关闭：
$pdo = new PDO($dsn, $user, $pass, [PDO::ATTR_EMULATE_PREPARES => false, PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]); - ? 验证是否生效：执行
$pdo->prepare("SELECT ?")，若抛出SQLSTATE[HY000]: General error，说明服务端预处理已启用 - ⚙️ 注意：
my.cnf中若设了max_prepared_stmt_count = 0，会静默退化为模拟模式，需检查
字符集不统一，所有防护都会失效
即使开了预处理、关了模拟，如果连接字符集和 MySQL 服务端不一致，宽字节注入（如 gbk 下的 %df%27）仍可绕过。
- ✅ PHP 连接 DSN 必须带
;charset=utf8mb4，或调用mysqli_set_charset($conn, 'utf8mb4') - ? 检查服务端：
SHOW VARIABLES LIKE 'character_set%'，确保character_set_client、character_set_connection、character_set_results全部为utf8mb4 - ? 表和字段的
collation也得是utf8mb4_unicode_ci，否则索引可能失效，emoji 存储异常
最容易被忽略的是 ORM 的 raw() 方法、Query Builder 的 whereRaw() 和 selectRaw()——这些接口一旦混入用户输入，就等于把预处理语句的保护层整个撕开。别信“框架很安全”，信你自己写的那行 raw 调用。
