没关系。Pk更独立于实际的主键字段，即你不需要关心主键字段是否被称为id或object_id或其他什么。

如果您的模型具有不同的主键字段，它还提供了更多的一致性。

没关系。Pk更独立于实际的主键字段，即你不需要关心主键字段是否被称为id或object_id或其他什么。

如果您的模型具有不同的主键字段，它还提供了更多的一致性。

在Django项目中，我知道pk总是返回id，我更喜欢使用id，当它不与id()函数冲突时(到处都是，除了变量名)。这样做的原因是pk是一个比id慢7倍的属性，因为它需要时间在meta中查找pk属性名。

%timeit obj.id
46 ns ± 0.187 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)
%timeit obj.pk
347 ns ± 11.3 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

下面是相关的Django代码:

def _get_pk_val(self, meta=None):
    meta = meta or self._meta
    return getattr(self, meta.pk.attname)

def _set_pk_val(self, value):
    return setattr(self, self._meta.pk.attname, value)

pk = property(_get_pk_val, _set_pk_val)

当我需要使用一个名为pk的变量时，这真的是一个罕见的情况。我更喜欢使用更详细的东西，如user_id而不是pk。

在整个项目中遵循相同的约定是可取的。在您的示例中，id是一个参数名，而不是一个属性，因此在计时方面几乎没有区别。形参名称不会与内置id()函数的名称冲突，因此在这里使用id是安全的。

总之，由您来选择是使用字段名id还是使用pk快捷方式。如果你不是在为Django开发库，而是在所有模型中都使用自动主键字段，那么在所有地方使用id是安全的，有时会更快。另一方面，如果您希望通用访问(可能是自定义的)主键字段，那么在任何地方都使用pk。三分之一微秒对于网络来说不算什么。