SQL存储过程不能直接暴露为Web API接口，必须由后端应用层调用并封装返回JSON；数据库不监听HTTP端口、不解析JSON，所有参数校验、错误处理和序列化均在应用层完成。
SQL存储过程不能直接暴露为 Web API 接口，必须由后端应用层调用并封装返回 JSON。 试图在浏览器里直接访问 /api/sp_get_orders 或用 fetch() 直连数据库里的存储过程，一定会失败——因为 HTTP 协议和 T-SQL 是两层完全不互通的系统。
为什么不能跳过应用层直接调用存储过程
数据库（如 SQL Server）本身不监听 HTTP 端口，也不解析 JSON 请求体。所谓“调用存储过程的 API”，本质是后端代码（C#、Node.js、Java 等）收到 HTTP 请求后，用数据库驱动（如 mssql、System.Data.SqlClient、sqlx）建立连接，再执行 EXEC sp_get_orders @user_id = 123。所有参数校验、错误映射、JSON 序列化都发生在应用层。
常见错误现象：
- 前端报
404 Not Found或ERR_CONNECTION_REFUSED，实际是因为根本没起一个监听该路径的 HTTP 服务 - 后端日志出现
Login failed for user，说明连接字符串写错或 SQL 登录权限不足，不是接口路由问题 - 返回 XML 而非 JSON（尤其在旧版 ASP.NET Web API 中），需手动清除 XML formatter
Node.js + mssql 示例：安全传参并返回结构化 JSON
使用 mssql 包调用存储过程时，必须用参数化方式绑定值，避免拼接 SQL 字符串。同时注意：存储过程的输出参数、结果集、返回码需分别处理。
关键点：
- 用
request.input()绑定参数，而非字符串模板 - 若存储过程有多个结果集（比如先查用户、再查订单），需用
request.multiple = true - 返回前确保字段名是小写或按需加
jsontag（Go/Python 同理），否则前端拿到空对象 - 不要把存储过程名硬编码进路由，如
/api/sp_update_inventory—— 这会让后续维护者误以为后端直连了 SP
示例片段（Express）：
app.post('/api/orders', async (req, res) => {
const { user_id } = req.body;
try {
const pool = await sql.connect(config);
const request = pool.request();
request.input('user_id', sql.Int, user_id);
const result = await request.execute('sp_get_user_orders');
res.json({ success: true, data: result.recordset });
} catch (err) {
res.status(500).json({ success: false, error: err.message });
}
});C# ASP.NET Core 中调用存储过程并序列化 JSON
.NET 6+ 默认返回 JSON，但要注意三处细节：连接生命周期、参数方向、空结果处理。
容易踩的坑：
- 忘记设置
command.CommandType = CommandType.StoredProcedure，导致执行的是普通 SQL 查询 - 用
SqlParameter时未指定SqlDbType，尤其对datetime2、varchar(max)类型易出错 - 存储过程含
SELECT但没设SET NOCOUNT ON，会多返回影响行数消息，干扰 ORM 解析 - 返回空集合时，前端收到
null而非[]，建议统一包装为ApiResponse<t></t>结构
简短示意（Controller 内）：
var cmd = conn.CreateCommand();
cmd.CommandText = "sp_get_user_orders";
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add(new SqlParameter("@user_id", SqlDbType.Int) { Value = userId });
var reader = await cmd.ExecuteReaderAsync();
var orders = await reader.Cast<DbDataRecord>()
.Select(r => new { Id = r.GetInt32(0), Title = r.GetString(1) })
.ToListAsync();
return Ok(new { success = true, data = orders });前端调用时的注意事项
前端只管发请求、收 JSON，但需配合后端约定好错误格式和空值语义。
实操建议：
- HTTP 状态码别全靠
200：数据库超时用503，参数校验失败用400，权限不足用403 - 响应体结构尽量统一，例如始终含
success、message、data字段，避免前端每个接口写不同解包逻辑 - 不要在 URL query 中传复杂参数（如 JSON 字符串），改用 POST + JSON body，否则可能触发 IIS/Nginx 的 URL 长度限制或编码问题
- 若存储过程执行耗时较长（>10s），前端需设 timeout，并提示“处理中”，后端建议加 SQL Server Agent 异步任务或消息队列解耦
最常被忽略的一点：存储过程内部的事务边界和锁行为，会直接影响 API 响应时间与并发能力。应用层无法绕过它优化——你封装得再漂亮，sp_update_inventory 里一个没加索引的 UPDATE 仍会让整个接口卡住。
