前端转义对SQL解析完全无效，浏览器中replace或encodeURIComponent仅修改字符串，数据库无法感知；真正有效的是后端参数化查询或ORM安全取值，前端操作在数据库眼中只是不可信原始字节流。
前端转义对SQL解析完全无效
浏览器里执行的 replace(/'/g, "''") 或 encodeURIComponent() 只是改字符串，数据库根本看不到这些操作。SQL 解析器只认后端拼出来的那条语句，前端处理过的值传到服务端后，如果后端还是用字符串拼接，照样被注入。
常见错误现象：用户输入 admin'--，前端转成 admin''--，但后端没做任何处理，直接拼进 "SELECT * FROM users WHERE name = '" + input + "'" —— 最终执行的仍是 name = 'admin''--'，注释符依然生效。
真正起作用的只有后端的参数化查询（如 PreparedStatement）或 ORM 的安全取值方式（如 MyBatis 的 #{}）。前端所有操作，在数据库眼里都是“不可信的原始字节流”。
攻击者绕过前端校验的典型路径
只要禁用 JavaScript、用 curl 发请求、抓包改数据，前端逻辑就彻底失效。这不是理论风险，而是每天都在发生的事实。
立即学习“前端免费学习笔记（深入）”；
- 直接调用 API：
curl -X POST /login -d 'username=admin%27--&password=123' - 篡改 hidden 字段：
<input type="hidden" name="role" value="user">→ 改成value="admin"再提交 - 绕过表单限制：React/Vue 应用里用 DevTools 修改
state后触发 submit - 利用旧接口或批量导入入口：这些路径往往没套前端校验逻辑
为什么白名单校验必须前后端一致
前端提示“用户名只能含字母数字”，后端却接受 @ 和点号，会导致两个问题：
一是用户填了 test@example.com 却被前端拦住，体验差；二是攻击者发现前端宽松、后端严格，会专门找那些前端没覆盖的字段（比如 URL 中的 id 参数、Cookie 里的 session_token）下手。
关键参数必须对齐：max_length、allowed_chars、trim_behavior、null_handling。哪怕只差一个空格处理逻辑，都可能暴露边界漏洞。
客户端唯一靠谱的用途是防手误和降负载
它不是安全层，是体验层。比如在搜索框输入 ' OR 1=1 --，立刻提示“请勿输入特殊符号”，比等后端返回 500 错误快 300ms，也省了一次无效请求。
但要注意：
- 所有可提交字段都要校验，包括
<select></select>、<textarea></textarea>、input[type=hidden]、动态生成的字段 - 正则不能只盯 ASCII，
String.fromCharCode(8217)（中文右单引号）这类 Unicode 变体也要覆盖 - 别用黑名单（如禁止
SELECT），优先白名单（如只允许[\w\u4e00-\u9fa5\-]）
复杂点在于：前端永远不知道后端用了哪种数据库、是否启用了 quote_ident、是否开了 pg_trgm 扩展——这些细节决定了哪些字符真能触发语法变化。所以别试图在客户端模拟 SQL 解析逻辑，老老实实把校验逻辑收敛到后端，前端只做轻量预筛。
