SQL注入防护必须在Node.js层使用参数化查询或ORM，前端校验无法阻止攻击；所有用户输入（包括params、query、headers）都需经占位符处理，拼接字符串即高危。
SQL注入只发生在后端执行数据库查询时，前端校验无法阻止它——但能减少无效请求和提升体验。真正的防护必须落在 Node.js 层的查询构造上。
为什么前端验证不能防 SQL 注入
Vue.js 运行在浏览器中，所有逻辑都可被绕过：用户禁用 JS、手动构造 fetch 请求、用 Postman 直调 API，都能跳过你的表单校验。所谓“前端防注入”只是障眼法，连防御门槛都算不上。
- 正则限制输入（如
/^[a-z0-9_]+$/）只能拦住明显恶意字符，对' OR 1=1 --这类绕过 payload 无效 -
v-model+onSubmit校验不阻断网络请求，攻击者改个curl就绕过 - Vue 自身不做任何 SQL 安全处理——它根本不知道你在连 MySQL 还是 MongoDB
Node.js 层必须用参数化查询或 ORM
这是唯一有效的防线。只要你在 mysql2、pg 或 sqlite3 中拼接字符串（比如 `SELECT * FROM users WHERE name = '${req.body.name}'`），就等于给攻击者开了后门。
- ✅ 正确做法：用
?占位符 + 数组传参，例如pool.execute('SELECT * FROM users WHERE id = ?', [req.query.id]) - ✅ ORM 更省心：
User.findOne({ where: { email: req.body.email } })（Sequelize）或userRepo.find({ where: { email } })（TypeORM）都默认走参数化 - ❌ 危险操作：调用
.query()时传入拼接字符串；在 ORM 中用sequelize.query("SELECT * FROM ... WHERE name = '" + name + "'") - ⚠️ 注意：表名、列名不能用
?占位——它们属于 SQL 结构，不是数据。需用白名单严格控制（如const allowedTables = ['users', 'posts']; if (!allowedTables.includes(tableName)) throw new Error('Invalid table')）
别信“双重校验”就能高枕无忧
前后端都做校验 ≠ 安全加倍。后端若仍用字符串拼接，前端再严也白搭；后端若已用参数化，前端校验只是锦上添花，用于改善 UI 反馈和减少无意义日志。
- 前端可做：限制输入长度、过滤
<script></script>等明显 XSS 特征（防的是 XSS，不是 SQL 注入） - 后端必须做：所有用户输入进 SQL 前，100% 经过占位符或 ORM 模型层，不拼接、不
escape、不信任任何req.xxx - 容易忽略的点：URL 路径参数（
req.params.id）、查询参数（req.query.sortBy）、请求头（req.headers['x-user-id']）——这些一样要进参数化流程，不是只有req.body才危险
真正卡住 SQL 注入的，永远是那一个 ? 和它背后的预编译机制。其他所有“加固”动作，都是围绕它打辅助。写错一次拼接，整个防护体系就塌了半边。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
