存储过程参数名是否必须与C#端传入的参数名称一致？

简单来说：不是强制要求完全一致，但这取决于你使用的参数匹配方式，并且名称不匹配很容易引发维护问题或运行错误。下面分两种核心场景详细解释：

1. 按位置匹配参数（不推荐） #

如果你的代码完全依赖参数添加的顺序来匹配存储过程的参数，那么参数名称可以不一样——只要C#中添加参数的顺序和存储过程定义的参数顺序完全对应，SQL Server会按位置把值传递给对应的参数。

比如你的存储过程参数顺序是@Name → @Dept，而C#中先加@UserName再加@Department，这种情况下按位置传递是能运行的，但这种方式风险极高：如果后续修改存储过程调整了参数顺序，你的代码会立刻出错，而且排查起来很麻烦。

2. 按名称匹配参数（推荐） #

这是SQL Server默认的参数匹配逻辑（当你在SqlCommand中指定CommandType.StoredProcedure时），此时参数名称必须完全匹配（SQL Server不区分大小写，但建议保持大小写一致避免混淆）。

你的代码现在就属于这种情况：存储过程定义的参数是@Name和@Dept，但C#中传入的是@UserName和@Department，这会导致SQL Server找不到对应的存储过程参数，抛出类似*“过程或函数SP_Test需要参数@Name，但未提供”*的错误。

正确的做法 #

方案一：保持参数名称一致（最稳妥） #

修改C#代码中的参数名称，和存储过程定义的完全对应：

SqlCommand scCommand = new SqlCommand("SP_Test", MysqlCon);
scCommand.CommandType = CommandType.StoredProcedure;
// 参数名称与存储过程的@Name、@Dept一一对应
scCommand.Parameters.Add("@Name", SqlDbType.VarChar, 10).Value = "SomeVal";
scCommand.Parameters.Add("@Dept", SqlDbType.VarChar, 10).Value = "SomeVal";

方案二：显式指定参数位置（不推荐，仅作了解） #

如果你坚持使用不同的参数名称，可以通过参数的Position属性（.NET Framework支持，.NET Core/.NET 5+已弃用）来强制按位置匹配，但这种方式维护性极差，后续修改存储过程时很容易出问题，不建议在生产代码中使用。

额外提示：修正你的存储过程语法 #

你的存储过程定义存在语法错误，SQL Server中存储过程的参数列表不需要加括号，正确的写法是：

CREATE PROCEDURE SP_Test
    @Name VARCHAR(10), 
    @Dept VARCHAR(10)
AS
BEGIN
    -- 这里写存储过程的业务逻辑
END

内容的提问来源于stack exchange，提问作者Magendran V