datacontext.getcommand()不能检测sql注入，因其返回的是含@p0等参数占位符的语句，用户输入早已转为参数；文本扫描会误报或漏报。
为什么 DataContext.GetCommand() 不能当作SQL注入检测手段
很多人以为调用 DataContext.GetCommand(query) 拿到生成的 SQL 字符串后，扫描其中是否有 '、; 或 UNION 就能判断是否“可能被注入”——这完全误解了 LINQ to SQL 的执行机制。它返回的是参数化查询（如 WHERE Name = @p0），所有用户输入都已转为参数占位符，原始字符串根本不会拼进 SQL。靠文本扫描只会误报（比如搜索含单引号的人名 O'Connor）或漏报（攻击者绕过前端校验直接发恶意对象）。
真正有效的防御：只允许表达式树编译，禁用 ExecuteQuery<t>()</t> 和字符串拼接
LINQ to SQL 的安全边界在于：只要全程使用 IQueryable<t></t> + 强类型表达式（Where(x => x.Name == input)），框架就自动走参数化路径；一旦你调用 ExecuteQuery<t>("SELECT * FROM Users WHERE Name = '" + input + "'")</t>，就等于亲手拆掉防护墙。
- 检查项目中所有
ExecuteQuery<t>()</t>和ExecuteCommand()调用，全部替换为IQueryable链式写法 - 禁止在
Where()、OrderBy()等方法中传入字符串或Func<t bool></t>（后者会触发客户端求值，丢失参数化） - 若需动态条件，用
Expression<func bool>></func>构建表达式树，再用AsExpandable()（来自 LinqKit）组合，而非字符串拼接
如何快速发现残留的不安全查询模式
在 Visual Studio 中用“查找全部”搜以下模式，它们是典型风险信号：
ExecuteQuery（尤其带字符串字面量或变量拼接的）-
ExecuteCommand("（同上） -
.AsEnumerable()后紧跟.Where(x => ...)（说明前面已把数据拉到内存，后续过滤不走 SQL） -
new { ... }匿名类型出现在Select()外且被赋给IQueryable变量（可能触发意外的客户端求值）
注意：SqlMethods.Like() 是安全的，它会被翻译成 SQL 的 LIKE；但自定义字符串匹配逻辑（如 input.Contains(x.Name)）若写在 Where() 内且未被识别为可翻译表达式，会导致全表拉取后内存过滤。
调试时确认查询真正在数据库执行
最简单的验证方式：在 DataContext 构造后启用日志输出：
context.Log = Console.Out;
运行查询，观察输出是否为带 @p0、@p1 的参数化语句。如果看到任何用户输入明文出现在 SQL 中（如 WHERE Name = 'admin'--'），说明某处绕过了 LINQ 表达式树，直接拼了字符串。
复杂点在于混合场景：比如前端传来的 JSON 条件数组，后端用反射+表达式树构建 IQueryable。这种地方最容易漏掉对嵌套属性名的白名单校验——攻击者传 {"prop": "Password; DROP TABLE Users--"} 不会触发 SQL 注入，但可能引发其他漏洞。参数化本身防不住所有问题，但它是最关键的第一道锁。
