购物车用arraylist而非hashmap，因需保留价格、规格等上下文；库存校验先用内存map模拟再替换为dao；订单状态用enum+switch限制合法迁移路径。
Java初学者做购物车与订单管理系统，别一上来就画UML、搭Spring Boot、连MySQL——90%的人卡在「对象关系没理清」和「控制流写成面条代码」上。
购物车用 ArrayList 还是 HashMap？看要不要支持重复添加同款商品
如果用户可以多次添加同一商品（比如加2个iPhone、再加1个），ArrayList<cartitem></cartitem> 更直观：每加一次就新增一个对象，数量字段存在 CartItem 里；HashMap<string integer></string>（用商品ID作key）虽省内存，但丢失了价格、规格等上下文，后续扩展属性（如选中的颜色、尺寸）立刻崩。
实操建议：
-
CartItem类至少包含：productId、productName、price、quantity、skuId - 购物车类用
ArrayList<cartitem></cartitem>存储，提供add(CartItem item)和updateQuantity(String productId, int newQty) - 避免在
add()里自动合并——初学者容易漏掉价格比对，导致“同ID不同价”被覆盖
Order 创建时必须校验库存，但别在 service 层直接查数据库
初学者常把「下单扣库存」写成：先查DB余额 → 判断够不够 → 再执行 update。这在多线程下必然超卖。但你现在还没学事务、锁、乐观更新，硬上数据库会越写越乱。
立即学习“Java免费学习笔记（深入）”；
OdnShop(原企站帮微商城系统，更名为OdnShop),基于ASP.NET 4.0+Access开发的轻量级微信商城系统，前台简洁美观，后台容易操作。系统容易部署，空间成本低，大部分的几百块一年的虚拟主机均可支持（具体请咨询空间商），适合要求不高，预算不多的小商店，小企业初次尝试微信线上销售产品，目前基本的核心功能，包括微信登陆/支付，产品管理，购物车与订单管理，分享获取积分，积分礼品兑换功能
实操建议：
- 先用内存模拟库存：
Map<string integer> inventory = new HashMap() {...}</string> - 在
createOrder()方法开头，遍历购物车所有CartItem，调用inventory.getOrDefault(productId, 0) >= item.getQuantity() - 校验通过后，才执行
inventory.put(productId, remaining - item.getQuantity()) - 这个模型跑通逻辑后，再把
inventory替换成 DAO 调用——你会立刻意识到哪步该加事务、哪步要加锁
订单状态流转不能靠 if-else 堆，用 enum + 状态机雏形控制边界
看到「待支付→已支付→已发货→已完成」就写四个 if，后面加个「已取消」就得改三处，加个「退款中」又全重来。初学者最易在此处写出无法维护的条件分支。
实操建议：
- 定义
enum OrderStatus { PENDING, PAID, SHIPPED, COMPLETED, CANCELLED } - 在
Order类里加changeStatus(OrderStatus to)方法，内部用 switch 列出允许的迁移路径：
public boolean changeStatus(OrderStatus to) {
switch (this.status) {
case PENDING:
if (to == OrderStatus.PAID || to == OrderStatus.CANCELLED) {
this.status = to;
return true;
}
break;
case PAID:
if (to == OrderStatus.SHIPPED || to == OrderStatus.CANCELLED) {
this.status = to;
return true;
}
break;
// ... 其他状态
}
return false; // 禁止非法跳转
}这样哪怕不引入 Spring State Machine，也把状态约束收口到一处。
真正卡住初学者的，从来不是语法，而是「什么时候该封装一个类」「哪个方法该返回布尔值还是抛异常」「为什么要把库存检查从 Controller 拉到 Service」——这些判断都藏在你第一次手动写完 cart.add(item) 然后发现数量没变的那几分钟里。
