为何部分Python包需加入Django的INSTALLED_APPS，部分无需？

这问题问得特别戳痛点，很多刚接触Django的同学都会疑惑这个区别。其实核心就是搞懂INSTALLED_APPS到底是干嘛的，以及不同第三方包和Django的交互逻辑差异。

Django的INSTALLED_APPS可不是随便列个名字的地方，它是框架的核心注册表——告诉Django哪些东西需要被“深度集成”到它的运行流程里：

• 启动时加载应用的配置类（AppConfig），初始化信号、注册中间件
• 运行migrate时，扫描这些应用的数据库迁移文件
• 模板引擎会从这些应用的templates目录找模板
• collectstatic命令会收集这些应用的静态资源
• 甚至admin后台能识别你的模型，也依赖应用在这个列表里被声明

这些包本质是Django专属应用（Django App），它们的功能完全绑定在Django的核心机制上，需要Django主动“认领”并加载它们：

• DRF：它自带序列化器、视图扩展，还有API调试界面的静态资源和模板。只有把它加入INSTALLED_APPS，Django才会加载它的配置，让你能访问那个好看的API浏览页，也能正常使用它的视图类、路由扩展
• django-filter：它要和Django的ORM、视图系统深度集成，通过AppConfig注册过滤器的核心功能，这样你才能在视图里直接用filterset_class这类便捷特性
• debug-toolbar：它需要注入中间件到Django的请求流程里，还要加载调试界面的静态资源。只有加入列表，Django才会初始化它的配置，在页面上显示那个实用的调试工具栏

这些包都是为Django量身定做的，它们的功能实现离不开Django的应用生命周期，所以必须进INSTALLED_APPS让框架“认”它们。

这些是独立的Python工具库，和Django的应用机制是松耦合甚至完全无关的：

• Requests：就是个发HTTP请求的工具，你在Django视图、任务里直接import requests就能用，它不需要碰Django的模板、模型、迁移这些需要INSTALLED_APPS管理的东西，完全独立运行
• Celery：虽然常和Django搭配，但它本身是独立的任务队列系统。你只需要在Django配置文件里写好Celery的broker地址这些参数，然后在代码里导入Celery实例就行——它不需要Django为它做初始化、加载资源这类操作，因为它不涉及Django的核心应用模块

简单说，这些包是“拿来就用”的工具，不需要Django为它们搞特殊化的加载流程，所以根本不用进INSTALLED_APPS。

以后遇到第三方包，判断要不要加进INSTALLED_APPS，就看两点：

• 它是不是Django App类型的包：有没有自己的AppConfig、模型、模板、静态资源这些Django应用专属的东西
• 它的功能是否依赖Django的应用生命周期：比如需要Django启动时初始化配置、注册路由/中间件、扫描迁移文件

满足任意一点，就加；如果只是独立的Python工具，直接导入用就行。

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