Django项目中是否可以在一个应用内引用其他应用的models？

首先明确一个认知误区：在同项目的不同App之间直接引用其他App的模型，完全符合Django的设计规范，是官方推荐的常规操作，不存在不符合规范的问题。你可以根据自己的项目场景选择以下几种方案：

1. 直接跨App引用（90%以上场景的首选） #

如果你的数据处理App和展示App同属一个项目，没有后续独立拆分部署到其他项目的需求，直接用这个方案即可，操作最简单也没有额外维护成本：

• 确保原有数据处理App已经在项目settings.py的INSTALLED_APPS中注册
• 在展示App的视图、序列化器等代码中直接导入对应模型即可，示例：

# 假设原有数据处理App名为 data_processor，对应模型为 BusinessData
from data_processor.models import BusinessData

# 展示逻辑中直接正常使用即可
def data_list(request):
    data = BusinessData.objects.all()
    return render(request, "list.html", {"data": data})

2. 抽离公共模型层（适合多App共用、未来可扩展场景） #

如果你的项目后续还会新增多个和这批业务数据相关的App，或者有计划未来把展示App独立到其他项目使用，可以把无业务绑定的核心数据模型单独抽成一个公共App：

• 新建一个独立App，比如命名为core，把所有业务通用的数据模型定义都迁移到这个App中
• 原有数据处理App、新的展示App都统一从core.models中导入对应模型即可
  这种方案的优势是模型定义统一收敛，后续迭代修改表结构只需要修改公共层一次，不会出现多份模型定义不一致的问题。

3. 代理模型（适合需要扩展展示专属逻辑的场景） #

如果你不想改动原有数据处理App的模型代码，又需要在展示App中给模型新增专属的展示类方法、自定义查询管理器，可以使用Django的代理模型特性：

# 展示App的models.py 代码示例
from data_processor.models import BusinessData

class DisplayBusinessData(BusinessData):
    class Meta:
        proxy = True # 标记为代理模型，不会生成新的数据库表
    
    # 仅在展示场景使用的格式化方法，完全不影响原有模型逻辑
    def get_formatted_amount(self):
        return f"{self.amount / 1000:.1f}k"

这种方案的优势是展示专属的逻辑完全收敛在展示App内部，不会侵入原有数据处理的业务代码，也完全复用原有模型的表结构。

绝对不要使用复制模型代码的方案，后续模型结构迭代时很容易出现多份定义不一致的隐性问题，排查成本极高。

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