CodeIgniter购物车是围绕真实电商场景构建的闭环逻辑，依赖MVC结构、会话管理、数据库联动及轻量扩展能力；默认基于Session存储，高并发下需结合设备ID+Redis临时存储、登录后合并绑定，并通过行级锁/乐观锁防超卖，确保价格、库存、规格、权限等校验准确，结算前冻结数据并事务扣减库存。
CodeIgniter 中的购物车功能不是靠“堆代码”实现的，而是围绕真实电商场景组织起来的一套闭环逻辑：从用户浏览商品、加入购物车、实时更新状态，到库存校验、价格计算、最终生成订单。它依赖框架的 MVC 结构、会话管理、数据库联动和轻量级扩展能力，而不是孤立使用某个类。
购物车数据如何持久化又不卡顿
CodeIgniter 自带的 Cart 类 默认基于 Session 存储，适合快速原型或低并发场景。但真实业务中必须解决两个问题：一是用户未登录时购物车需跨设备保留（比如扫码登录后合并），二是高并发下 Session 读写易成瓶颈。
- 登录前用唯一设备 ID（如 fingerprintjs 生成的 hash）作为临时标识，将购物车存入 Redis 或数据库，键名为
cart_:device_id - 用户登录后，把临时购物车与账号绑定，并合并重复 SKU，再清空设备缓存
- 对频繁读写的购物车表启用行级锁或乐观锁，避免“超卖”——比如更新数量前先查库存，再原子执行
UPDATE cart SET qty = ? WHERE id = ? AND qty
商品加入购物车时必须校验什么
点击“加入购物车”不是简单插入一条记录，而是一次微型事务判断。常见漏检项会导致售后纠纷或系统异常：
-
库存实时性：显示库存为 10，但秒杀场景下可能已被抢完，需在加购前查
stock > 0并锁定该 SKU 的库存行（SELECT FOR UPDATE） - 规格完整性：如“小牛电动”选车型+颜色+电池容量，缺一不可；前端传参缺失时后端应拒绝并返回明确错误码
-
价格有效性：促销价可能已过期，需比对
start_time ≤ NOW() ≤ end_time，且优先级高于原价 - 用户权限：企业客户可能有专属价，普通用户看不到；B2B 场景还需校验采购额度是否超限
购物车页面怎么做到“所见即所得”
用户看到的价格、库存、优惠信息，必须和结算页完全一致，否则信任崩塌。关键不在 UI 多炫，而在数据链路干净：
- 所有金额（小计、运费、满减、券抵扣）全部由后端计算并返回，前端只做展示，禁用 JS 本地算价
- 每个商品条目携带
version字段，当库存或价格变更时自动更新 version，前端检测到变化就触发刷新提示 - 促销规则（如“满 300 减 50”）不在前端配置，而是由规则引擎动态匹配，避免硬编码导致活动失效
- 移动端吸底结算栏固定显示总金额，但金额数字加 class="price-updating" 实时轮询接口，延迟控制在 800ms 内
订单生成前最后一道关卡
从购物车到订单，不是 copy-paste 数据，而是状态跃迁。这个环节最容易出错：
- 先冻结购物车数据（
status = 'locked'），防止用户反复提交 - 重新校验所有商品：库存是否仍充足、价格是否变动、优惠券是否还有效、地址是否合规（如偏远地区不支持某物流）
- 生成唯一订单号（推荐时间戳+微秒+随机数，避免单点冲突）
- 扣减库存用事务包裹，失败则回滚并释放购物车锁，同时推送失败原因给前端（如“红色 S 码仅剩 1 件，您选了 2 件”）
