前端过滤sql非法字符无效且误导，必须依赖后端参数化查询防御sql注入；所谓“非法字符”无固定清单，过滤易误伤正常输入；layui可做基础格式校验但不解决安全问题。
为什么不能在前端过滤sql非法字符
直接说结论：input 框里用 javascript 过滤所谓“sql非法字符”既无效，也误导安全认知。sql注入的防御必须落在后端参数化查询或预处理语句上，前端任何过滤都可被绕过——用户禁用 js、抓包重放、用 curl 直接发请求，filter 逻辑完全失效。
更实际的问题是：所谓“SQL非法字符”本身没有固定清单。单引号 '、分号 ;、UNION 关键字……这些在合法业务场景中大量存在（比如用户昵称叫 O'Reilly，地址含 ;，搜索词就是 select * from）。强行过滤会误伤正常输入，引发投诉或数据丢失。
Layui input 如何做基础输入校验（非SQL防御）
如果你只是想防用户手滑输错、或统一格式（比如禁止全角空格、连续空白、控制长度），可以用 Layui 的 lay-verify + 自定义验证规则，配合 input 事件微调：
- 在
layui.use(['form'], ...)中用form.verify添加规则，例如过滤首尾空格和全角空格：form.verify({ safeInput: function(value, item){ if (/\s/.test(value) || /[\u3000]/.test(value)) { return '请勿输入空格或全角空格'; } } }); - 对特定
input元素绑定input事件实时清理（仅视觉/体验层）：elem.on('input', function(){ this.value = this.value.replace(/[\u3000\s]+/g, ''); // 清掉所有空格类字符 }); - 注意：这类操作不改变后端接收逻辑，也不影响提交内容；Layui 表单提交仍走原生
form.submit()或form.on('submit', ...)，值以清理后为准。
后端才是SQL注入的唯一防线
真正起作用的只有后端。无论你前端怎么“过滤”，只要后端拼接 SQL 字符串，就等于开门揖盗。
- PHP 用
PDO::prepare()+bindValue()，不是mysql_query("SELECT * FROM user WHERE name = '$name'") - Java 用
PreparedStatement，参数用setString(1, userInput)，不是Statement拼接 - Node.js 用
mysql2的execute()方法，传参数组，不是query("SELECT ... " + userInput) - Python 用
cursor.execute("SELECT ...", [userInput])，不是.execute("SELECT ..." % userInput)
这些机制由数据库驱动保证参数与 SQL 结构分离，根本不存在“字符是否非法”的判断环节——' 就是普通字符串，; 不会触发多语句执行（除非显式开启且数据库支持，但主流生产环境默认关闭）。
如果非要前端加一层“心理安慰”过滤
可以写个轻量函数，在表单提交前扫一遍字段值，移除明显危险模式（仅用于降低低级误提交概率，不替代后端）：
function sanitizeForDisplay(input) {
if (!input || typeof input !== 'string') return input;
return input
.replace(/(union\s+select|insert\s+into|drop\s+table|exec\s+|xp_cmdshell)/gi, '')
.replace(/(;|--|#|\*\/\*|\*\/)/g, '')
.trim();
}
然后在 Layui 提交回调里调用：
form.on('submit(formDemo)', function(data){
data.field.username = sanitizeForDisplay(data.field.username);
// 再发 Ajax...
});
注意：这个函数只做简单替换，无法覆盖所有绕过方式（比如大小写混写、编码变形、注释干扰），且可能误删业务关键词。它存在的唯一意义是让测试人员少点“看到单引号就喊高危”的条件反射。
真正的边界永远在后端——只要后端用了参数化查询，前端哪怕把整个 SQL 手动粘贴进去，也只会当作文本存进数据库字段里。
