React前端无法阻止SQL注入，关键在于不干预内容本身而按字段语义设白名单+长度限制，确保后端参数化查询安全执行，且前后端校验规则必须完全一致。
React前端无法阻止SQL注入，但可以避免把明显危险的字符或结构直接交给后端——关键不是“过滤掉所有可能被利用的字符”，而是让后端参数化查询能安全执行。
为什么不能靠正则过滤单引号、分号、--
攻击者用反引号`、十六进制编码0x27、宽字节%A1%A1就能绕过常见正则；更麻烦的是，你删掉一个'，后端拼接时可能反而破坏语义（比如把O'Connor变成OConnor，导致查不到用户）。真正该做的是：不干预内容本身，只拦截明显不合业务逻辑的输入。
该拦截什么？按字段类型设白名单+长度限制
不是一刀切地“过滤特殊字符”，而是结合字段语义做快速失败判断：
-
id字段必须是纯数字或UUID格式：用/^\d+$|^[\da-f]{8}-[\da-f]{4}-[\da-f]{4}-[\da-f]{4}-[\da-f]{12}$/i校验，非匹配立即报错 -
email字段走标准 RFC 5322 子集校验（别用过于宽松的.+@.+\..+），长度上限 254 字符 -
searchTerm限制最大 200 字符，且禁止空格开头/结尾（但不要trim()—— 后端需要原始字符串做参数绑定） -
sort或order这类动态 SQL 结构字段，必须映射到硬编码白名单：const allowedSorts = { name: 'name', createdAt: 'created_at' }
传参时最容易踩的坑：隐式类型转换和包装
你传给后端的数据形态，直接影响后端能否正确执行 pool.execute('SELECT * FROM users WHERE id = ?', [id])：
立即学习“前端免费学习笔记（深入）”；
- 别在 axios 请求里写
params: { id: Number(id) }—— 如果id是空字符串或abc，Number()返回NaN，后端收到的是字符串"NaN"，拼进 SQL 就是WHERE id = NaN - 搜索字段保持原始字符串，不要加引号、不要
JSON.stringify()、不要额外包裹对象层（比如{ value: "admin'--" }） - 日期类字段统一用 ISO 格式字符串（
"2026-06-23"），别传 Date 对象或时间戳数字 —— 后端解析歧义多，容易误判为数值参与拼接
最常被忽略的一点：前端校验规则必须和后端完全一致。如果前端允许用户名 3–15 位，后端却只接受 3–12 位，用户会卡在“前端能提交、后端报错”的灰色地带，反而掩盖真实问题。校验不是防线，是信号灯——亮红灯时，问题一定出在数据源头，而不是等它跑到数据库再炸。
