Session存购物车价格不准因商品对象被共享引用，需存不可变数据结构或深拷贝；BigDecimal计算须用字符串构造、统一scale和舍入模式；登录后应合并Session购物车至数据库并清空Session；高并发下需加锁或迁至数据库行锁。
Session 存储商品对象时为什么价格总对不上？
Java Web 里用 HttpSession 存购物车，最常见问题是「加进 Session 的商品价格和下单时差了一截」——不是因为 Session 失效，而是商品对象被共享引用了。比如你从数据库查出一个 Product 实例，直接塞进 session.setAttribute("cart", cart)，后续该商品在后台调价或库存变更，Cart 里的对象也会跟着变（尤其用了 Hibernate/JPA 的懒加载代理或同一级缓存）。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 往 Session 存的必须是**不可变数据结构**，比如用
Map<String, BigDecimal>存skuId → price，而不是存整个Product实体 - 如果真要存对象，务必做深拷贝：
new CartItem(item.getSkuId(), item.getName(), item.getPrice().setScale(2, RoundingMode.HALF_UP)) - 避免在 Cart 对象里保留对 DAO 或 Service 的引用，否则序列化时可能报
NotSerializableException
计算总价时 BigDecimal 加法为什么越算越不准？
购物车总价用 float 或 double 算，19.99 + 0.01 就可能变成 19.999999999999996。但就算用了 BigDecimal，也常踩两个坑：构造函数传 double、没统一 scale 和 rounding mode。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 永远用字符串构造：
new BigDecimal("19.99")，别用new BigDecimal(19.99) - 所有加减运算前先统一 scale：
price.setScale(2, RoundingMode.HALF_UP) - 总价计算别用循环累加原始值，改用流式归约：
items.stream().map(CartItem::getTotal).reduce(BigDecimal.ZERO, BigDecimal::add).setScale(2, RoundingMode.HALF_UP)
用户未登录时把购物车存在 Session，登录后怎么合并到数据库？
用户先逛着加了 3 个商品到 HttpSession，然后登录，这时得把 Session 里的数据迁到用户专属的数据库表（如 t_cart_item），同时处理冲突：比如 Session 里有 SKU A（数量 2），数据库里也有 SKU A（数量 1），最终应是 3 还是覆盖？
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 登录成功后立刻读取
session.getAttribute("temp_cart")，然后清空该 key，防止重复合并 - 合并逻辑用数据库的
INSERT ... ON DUPLICATE KEY UPDATE quantity = quantity + VALUES(quantity)（MySQL）或MERGE（PostgreSQL），别先查再更新 - 合并完记得删掉 Session 中的临时 cart，否则下次刷新页面又触发一遍
- 前端加个提示：“已为您合并了 X 件之前添加的商品”
高并发下多个请求同时修改同一个 Session 购物车会出问题吗？
会。Servlet 容器（如 Tomcat）对单个 HttpSession 是线程安全的，但「线程安全」只保证 setAttribute/getAttribute 不抛异常，并不保证业务逻辑原子性。比如两个请求同时执行「获取当前数量 → +1 → 存回」，大概率少加一次。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 别依赖 Session 自带的同步机制来做计数类操作
- 对 Cart 的增删改操作，加
synchronized (session.getId().intern())锁住当前 session ID 字符串（注意 intern() 避免锁对象过多） - 更稳妥的做法是：用户登录后，强制把购物车落库，后续所有操作走数据库行锁（
SELECT ... FOR UPDATE） - Session 存购物车只适合低并发、临时态场景；生产环境建议登录即迁移，Session 仅作跳转过渡
真正麻烦的不是怎么存，而是什么时候不该存——Session 的生命周期、集群下的复制开销、GC 压力，都比写几行合并逻辑更值得提前想清楚。
