参数化查询是唯一可靠的sql注入防线，其他如关键词过滤均为临时补丁；必须用@param占位符配合sqlparameter或fromsqlraw，禁用字符串拼接、addwithvalue及fromsqlinterpolated，动态对象名需白名单校验，拦截须在模型绑定后、控制器执行前完成。
参数化查询是唯一可靠防线，其他都是补丁
别指望关键词过滤能拦住SQL注入——admin'--、%27OR%201%3D1、/*这些绕过手段太常见。真正起作用的只有参数化查询：用@param占位符 + SqlParameter或EF Core的FromSqlRaw(sql, params)。所有没迁移到这一步的代码，哪怕加了10层关键词检测，都等于没防。
常见错误现象：
- 在
string.Format或$"SELECT * FROM {table}"里拼接表名/列名——参数化对此完全无效 - 用
AddWithValue传null导致类型推断错误，某些驱动会退化为字符串拼接 - 在Stored Procedure调用中仍用
string.Concat拼接WHERE条件
实操建议：
- 强制所有
SqlCommand构造必须带Parameters.Add()，禁用AddWithValue - EF Core中禁用
FromSqlInterpolated，只用FromSqlRaw配合显式参数数组 - 对动态表名/排序字段，用白名单硬编码：
new[] { "name", "email", "created_at" }.Contains(input)
全局过滤器只能查已绑定参数，别碰原始请求流
在OnActionExecuting里直接读HttpContext.Request.Body或Form会消耗流，导致后续Controller收不到JSON数据——这是静默失败，不是报错。
正确做法是优先从context.ActionArguments取值，它已是模型绑定后的干净对象。如果必须检查原始Query字符串，用context.HttpContext.Request.QueryString.Value；检查POST Body前，先调context.HttpContext.Request.EnableBuffering()再重置Position = 0。
还要跳过ASP.NET内置字段：__RequestVerificationToken、__viewstate（大小写不敏感），它们合法含'或--，误杀会导致登录失败。
关键词检测必须解码+词边界+注释符覆盖
不WebUtility.UrlDecode()和WebUtility.HtmlDecode()就匹配，等于开门揖盗。%27（单引号）、%6f%72（or）会直接漏过。
正则必须加\b词边界，否则"Select"昵称、"union_all"字段名全被误杀。关键词列表至少包含：select、union、drop、exec、xp_cmdshell、--、/*、#——漏掉任一注释符，admin'--就能逃逸。
注意：这种检测只适合临时补丁，且必须配合日志记录（记录原始参数+IP+路径），不能替代参数化。
验证时机错了，整个拦截就失效
在catch (Exception e)里判断是不是SQL注入？晚了。此时SQL可能已执行，数据已泄露，甚至DROP TABLE已完成。
有效拦截点只有一个：模型绑定完成、控制器方法执行前。Minimal API用Validator.TryValidateObject；Controller启用[ApiController]特性让框架自动校验[FromBody]和[FromQuery]参数并返回400。
复杂场景需运行时参数驱动规则：
- 公网IP请求才启用
sqlPattern扫描，内网跳过 -
/api/v1/report/export接口对keyword额外模拟SQL WHERE子句环境校验 - 管理员提交的
script字段启用AST解析，拒绝任何含函数调用的JS表达式
真正该花时间盯的，不是写了多少关键词，而是确认每个string.Format拼接点是否已清理干净——漏一个，全局过滤器就是摆设。
