不建议盲目用 uuid 代替自增主键，仅在防 id 枚举、跨库合并或分布式写入频繁且数据量不大时适用；多数内部系统仍应优先选用 autofield。
不建议盲目用 UUID 代替自增主键——它只在特定场景下真正值得切换，比如要防 ID 枚举、跨库合并、或分布式写入频繁但数据量不大。多数内部管理系统、博客、CMS 类项目，用 AutoField 更稳更快。
防 ID 枚举和业务量推测是核心动因
自增 ID 暴露了记录总数和创建顺序，比如 /api/user/12345 被扫一遍就能估算用户规模；订单号连续还能反推日活。UUID（尤其是 uuid.uuid4()）天然无序、不可预测，直接切断这条攻击路径。
- 必须用
uuid.uuid4（函数对象），不是uuid.uuid4()（调用结果），否则所有实例共享同一个 ID -
editable=False是硬性要求，否则 Django Admin 或 ModelForm 可能意外覆盖主键 - 仅声明
models.UUIDField(default=uuid.uuid4)不够——Django 仍会加隐式AutoField，必须显式写id = models.UUIDField(primary_key=True, ...)
MySQL 和 PostgreSQL 对 UUID 的处理差异极大
PostgreSQL 原生支持 UUID 类型，索引效率接近整数；MySQL 默认把 UUIDField 存成 CHAR(36)，体积翻倍、排序慢、B+树页分裂严重。
- Django 4.2+ 推荐用
BinaryUUIDField，底层存为BINARY(16)，比字符串快得多 - 老版本 Django + MySQL 必须手动在迁移中指定
db_type='BINARY(16)'，并配合uuid_to_bin()写入 - 哪怕用了二进制存储，UUID 主键的插入性能仍略低于自增 ID——因为 B+树无法预分配尾部位置，随机写放大明显
已有数据表迁移极易出错
Django 禁止对已有数据的表直接添加非空主键，会报 NOT NULL constraint failed 或提示 “You are trying to add a non-nullable field without a default”。
- 开发环境可清空重来：
python manage.py migrate --fake-initial配合删库 - 生产环境必须分三步：先加普通
UUIDField→bulk_update填充 → 手动编辑迁移文件，把旧id改为db_column='old_id'，再删之 - 更稳妥的做法：不碰主键，新增
public_id = models.UUIDField(unique=True, default=uuid.uuid4)作业务标识，保留id仅用于外键关联
路由和 API 输入校验不能省
Django 默认序列化 UUID 为小写带连字符格式（如 'a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8'），但用户可能手输大写、漏连字符、甚至粘连成 32 位字符串，后端不拦截就直接 404 或查错记录。
- URL 路由务必用
path('<pk>/', ...)</pk>，它自动做格式校验和大小写归一 - 手动解析时必须包
uuid.UUID()并捕获ValueError，别信正则 - 前端拼 URL 时，确保调用
.toString()或.asHex生成标准格式，避免用Math.random().toString(36)类伪 UUID
真正容易被忽略的点是外键一致性：一旦主键换成 UUID，所有引用它的外键字段也必须同步改为 UUIDField，否则类型不匹配、迁移失败、查询静默出错。这不是改一个模型的事，而是整条关联链都要对齐。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
