使用UUIDField。复制自文档：
用于存储通用唯一标识符的字段。使用Python的UUID类。当在PostgreSQL上使用时，它以uuid数据类型存储，否则以char（32）存储。
通用唯一标识符是primary_key的自动字段的一个很好的替代方案。数据库不会为您生成UUID，建议使用default：

import uuid from django.db import models

class MyUUIDModel(models.Model):
    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
    # other fields

请注意，传递给default的是一个可调用对象（省略括号），而不是UUID的示例。

可以使用以下代码。但是有可能有重复的号码并出错。

import random

def big_random():
    return random.randint(1000000, 9999999)

class Foo(models.Model):
    id = models.IntegerField(default=big_random, primary_key=True)
    bar = models.CharField(max_length=30)

我建议使用uuid作为pk：

import uuid

class Foo(models.Model):
    id = models.IntegerField(default=uuid.uuid4, primary_key=True)
    bar = models.CharField(max_length=30)

如果需要一个唯一的32位整数实体来代替URL中的pk，那么可以在该域中使用可逆的1到1Map函数。这并不安全，但可以防止没有访问源代码的人“钓鱼”下一个或上一个pk。
使用CBV，您将在一端解码不是pk的“pk”，例如在子类get_object方法中，并在另一端使用例如

reverse( 'app:name', kwargs={ 'pk': my_mapping_function( object.pk) } )

我不会主动提供这样一个Map函数，因为一旦发布它，我会立即让它变得不那么有用！（一个简单的方法是将整数pk的位置换成新的顺序。对于不那么琐碎的问题，请咨询数学家）。
我仍然坚持我的评论，这是一个错误的例子。如果猜测pk值会损害应用程序的安全性，那么“模糊安全性”也好不到哪里去，下面的答案就是一个例子。
这就是说，Hashids可能有用。

流行的软件包django-extensions有几个这样的字段选项。
特别是它们有ShortUUIDField和RandomCharField（如果您想自动生成slug字段，还有AutoSlugField）选项。请参见this post