字符串拼接SQL在C#中等于埋雷,因用户输入直接拼入SQL会导致语法错误或SQL注入;根本原因是SQL引擎不区分代码与数据,必须用SqlCommand.Parameters参数化查询,而非字符串处理。为什么字符串拼接 SQL 在 C# 里等于埋雷因为用户输入直接进 string.Format 或 + 拼出来的 SQL,数据库就当真实命令执行。一个单引号就能让 WHERE name = 'O'Connor' 直接语法报错;更危险的是 ' OR 1=1 -- 这类注入,可能删库、拖库、越权查数据。根本原因不是 C# 语言问题,而是 SQL 引擎不区分"代码"和"数据"。你拼进去的,它全当 SQL 解析。所有用户可控输入(TextBox.Text、Request.QueryString、Model.Id)都不能直接拼进 SQL 字符串即使加了 SqlHelper.Escape 类的自定义转义函数也不安全------不同数据库转义规则不同,且容易漏掉边界情况SqlCommand.CommandText 只接受原始 SQL 字符串,它本身不校验内容;安全靠的是参数化机制,不是字符串处理C# 中必须用 SqlCommand.Parameters.Add 的三种写法参数化查询的核心是把值和 SQL 结构分开:SQL 里只留占位符,值通过 Parameters 集合传入。数据库驱动层负责把值安全地绑定过去,自动处理引号、类型转换、编码等。推荐写法:cmd.Parameters.AddWithValue("@name", userName) ------ 简单场景够用,但注意类型推断不准(比如传 null 会推成 Object,可能触发隐式转换失败)更稳写法:cmd.Parameters.Add("@age", SqlDbType.Int).Value = userAge ------ 显式指定 SQL 类型,避免因 .NET 类型映射偏差导致查询计划缓存失效或比较异常批量插入时别用 AddWithValue 循环:同一参数名重复添加会抛 ArgumentException;应改用 cmd.Parameters.Clear() 或为每个参数用唯一名称(如 @name1, @name2)示例:var cmd = new SqlCommand("SELECT * FROM Users WHERE Status = @status AND CreatedAt > @since", conn);cmd.Parameters.Add("@status", SqlDbType.VarChar, 20).Value = "active";cmd.Parameters.Add("@since", SqlDbType.DateTime2).Value = DateTime.UtcNow.AddDays(-7);Where 条件动态拼接时怎么保参数化不能因为"条件不确定"就退回到字符串拼接。动态 SQL 一样能参数化,关键是把占位符和参数添加逻辑对齐。 文心快码 文心快码(Comate)是百度推出的一款AI辅助编程工具
相关推荐
坚定信念,勇往无前2 小时前
mongodb的日志分割oradh6 小时前
Oracle TX 锁 Mode 4(Share)问题排查总结yi.Ist6 小时前
数据定义语言-DDL操作傲笑风7 小时前
【openvino】tinybert基于openvino服务化部署(四)维基框架7 小时前
WIKI 知识库 v1.1.1 正式发布2601_963282778 小时前
工程项目、政企采购为什么优先选择对讲机批量采购?Doraemomo8 小时前
SQLite数据库云贝教育-郑老师8 小时前
MySQL 的“黑匣子“:Performance Schema 把数据库内部变成一张可查的表这个DBA有点耶10 小时前
同城双活落地的三座山:网络延迟、脑裂预防、反向同步