前端拼接SQL字符串不可行且危险，因浏览器无法执行原生SQL，仅能发送字符串至后端；此举暴露数据库结构、误导开发、放大注入风险，且前端校验无效，安全必须由后端严格白名单与参数化查询保障。
在前端 JavaScript 中拼接 SQL 字符串不是“不推荐”，而是根本不可行——浏览器环境压根无法执行原生 SQL，所谓“拼接”只会暴露逻辑漏洞或引发严重误解。
前端根本不能运行 SQL 查询
现代浏览器不提供直接连接 MySQL、PostgreSQL 等数据库的原生能力。任何看似在 fetch() 或 axios 里拼接的 "SELECT * FROM users WHERE name = '" + name + "'"，实际只是字符串，最终仍要发给后端 API。此时拼接行为本身不触发 SQL 执行，但会把危险逻辑提前暴露在客户端：
- 攻击者可直接查看源码，拿到 SQL 模板结构（比如知道表名是
users、字段是name） - 若前端错误地把后端接口路径或参数格式“模拟成 SQL”，可能误导开发者绕过真实校验
- 部分低代码平台或 Electron 应用误用 sqlite3 模块时，才真有本地 SQL 执行风险，但那已不属于 Web 前端标准场景
真正危险的是后端拼接，但前端会放大风险
前端 JS 里出现 "WHERE username = '" + x + "'" 这类代码，往往意味着后端也在用同样方式构造 SQL。这种写法一旦落到服务端，立刻变成高危入口：
- 用户输入
admin' --会让最终语句变成WHERE username = 'admin' -- '，注释掉后续条件 - 输入
admin' OR '1'='1可能绕过登录校验 - 如果前端还把拼接结果直接塞进
fetch('/api/login?sql=' + sql)，等于主动帮攻击者构造 payload
为什么白名单和正则校验在前端无效
有人试图在前端用正则过滤 '、--、UNION 等关键词来“防注入”，这完全徒劳：
立即学习“前端免费学习笔记（深入）”；
- SQL 注入变种极多（如宽字节、编码绕过、注释符嵌套），前端正则永远滞后
- 攻击者可禁用 JS、改写前端逻辑、或直接跳过前端调用后端接口
- 校验必须由后端完成，且仅对动态结构（如表名、排序字段）才需白名单 —— 但白名单也必须服务端校验，前端传来的任何值都不能信
ORM 和框架的“安全假象”容易被打破
即使你用的是 Sequelize 或 TypeORM，只要在前端诱导后端执行了 .raw() 或 .query()，就退回裸奔状态：
- 错误示例：
User.sequelize.query(`SELECT * FROM ${tableName}`)—— 表名无法参数化，必须后端白名单硬校验 - 更隐蔽的坑：
db.session.execute(f"UPDATE logs SET status = '{status}'")—— Python 的 f-string 和 JS 的模板字符串一样危险 - 安全写法只有一种：
client.query("SELECT * FROM logs WHERE level = $1", ["error"])或User.query.filter(User.name == name).all()
最容易被忽略的不是“怎么写安全 SQL”，而是“谁来决定哪部分能动态、哪部分必须冻结”。表名、字段名、ORDER BY 子句、LIMIT 值……这些都不能靠参数占位符，必须由后端用严格白名单 + 正则 + 最小权限 DB 账号兜底。前端连参与决策的资格都没有。
