AntiXss库仅用于XSS防护，对SQL注入完全无效；其HtmlEncode等输出编码不作用于数据库层，防SQL注入唯一可靠方式是参数化查询。
AntiXss库**不用于防范SQL注入**，它只处理XSS（跨站脚本）防护。拿它防SQL注入是方向性错误，起不到任何作用。
AntiXss.HtmlEncode对SQL注入完全无效
AntiXss库的核心能力是输出编码（如Encoder.HtmlEncode()、Encoder.JavaScriptEncode()），它把危险字符转成HTML实体或JS安全字符串，仅影响浏览器渲染行为。而SQL注入发生在**数据库查询执行层**，与HTML输出无关。
- 用户输入
" OR 1=1 --经Encoder.HtmlEncode()变成" OR 1=1 --，但传给数据库的仍是原始恶意字符串，未被拦截或参数化 - 数据库收到的仍是拼接后的SQL语句，只要没走参数化查询，照样执行成功
- AntiXss甚至不会检查输入是否含SQL关键字，它根本不知道SQL语法
真正防SQL注入的唯一可靠方式是参数化查询
ASP.NET MVC中必须依赖数据访问层的参数化机制，和AntiXss无关：
- 用
SqlCommand时，**必须**用Parameters.AddWithValue()或Parameters.Add()，绝不用字符串拼接 - Entity Framework（包括EF Core）默认使用参数化，但需确认没写
.FromSqlRaw()或.ExecuteSqlRaw()并直接拼接用户输入 - 若用Dapper，确保用
@param占位符，而非 $"{userInput}" - 存储过程本身不等于安全——如果存储过程中用了
EXEC(@sql)动态拼接，同样存在注入风险
为什么有人会混淆AntiXss和SQL注入防护？
常见误解来源：
- 看到“用户输入→后端→数据库”链条，误以为所有输入都要统一过滤
- 在View里用
Encoder.HtmlEncode()后页面没弹窗，就以为“输入被净化了”，忽略了后端逻辑仍可能直连DB - 把
ValidateInput(false)或[AllowHtml]和SQL防护混为一谈，其实它们只绕过MVC默认的请求验证，和数据库毫无关系
真正需要警惕的是：SQL注入漏洞往往藏在自定义SQL拼接、动态LINQ构造、日志记录字段入库、或第三方组件未校验输入的地方——这些地方，AntiXss连看都不会看一眼。
