应使用事务内查最大值加一并在beforeWrite钩子中生成带前缀流水号：先查当前前缀最大号并加1，格式化补零后赋值，全程事务包裹加行级锁；不可用auto/type配置，因其不支持依赖数据库状态的动态计算且无法保证并发安全；必须建唯一索引兜底防重。
ThinkPHP 模型保存时怎么生成带前缀的流水号
直接在 save() 前手动拼接前缀 + 自增数，是最常见也最容易出错的做法。根本问题在于：数据库自增 ID 在写入前不可知，而业务要求的“前缀+流水号”又必须唯一、可预测、不能重复——所以不能靠数据库主键回填后再拼，得在写入前就定死。
推荐用「事务内查最大值 + 加一」方式，在模型的 beforeWrite 钩子中生成：
- 先查当前前缀下已存在的最大流水号（比如
SELECT MAX(id) FROM order WHERE id LIKE 'ORD%'），提取数字部分 - 加 1 后格式化补零（如
sprintf('ORD%06d', $next)） - 赋值给模型字段（如
$this->id = $sn），再继续保存 - 务必用事务包裹整个查+生+存流程，否则高并发下会撞号
为什么不能用 auto 或 type 配置自动处理
ThinkPHP 的模型字段 auto、type 或 filter 都只负责类型转换或默认值填充，不支持依赖数据库状态的动态计算。比如你设 'id' => ['text', '', 'add']，它只会塞个固定字符串或回调返回值，但回调里没法安全地查数据库——因为此时还没开启事务，且模型尚未绑定连接实例。
更关键的是：这些配置在批量写入（saveAll）时会被统一执行，无法为每条记录单独查最大值，必然导致重复。
立即学习“PHP免费学习笔记（深入）”；
-
auto回调中调Db::max()属于跨模型操作，易引发事务隔离问题 - 即使查到最大值，没锁表或没事务保护，另一请求可能在同一毫秒插入相同编号
- MySQL 的
SELECT ... FOR UPDATE在非事务块里无效，必须显式Db::startTrans()
并发场景下怎么避免流水号重复
核心就一条：所有生成逻辑必须落在同一个数据库事务里，并对相关记录加行级锁。不要试图用 Redis 自增（INCR）替代，除非你能保证 Redis 和 DB 强一致——实际做不到，且一旦 Redis 故障就断号。
正确姿势是：
- 用
Db::table('order')->where('id', 'like', 'ORD%')->lock(true)->value('id')查最新号（lock(true)等价于FOR UPDATE） - 解析出数字后 +1，再用
sprintf()补零生成新号 - 立刻
save()，让事务提交释放锁 - 如果查不到记录，说明是第一条，从 1 开始（不是 0）
注意：lock(true) 在 ThinkPHP 6.0+ 才稳定支持；5.x 需手写原生 SQL 或用 query('SELECT ... FOR UPDATE')。
流水号字段要不要设成主键或唯一索引
要。而且必须是唯一索引（UNIQUE KEY `uk_sn` (`sn`)），不能只靠应用层校验。因为哪怕事务锁住了查+生环节，万一最后 save() 失败（如其他字段验证不通过），下次重试仍可能生成相同号——唯一索引能在 DB 层兜底报 SQLSTATE[23000]: Integrity constraint violation，你再捕获这个错误重试即可。
- 主键可以不用，尤其当已有自增
id字段时，sn设唯一索引更灵活 - 别忘了在模型里加验证规则：
'sn' => 'unique:order'，作为前置提醒，但不能替代 DB 约束 - 如果用了唯一索引，
INSERT ... ON DUPLICATE KEY UPDATE这类语句会失效，需按业务决定是否接受
最麻烦的其实是补零位数变化——比如从 ORD000123 到 ORD001234，解析时得用正则 /ORD(\d+)/ 而不是 substr，不然位数一变就截错。
