字符串拼接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辅助编程工具
相关推荐
量化吞吐机1 分钟前
2026年交易想法转Python,中间先补规则转译夜雪一千1 分钟前
MySQL查询条件的顺序是否影响查询效率用户298698530143 分钟前
Python 实现 Excel 与 Markdown 互转的实用指南决战灬7 分钟前
langgraph之interrupt(事例篇)X-⃢_⃢-X15 分钟前
十、Redis之布隆过滤器IPdodo_17 分钟前
Codex 总是 Reconnecting?从 401 到响应流中断的排查方法Nturmoils17 分钟前
订单号查出了三笔,我以为是数据脏了,其实是自己写错了ZKNOW甄知科技21 分钟前
燕千云深度集成飞书:以AI之力,开启无感IT运维体验京和动物医院·总院25 分钟前
2026年未央区宠物医院:如何挑选最适合您爱宠的健康守护者刘小八28 分钟前
RAG 文档切分不是越细越好:选择 Chunk Size 与 Overlap