简介：本资源为基于PHP+MySQL实现的服装商城购物系统课程设计项目，编号100013121，面向计算机相关专业学生、Web开发初学者及需要完成课程设计或毕业设计的开发者。系统涵盖用户注册登录、男装女装及推荐商品浏览、购物车增删改查、后台订单与库存管理等模块，并涉及数据库表结构设计、SQL查询优化、预编译防注入、响应式布局等关键知识点，可作为学习PHP动态网站开发与MySQL数据库应用的完整实践案例。压缩包共260个文件，包含10个PHP核心页面、1个SQL建库脚本、9个HTML与9个CSS样式文件、21个JavaScript脚本，以及大量jpg、png、gif图片素材和字体文件，另附项目说明书文档，整体约5.54MB，目录结构清晰，便于按模块查阅与二次开发。目前已有393人学习下载，适合需要完整项目源码、数据库脚本与开发文档的读者参考借鉴。
1. 服装商城购物系统：从建表到下单，PHP+MySQL 这套组合还能怎么打
服装商城购物系统这个题目，几乎每个 PHP 从业者都在简历或接单列表里见过。它不新鲜，但每年仍有大量中小商家、独立站卖家、校园项目在用它跑真实业务——因为 PHP+MySQL 的部署成本低到一台 2 核 4G 的机器就能撑起日均几千单，而服装这个品类天然适合「多 SKU、多尺码、多颜色」的库存模型，正好把关系型数据库的强项压满。问题在于，网上流传的所谓「PHP 服装商城源码」大多是半成品：商品表没有规格维度，下单不锁库存，支付回调不验签，上线三天就被薅穿。这篇笔记不讲概念，只讲一套能真正跑起来的服装商城购物系统该怎么设计表、怎么写核心链路、怎么避开那些让项目翻车的坑。适合手里有 PHP 基础、想接服装类私活或做独立站，但被库存和订单一致性折磨过的开发者。
2. 服装商城的表结构：为什么通用电商模板一上来就错
服装商城和普通电商最大的区别在 SKU 维度。一件 T 恤有 S/M/L/XL 四个尺码，每个尺码又有黑/白/灰三种颜色，组合起来就是 12 个可售单元。通用电商模板通常只建goods和goods_attr两张表，把规格塞进一个 JSON 字段，结果就是库存扣减时无法行级锁定，超卖成了必然。我一般会拆成四张表：product（SPU 层）、product_sku（SKU 层，带独立库存和价格）、attribute（属性字典）、sku_attribute（SKU 与属性的映射）。这样每个 SKU 有独立主键，扣库存时UPDATE ... WHERE sku_id = ? AND stock >= ?就能靠 InnoDB 行锁保证原子性。
2.1 四张核心表的字段设计与索引取舍
先看 SPU 表，它只存商品公共信息，不存任何规格相关字段：
CREATE TABLE `product` ( `id` int unsigned NOT NULL AUTO_INCREMENT, `title` varchar(120) NOT NULL COMMENT '商品标题', `category_id` int unsigned NOT NULL DEFAULT 0, `main_image` varchar(255) NOT NULL DEFAULT '', `detail` text COMMENT '详情HTML', `status` tinyint NOT NULL DEFAULT 1 COMMENT '1上架 0下架', `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_category_status` (`category_id`,`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;SKU 表是整套系统的命脉，库存、价格、销量都挂在这里：
CREATE TABLE `product_sku` ( `id` int unsigned NOT NULL AUTO_INCREMENT, `product_id` int unsigned NOT NULL, `sku_code` varchar(64) NOT NULL COMMENT '商家编码', `price` decimal(10,2) NOT NULL DEFAULT 0.00, `stock` int NOT NULL DEFAULT 0, `sales` int NOT NULL DEFAULT 0, `spec_json` json DEFAULT NULL COMMENT '冗余规格快照，便于展示', PRIMARY KEY (`id`), UNIQUE KEY `uk_sku_code` (`sku_code`), KEY `idx_product` (`product_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;属性字典和映射表负责把「颜色:黑」这种可读文本和 SKU 关联起来：
CREATE TABLE `attribute` ( `id` int unsigned NOT NULL AUTO_INCREMENT, `name` varchar(32) NOT NULL COMMENT '如 颜色/尺码', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `sku_attribute` ( `sku_id` int unsigned NOT NULL, `attr_id` int unsigned NOT NULL, `value` varchar(32) NOT NULL COMMENT '如 黑色/XL', PRIMARY KEY (`sku_id`,`attr_id`), KEY `idx_attr_value` (`attr_id`,`value`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;参数说明：spec_json是冗余字段，下单时直接把它快照进订单表，避免商品改规格后历史订单显示错乱；sku_code加唯一索引，防止运营重复导入；stock用int而非unsigned，因为退货回补时可能出现临时负数，靠业务层拦截比数据库报错更可控。索引上，idx_category_status支撑前台分类列表，idx_product支撑商品详情页拉取所有 SKU，这两个查询是服装商城最高频的读操作，必须走覆盖索引。
2.2 用一条 SQL 拉出商品详情页的全部规格
前台详情页需要一次性拿到 SPU 信息、所有 SKU、以及每个 SKU 的属性组合。常见做法是三次查询在 PHP 里拼装，但服装商城 SKU 多，三次查询在并发下容易放大延迟。我一般用两条 SQL 解决：先查 SPU，再用IN批量查 SKU 和属性。
<?php // $pdo 为已建立的 PDO 连接，字符集 utf8mb4 $productId = (int)$_GET['id']; $stmt = $pdo->prepare("SELECT id,title,main_image,detail FROM product WHERE id=? AND status=1"); $stmt->execute([$productId]); $product = $stmt->fetch(PDO::FETCH_ASSOC); if (!$product) { exit('商品不存在或已下架'); } $stmt = $pdo->prepare("SELECT id,price,stock,spec_json FROM product_sku WHERE product_id=? ORDER BY id"); $stmt->execute([$productId]); $skus = $stmt->fetchAll(PDO::FETCH_ASSOC); $skuIds = array_column($skus, 'id'); if ($skuIds) { $in = implode(',', array_fill(0, count($skuIds), '?')); $stmt = $pdo->prepare("SELECT sku_id,attr_id,value FROM sku_attribute WHERE sku_id IN ($in)"); $stmt->execute($skuIds); $attrs = []; foreach ($stmt->fetchAll(PDO::FETCH_ASSOC) as $row) { $attrs[$row['sku_id']][] = $row; } foreach ($skus as &$sku) { $sku['attrs'] = $attrs[$sku['id']] ?? []; } unset($sku); } // 输出给模板：$product 与 $skus逻辑说明：array_fill生成占位符避免 SQL 注入，IN查询把 N 次属性查询压成 1 次。参数上，ORDER BY id保证 SKU 展示顺序稳定，运营调整时不会跳位。失败时先看$skus是否为空——如果为空但 SPU 存在，说明 SKU 没导入或product_id对不上，这是新手最常踩的坑，别急着怀疑 PDO 配置。
3. 下单链路：库存扣减、订单落库与支付回调怎么串
下单是服装商城最容易出事故的地方。秒杀场景下，100 件库存被 300 个请求同时读到，如果先SELECT stock再UPDATE stock = 原值-1，必然超卖。正确做法是把判断和扣减合并成一条原子 SQL，靠 InnoDB 行锁串行化同一 SKU 的并发扣减。订单落库要和扣库存放在同一个事务里，支付回调则必须做幂等，否则用户重复点击或支付平台重试就会生成多笔已支付订单。
3.1 用事务 + 条件更新锁住库存
下面这段是下单核心，省略了购物车校验和地址校验，聚焦库存与订单：
<?php $pdo->beginTransaction(); try { $skuId = (int)$_POST['sku_id']; $qty = (int)$_POST['qty']; if ($qty < 1 || $qty > 99) { throw new Exception('数量非法'); } // 原子扣减：stock >= qty 才更新，返回受影响行数 $stmt = $pdo->prepare("UPDATE product_sku SET stock = stock - ?, sales = sales + ? WHERE id = ? AND stock >= ?"); $stmt->execute([$qty, $qty, $skuId, $qty]); if ($stmt->rowCount() === 0) { throw new Exception('库存不足'); } // 读取扣减后的价格，防止下单瞬间改价 $stmt = $pdo->prepare("SELECT price FROM product_sku WHERE id = ?"); $stmt->execute([$skuId]); $price = $stmt->fetchColumn(); $orderNo = date('YmdHis') . mt_rand(1000, 9999); $stmt = $pdo->prepare("INSERT INTO orders (order_no, user_id, sku_id, qty, amount, status, created_at) VALUES (?,?,?,?,?,0,NOW())"); $stmt->execute([$orderNo, $userId, $skuId, $qty, $price * $qty]); $pdo->commit(); echo json_encode(['code' => 0, 'order_no' => $orderNo]); } catch (Exception $e) { $pdo->rollBack(); echo json_encode(['code' => 1, 'msg' => $e->getMessage()]); }参数说明：stock >= ?是防超卖的关键条件，rowCount()为 0 直接抛异常回滚；sales同步累加，方便按销量排序；status=0表示待支付。注意price必须在扣减后重新查，不能信任前端传值，否则改价接口一上线就被刷。事务隔离级别用默认的 REPEATABLE READ 即可，UPDATE本身会加排他锁，不需要额外SELECT ... FOR UPDATE，后者反而增加死锁概率。
3.2 支付回调的幂等处理与订单状态机
支付平台回调可能重复推送，必须用订单号做幂等。常见做法是给orders表加pay_no唯一索引，回调时先UPDATE ... WHERE order_no=? AND status=0，受影响行数为 0 说明已处理过，直接返回成功。
<?php // 支付回调入口，$raw 为回调原始数据，$sign 为平台签名 $orderNo = $raw['out_trade_no']; $payNo = $raw['transaction_id']; $pdo->beginTransaction(); try { $stmt = $pdo->prepare("UPDATE orders SET status=1, pay_no=?, paid_at=NOW() WHERE order_no=? AND status=0"); $stmt->execute([$payNo, $orderNo]); if ($stmt->rowCount() === 0) { // 已处理或订单不存在，幂等返回 $pdo->commit(); exit('success'); } // 可在此触发发货队列、短信通知 $pdo->commit(); exit('success'); } catch (Exception $e) { $pdo->rollBack(); exit('fail'); }逻辑说明：status=0作为状态机守卫，只有待支付订单能被改成已支付；pay_no唯一索引兜底，即使并发回调同时进来，数据库也会拒绝第二条。参数上，paid_at用于对账，exit('success')的字符串必须和支付平台约定一致，否则平台会持续重推。失败时先查orders表该订单的status，如果已是 1 却还在重推，说明平台没收到成功响应，检查exit前是否有输出缓冲或 BOM 头。
4. 避坑与排查：服装商城上线后最常炸的五个点
这套系统我在不同项目里部署过多次，下面五个问题几乎每次都会遇到，按「现象 → 原因 → 解决」记录，省得你半夜被电话叫醒。
现象一：商品详情页 SKU 价格全部显示 0。原因通常是product_sku导入时price字段没给默认值或 CSV 列错位，MySQL 在非严格模式下静默写入 0。解决：把sql_mode设为STRICT_TRANS_TABLES，导入前用SELECT COUNT(*) FROM product_sku WHERE price=0排查，运营后台加价格必填校验。
现象二：下单提示库存不足，但后台看库存还有。原因是stock字段被设成了unsigned，退货回补时stock = stock - 1在库存为 0 时触发数据库报错，事务回滚导致后续正常扣减也失败。解决：stock用有符号int，业务层在扣减前判断，退货回补走独立逻辑并记录流水。
现象三：支付成功但订单还是待支付。回调地址被 Nginx 重写规则拦截，或者 PHP 入口有session_start()导致响应前输出警告，平台判定失败。解决：回调入口独立文件，关闭 session，exit('success')前不要有任何 echo；用tail -f看 Nginx access log 确认回调是否到达。
现象四：并发下单出现负库存。说明扣减 SQL 没带stock >= ?条件，或者用了SELECT再UPDATE的两步写法。解决：统一改成条件更新，并在压测环境用ab -n 500 -c 50模拟并发验证stock最终值。
现象五：订单列表分页越翻越慢。LIMIT 100000, 20在订单量过百万后扫描大量行。解决：改用游标分页，WHERE id < 上一页最后id ORDER BY id DESC LIMIT 20，并给user_id加索引支撑按用户查询。
提示：上线前务必把
orders表的order_no和pay_no都加上唯一索引，这两个索引是数据一致性的最后一道防线，比任何业务代码都可靠。
5. 把服装商城跑得更稳：两个我压箱底的技巧
第一个技巧是给 SKU 库存加一层 Redis 预扣。MySQL 行锁在几百并发下没问题，但服装商城做限时活动时，同一 SKU 可能瞬间涌入几千请求，全部打到数据库会让连接池耗尽。我一般在下单前用 Redis 的DECRBY做预扣，扣到负数直接拒绝，扣成功再走 MySQL 事务，事务失败时INCRBY回补。这样数据库只处理真正能下单的请求，吞吐量能提升一个数量级。注意 Redis 预扣和 MySQL 扣减之间要加一个短过期时间的标记，防止回补遗漏。
第二个技巧是订单表按月分表。服装商城订单增长快，单表过千万后即使有索引，统计报表也会拖慢主库。我习惯用orders_202601这种命名，PHP 层根据created_at路由，查询时按月份 UNION。分表后对账脚本要同步改，否则财务月底会发现数据对不上。这两个技巧都不复杂，但需要在上线前就规划好，事后补的代价是停机迁移。
我自己踩过最狠的一次，是活动前忘了给 Redis 预扣加回补逻辑，结果 MySQL 事务失败后库存凭空少了两百件，运营对着后台骂了半小时。从那以后，任何涉及库存的代码我都先写回补再写扣减，这个习惯救了我很多次。希望帮到你。
本文还有配套的精品资源，点击获取
