数据库不提供禁用--或#注释的配置，因它们是SQL标准语法；防御关键在应用层拼接前使用参数化查询，白名单校验动态字段，并过滤%23、%09等绕过编码。

数据库解析器本身不会“忽略异常注释”——它严格按SQL标准解析，而--和#是合法注释语法。所谓“防御注释符注入”，本质是阻止用户输入被拼进SQL语句后形成有效注释，从而截断原有逻辑。

为什么不能靠数据库配置禁用--或#

MySQL、PostgreSQL等主流数据库不提供“关闭注释支持”的开关。--和#是SQL标准的一部分，禁用它们会导致大量合法SQL（如开发注释、运维脚本）执行失败。WAF或应用层过滤也难彻底拦截：URL中#会被浏览器截断，需用%23编码；--后面必须跟空格才生效，但攻击者可插%09（制表符）绕过空格检测。

真正有效的拦截点在应用层拼接前

注释符只有在用户输入被直接拼进SQL字符串时才有危害。防御必须卡在拼接动作发生之前：

• 强制使用参数化查询：SELECT * FROM users WHERE name = ?，把--当普通字符串处理，不会触发注释行为
• 若必须动态拼接（如ORDER BY字段），先白名单校验字段名，再拼接，绝不允许用户控制注释位置
• 对LIKE等无法参数化的场景，用ESCAPE转义用户输入中的%、_，同时过滤--、#、%23、%09等编码变体

常见误判：以为过滤掉--就能防住

实际中，仅过滤--会漏掉多种绕过方式：

• 用/**/替代空格+注释：UNION/**/SELECT → 数据库仍识别为UNION SELECT
• 用%0a（换行符）代替空格：--%0aAND 1=1 → MySQL接受换行作为注释分隔符
• 闭合引号后不依赖注释：' OR '1'='1' AND username='admin → 原语句末尾的AND password='xxx'因引号已闭合而失效，根本不用注释

Prisma、MyBatis等ORM的陷阱

这些框架默认安全，但留了危险出口：

• Prisma的$queryRawUnsafe：传入的SQL字符串完全不校验，--和#照常生效
• MyBatis的${}语法：直接字符串替换，WHERE name = '${name}'遇到admin' --就崩
• Spring JDBC的update(String sql, Object... args)：若sql含拼接变量，而非预编译占位符，同样失效

最易被忽略的是：**注释符不是攻击目标，而是攻击手段的副产品。真正的防线永远在SQL语句生成那一刻——你有没有让用户的输入变成代码，而不是数据。**