Django中何时应重写并使用自定义主键？

首先明确：Django默认的BigAutoField主键在大多数小型到中型单体应用里完全够用，没必要盲目跟风大型项目改自定义主键。但在一些特定场景下，默认主键的弊端会凸显，这时候就需要考虑重写。

默认主键的潜在弊端 #

• 暴露业务规模：自增ID是连续的，一旦在API或公开页面暴露，外部可以通过ID的增长幅度推测你的数据量、业务增长速度，比如从/user/1到/user/100000，很容易猜到用户规模。
• 分布式场景下的ID冲突：如果以后要做分库分表、多实例部署，不同数据库实例的自增ID会重复，合并数据或跨库查询时会出现主键冲突问题。
• 资源遍历风险：自增ID的可预测性很强，攻击者可以通过遍历ID（比如/item/1、/item/2...）轻易爬取所有公开资源，而无规律的自定义主键能大幅提高遍历成本。
• 第三方集成适配成本高：如果需要和外部系统对接，对方可能要求使用UUID或特定格式的ID，后期再修改主键结构会涉及大量数据迁移和代码调整。

需要使用自定义主键的场景 #

• 分布式部署/分库分表需求：当你的服务需要横向扩展，拆分数据库时，必须用全局唯一的自定义ID（比如UUID、雪花ID）来避免主键冲突。
• 需要隐藏业务数据或防止资源爬取：如果你的API接口、公开页面会暴露主键，用无规律的主键（如UUID）替代自增ID，能有效降低数据泄露风险。
• 与外部系统深度集成：如果业务需要和第三方系统共享数据，且对方有特定的ID格式要求，提前使用符合要求的自定义主键能减少后续适配工作量。
• 合并多数据源：比如要合并不同环境（测试/生产）或不同业务线的数据库，自增ID几乎必然冲突，自定义主键能避免这类问题。

不需要担忧默认主键的情况 #

如果你的项目是小型单体应用，没有分布式扩展、分库分表的计划，也不需要对外暴露主键或对接复杂外部系统，那默认的BigAutoField完全能满足需求。它经过Django官方多年优化，性能稳定，没必要为了模仿大型项目而额外折腾——那些知名Django应用用自定义主键，是因为它们的业务规模和架构需求决定的，不是默认主键本身有问题。

内容的提问来源于stack exchange，提问作者Seyed Mostafa SeyedAshoor