核心是数据存储位置与同步时机：未登录用户用session，已登录用户必须用redis（优先）或数据库，session仅作临时兜底；因session生命周期短、无持久性、不支持跨服务共享，易导致购物车丢失、多标签错乱、登录前后不合并等问题。
购物车功能在 ThinkPHP 商城中，核心不是“怎么写”，而是“数据存在哪”和“什么时候同步”。直接结论：未登录用户用 session，已登录用户必须存 Redis 或数据库，session 只能当临时兜底，不能作为唯一存储。
为什么不能只靠 session 存登录用户的购物车
Session 本质是服务端临时内存（或文件），生命周期短、无持久性、不支持跨服务共享。一旦 PHP 进程重启、session 文件过期、负载均衡分发到不同机器，购物车就丢了。线上商城出现“刚加完商品刷新就没了”，90% 是这个原因。
常见错误现象：$_SESSION['cart'] 在本地开发一切正常，上线后频繁清空；多标签页操作时数量错乱；用户登录前后购物车不合并。
- ThinkPHP 默认的
session驱动（file）不适合高并发读写 -
session_id和用户身份没强绑定，登录态变更后无法自动迁移数据 - 无法做原子性操作（比如库存扣减 + 购物车更新需事务保障）
登录用户该用 Redis 还是数据库存购物车
优先选 Redis，尤其是用 HASH 结构（HSET cart:uid:123 product_id_456 2）。它快、支持过期、天然适合“用户维度+商品维度”的键值映射。
数据库（如 cart 表）适合需要强一致性审计的场景，比如要查“某用户历史所有加购行为”，但日常增删改查比 Redis 慢 3–5 倍，且容易锁表。
- Redis 方案：用
$redis->hSet('cart:uid:'.$uid, $product_id, $num)，配合EXPIRE设置 7 天过期 - 数据库方案：必须加唯一索引
UNIQUE KEY `uid_pid` (`user_id`, `product_id`)，否则重复添加会报错 - 两者都得配库存校验——加购前查
products表的stock字段，不能只信 Redis 里的值
未登录用户购物车怎么平滑迁移到登录态
关键不是“存哪里”，而是“怎么识别同一个用户”。浏览器 Cookie 中存一个长期有效的 guest_id（UUID v4），未登录时所有操作都基于它；登录成功后，把 cart:guest:xxx 里的商品批量写入 cart:uid:123，再删掉 guest 键。
容易踩的坑：session_destroy() 后没清空前端 Cookie，导致下次访问又生成新 guest_id；合并时没去重，同一商品被加了两次。
- 生成 guest_id：用
bin2hex(random_bytes(16))，别用uniqid() - 合并逻辑必须在登录成功后的第一个接口里完成，不能等用户进购物车页面才触发
- 合并完立刻调用
$redis->del('cart:guest:'.$guest_id)，避免重复合并
ThinkPHP 6 的实际写法要注意什么
别直接在控制器里写 $_SESSION 或裸连 Redis。TP6 自带 cache 门面，统一走配置驱动：
在 config/cache.php 里启用 redis 驱动，然后用 Cache::store('redis')->hSet(...)。这样后续切到其他缓存（比如阿里云 Tair）只需改配置，不用动业务代码。
- 不要在模型里硬编码
$redis = new Redis()，破坏依赖注入原则 - 加购接口必须校验
$request->param('product_id')和$request->param('spec_id')是否合法，防止 SQL 注入或越权操作 - 前端传数量时，用
intval($num)强转，别信$_POST['num']的原始值——有人会手动改 form 提交 999999
真正难的不是写几行 hSet，而是库存扣减、优惠券核销、规格组合这三件事必须和购物车更新在同一个事务里完成。这里一漏，就会出现“显示有货却下单失败”的用户投诉。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
