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