Django 3.2.7：如何检测当前运行命令以解决迁移报错？

针对你遇到的Docker化从头执行迁移时，URL配置中依赖未创建的Config表导致的psycopg2.errors.UndefinedTable错误，提供以下几种可行的解决思路：

方案一：检测命令并动态加载路由 #

这是你提到思路的具体实现，在URL配置文件中判断当前运行的命令，仅在非迁移类命令时加载完整路由：

import sys
from django.urls import path

# 默认空路由，迁移时不会触发模型导入
urlpatterns = []

# 排除迁移、静态文件收集等初始化命令
skip_commands = {'makemigrations', 'migrate', 'collectstatic'}
if not any(cmd in sys.argv for cmd in skip_commands):
    # 仅在正常运行时导入依赖Config的视图/路由模块
    from .views import SomeView, AnotherView
    urlpatterns = [
        path('api/data/', SomeView.as_view()),
        path('api/config/', AnotherView.as_view()),
        # 其他正常路由配置
    ]

优点：无需修改业务代码，实现简单；缺点：需要覆盖所有可能触发模型初始化的命令，避免遗漏。

方案二：延迟加载依赖模型的视图/路由 #

通过延迟导入的方式，避免在URL初始化阶段触发模型的数据库查询：

1. 路由层延迟加载：使用字符串形式引用视图，而非直接导入

from django.urls import path, include

urlpatterns = [
    # 用字符串路径代替直接导入视图类
    path('api/data/', 'myapp.views.SomeView'),
    # 或者用include的字符串形式加载子路由
    path('api/', include('myapp.urls')),
]

2. 视图层延迟导入：在视图方法内部而非模块顶部导入依赖模型

from django.views import View

class SomeView(View):
    def get(self, request):
        # 仅在请求处理时才导入依赖Config的模型
        from myapp.models import DependentModel
        data = DependentModel.objects.all()
        # 后续业务逻辑

优点：通用性强，同时降低应用启动时的初始化负载；缺点：需要调整部分视图和路由的写法。

方案三：给Config模型添加数据库不存在时的 fallback 逻辑 #

修改Config模型的配置获取方法，当数据库表未创建时返回默认值，而非直接报错：

from django.db import connection
from django.db import models

class Config(models.Model):
    key = models.CharField(unique=True, max_length=100)
    value = models.TextField()

    @classmethod
    def get_config(cls, key, default=None):
        # 先检查当前数据库中是否存在Config表
        with connection.cursor() as cursor:
            table_exists = connection.introspection.table_exists(cursor, cls._meta.db_table)
        
        if not table_exists:
            return default
        
        # 表存在时正常查询
        try:
            return cls.objects.get(key=key).value
        except cls.DoesNotExist:
            return default

优点：从根源解决依赖问题，不影响正常业务逻辑；缺点：需要修改Config模型的核心方法。

方案四：拆分迁移顺序，先初始化Config表 #

在Docker启动脚本中调整迁移命令的顺序，先执行Config模型所在app的迁移，再执行全量迁移：

# 先执行Config所在app的迁移（假设app名为core）
python manage.py migrate core
# 再执行其他所有app的迁移
python manage.py migrate

优点：无需修改代码，仅调整命令顺序；缺点：后续新增依赖Config的模型时，可能需要重新维护迁移顺序，长期维护成本较高。

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