前端校验可被任意绕过，本质是用户体验优化而非安全防线；禁用JS、curl直发、控制台改fetch、WebView注入等均能跳过v-model/onSubmit/pattern校验，真正防御必须依赖后端参数化查询与输入隔离。
前端校验可被任意绕过，根本拦不住真实请求
用户禁用 JavaScript、用 curl / Postman 直发请求、浏览器控制台改写 fetch、移动端 WebView 注入——这些操作都能跳过你写的 v-model 校验、onSubmit 事件和 pattern 属性。所谓“前端防注入”，只是把攻击门槛从 0 提到 1，不是设了路障，是摆了个纸牌子。
常见错误现象包括：
- 表单提交前调用
validateInput()，但后端仍收到' OR 1=1 --这类 payload - 用了
type="number"或maxlength="50"，结果攻击者在 Postman 中手动填入123; DROP TABLE users; - Vue 组件里写了正则
/^[a-z0-9_]+$/，却对1 OR 1=1（数字字段合法值）完全放行
前端不参与 SQL 构造，它压根不知道数据库在执行什么
Vue.js 只负责把数据打包成 JSON 发给 API，它不解析 SQL，不连接数据库，也不决定哪段字符串进 WHERE 子句。哪怕你在前端把引号全替换成空格，后端照样可能用 req.body.name 拼出 SELECT * FROM users WHERE name = '${name}' —— 此时前端的任何处理都已失效。
关键事实：
立即学习“前端免费学习笔记（深入）”；
-
encodeURIComponent()是为 URL 安全设计的，不是为 SQL 防御；它对OR、UNION、注释符--完全无感 - 前端做的
.trim()或类型强转（如Number(id)），反而可能破坏原始输入语义，让后端难以做一致校验 - 所有用户输入源（
req.query、req.params、req.headers、req.body）在后端看来地位完全相等，前端只管其中一部分
真正卡住 SQL 注入的，永远是那个 ? 占位符
SQL 注入发生的唯一前提：用户输入被拼进 SQL 字符串，然后交给数据库执行。防御的核心不是“清洗输入”，而是“切断拼接”。Java 的 PreparedStatement、Node.js 的 pool.execute('SELECT ... WHERE id = ?', [id])、Python 的 cursor.execute("SELECT ... WHERE name = %s", (name,))，它们的共同点是——参数与 SQL 结构分离，数据库引擎天然拒绝执行参数里的指令。
容易忽略的细节：
- 表名、列名、排序字段（如
ORDER BY ?）不能用占位符，必须走白名单映射，比如const allowedSortFields = { created_at: 'created_time' } - ORM 并非绝对安全：
sequelize.query("SELECT * FROM users WHERE name = '" + name + "'")就是高危写法，哪怕用了 Sequelize - 日志记录原始参数时若不做脱敏，可能引发二次漏洞（如 log4j 类型的日志注入）
前后端校验逻辑不一致，反而制造体验断层
前端限制 searchTerm 最长 100 字符，后端却设了 200；前端允许 @ 和 .，后端 regex 写成 [a-zA-Z0-9] —— 这些不一致会导致用户在 UI 上能提交，后端却返回 400，或者更糟：前端没拦住的 payload，后端也没校验就进了 SQL。
所以前端校验唯一可靠的作用是快速失败（fail-fast）：
- 拦截空 ID：
if (!id) throw new Error('ID required') - 拦截明显非法格式：
!/^\d+$/.test(id)立即提示“ID 必须为数字” - 拦截超长字段：
searchTerm.length > 200直接报错，避免无效请求打满后端
它不是防线，是漏斗。真正承重的那堵墙，必须建在后端参数化查询这一层。而最容易被忽略的，是那些“看起来不像参数”的地方：URL 路径里的 req.params.id、请求头里的 req.headers['x-tenant-id']、甚至从 Redis 读出来的缓存值再拼进 SQL —— 它们一样要进 ? 流程。
