使用jsforce对Contact执行带LIKE运算符的SOQL查询无结果的问题求助

最常见的踩坑根因 #

双重URL编码导致通配符失效

• jsforce的query()方法内置参数编码逻辑：传入的整段SOQL会被自动作为q查询参数拼接至Salesforce REST查询接口路径，并且自动执行encodeURIComponent完成全量转义，开发者完全不需要手动对特殊字符做提前URL编码。
• 你当前代码中写的LIKE 'michael%25'，本质是手动把SOQL里的通配符%提前做了一次URL编码（URL规范中%的转义值就是%25）。但jsforce拿到这段字符串后会再做一次自动转义：原本%25里的%会被二次编码，最终实际发送到Salesforce的查询条件，就变成了匹配字面值michael%25，而非你预期的匹配michael开头的记录，自然查不到结果。
• 你在Postman里能正常返回数据的原因：Postman对请求参数的处理逻辑是，如果你手动传入了带转义符的参数值，它会默认你已经完成了编码流程，不会额外做二次转义，因此最终请求条件和预期一致，能正常返回。
• 对应正确写法：直接在SOQL里写原生通配符即可，无需手动转义：

  const resp = await conn.query("SELECT Id,Name,Title,Email,Phone,Department FROM contact WHERE Name LIKE 'michael%' ORDER BY LastModifiedDate DESC LIMIT 10");
  

其他可同步排查的方向 #

• 打印实际发出的请求内容做比对：通过jsforce的请求事件监听，直接拿到拼接完成的实际请求路径，和Postman里正常跑通的请求参数逐值比对，排除“代码传值和预期不一致”的隐性问题。示例代码：

  conn.on("request", (reqConfig) => {
    console.log("实际发送的接口请求路径:", reqConfig.url);
  })
  

  按你当前的代码逻辑，打印出的请求路径中，查询条件部分大概率会出现michael%2525的内容，和Postman请求中的michael%25形成明显差异。
• 保持SOQL语法和官方规范一致：对象名、字段名建议采用标准大小写（比如Contact对象名首字母大写），虽然多数场景下Salesforce接口会兼容小写写法，但部分权限隔离、解析异常场景下可能出现语法解析偏差。
• 若需要在查询条件中使用单引号、反斜杠等特殊字符，直接按照原生SOQL语法书写即可，无需提前做URL编码，jsforce会自动完成合规转义。

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