Django自定义用户模型报错：users_customuser表不存在

以下是几个常见的非迁移相关原因及排查方向：

• 数据库连接配置偏差
  检查settings.py（或团队用的本地配置文件，比如local_settings.py）中的DATABASES配置，确认当前连接的数据库是你执行过迁移的那一个。比如SQLite的NAME路径是否指向正确的db.sqlite3文件，MySQL/PostgreSQL的库名、账号是否对应已迁移的实例。
  可以执行python manage.py inspectdb，查看输出里是否包含users_customuser表，快速验证当前连接的数据库结构。

• 模型与迁移文件不一致
  即便迁移记录显示0001_initial已执行，也可能存在模型后续修改但未生成新迁移，或者初始迁移文件本身存在缺陷的情况。
  对比users/migrations/0001_initial.py中的模型定义和users/models.py里的CustomUser，确认events_attending等字段在迁移文件中被正确声明。比如多对多字段是否指定了正确的关联模型、是否有遗漏的参数。

• ORM元数据缓存问题
  Django ORM会缓存模型的元数据，旧缓存可能导致系统“看不到”已存在的表。解决方法：

  • 完全重启本地开发服务器（不要只是重载）
  • 执行python manage.py clearcache清除Django内置缓存
  • 若使用了Redis等第三方缓存服务，同步清空对应缓存

• 多对多关联的依赖问题
  events_attending关联的Event模型如果属于其他应用，要确认该应用的迁移已正常执行，且Event模型无循环依赖或定义错误。
  另外，跨应用的多对多关联可能因迁移执行顺序问题，间接影响用户表的查询逻辑——虽然用户表已生成，但关联的中间表缺失可能触发类似错误，可检查数据库中是否存在users_customuser_events_attending这类中间表。

• 硬编码表名或第三方库配置遗漏
  仔细检查项目中是否存在硬编码用户表名的情况，比如原生SQL查询、自定义认证后端、DRF序列化器里直接写了auth_user而非使用get_user_model()。
  另外，第三方库（比如认证、权限相关）的配置可能仍引用默认用户模型，需确认所有涉及用户模型的配置都替换成了users.CustomUser（比如AUTH_USER_MODEL = 'users.CustomUser'是否正确设置）。

• SQLite数据库文件损坏
  若使用SQLite作为本地数据库，文件可能因异常退出、权限问题损坏，导致表存在但无法被读取。可以先备份当前db.sqlite3，再执行python manage.py migrate --fresh重新初始化数据库（注意此操作会清空所有数据，仅用于本地排查）。

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