当你使用python manage.py startapp app01的命令创建了一个名为app01的新应用后，通常接下来要做的就是在settings.py里注册它，把它加到INSTALLED_APPS里去。你可以选择直接添加app名，还可以添加该app对应的配置AppConfig子类。到底哪种方式更好呢？
-
# settings.py 注册app
-
# 方式1：直接加入app名，
-
INSTALLED_APPS = [
-
'django.contrib.admin',
-
'app01',
-
]
-
-
-
# 方式2：直接加入app对应的AppConfig子类
-
INSTALLED_APPS = [
-
'django.contrib.admin',
-
'app01.apps.App01Config',
-
]
-
回答这个问题没有简易答案，一切还得从Django的AppConfig类说起。
配置信息和verbose_name - 你有的我也要
Django一个项目(project)由多个应用(app)组成，每个app的创建和注册体现了一个插拔的思想，即插即用。与project一样，每个app其实也有自己的配置信息，只是我们很少配置而已。项目的配置信息我们一般写在settings.py里，那么每个app对应的配置信息我们写在哪里? 答案是每个app目录下的apps.py里。与settings.py中以字符串形式配置相关信息不同，每个app的配置信息是通过继承Django的AppConfig类实现的。
在实际开发过程中，我们不需要编辑apps.py，给每个app手动添加配置信息，这是因为Django会根据app名生成默认的配置类。它继承了AppConfig类，里面只有name一个基本属性，如下所示：
-
#app01/apps.py
-
from django.apps
import AppConfig
-
-
-
class App01Config(AppConfig):
-
name =
'app01'
但也有不少情况下我们需要给app添加额外配置信息。举个例子，我们在自定义模型(Models)时会给每个模型起个verbose_name(别名), 便于人阅读。同样的，我们也可以给app起个verbose_name, 这时我们就需要修改apps.py添加别名了。比如本例中app01这个名字可读性太差，我们最好给它起个别名，比如"用户管理"，我们可以按如下修改代码：
-
#app01/apps.py
-
from django.apps
import AppConfig
-
-
-
class App01Config(AppConfig):
-
name =
'app01'
-
verbose_name =
'用户管理'
或许你会问app的别名哪里会用到呢？Django的admin后台啊。一般app的创建名字都是英文，如果你希望以在admin中以中文显示app名，就必须用到app的verbose_name了。
那么还有什么情况下我们需要自定义app的配置信息呢？要回答这个问题，我们需要了解下AppConfig这个类的类的源码。。
AppConfig类 - 源码分析
Django的AppConfig类主要有如下属性和方法，部分源码见后面。属性里4个标红的属性可以自定义的，两个标红方法是可以重写的。
属性：
name：django应用的完整python路径，eg.'django.contrib.admin'，在初始化参数中由app_name参数指定。
label：app的标签，这个名字必需独一无二，如果不设置即为app名。
verbose_name: app的别名，如果不设置即为app首字母大写形式。
path：django应用的文件系统的路径
module：django应用的根模块，是一个模块对象，eg.<module 'django.contrib.admin' from 'django/contrib/admin/__init__.py'>
apps：Apps注册表的引用，该注册表保存管理着这个AppConfig。当注册表注册这个AppConfig实例的时候，由注册表进行设置。
models_module：包含models的模块，也就是models.py文件，这是由import_models()设置，若没有则为None。
方法：
create方法:这是一个类方法，是一个工厂为INSTALLED_APPS的一个条目创建一个app config，返回是cls(app_name,app_module)，即该类的一个实例。
ready方法: 子类可以覆盖此方法来执行初始化任务,例如注册信号和连接non-SQL数据库。
源码:
-
class AppConfig:
-
""
"Class representing a Django application and its configuration."
""
-
-
-
def __init__(self, app_name, app_module):
-
# 完整的python路径，比如 'django.contrib.admin'.
-
self.name = app_name
-
# 自动生成
-
self.
module = app_module
-
# Reference to the Apps registry that holds this AppConfig.
-
self.apps = None
-
-
-
# 如果没有设置label标签，使用app_name.结尾的最后部分.
-
# 比如admin
-
if
not hasattr(
self,
'label'):
-
self.label = app_name.rpartition(
".")[
2]
-
-
-
# 如果没有设置verbose_name, 使用label.title()
-
# 比如Admin
-
if
not hasattr(
self,
'verbose_name'):
-
self.verbose_name =
self.label.title()
-
-
-
# 应用目录路径，比如
-
# '/path/to/django/contrib/admin'.
-
if
not hasattr(
self,
'path'):
-
self.path =
self._path_from_module(app_module)
-
-
-
self.models_module = None
-
self.models = None
-
-
-
@classmethod
-
def create(cls, entry):
-
-
def ready(self):
-
""
"
-
Override this method in subclasses to run code when Django starts.
-
"
""
通过继承AppConfig类自定义label和自定义verbose_name一样简单，这里就不贴代码了。或许你会问在什么情况下需要自定义app的label呢？答案是：第三方库的app的名和你自己的app名可能存在命名冲突时，可以通过自定义label避开，因为app_label必须是独一无二的存在。
下面我们着重介绍下如何在继承AppConfig类时重写ready方法，这个在使用信号(signals)时会经常遇到的。
重写ready方法
假如我们有个account的app，包含了User和Pofile模型(1对1的关系)，我们希望通过信号实现创建一个新User实例的同时也创建一个Profile实例。这时我们可以在account文件夹下新建signals.py，需要修改account文件下apps.py，重写ready方法，确保Django项目初始化时即可导入创建的信号监听函数。
# account/signals.py
-
from django.db.models.signals import post_save
-
from django.dispatch import receiver
-
from .models import User, Profile
-
@receiver(post_save, sender=User)
-
def create_user_profile(sender, instance, created, **kwargs):
-
if created:
-
Profile.objects.create(user=instance)
-
@receiver(post_save, sender=User)
-
def save_user_profile(sender, instance, **kwargs):
-
instance.profile.save()
# account/apps.py
-
from django.apps import AppConfig
-
-
class AccountConfig(AppConfig):
-
name = '
account'
-
-
def
ready(
self):
-
import
account.
signals
相关阅读
Django基础(31): 如何理解和正确使用Django信号(Signals)
如何让自定义的AppConfig子类生效?
前面我们只是修改了app01和account应用的apps.py, 自定义了App01Config和AccountConfig两个子类，它们继承了Django的AppConfig基类。遗憾的是这些自定义的子类不会立即生效。接下来我们要说的是本文的重点，会帮你解答你所有的疑惑。
如果你直接把app名加入到INSTALLED_APPS，Django会默认采用AppConfig基类中的配置信息，而不是你在apps.py中定义的子类。如果你希望在不修改INSTALLED_APPS的前提下让自定义的子类生效，，还需要修改app目录下的__init__.py, 新增default_app_config属性, 将自定义子类设为默认，如下述所示：
# account/__init__.py
default_app_config = 'account.apps.AccountConfig'如果你直接把自定义的AppConfig子类路径加入到INSTALLED_APPS，那么自定义的子类可以直接生效，如下所示：
-
# 直接加入app对应的AppConfig子类路径，可让自定义app配置直接生效
-
INSTALLED_APPS = [
-
'django.contrib.admin',
-
'app01.apps.App01Config',
-
]
-
小结
每个app也有自己的配置信息，放在apps.py里的。在大多数情况下，把app名直接加入到INSTALLED_APPS就足够了。只有当你需要给app自定义配置信息时，需要把加入app对应的AppConfig子类路径直接加入到INSTALLED_APPS。这个知识点，你get到了吗?
参考资料：
https://docs.djangoproject.com/en/3.1/ref/applications/#django.apps.AppConfig
大江狗
2020.9
推荐阅读
Linux服务器上正式部署Django项目时该如何正确设置文件和文件夹的权限?
为什么Django 3后建议使用Field.choices枚举类型定义choices选项
Django Object Permission之Django-guardian使用详解
转载：https://blog.csdn.net/weixin_42134789/article/details/108373452