第三方sdk本身不直接执行sql，但若用户用它拼接sql或传入未过滤字符串，可能引发注入；关键在使用方式而非sdk本身是否安全。
第三方SDK本身不会直接执行SQL，但如果你用它拼接SQL、或它内部调用数据库时又接收了你传入的未过滤字符串，就可能成为注入入口。关键不在“它安不安全”，而在于“你怎么用它”。
检查SDK是否暴露原始SQL构造接口
很多SDK（尤其是轻量级数据库封装、ORM辅助工具）会提供类似 execRawQuery、rawQuery、executeSql 这类方法。一旦看到这些名称，立刻提高警惕。
- 翻 SDK 文档，确认它是否要求你传入完整 SQL 字符串 —— 如果是，且没强制你用占位符（如
?或:param），那就等于把参数化责任甩给你 - 查源码或反编译（若开源/可访问），看它内部是否对传入的字符串做转义或直接
eval/concat—— 比如发现它有replace("'", "''")这种简单替换，基本可以判定不抗绕过 - 特别注意日志上报、埋点、本地缓存等非核心路径的 SDK —— 它们常被忽略，却可能偷偷拼接 SQL 存本地数据库
禁止向SDK传入拼接后的SQL字符串
哪怕文档写着“支持自定义查询”，也不要手写 "SELECT * FROM user WHERE name = '" + name + "'" 再塞给 SDK。这是最常见也最致命的误用。
- 所有传给 SDK 的查询条件，必须走它明确支持的参数化方式：比如
query({name: userInput})、where("name", "=", userInput)、或带?占位符的数组式参数 - 如果 SDK 只接受字符串且无占位符机制（例如某些老版本 SQLite 封装），必须在外层手动包装一层参数化逻辑，或彻底弃用
- 注意 JavaScript 中的模板字符串陷阱：
`SELECT * FROM t WHERE id = ${id}`和拼接字符串本质相同，一样危险
验证SDK在不同输入下的实际行为
文档和宣传页不等于运行时行为。真实风险藏在边界 case 里。
- 用典型注入 payload 测试：传入
admin' --、test' OR '1'='1、1; DROP TABLE users--，观察是否报错、是否返回异常数据、是否真的执行了多语句 - 开启数据库查询日志（如 SQLite 的
PRAGMA compile_options查是否启用ENABLE_FTS5不影响，但可配sqlite3_trace_v2），确认最终执行的 SQL 是否含用户输入原文 - 如果 SDK 支持调试模式（如某些 Android 数据库 SDK 有
setDebug(true)），打开后直看它生成的语句
最容易被忽略的是：SDK 可能只在特定平台（如 iOS 的 Core Data 封装）或特定配置（如关闭了 prepared statement fallback）下才退化为字符串拼接。别只测一个环境，也别默认“它用了 ORM 就一定安全”——得亲眼看见 bind 参数那一步才踏实。
