二手手机商城面试突击：3个高频考点速查手册

官方文档太长抓不住重点？别慌，这份二手手机商城的面试速查手册帮你把核心考点剥出来。大厂面试官不关心你背了多少八股文，他们只想知道你能不能把业务逻辑跑通，还能不能扛住高并发。

很多候选人一提到二手手机商城，脑子里全是CRUD。错得离谱。这类系统看似简单，实则踩坑无数。库存扣减、价格波动、状态机流转，哪一步错了，线上就炸了。今天这篇速查手册，直击面试中最容易被问倒的三个硬核问题。

考点梳理：面试官到底在考什么

二手手机商城的系统设计与标准电商有本质区别。标准电商卖的是全新标品，库存固定，价格稳定。二手手机是非标品，每台机器都有独特的成色、维修记录、保修状态。这就导致三个核心难点：

唯一性管理。每台二手手机都有IMEI号，必须全局唯一。面试中常问：如何防止重复录入同一台设备？如何防止用户A买走了，用户B还能看到并下单？

动态定价。二手手机价格随市场行情波动，不像iPhone 15 Pro那样有固定指导价。面试常考：价格更新频率如何控制？并发场景下价格变更导致超卖怎么解？

状态机复杂。从“待检测”到“待上架”，再到“已售出”或“已退货”，状态流转比标准电商复杂得多。尤其是退货后重新入库，IMEI号复用还是新建？这是高频追问点。

面试官真正想看的，不是你能不能写出一个能跑的商城，而是你能不能在复杂业务约束下，设计出稳定、可维护的系统架构。

标准答法：三句话搞定核心逻辑

面对“请设计一个二手手机商城系统”这类开放题，别上来就画架构图。先用三句话定调，展示你对业务的理解深度。

第一句：强调唯一性约束。 “二手手机的核心是IMEI唯一性，我在数据层会加唯一索引，业务层用Redis做分布式锁，防止同一台设备被重复上架或重复下单。”

第二句：说明动态定价策略。 “价格不是静态字段，我会引入价格版本表，每次调价生成新版本，下单时锁定当前版本价格，避免并发调价导致的价格不一致问题。”

第三句：点明状态机设计。 “设备状态采用有限状态机模型，所有状态变更必须通过状态机校验，禁止直接UPDATE数据库。退货入库时，原IMEI号标记为‘历史已用’，新入库生成新SKU，避免数据混乱。”

这三句话，直接命中面试官关注的三个核心点：数据一致性、并发安全、业务合规性。比背一百条MySQL优化技巧都管用。

代码实现：库存扣减与价格锁定的实战代码

下面这段Go代码，展示了二手手机商城中“下单扣库存+锁定价格”的核心逻辑。注意，这不是简单的UPDATE stock = stock - 1，而是带版本控制的原子操作。

package serviceimport ("context""database/sql""errors""fmt"
)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 + 异步落库，避免唯一索引成为瓶颈。价格版本表独立分库，因为读写比极高。”

记住，追问的本质是考察你的边界意识。不要试图给出“完美方案”，要展示你清楚每种方案的适用场景和代价。