UUID 作为 TP6 主键需手动配置 $pk、$auto=false 等模型属性，并推荐用 ramsey/uuid 生成 BINARY(16) 存储，避免 VARCHAR(36) 性能毒药；MySQL 8.0+ 可配合 uuid_to_bin()/bin_to_uuid() 提升索引效率。
UUID 作为 ThinkPHP 主键不是“好不好”的问题，而是“在哪用、怎么配、踩什么坑”的问题。直接结论：MySQL 8.0+ 配合 uuid_to_bin() + bin_to_uuid() 可以用，但必须手动处理二进制转换；PHP 层用 ramsey/uuid 生成再存为 BINARY(16) 是当前最稳路径；裸用 varchar(36) 存标准 UUID 是性能毒药，别碰。
为什么 UUID 在 TP6 里容易查不到、插不进、排序乱
ThinkPHP 默认把主键当字符串处理，而 UUID 的标准格式（如 "a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8"）是 36 字符的 VARCHAR，索引效率低、比较慢、ORDER BY 结果不可预测。更关键的是：TP6 的 find()、update()、delete() 全部依赖模型声明的 $pk 字段做 WHERE 条件——如果你设了 protected $pk = 'id'，但数据库里主键字段叫 user_uuid，那所有操作都会悄悄错过去。
常见错误现象：
-
UserModel::find('a1b2...')返回 null，日志里 SQL 却是WHERE id = 'a1b2...' -
save()后getLastInsID()是 0，因为 TP 默认从自增列读 ID，而 UUID 字段根本不是 AUTO_INCREMENT -
chunk(100, ...)报错Unknown column 'id' in 'order clause'，因为连表时没指定column参数，框架仍试图按id排序
MySQL 8.0+ 正确存 UUID 的三步实操
核心是绕过字符串比较，用二进制压缩 + 数据库函数转换。TP6 不自动帮你做这层，得自己写。
立即学习“PHP免费学习笔记（深入）”；
- 建表时主键字段定义为
id BINARY(16) PRIMARY KEY，不是VARCHAR - 插入前用 MySQL 函数转：
INSERT INTO users (id, name) VALUES (UUID_TO_BIN('a1b2...', TRUE), 'Alice')—— 注意第二个参数TRUE启用优化序（time-first），让索引局部性变好 - 查询时反向转：
SELECT BIN_TO_UUID(id, TRUE) AS id, name FROM users，或在 TP 模型里用->field('BIN_TO_UUID(id, TRUE) AS id, name')
PHP 层推荐配合 ramsey/uuid：
$uuid = \Ramsey\Uuid\Uuid::uuid4();
$bin = $uuid->getBytes(); // 直接是 16 字节 binary，可直传 PDO
Db::name('users')->insert(['id' => $bin, 'name' => 'Bob']);
TP6 模型里怎么声明 UUID 主键才生效
不能只改数据库字段，TP 模型必须显式告诉框架：“这个字段就是主键，且它不是自增的”。否则所有基于主键的操作都会失效。
- 必须写
protected $pk = 'id'（字段名要和 DB 一致，大小写敏感） - 必须写
protected $auto = false，关掉自增逻辑，否则insertGetId()会去读不存在的 AUTO_INCREMENT 列 - 如果用了软删除或时间戳，记得关掉干扰：
protected $autoWriteTimestamp = false，避免 TP 尝试往id字段写时间值 - 不要设
protected $sequence—— 这是给 Oracle 用的，MySQL+UUID 场景下无效还可能报错
示例模型：
class UserModel extends Model
{
protected $pk = 'id';
protected $auto = false;
protected $autoWriteTimestamp = false;
}
比 UUID 更轻量的替代：ULID 或组合业务码
如果只是想避开自增暴露规律，又嫌 UUID 太重，ULID（如 ulid/ulid 包）是更优解：128-bit、时间前置、可排序、字符串形式紧凑（26 字符）、PHP 原生支持 random_bytes() 生成。
但注意：ULID 本身不解决分布式唯一性，只是比 UUID 更友好。真正要防遍历，还得加一层业务掩码，比如：
- 用户表用
ULID生成内部主键id（BINARY(16)） - 对外暴露
user_no字段，值为base32(ULID) . checksum或拼接租户前缀 - 所有 API 和前端交互只认
user_no，DB 查询走JOIN或冗余字段映射
这种组合既保了数据库性能，又断了爬虫推测路径的可能——比纯 UUID 更贴近真实业务约束。
