快递单号不能直接用UUID，因其不可读、不可追溯、无业务时间维度；应采用“前缀+定长时戳+防冲突序列”结构，如SF24052014000123，并通过Redis分片计数与前缀索引保障高并发与查询性能。
快递单号为什么不能直接用 UUID.randomUUID()
因为用户和物流系统都认“可读、可追溯、可校验”的单号，UUID 是 32 位十六进制字符串（如 550e8400-e29b-41d4-a716-446655440000），既难念又难输，还缺乏业务时间维度。真实场景中，客服查单、用户报错、系统对账，都依赖前缀+时间+序列的组合结构。
常见错误现象：UUID 直接入库后，运营反馈“单号太长记不住”“Excel 导出乱码”“扫描枪识别率低”。这不是技术问题，是设计没对齐业务输入输出习惯。
- 必须带业务前缀（如
"SF"表示顺丰，"JD"表示京东物流） - 必须含可排序的时间戳（精确到秒或毫秒，避免分布式下重复）
- 必须有防冲突的序列段（尤其多实例并发时，不能只靠时间戳）
如何用 System.currentTimeMillis() + 序列号生成 16 位数字单号
16 位纯数字单号是主流选择：兼容老系统、支持短信/语音播报、扫描枪识别率高。关键不是“怎么拼”，而是“怎么防重”。
典型错误写法：String orderNo = "SF" + System.currentTimeMillis() + new Random().nextInt(90) + 10; —— 并发下毫秒级相同 + 随机数范围太小，极易撞号。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 时间戳截取后 8 位（如
24052014表示 2024-05-20 14 点），用LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyMMddHH"))更可控 - 序列号用原子计数器（
AtomicInteger），每秒重置一次，避免越界；或用 Redis 的INCR+ 过期时间（EXPIRE key 1）实现跨 JVM 共享 - 前缀固定 2 位（如
"SF"），总长控制在 16 位：2（前缀）+ 8（时间）+ 6（序列，不足补零）→"SF24052014000123"
分布式环境下 synchronized 锁不住单号重复怎么办
单机用 synchronized 或 ReentrantLock 没问题，但微服务部署多个实例时，锁只在本 JVM 内生效，各实例同时生成 SF24052014000001 就完蛋。
性能与可靠性必须权衡：不能每次生成都走数据库唯一索引（写放大严重），也不能全靠 Redis（网络抖动导致失败）。
- 推荐方案：Redis + 时间窗口分片。Key 设为
"order_seq:SF:24052014"，过期设为 3600 秒，INCR后用GETSET做原子重置（仅当值超 999999 时） - 兜底策略：生成后插入数据库前，先查是否存在；若存在，自动递增序列再试（最多 3 次，避免死循环）
- 不建议用雪花算法（
Twitter Snowflake）：需要维护机器 ID 和数据中心 ID，中小项目运维成本高，且生成的数字过长（18–19 位）
查询单号时，LIKE 'SF240520%' 会拖慢数据库吗
会，而且很常见。如果单号字段没建前缀索引，LIKE 'SF240520%' 在百万级订单表上可能全表扫描。
错误认知：“单号是主键，查它肯定快”——但主键是完整单号，而查询常按前缀模糊匹配（比如查某天所有 SF 单）。
- MySQL 必须给
order_no字段加前缀索引：ALTER TABLE orders ADD INDEX idx_order_no_prefix (order_no(10));（覆盖前缀+时间共 10 位） - PostgreSQL 推荐用函数索引：
CREATE INDEX idx_order_no_date ON orders ((substring(order_no, 1, 10))); - 别在单号里塞分隔符（如
"SF-240520-000123"）：破环索引连续性，LIKE效率断崖下跌
最易被忽略的一点：时间戳部分必须左对齐、定长、无符号。用 yyMMddHHmm（10 位）比 yyyy-MM-dd HH:mm（16 位且含符号）更适合索引和比较。
