直接用 UUIDField 替换 AutoField 主键可防 ID 枚举，但需正确定义（primary_key=True、default=uuid.uuid4、editable=False）、谨慎迁移、适配数据库存储（如 MySQL 用 BINARY(16)）、严格校验路由与 API 输入，否则反致数据错乱或性能下降。
直接用 UUIDField 替换默认 AutoField 主键，就能阻断 ID 枚举和业务量推测——但必须写对字段定义、选对生成方式、处理好迁移路径，否则反而引入数据错乱或性能倒退。
UUIDField 声明必须带 primary_key=True，否则 Django 仍加自增 id
常见错误是只写 uuid = models.UUIDField(default=uuid.uuid4)，结果数据库里同时存在隐式自增 id 和无主键的 uuid 字段，完全没达到防遍历目的。
- 正确写法：
id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False) -
default=uuid.uuid4是传函数对象，不是uuid.uuid4()—— 后者会在模块加载时执行一次，所有实例共享同一个 UUID -
editable=False防止 Django Admin 或 ModelForm 意外改写主键值
已有数据表迁移时，不能直接加非空主键
Django 对已有数据的表禁止新增非空主键，会报 NOT NULL constraint failed 或提示 “You are trying to add a non-nullable field without a default”。
- 开发环境可清空表重来：
python manage.py migrate --fake-initial配合删库重迁 - 生产环境必须保留旧数据：先添加普通
models.UUIDField字段 → 用bulk_update批量填充 → 再手动编辑迁移文件，把旧id字段设为db_column='old_id'，最后删之 - 更稳妥做法：不替换主键，改用
public_id = models.UUIDField(unique=True, default=uuid.uuid4)作业务主键，保留id仅用于内部关联
MySQL 用户必须注意存储格式，否则索引性能暴跌
PostgreSQL 原生支持 UUID 类型，Django 映射为高效 B-tree 索引；MySQL 默认用 CHAR(32) 存十六进制字符串（如 'a1b2c3d4e5f67890g1h2i3j4k5l6m7n8'），体积翻倍、排序慢、易页分裂。
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
立即学习“Python免费学习笔记（深入）”；
- Django 4.2+ 推荐用
BinaryUUIDField，底层存为BINARY(16) - 若用老版本，需手动在迁移中定义
db_type='BINARY(16)'并配合uuid_to_bin()写入 - 无论哪种数据库，UUID 主键插入性能都略低于自增 ID —— 因为无法预测下个值，B-tree 插入位置随机
路由和 API 透出 UUID 时，大小写与连字符必须校验
Django 默认序列化 UUID 为小写带连字符格式（如 'a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8'），但用户可能手输大写、漏连字符或粘连字符串，后端不拦截就会 404 或查到错误记录。
- URL 路由务必用
path('<uuid:pk>/', ...)，它自动调用uuid.UUID()校验并标准化格式 - 手动解析时必须用
try: uuid.UUID(input_str) except ValueError:，别用正则粗筛 - 前端拼接 URL 时，确保调用
.hex或str(uuid_obj)，避免直接用uuid_obj.bytes或未格式化的整数
真正难的不是生成 UUID，而是让整个链路——从模型定义、数据库存储、迁移操作、外键约束，到路由解析和前端透出——全部对齐 UUID 的语义和边界条件。任何一个环节松动，安全性和一致性就立刻打折扣。
