Djongo 的 filter() 返回空结果却不报错，是因为它将 Django ORM 的 SQL 语义强行翻译为 BSON 查询，遇到嵌套字段、icontains、__in 列表或 ArrayField 排序时，会生成无效聚合管道或跳过条件，导致静默返回空游标，而非抛出异常。
Djongo 不是 Django 集成 MongoDB 的可行路径，它会在复杂查询、数组操作、聚合和事务中产生静默错误或 NotImplementedError，实际项目中应直接弃用；PyMongo（或异步的 motor）才是稳定、可控、可维护的选择。
为什么 Djongo 的 filter() 会返回空结果却不报错
Djongo 把 Django ORM 的 SQL 式语义强行翻译成 BSON 查询，但 MongoDB 并不支持 JOIN、子查询或关系型索引语义。一旦遇到嵌套字段（如 tags__2="vip"）、icontains、__in 带列表、或含 ArrayField 的 order_by，它要么生成无效聚合管道，要么跳过条件直接返回空游标。
常见表现：
FieldError: Unsupported lookup 'icontains' for CharField-
Person.objects.filter(tags__in=["vip", "beta"]) → []，但用db["person"].find({"tags": {"$in": ["vip", "beta"]}})能查到 -
Post.objects.order_by("-comments.0.created_at")完全静默失效，排序未发生
根本原因：Djongo 没有真正理解文档模型，它只是在 query 构建阶段做字符串/AST 层面的“SQL → BSON”映射，丢失了 MongoDB 的语义边界。
PyMongo 直连怎么配、怎么用、怎么避免踩坑
不改 DATABASES，不写 models.py，直接在视图、管理命令或服务层调用客户端——这才是匹配 MongoDB 使用逻辑的方式。
实操建议：
- 在
settings.py中定义连接配置：MONGODB_URI = "mongodb://localhost:27017/"，或 Atlas 连接串（含用户名密码与?authSource=admin） - 初始化客户端时复用单例：
from pymongo import MongoClient; client = MongoClient(settings.MONGODB_URI)，不要每次请求都新建 - 用
db = client["myapp_db"]获取数据库，再用db["users"]操作集合，字段名和嵌套结构完全自由 - 查询写原生语法：
db["orders"].find({"status": "paid", "items.0.sku": "ABC123"})，别尝试模拟filter(items__0__sku="ABC123") - 写入前用
pydantic.BaseModel校验结构，比如UserCreate(name=str, tags=list[str])，MongoDB 本身不做 schema 约束
需要类 ORM 的链式查询？选 MongoEngine 或 Beanie，别碰 Djongo
如果业务强依赖声明式模型 + 链式方法（如 .filter().sort().limit()），Djongo 是最差选项；MongoEngine 和 Beanie 才是为文档模型设计的。
关键差异：
-
MongoEngine的EmbeddedDocumentListField明确对应数组嵌套，queryset.filter(name__iexact="a")稳定转为{name: /^a$/i} -
Beanie基于pydantic，支持Document.find().sort("-created_at").limit(10)，底层直调find()，无中间翻译损耗 - 二者都支持
aggregate()、update_many()、事务（4.0+）等 MongoDB 原生能力，而 Djongo 对这些基本不可用
真正容易被忽略的是：MongoDB 的“无模式”不是放任不管，而是把 schema 控制权交还给应用层。用 PyMongo 或 Beanie 时，你得自己在数据流入前做校验、在变更时更新索引、在聚合时手写 pipeline——这不是缺陷，是文档数据库的设计前提。指望 Django ORM 风格自动兜底，只会让问题延迟爆发。
