joi校验不能直接防sql注入，因其仅做数据格式验证，不干预sql执行；必须配合参数化查询才能有效防御，且动态sql结构（如列名、表名）需额外白名单校验。
为什么Joi校验不能直接防SQL注入
Joi本身不处理SQL执行，它只做数据结构和格式验证。哪怕你用joi.string().email()把邮箱校得滴水不漏，如果后续代码还是用模板字符串拼接SQL：`SELECT * FROM users WHERE email = '${req.body.email}'`，照样被注入。Joi的作用是“提前筛掉明显非法输入”，不是给SQL语句加保险丝。
哪些Joi规则对防注入有实际价值
真正能降低SQL注入风险的，是那些能拒绝危险字符或结构的规则，而不是单纯检查长度或格式：
-
joi.string().pattern(/^[\w\s\-@.]+$/)：白名单式限制，禁止'、"、;、--、/*等SQL元字符 -
joi.number().integer().min(1).max(1000)：数值类参数（如id、limit）必须走数字类型，杜绝1 OR 1=1这种字符串注入 -
joi.string().valid('active', 'inactive', 'pending')：状态类字段强制枚举，避免用户传' OR 1=1 --绕过条件 -
joi.string().alphanum().max(50)：比.string()更严格，自动排除空格外的符号（但注意：连字符-和下划线_仍允许，需按需补充.pattern()）
Joi校验必须配合参数化查询才有效
校验只是第一道门，真正拦住SQL注入的是执行层。常见错误组合：
✅ 正确链路：req.body → joi.validate() → 通过 → connection.query("SELECT * FROM users WHERE id = ?", [validated.id])
❌ 危险链路：req.body → joi.validate() → 通过 → connection.query(`SELECT * FROM users WHERE name = '${validated.name}'`)
基于三引擎设计，从微信文章、新闻和博客网页提取干净内容，支持标题作者日期元数据，多格式和批量处理。
注意：mysql2的query()方法支持数组参数（位置绑定）和对象参数（命名绑定），但mysql原生模块只支持数组。别写错占位符——?不能写成:id，否则参数根本不会绑定。
动态列名/表名是Joi无法覆盖的盲区
Joi能校验值，但没法校验SQL结构本身。比如排序字段req.query.sortBy若用于ORDER BY ${req.query.sortBy}，即使Joi校验为string().max(20)也毫无意义。
必须手动白名单控制：
const allowedSortFields = ['id', 'name', 'created_at'];if (!allowedSortFields.includes(req.query.sortBy)) { throw new Error('Invalid sort field'); }
同理，req.query.tableName、req.body.joinType这类直接影响SQL语法的输入，Joi只能做存在性检查，不能替代逻辑层的硬校验。
