返回文章列表Architecture精选电商订单号与支付单号生成方案覆盖雪花算法、号段模式、幂等、重试、补偿、退款与对账场景。2026-03-2113 min文章定位面向生产环境的实战经验沉淀，适合拿来做方案评审、复盘和升级前检查。阅读建议先看标题和列表，再回到关键段落。技术文章更适合跳读和回查的阅读节奏。适合场景云原生、后端工程、系统设计、性能优化、故障处理和团队知识沉淀。编号系统不是一个工具函数# 订单号和支付单号一开始看起来只是“生成字符串”，但一旦涉及支付、退款、对账和补偿，它就会变成系统级能力。 设计要回答的问题# 是否全局唯一 是否按业务可追踪 是否便于分库分表 是否支持重试和幂等 两类常见方案# 雪花类# 优点： 生成快 分布式友好 适合高并发 缺点： 可读性差 业务定位不直观 号段类# 优点： 便于业务侧理解 可按场景拆分 缺点： 容易形成集中式依赖 需要更严格的容量和故障设计 我的倾向# 如果是核心交易链路，我更倾向把“唯一性”和“业务可读性”分开： 内部主键用高性能全局 ID 对外展示号单独生成 这样会比试图让一个字段同时承担所有责任更稳。