积分商城兑换必须在Model层事务中完成查余额、查库存、扣积分、减库存、写订单五步，用SELECT FOR UPDATE加锁，订单号幂等处理，积分变动走统一记账模型并记录流水。
兑换前必须校验用户积分余额和商品库存
直接扣减积分却没检查余额，是积分商城最常引发投诉的问题。CodeIgniter 的 Model 层必须在事务中完成「查余额 → 查库存 → 扣积分 → 减库存 → 写订单」五步，缺一不可。
常见错误是把校验逻辑放在控制器里，结果绕过模型直接调用 $this->db->update()，导致并发时超兑。正确做法是在 Points_m.php 模型中封装 can_exchange($user_id, $goods_id, $quantity) 方法，内部用 SELECT ... FOR UPDATE 加行锁（需 InnoDB）。
- 使用
$this->db->trans_start()包裹整个兑换流程，失败时自动回滚 - 库存字段建议用
INT UNSIGNED，避免负数；积分字段同理，且更新时用SET points = points - ?而非先查后算，防竞态 - 不要依赖前端传来的积分值做扣减依据，一切以数据库当前值为准
兑换记录必须绑定唯一订单号并支持幂等写入
用户连点“兑换”按钮，或网络重发请求，会导致重复下单。CodeIgniter 本身不提供分布式 ID 或幂等键，得自己处理。
推荐在控制器中生成带时间戳 + 用户ID + 随机数的订单号，例如 EX_20240520_12345_7a9f，然后在插入兑换记录前，用 INSERT IGNORE INTO exchange_log (...) VALUES (...) 或先 SELECT COUNT(*) WHERE order_no = ? 判断是否存在。
- 订单号字段必须加
UNIQUE KEY约束，否则INSERT IGNORE无效 - 不要用 PHP
uniqid()单独生成，它不保证全局唯一，高并发下易冲突 - 日志表要包含
status字段（如 pending/success/failed），方便对账和人工干预
虚拟币（积分）变动必须走统一记账模型，禁止直改用户表
很多项目图省事，在兑换成功后直接 $this->db->set('points', 'points-100', FALSE)->where('id', $uid)->update('users')，这会让积分流水无法追溯，审计和排查问题时抓瞎。
必须建立独立的 points_log 表，字段至少含 user_id、change_amount（可正可负）、balance_after、type（如 'exchange'/'recharge'）、ref_id（关联订单号或充值单号）、created_at。
-
balance_after要在应用层计算（查当前余额 + change_amount），不能靠触发器，否则事务中难控制 - 每次积分变动，都应调用统一方法
$this->points_m->record_change($user_id, -100, 'exchange', $order_no) - 该方法内部必须和兑换主逻辑共用同一个事务，否则日志写成功但兑换失败，数据就错乱了
前端提交时需携带防重放 token，后端校验有效期
单纯靠按钮置灰或 JS 禁用，挡不住 Postman 或脚本重放。CodeIgniter 自带的 CSRF 保护只防跨站，不防同一用户重复提交。
可在兑换表单渲染时，通过 $this->security->get_csrf_hash() 获取一个临时 token，并存入 Redis，设置 2 分钟过期，key 形如 exchange_token:uid_12345:hash_abc。提交时控制器先校验该 token 是否存在且未被使用过，验证通过后立即 DEL。
- 别把 token 存 session，session 在负载均衡下可能不同步；Redis 是必须的
- token 过期时间不宜过长（超过 5 分钟易被截获重放），也不宜过短（影响正常操作）
- 校验失败时返回明确错误，如
"invalid_or_expired_token"，不要暴露是否已使用
实际跑通这套逻辑，最难的不是写代码，而是让所有积分变动入口（充值、抽奖、兑换、退款）全部收敛到同一个记账模型，并确保每个入口都严格走事务+幂等+日志。漏掉任意一个，后续对账就会变成灾难。
