17370845950

电商架构首要是明确模块优先级：用户认证与会话管理必须前置，SKU需独立建模并校验库存，订单创建须原子化，支付回调要验签与幂等，数据一致性是核心约束。

别急着写 Cart 类或啃 Composer 自动加载源码——新手用 PHP 搭电商架构，第一关不是功能，是「分清哪些模块必须立刻能跑，哪些可以后期补」。

用户认证和会话管理必须前置落地

没登录态，商品页都可能暴露管理员接口；没会话隔离，$_SESSION 写错作用域会导致购物车跨用户混用。PHP 默认的 session_start() 不够用，尤其在负载均衡或 Redis 集群下。

• 先用 ini_set('session.save_handler', 'redis') 切到 Redis 存储，避免文件锁阻塞
• 禁用 session.use_cookies=0 的调试模式，生产环境必须走 Cookie + HttpOnly + Secure
• password_hash() 必须用于密码存储，别碰 md5() 或 sha1() ——哪怕只是本地测试
• 登录后立即调用 session_regenerate_id(true)，防会话固定攻击

商品目录和 SKU 数据结构不能靠数组硬编码

很多新手把商品数据写成 $products = [...] 数组，结果加个规格（颜色/尺寸）就全重写逻辑。SKU 不是“商品+属性”，而是独立实体，必须有唯一 sku_code 字段。

• 数据库至少三张表：products（品牌、类目、主图）、skus（库存、价格、sku_code）、sku_attributes（关联颜色ID、尺码ID）
• 前端传来的加购请求必须校验 sku_code 是否存在且 stock > 0，不能只查 product_id
• 不要在 PHP 层拼接 SQL 查询 SKU 列表，用预处理语句绑定 $category_id 和 $status 参数

订单创建必须原子化，别信“先扣库存再写订单”

并发下单时，“查库存→扣减→写订单”三步非原子操作，会导致超卖。PHP 没有内置事务锁，得靠数据库行锁或应用层分布式锁兜底。

• 用 SELECT ... FOR UPDATE 锁住 skus 行，再执行 UPDATE skus SET stock = stock - 1 WHERE sku_code = ? AND stock >= 1
• 如果 mysqli_affected_rows() 返回 0，说明库存不足，直接失败，不生成订单
• 订单号别用 time().rand(1000,9999)，用 date('ymd').sprintf('%06d', $order_id) 确保可排序、可追溯
• 支付回调必须验签 + 幂等判断（用 out_trade_no 去查订单状态，不是直接更新）

INSERT INTO `orders` (`order_no`, `user_id`, `total_amount`, `status`) 
VALUES (?, ?, ?, 'pending') 
ON DUPLICATE KEY UPDATE `status` = VALUES(`status`);

电商不是功能堆砌，是状态流转的约束系统。SKU 库存为 0 却还能下单，比页面样式错位严重十倍。所有模块里，最不能妥协的是数据一致性——它不体现在代码行数里，藏在每一条 WHERE 条件和每一次 START TRANSACTION 里。