在Node.js中编写原生SQL是否为最佳实践？风险与替代方案咨询

作为常年和Node.js数据库交互的开发者，我来给你拆解这几个问题：

1. 是否推荐在.js文件中编写原生SQL？ #

不推荐直接像你示例里那样用字符串拼接的方式写原生SQL。当然，如果是完全固定、没有任何用户输入参数的简单查询，偶尔写一次问题不大，但绝大多数业务场景下，这种写法弊大于利——不仅容易出现语法错误，后期维护起来也很麻烦，一旦涉及动态参数，还会带来严重的安全隐患。

2. 是否存在SQL注入风险？ #

绝对存在，而且风险极高！ 你给出的这段代码就是典型的危险写法：

var sql = "update node SET changed = " + params.updationTime + " where nid = " + params.nid

假设攻击者把params.nid篡改为"1; DROP TABLE node;"，拼接后的SQL就会变成：

update node SET changed = [传入的时间值] where nid = 1; DROP TABLE node;

数据库执行时会先完成更新操作，紧接着执行删除表的恶意指令，这就是典型的SQL注入攻击，可能直接导致数据丢失或泄露。就算是时间参数，如果用户能篡改params.updationTime，也可能注入恶意SQL片段。

3. 使用Knex.js这类库是否更优？ #

非常推荐使用Knex.js这类查询构建器（或者类似的ORM框架），优势非常突出：

• 彻底规避SQL注入：Knex会自动帮你做参数绑定，而不是直接拼接字符串。比如你的示例用Knex改写后是这样：

  knex('node')
    .where('nid', params.nid)
    .update({ changed: params.updationTime })
  

  它会把参数安全地传递给数据库驱动，从根源上避免注入风险。
• 代码可读性更强：链式调用的写法比字符串拼接直观太多，一眼就能看懂是更新哪个表、筛选条件是什么、更新哪些字段。
• 跨数据库兼容性好：如果以后需要切换数据库（比如从MySQL换成PostgreSQL），Knex能屏蔽大部分语法差异，不用大面积修改代码。
• 动态查询更灵活：遇到需要根据不同条件拼接查询的场景，Knex的API比手动拼接原生SQL要简洁得多，也不容易出错。

当然，如果是极其复杂的查询（比如多表关联的复杂统计），原生SQL可能更灵活，但也建议使用数据库驱动支持的参数占位符（比如?）来传递参数，而不是直接拼接字符串。

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