django中使用uuid作为主键的坑、问题记录 之 django使用uuid作为主键出现path匹配不到

问题一 model设置问题

两个例子

例子一：
models.CharField(max_length=10,default=uuid.uuid4,editable=False, primary_key=True)
例子二：
models.UUIDField(max_length=10,default=uuid.uuid4,editable=False, primary_key=True)

这里我使用的是例子一，使用例子二发现生成的uuid不符合django中path里面uuid的规范，导致path识别不到，非常坑，下面是我问gpt的一些回答，我这里总结一下：①uuid的规范是中间有几个横杆的；②使用UUIDField可以减少字符串和UUID之间数据类型的切换，提高性能；③使用UUIDField可以使用数据库里面的一些操作，而使用CharField+uuid.uuid4来实现就会比较直接，但是里面会涉及到UUID和字符串之间的转换。
GPT：

一种是使用models.CharField并在其中使用uuid.uuid4作为默认值，另一种是直接使用models.UUIDField。这两种方法生成UUID的方式是不同的，原因如下：

字段类型的差异：

models.CharField：这是一个字符字段，用于存储字符串。在您的方法中，UUID被转换为字符串存储。
models.UUIDField：这是一个专门用于存储UUID的字段。它确保UUID始终以正确的格式（通常是32个字符长，例如：123e4567-e89b-12d3-a456-426655440000）存储。
默认值的差异：

使用uuid.uuid4()生成新的UUID。每次您运行数据库迁移或创建新的数据库记录时，都会生成一个新的UUID。
models.UUIDField的默认值通常是None，除非您明确为其指定一个值。
性能和存储的差异：

使用models.CharField，UUID被存储为字符串。这可能会稍微增加存储需求，并可能在某些操作中略微降低性能，因为需要进行字符串到UUID的转换。
models.UUIDField直接存储UUID，通常更为高效。
功能和灵活性的差异：

models.UUIDField提供了更多的内置功能和验证，例如自动的UUID版本检查（例如，确保UUID是V4格式）。
使用models.CharField和uuid.uuid4可能不会提供这些内置功能。
数据库级别的约束：

在某些数据库系统中，字符串字段和UUID字段可能有不同的性能特性或索引选项。虽然Django隐藏了这些底层细节，但了解这些差异可以帮助您更好地优化数据库性能。
与Python 3.8+版本的兼容性：

从Python 3.8开始，您可以直接在字段类型中定义默认的函数调用，如您的例子所示。这意味着当您迁移模型时，Django可以自动为您调用uuid.uuid4()。但使用models.UUIDField，您仍然需要显式地生成和设置UUID。
基于上述差异，如果您的应用场景需要专门处理和验证UUID、追求最佳性能和利用数据库功能，那么使用models.UUIDField可能是更好的选择。如果您只是需要一个唯一的标识符，并且不关心UUID的具体格式或验证，那么使用models.CharField和uuid.uuid4作为默认值可能更简单、更直接。
# 

问题二 path默认最后加入’/’

如果你上面没有解决，试试这个

paht("xxxx/<uuid:pk>/",xxxViewSet.as_view())