技术方案要落到业务语境才有意义。本文从订单号、券码、支付码等场景梳理 ID 设计的额外约束，说明如何在通用算法之上叠加业务编码规则。

要解决什么问题

纯技术 ID 方案未考虑业务可读性、防猜测、对账需要和渠道编码。订单号可能要带日期和业务线便于客服查询；优惠券要短且难爆破；一码付二维码需固定长度便于扫码设备解析。若直接暴露 DB 自增 ID，还存在竞对估算销量和恶意遍历的风险。

核心原理

业务 ID 常在 Snowflake/号段之上叠加：时间分段（按日分库分表）、业务前缀（区分订单类型与渠道）、随机盐（防遍历）、校验位（防手工输错）。订单号可用”日期+序列+分片位”组合；短码用 Base62 压缩并剔除易混淆字符；支付码绑定用户/session 并设 TTL，消费后立即失效。

方案权衡

可读性 vs 安全性：纯递增易猜测，需加随机段或哈希；长度 vs 容量：短码用户友好但熵空间小，要监控使用率；中心化发号易管控但增加依赖，本地生成低延迟但 workerId 治理复杂。对外 ID 与对内 surrogate key 分离是常见折中：内部仍用 bigint，对外展示编码过的业务号。

落地要点

订单号设计预留扩容位和版本号；券码生成加速率限制、黑名单与批量作废；支付码设置 TTL 与一次性消费标记；所有生成路径写审计日志便于对账。与风控联动：同一用户短时间大量领券触发规则。压测短码空间在促销峰值下是否足够，并准备扩容字符集或加长策略。

常见误区

误区：直接暴露数据库自增 ID 给外部 API；短码空间不足未监控使用率；不同业务共用同一规则导致耦合和解析歧义；忽略 ID 在日志、客服、纸质单据上的可读性与口述需求。另一个坑是校验位算法过弱，无法防简单篡改。