如何保留django.contrib.auth核心功能时移除auth_group与auth_permission表？

1. 如何避免生成auth_group和auth_permission表？ #

最稳妥的方式是自定义User模型，从根源上剥离对Group和Permission的依赖：

• 继承AbstractBaseUser和BaseUserManager，而非默认的AbstractUser或PermissionsMixin（后者会自动关联Group和Permission模型）。
• 手动实现必要字段（如username、email、is_active、is_staff等）和方法（如get_full_name()、get_short_name()），确保login、authenticate等核心功能正常运行。
• 在settings.py中配置AUTH_USER_MODEL = 'your_app.YourUserModel'，让Django使用你自定义的用户模型。

如果不想自定义User模型，也可以尝试在迁移时跳过相关的auth迁移文件，但这种方式风险较高——Django版本更新可能会修改auth的迁移结构，后续容易出现迁移冲突。操作步骤大致为：

1. 查看auth应用的迁移文件，定位创建auth_group和auth_permission的具体迁移（通常包含在auth.0001_initial中）。
2. 执行python manage.py migrate auth --exclude=auth.XXXX跳过对应迁移，但需仔细核对每个迁移的内容，避免遗漏必要的auth表结构。

2. 手动删除这两张表会有什么影响？ #

绝对不建议手动删除，会引发一系列潜在问题：

• 核心auth逻辑报错：Django内部的权限检查模块（即使你没主动使用）可能会隐式查询auth_permission表，删除后直接抛出数据库表不存在的异常，导致login等功能无法正常运行。
• Admin后台异常：即使取消了Groups的注册，Django Admin的权限系统默认依赖auth_permission表，删除后可能导致Admin页面加载失败或操作报错。
• 迁移冲突：后续执行migrate命令时，Django会检测到这些表缺失，尝试重新创建，引发迁移状态不一致的问题。
• 第三方库兼容问题：部分依赖Django auth系统的第三方库（如DRF的某些扩展）可能默认调用Group或Permission模型，导致集成失败。

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