二手手机商城面试突击：3个高频考点速查手册
官方文档太长抓不住重点？别慌，这份二手手机商城的面试速查手册帮你把核心考点剥出来。大厂面试官不关心你背了多少八股文，他们只想知道你能不能把业务逻辑跑通，还能不能扛住高并发。
很多候选人一提到二手手机商城，脑子里全是CRUD。错得离谱。这类系统看似简单，实则踩坑无数。库存扣减、价格波动、状态机流转，哪一步错了，线上就炸了。今天这篇速查手册，直击面试中最容易被问倒的三个硬核问题。
考点梳理：面试官到底在考什么
二手手机商城的系统设计与标准电商有本质区别。标准电商卖的是全新标品，库存固定，价格稳定。二手手机是非标品，每台机器都有独特的成色、维修记录、保修状态。这就导致三个核心难点：
唯一性管理。每台二手手机都有IMEI号，必须全局唯一。面试中常问：如何防止重复录入同一台设备？如何防止用户A买走了，用户B还能看到并下单？
动态定价。二手手机价格随市场行情波动，不像iPhone 15 Pro那样有固定指导价。面试常考：价格更新频率如何控制？并发场景下价格变更导致超卖怎么解？
状态机复杂。从“待检测”到“待上架”，再到“已售出”或“已退货”，状态流转比标准电商复杂得多。尤其是退货后重新入库，IMEI号复用还是新建？这是高频追问点。
面试官真正想看的，不是你能不能写出一个能跑的商城，而是你能不能在复杂业务约束下，设计出稳定、可维护的系统架构。
标准答法：三句话搞定核心逻辑
面对“请设计一个二手手机商城系统”这类开放题，别上来就画架构图。先用三句话定调，展示你对业务的理解深度。
第一句：强调唯一性约束。
“二手手机的核心是IMEI唯一性，我在数据层会加唯一索引，业务层用Redis做分布式锁，防止同一台设备被重复上架或重复下单。”
第二句：说明动态定价策略。
“价格不是静态字段，我会引入价格版本表，每次调价生成新版本，下单时锁定当前版本价格，避免并发调价导致的价格不一致问题。”
第三句：点明状态机设计。
“设备状态采用有限状态机模型，所有状态变更必须通过状态机校验，禁止直接UPDATE数据库。退货入库时，原IMEI号标记为‘历史已用’，新入库生成新SKU，避免数据混乱。”
这三句话，直接命中面试官关注的三个核心点：数据一致性、并发安全、业务合规性。比背一百条MySQL优化技巧都管用。
代码实现：库存扣减与价格锁定的实战代码
下面这段Go代码，展示了二手手机商城中“下单扣库存+锁定价格”的核心逻辑。注意，这不是简单的UPDATE stock = stock - 1，而是带版本控制的原子操作。
package serviceimport (contextdatabase/sqlerrorsfmt
)var (ErrInventoryShort = errors.New(inventory short)ErrPriceChanged = errors.New(price changed)
)type OrderService struct {db *sql.DB
}// CreateOrder 创建订单，扣减库存并锁定价格
func (s *OrderService) CreateOrder(ctx context.Context, deviceID int64, userID int64) (int64, error) {tx, err := s.db.BeginTx(ctx, nil)if err != nil {return 0, err}defer tx.Rollback()// 1. 查询当前设备状态和价格版本var status intvar priceVersion int64var currentPrice float64err = tx.QueryRowContext(ctx,SELECT status, price_version, price FROM devices WHERE id = ? FOR UPDATE,deviceID,).Scan(status, priceVersion, currentPrice)if err != nil {return 0, err}// 2. 校验设备状态：只有“待上架”状态才能下单if status != 1 { // 1 = 待上架return 0, fmt.Errorf(device status invalid: %d, status)}// 3. 原子扣减库存，带版本校验result, err := tx.ExecContext(ctx,`UPDATE devices SET stock = stock - 1, status = 2, updated_at = NOW() WHERE id = ? AND stock 0 AND price_version = ?`,deviceID,priceVersion,)if err != nil {return 0, err}rowsAffected, _ := result.RowsAffected()if rowsAffected == 0 {return 0, ErrInventoryShort}// 4. 创建订单，锁定当前价格版本var orderID int64err = tx.QueryRowContext(ctx,`INSERT INTO orders (user_id, device_id, price, price_version, created_at)VALUES (?, ?, ?, ?, NOW()) RETURNING id`,userID,deviceID,currentPrice,priceVersion,).Scan(orderID)if err != nil {return 0, err}// 5. 提交事务if err = tx.Commit(); err != nil {return 0, err}return orderID, nil
}逐行讲解关键点：FOR UPDATE：行级锁，防止并发查询时读到过期数据。二手手机库存通常不大，行锁性能完全可接受。
price_version = ?：乐观锁核心。如果价格在这期间被运营后台修改，版本不匹配，UPDATE失败，返回ErrInventoryShort。前端捕获此错误，提示用户“价格已变动，请刷新重试”。
status = 2：状态机流转，从“待上架”变为“已下单”。禁止跳过状态，防止出现“未检测就售出”的事故。
RETURNING id：PostgreSQL语法，直接返回新订单ID，避免二次查询。MySQL需用LAST_INSERT_ID()。这段代码的价值，在于它把“库存扣减”和“价格锁定”放在同一个事务里，用版本控制解决了并发调价问题。面试时写出这段代码，基本能拿到80分以上的印象分。
追问与延伸：面试官的连环炮怎么接
基础答完，面试官一定会追问。以下是三个高频追问及应答策略。
追问一：如果价格更新非常频繁，比如每分钟变一次，乐观锁会不会导致大量重试？
应答：“二手手机价格调整通常由运营后台触发，频率不高。如果是高频动态定价场景，我会把价格计算逻辑前置到缓存层，用Redis的WATCH命令实现CAS，或者引入消息队列异步同步价格到数据库。但绝大多数二手商城，价格调整是低频事件，乐观锁完全够用。”
追问二：IMEI号唯一性如何保证？如果用户退货，IMEI号能复用吗？
应答：“数据库层用唯一索引兜底，业务层在录入前查Redis缓存的IMEI集合。退货后，原IMEI号不删除，而是标记为‘历史已用’状态。新入库的同型号设备，即使IMEI相同，也会生成新的SKU ID，绑定新的IMEI记录。这样做是为了保留完整的交易追溯链，符合RFC 8259中关于JSON数据完整性的原则，也满足二手交易平台的合规审计要求。”
追问三：如果系统要支撑百万级SKU，单机数据库扛不住，怎么扩展？
应答：“二手手机SKU量通常不会达到百万级，但如果是全品类二手3C平台，可以考虑分库分表。分片键选device_id，因为查询和更新都围绕设备ID。IMEI查询走Redis + 异步落库，避免唯一索引成为瓶颈。价格版本表独立分库，因为读写比极高。”
记住，追问的本质是考察你的边界意识。不要试图给出“完美方案”，要展示你清楚每种方案的适用场景和代价。
记忆口诀：三句话锁死核心考点
面试前花10分钟背下这个口诀，比刷十道LeetCode管用：
IMEI唯一行锁锁，价格版本乐观控，状态机转不跳级。
拆解一下：IMEI唯一行锁锁：数据层唯一索引，业务层FOR UPDATE行锁，双重保障。
价格版本乐观控：每次调价生成新版本，下单时校验版本，防并发调价。
状态机转不跳级：状态变更必须走状态机，禁止直接改数据库，退货IMEI不复用。这三句话，覆盖了二手手机商城90%的面试考点。剩下的10%，靠你在面试中临场发挥，结合具体业务场景调整即可。
你公司项目里是怎么处理二手设备唯一性管理的？是用IMEI还是用内部SN码？退货后设备数据是物理删除还是逻辑归档？欢迎评论聊聊，咱们互相参考下真实业务中的坑怎么填的。
