SQLAlchemy的SQL注入防护是仅在ORM层生效还是Core层面也支持？

结论 #

你当前的实现存在SQL注入风险，风险并非来自SQLAlchemy Core本身，而是你手动编译SQL时开启了literal_binds=True的配置。

针对你的三个考量点的解释 #

• 关于SQL编译生成逻辑：SQLAlchemy防注入的核心逻辑是「生成带占位符的SQL语句+单独传递查询参数」，而非直接把用户输入拼入SQL字符串。当你设置compile_kwargs={"literal_binds": True}时，SQLAlchemy会跳过占位符生成流程，直接将参数值转义后拼入SQL字符串。官方明确标注该功能仅用于调试、生成静态SQL等场景，不支持处理不可信用户输入，不同数据库的转义规则存在边缘遗漏（比如特殊编码、特殊字符组合），存在被绕过的可能。
• 关于cursor.execute和conn.execute的差异：二者本身和SQL注入防护没有直接关联，防护的核心是执行时是否使用参数化查询。你正常调用conn.execute(stmt)时，SQLAlchemy会自动将语句转为带占位符的SQL、单独提取参数传递给数据库驱动，所以是安全的；你现在将拼接好用户输入的完整SQL串传给cursor.execute，等于放弃了参数化防护，和调用哪个执行接口无关。
• 关于SQLAlchemy Core的注入防护能力：SQLAlchemy Core本身具备完善的SQL注入防护能力，前提是你将Select对象直接传递给execute接口，由框架处理参数传递流程。你当前手动编译拼接SQL的操作绕开了框架的防护逻辑，自然享受不到对应的安全保障。

更安全的优化方案 #

如果要实现单次往返执行多条查询的需求，无需手动拼接SQL，有更安全的实现方式：

• SQLAlchemy 1.4及以上版本支持直接传递可迭代的语句对象给conn.execute，框架会自动处理多语句执行，参数依然走参数化流程，完全规避注入风险。
• 如果你使用的版本不支持该特性，可以分别编译每条语句拿到带占位符的SQL和对应参数列表，再将多段占位符SQL用分号拼接、参数按顺序合并后，传递给cursor.execute，全程不要开启literal_binds。

内容的提问来源于stack exchange，提问作者T.H.