Node mssql包执行动态SQL丢失首个条件，求原因及优化方案

首先排除SQL注入防护机制的直接影响——SQL Server的参数化防护不会主动忽略合法条件，问题大概率出在动态SQL的参数绑定逻辑上：

1. 当你用accounts.shift()取出首个账户值并直接拼接进SQL字符串时，可能出现两种参数绑定错位的情况：

   • 若后续账户值用参数化绑定，而首个值是硬编码字符串，mssql的参数解析逻辑（如占位符顺序、类型匹配）可能误判第一个条件的有效性；
   • 若你先执行shift()再构建参数数组，会直接丢失首个值的参数绑定，导致SQL里的占位符和实际参数数组不匹配。比如SQL写了konto = @p0 OR konto = @p1，但参数数组只有@p1的值，此时@p0会被视为NULL，konto = NULL永远为假，看起来就像第一个条件被忽略。

2. 你添加konto = '0'的无效条件后，相当于给OR条件加了一个明确的“假”前缀，参数绑定逻辑被强制对齐，所以能得到预期结果——这也侧面验证了参数绑定错位的核心问题。

核心原则：全程使用参数化查询，绝对避免直接拼接用户输入到SQL字符串中，同时规范数组处理逻辑，避免shift()这类破坏性方法导致的参数错位。

方案1：使用IN子句+参数化数组（推荐） #

这是最简洁安全的方式，@cityssm/mssql-multi-pool基于官方mssql包，原生支持数组参数绑定：

import sql from '@cityssm/mssql-multi-pool';

async function getAccounts(accounts: string[]) {
  const pool = await sql.connect('your-db-key');
  const result = await pool.request()
    .input('accounts', sql.VarChar, accounts) // 直接传入数组参数
    .query(`SELECT * FROM your_table WHERE konto IN (@accounts)`);
  return result.recordset;
}

SQL Server会自动将数组解析为合法的IN条件，既避免了手动拼接OR的麻烦，又从根源上杜绝SQL注入风险。

方案2：手动构建参数化OR条件（适配特殊业务场景） #

如果业务必须用OR而非IN，严格按参数索引绑定，不要修改原数组顺序：

async function getAccounts(accounts: string[]) {
  const pool = await sql.connect('your-db-key');
  const request = pool.request();
  
  // 构建参数占位符并绑定对应参数
  const conditions = accounts.map((_, index) => `konto = @p${index}`);
  accounts.forEach((account, index) => {
    request.input(`p${index}`, sql.VarChar, account);
  });
  
  // 处理空数组情况，避免生成无效SQL
  const whereClause = conditions.length > 0 ? `WHERE ${conditions.join(' OR ')}` : '';
  const sqlQuery = `SELECT * FROM your_table ${whereClause}`;
  
  const result = await request.query(sqlQuery);
  return result.recordset;
}

这种方式确保每个账户值都对应明确的参数占位符，参数数组和SQL条件完全对齐，不会出现丢失或错位问题。

关键注意事项 #

• 永远不要将外部传入的变量直接拼接进SQL字符串，这会引发严重的SQL注入风险；
• 避免使用shift()、pop()等修改原数组的方法处理参数，改用map()、forEach()等非破坏性方法；
• 必须处理空数组场景，可添加1=0这类恒假条件，避免生成WHERE后无内容的无效SQL。

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