去年帮一个同事排查问题，管理他写了个Django模型，类对自定义了`objects = MyManager()`，象无结果`Model.objects.all()`直接报`AttributeError: 'MyManager' object has no attribute 'all'`。法使他第一反应是管理Django版本不对，换了三个版本，类对问题照旧。象无我扫了一眼代码就笑了——他自定义的法使Manager类继承自`models.Manager`，但重写了`__init__`方法，管理忘了调用`super().__init__()`。类对就这么一个细节，象无折腾了他一整个下午。法使
Django的管理Manager不是普通类。它是类对模型与数据库之间的接口层，默认的象无`objects`是`Manager`的实例，而`Manager`本身继承自`QuerySet`的很多行为，但它不是QuerySet。很多人把Manager当成一个简单的容器，觉得随便写个类挂上去就能用，结果连最基本的`all()`、`filter()`都调不出来。根本原因在于：Django在模型类创建时，会对Manager做元类层面的处理，如果你的Manager没有正确继承或初始化，它就不会被识别为合法的管理器。
具体来说，Django的`ModelBase`元类在构建模型类时，会遍历所有属性，把`Manager`实例收集起来，并调用`Manager.contribute_to_class()`。这个方法负责把Manager绑定到模型上，同时确保它拥有查询能力。如果你自己写的Manager类没有继承`models.Manager`，或者继承了但把`contribute_to_class`搞坏了，Django就不会给它注入那些查询方法。这时候你访问`Model.objects`，拿到的就是一个光秃秃的对象，自然没有`all()`。
还有一种更隐蔽的情况：你用了`Manager.from_queryset()`来生成Manager，但传进去的QuerySet子类里重写了`__init__`，同样忘了调`super()`。这种错误不会在启动时报错，只有当你真正执行查询时才会炸。我见过一个项目，开发环境一直正常，上了生产突然所有查询都挂掉，最后发现是某个自定义QuerySet在`__init__`里做了条件判断，而那个条件依赖了一个环境变量，生产环境没设置，导致`super().__init__()`根本没执行。
另一个常见坑是多重继承。有人想让Manager同时具备两套逻辑，写了个类继承`models.Manager`和另一个自定义Manager，结果MRO顺序不对，`contribute_to_class`被覆盖成了空方法。Django不会报错，但Manager彻底失效。这种问题用`inspect.getmro()`一看就清楚，可惜很多人连MRO是什么都不知道。
说到底，Django的Manager机制并不复杂，但它依赖一套隐式的契约：你必须继承正确的基类，必须让`__init__`链完整，必须保证`contribute_to_class`不被破坏。一旦违反，Django不会给你友好的提示，它只会让你在某个深夜对着`AttributeError`发呆。我的建议很简单——自定义Manager时，先写个空类继承`models.Manager`，跑通`all()`，再往里加逻辑。别一上来就搞花活，Django的元类编程不是闹着玩的。