直接用Tkinter写复杂查询界面易失控，因其缺乏SQL解析、语法高亮等能力，易导致手动拼接SQL引发注入风险；应拆解为可验证组件，如Combobox限表名、Treeview动态映射字段并分页排序、Condition类构建参数化WHERE条件。
为什么直接用 Tkinter 写复杂查询界面容易失控
因为 Tkinter 本身不提供 SQL 解析、语法高亮、表结构自动补全或执行计划可视化能力。你写出来的“复杂查询逻辑”，大概率会变成一堆 Entry 和 Text 手动拼接字符串，最后传给 sqlite3.execute() 或 psycopg2.cursor.execute() —— 这不是工具，是 SQL 注入温床。
真正可控的做法是：把“复杂查询”拆成可验证的组件，而不是放任用户在 Text 里自由发挥。
- 用
ttk.Combobox限制表名输入（从PRAGMA table_info(...)或information_schema动态加载） - 用
Treeview显示字段列表，支持多选生成SELECT col1, col2 - 条件行用
Frame+Combobox(字段) +Combobox(操作符) +Entry组合，每行对应一个WHERE子句 - 禁止直接执行原始 SQL 输入框；如需高级模式，加开关并默认禁用，启用时明确提示风险
Treeview 如何安全映射数据库字段并支持动态排序
别用 Treeview.insert() 一行行塞数据 —— 大结果集卡死 UI。必须配合 fetchmany() 分页 + after() 调度，且字段名不能硬编码。
正确做法是先查元数据：
立即学习“Python免费学习笔记（深入）”；
cursor.execute("PRAGMA table_info(orders)")
cols = [row[1] for row in cursor.fetchall()] # 字段名列表
tree["columns"] = cols
for col in cols:
tree.heading(col, text=col)
tree.column(col, width=100)
排序要绑定到列头点击事件，并生成带 ORDER BY 的新查询（不是内存排序），否则翻页后顺序错乱：
- 监听
tree.heading(col, command=lambda c=col: self.sort_by(c)) -
sort_by()重建查询语句，追加ORDER BY {col} DESC，再fetchmany() - 记住上次排序字段和方向，避免点两次升序变降序再变升序的混乱
多条件 WHERE 构建时如何避免 SQL 注入和括号错位
用户加 5 个条件、选 2 个“AND/OR”组合，手拼字符串几乎必然出错。正确路径是构造抽象语法树（AST）式条件对象，再转 SQL。
最简可行方案：
class Condition:
def __init__(self, field, op, value):
self.field = field
self.op = op # '==', 'LIKE', 'IN', 'BETWEEN'
self.value = value # 值本身，非字符串
<p>conditions = [
Condition("status", "==", "shipped"),
Condition("created_at", ">=", "2024-01-01")
]</p><h1>生成 WHERE status = ? AND created_at >= ?</h1><h1>参数用 tuple( [c.value for c in conditions] ) 传给 execute()</h1><p>- 所有用户输入值都走参数化查询，
value字段不参与字符串拼接 - 操作符
op只从预设白名单取：["==", "!=", ">", ">=", "<li>“括号分组”功能如果真需要，用嵌套 <code>ConditionGroup([c1, c2], logic="OR")，而非让用户画括号
连接 PostgreSQL/MySQL 时 Tkinter 主线程阻塞怎么办
connect() 和 execute() 是同步阻塞调用，直接放 Button 回调里，整个 UI 会冻结数秒甚至十几秒 —— 用户点不动、关不掉、以为崩溃了。
必须剥离到后台线程，但 Tkinter 组件不可跨线程访问，所以不能在线程里调用 tree.insert()。
- 用
threading.Thread(target=self.run_query, args=(sql, params))执行查询 - 查询结果存入队列：
queue.Queue()，主线程用root.after(100, self.check_queue)轮询 - 每次只取一批（比如 100 行），插入
Treeview，避免单次插入卡顿 - 连接失败或超时必须捕获具体异常：
psycopg2.OperationalError、mysql.connector.errors.DatabaseError，而不是笼统的Exception
复杂点不在 SQL 逻辑本身，而在于你是否愿意把“用户觉得复杂”的部分，拆成机器可验证、可回滚、可中断的原子操作。否则，它很快就会变成没人敢改、不敢用、出问题只能重启的“半成品”。
