必须使用$wpdb->prepare()处理所有含用户输入的sql查询，因其通过%d、%s等占位符严格分离代码与数据，防止攻击者通过' or 1=1--等输入篡改查询逻辑；字符串拼接则让输入直接成为sql结构的一部分，导致注入。
直接用 $wpdb->prepare()，别拼接字符串；所有用户输入进SQL前必须过这道关，否则就是给攻击者留后门。
为什么不能用字符串拼接构造SQL
WordPress 的 $wpdb 对象本身不自动过滤变量，它只负责执行你给它的 SQL。一旦你写成 "SELECT * FROM $table WHERE title = '" . $_GET['q'] . "'" 这种形式，攻击者输入 ' OR 1=1 -- 就能让整条查询逻辑崩坏——数据库会把它当语法的一部分执行，而不是数据。
常见错误现象包括：
- 后台搜索功能返回全部文章（
1=1恒真） - 用户登录绕过（
' OR 'a'='a让 WHERE 条件永远成立） - 页面空白或报错
WordPress database error You have an error in your SQL syntax
根本原因不是“单引号没转义”，而是程序把用户输入当成了代码结构的一部分。这不是修补小漏洞，是重划数据与指令的边界。
$wpdb->prepare() 的正确用法和参数规则
$wpdb->prepare() 是 WordPress 官方推荐且唯一内置的参数化查询机制，它底层调用的是 MySQLi 的 mysqli_real_escape_string() + 占位符解析，但比手写更安全、更统一。
使用要点：
- 占位符只能是
%s（字符串）、%d（整数）、%f（浮点），不支持%i或自定义格式 - 每个占位符必须有且仅有一个对应参数，多一个少一个都会导致返回
false或静默截断 - 表名、字段名、ORDER BY 子句不能用占位符——它们属于 SQL 结构，不是数据，必须白名单校验或硬编码
- LIKE 查询要手动拼接通配符，但必须套在
$wpdb->esc_like()里防转义干扰：$wpdb->prepare("WHERE post_title LIKE %s", '%' . $wpdb->esc_like($title) . '%')
错误示例：$wpdb->prepare("SELECT * FROM %s WHERE id = %d", $table_name, $id) ——%s 不能用于表名，会被原样转义，查不到数据。
哪些地方容易漏掉 prepare()？
高频失守点不在主查询，而在边缘场景：
- 自定义 REST API 回调函数中直接用
$_POST构造$wpdb->get_var() - WP_Query 之外的手动分页逻辑，比如
OFFSET和LIMIT从$_GET读取却没校验是否为数字 - 插件设置页面保存时，把
update_option()的值直接塞进$wpdb->insert()而没 prepare - AJAX 处理器里调用
$wpdb->delete()时，条件字段来自未过滤的$_REQUEST
特别注意：即使你用了 esc_sql()，它只是简单转义单引号和反斜线，无法防御 UNION SELECT 或基于错误的注入。它已被标记为 deprecated，官方文档明确建议改用 prepare()。
复杂动态查询怎么办？比如可选字段、可变排序
遇到 ORDER BY ? 或 GROUP BY ? 这类无法用占位符的地方，必须放弃“通用拼接”，改用白名单控制：
- 排序字段限定为
['post_date', 'post_title', 'menu_order']，用in_array($order_by, $allowed_fields, true)校验 - 动态表名必须来自常量或配置项，禁止从请求参数读取；若真需多租户支持，用
$wpdb->prefix . 'custom_table'拼接前缀，而非接收完整表名 - 如果业务强依赖
UNION或子查询，优先拆成多个prepare()查询，在 PHP 层合并结果，而不是在一个字符串里拼出整个 SQL
最危险的不是不会写 prepare()，而是以为加了 esc_html() 或 intval() 就等于安全——它们只解决输出或类型问题，跟 SQL 执行时的数据边界毫无关系。
