Django不依赖ORM如何通过原生SQL实现单页面多搜索字段过滤

原代码存在的核心问题 #

• 游标返回值认知错误：cursor.execute()仅负责执行SQL语句，本身不返回查询结果，原代码里将执行语句的返回值直接赋值给objects实际拿到的是None，查询结果需要执行完成后通过游标拉取
• 查询逻辑冗余：每命中一个搜索条件就重写完整SQL，重复编写表关联逻辑，且后续扩展字段时会陷入分支判断爆炸的问题
• 没有可扩展的条件拼接机制：没有拆分SQL的固定部分和可变条件部分，导致每加一个过滤项都需要重写一整条查询逻辑

具体实现逻辑 #

完全不需要枚举所有搜索字段的取值组合，采用「固定SQL主干 + 独立条件片段 + 解耦参数列表」的结构实现动态拼接，后续新增搜索字段时仅需追加对应条件配置即可，无需改动整体查询流程，扩展成本极低。
执行步骤为：

1. 定义固定不变的SQL主干（包含表关联、查询字段选择逻辑）
2. 初始化空列表，分别存储命中的过滤条件SQL片段、对应的实际查询参数
3. 遍历所有需要支持的搜索字段，若字段对应的请求值非空，就将该字段的过滤条件片段追加到条件列表，把实际参数值追加到参数列表
4. 若存在命中的过滤条件，就将所有条件片段用AND连接，拼接上WHERE前缀附加到SQL主干上；若无任何命中条件，直接使用不带过滤的SQL主干执行查询
5. 执行完整SQL时将参数列表作为单独参数传入，通过数据库驱动自动完成参数转义，规避SQL注入风险

通用工具方法说明：dictfetchall是原生查询场景下常用的结果转换方法，用于把游标返回的元组格式数据转换为以字段名为键的字典结构，通用实现为：

def dictfetchall(cursor):
    columns = [col[0] for col in cursor.description]
    return [
        dict(zip(columns, row))
        for row in cursor.fetchall()
    ]

可直接落地的示例代码 #

def profile(request):
    # 固定SQL主干，后续调整表关联、查询字段仅需修改此处
    base_sql = 'SELECT * from People p JOIN Jobs j on p.JobId = j.Id '
    where_conditions = []
    query_params = []

    # 读取请求中的搜索参数
    search_age = request.GET.get("searchage", None)
    search_keyword = request.GET.get("search", None)

    # 动态条件拼接块，后续新增搜索字段仅需在此处追加对应逻辑
    if search_age:
        where_conditions.append("p.Age = %s")
        query_params.append(search_age)
    
    if search_keyword:
        where_conditions.append("j.JobName LIKE %s")
        query_params.append(f"%{search_keyword}%")

    # 组装最终执行的完整SQL
    if where_conditions:
        full_sql = base_sql + " WHERE " + " AND ".join(where_conditions)
    else:
        full_sql = base_sql

    # 执行查询，使用上下文管理器自动管理游标生命周期
    with connection.cursor() as cursor:
        cursor.execute(full_sql, query_params)
        objects = dictfetchall(cursor)

    return render(request,'personal.html', {
        'value1': search_age, 
        'value2': search_keyword, 
        'objects': objects
    })

方案优势 #

• 扩展成本极低：从2个搜索字段扩展到10个、20个字段，仅需在动态条件拼接块追加2行对应逻辑，无需枚举字段组合，不会出现分支爆炸的问题
• 维护成本低：表关联、查询字段等固定逻辑仅在SQL主干处编写一次，后期调整表结构或查询字段不需要修改条件拼接的逻辑
• 安全性符合要求：所有查询参数都通过占位符传入，由数据库驱动完成转义，不存在SQL注入风险
• 完全符合原生SQL的使用规范，没有依赖Django ORM的任何过滤能力

注意事项：禁止直接将请求获取的搜索值直接拼接到SQL字符串中，比如写WHERE p.Age = {search_age}这类写法，会直接造成SQL注入漏洞，必须通过占位符传值的方式传递参数。

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