用dict拼接查询条件最直接，需分层组装避免覆盖，$expr用于字段间比较且字段名须加$前缀，用户输入值须类型校验转换，复杂条件应封装为可测试函数。
用 dict 拼接查询条件最直接，但嵌套逻辑容易写错
MongoDB 的 find() 接收一个字典作为过滤器，动态构建本质就是把用户输入、业务规则等转换成合法的嵌套字典结构。常见错误是手动拼字符串或用 eval()，既不安全也不易维护。
正确做法是分层组装：先初始化空 dict，再根据条件逐层更新。特别注意布尔逻辑操作符（如 $and、$or）必须显式包裹，不能靠 Python 的 and/or 替代。
- 多个字段“且”关系：直接在顶层字典中添加键值对，例如
{"status": "active", "score": {"$gt": 50}} - 字段内“或”关系：用
{"$or": [{"type": "A"}, {"type": "B"}]}，不能写成{"type": "A" or "B"} - 避免重复覆盖：用
update()或|=（Python 3.9+）合并子条件，别用=直接赋值覆盖前序逻辑
$expr 是动态比较字段间关系的唯一可靠方式
当需要比较两个字段（比如 "start_time" > "end_time"），或调用 MongoDB 表达式函数（如 $dateDiff、$regexMatch），必须走 $expr。普通字段过滤语法不支持这种计算逻辑。
容易忽略的是：$expr 内部所有字段引用必须加 $ 前缀，且不能混用 Python 变量名。写错会静默失败或返回空结果。
立即学习“Python免费学习笔记（深入）”；
- 正确：
{"$expr": {"$gt": ["$start_time", "$end_time"]}} - 错误：
{"$expr": {"$gt": [start_time, end_time]}}（Python 变量未转为字符串引用） - 复合表达式建议先用
pymongo.ASCENDING等常量辅助构造，避免手敲字符串出错
用户输入值要过一遍 json_util.loads() 或类型校验
前端传来的 JSON 字符串（如日期范围、数组 ID 列表）若直接塞进查询字典，可能引发类型错误或注入风险。MongoDB 驱动不会自动转换字符串为 datetime 或 ObjectId。
典型踩坑点：用户提交 "created_after": "2024-01-01"，没转成 datetime 就放进 {"created_at": {"$gt": "2024-01-01"}} —— 字符串比较和日期比较结果完全不同。
- 日期字符串 → 用
datetime.fromisoformat()或dateutil.parser.parse() - ID 字符串 → 用
ObjectId()包裹，否则查不到（即使格式正确） - 数值范围输入 → 显式转
int/float，避免字符串隐式比较 - 不确定结构时，用
json_util.loads()处理带$操作符的原始 JSON
复杂条件建议封装成可测试的函数，别堆在视图里
超过 3 层嵌套或含 2 个以上 $or/$and 的查询，硬编码在路由函数里极易失控。调试时连打印出来的字典都难读，更别说复现边界 case。
真正省时间的做法是把条件生成逻辑拆出来，输入参数、输出纯字典，并配单元测试验证各种组合分支。这样改需求时只动一个函数，不用翻遍整个 API 层。
- 函数签名示例：
build_user_query(status=None, tags=None, date_range=None, has_attachment=False) - 每个参数对应一类条件分支，内部用
if/elif组装子字典，最后用dict()合并 - 测试重点：空参数、多选标签、日期边界、
None值是否被忽略而非参与查询
动态查询最难的不是语法，而是状态组合爆炸后没人能说清“此时到底查了什么”。把条件生成过程显式化、可测化，比优化单次查询性能重要得多。
