做电商项目这些年，我越来越觉得"从零搭一套商城系统"是检验PHP基本功最好的方式。最近拿到一套名为"木兮"的服装购物系统源码，文件名后面带着编号38169，应该是打包发布时记录的版本号。这套系统用原生PHP加MySQL写成，前台有商品浏览、规格选择、购物车、订单结算，后台有商品管理、分类管理、订单管理、会员管理，功能完整度在同类源码里算比较高的。这篇文章不打算照着官网说明念，而是站在一个接手源码的开发者角度，把"木兮"从架构到数据库、从前台流程到后台操作、从安全加固到二次开发，一条条拆开讲清楚。无论你是刚学完PHP想找个完整项目练手，还是手里已经有这套源码正打算改造成自己的服装商城，都能从中找到可以直接抄作业的内容。
1. 拆解整体架构：原生PHP项目的目录组织与双入口设计
1.1 前台与后台的双入口机制
打开"木兮"的源码包，第一眼看到的结构通常是根目录下放着index.php和admin.php两个入口文件，分别对应前台购物端和后台管理端。这种"双入口"设计在早期PHP项目里非常普遍，好处是简单直接，访问前台就是/index.php，访问后台就是/admin.php，不需要复杂的路由配置，放到任何一个支持PHP的虚拟主机上都能跑。我当时第一次看到这个结构就觉得，这套代码的受众定位非常明确，就是给那些不想折腾框架、希望拿来就能部署的开发者用的。
与之配套的目录结构一般长这样：
/ ├── index.php // 前台入口 ├── admin.php // 后台入口 ├── config/ │ └── database.php // 数据库连接配置 ├── includes/ │ ├── init.php // 初始化DB、session、公共函数 │ └── common.php // 公共函数库 ├── template/ │ ├── home/ // 前台模板 │ └── admin/ // 后台模板 ├── upload/ // 商品图片上传目录 └── install/ // 安装向导脚本init.php是整套系统的地基，它负责三件事：用mysqli建立数据库连接、调用session_start()开启会话、把common.php里的公共函数加载进来。所有业务页面在干活之前，都会先require_once这个文件。这样的好处是任何页面都能直接使用$db对象和公共函数，不用重复写连接代码。
1.2 为什么这类项目偏爱原生PHP而不是框架
这里要解释一个很多新手困惑的问题：现在主流PHP开发都用Laravel、ThinkPHP这类框架，为什么"木兮"这类下载源码仍然坚持原生PHP？我拆完之后的理解是，原生PHP项目有三个不可替代的优势。
第一，部署门槛极低。框架项目往往需要Composer装依赖、配置伪静态规则、设置runtime目录权限，而原生项目只需要把源码丢到网站根目录，导入一份SQL，改一下数据库连接文件，就能跑起来。对于很多只是想要一个能用的商城、又不太熟悉服务器操作的小团队来说，这才是最省事的选择。
第二，代码完全透明。框架把大量逻辑隐藏在最外层封装里，出问题要顺着命名空间一层层翻源码。原生项目里一个goods_list.php从查数据库到输出HTML都是明摆着的，改起来胆子大，不容易改崩。
第三，资源占用低。原生PHP不需要加载框架的常驻内核，同样的虚拟主机配置，原生项目能承受的并发和响应速度通常更好。当然代价也有，就是路由不灵活、代码重复多、团队协作时规范难统一，真到了业务量上来的时候，重构成本会很高。
1.3 配置项与公共函数库的阅读重点
接手任何一套源码，我建议先看两个文件，一个config/database.php，一个includes/common.php。前者能告诉你数据库连接参数怎么配，后者能告诉你这个项目的代码习惯是什么。
"木兮"的公共函数库大致围绕几个职责展开：SQL查询的封装函数、表单提交的判断、上传文件处理、分页计算。比如封装一个query($sql)函数去执行查询并返回结果集，比每个页面都直接写mysqli_query要集中好维护。阅读这套源码的时候你会发现，很多页面几行代码就能完成一块功能，原因就是公共函数把琐碎逻辑都吃掉了。
提示：拿到源码后第一件事，不要急着配置数据库，先把
common.php里所有函数名和注释扫一遍。理解了这些公共函数，整个系统的调用关系就清晰了一大半。
2. 数据库设计：服装商品的多维属性如何落到表里
2.1 分类表与商品表：一对多的核心关系
服装购物系统和普通商城最大的区别，在于商品属性维度多，颜色、尺码、季节、款式都要管理。但"木兮"这类定位偏轻量的系统，不会一上来就上SKU（库存量单位）多级模型，而是先用最基础的两张表把商品主体撑起来。
分类表category通常包含cat_id、cat_name、parent_id、sort_order这几个字段。parent_id用来支持二级分类，比如"女装"下面是"连衣裙""T恤"，前台可以通过递归或循环把二级分类拉出来。商品表goods的核心字段是goods_id、goods_name、cat_id、price、original_price、stock、goods_image、goods_desc、is_on_sale、add_time。
这里我想强调一个设计细节：价格字段建议直接用DECIMAL(10,2)，而不是FLOAT。浮点数在计算总价时会出现0.1+0.2不等于0.3的精度问题，这在订单金额上是要命的。我见过不少半路改造的项目因为价格字段用错类型，导致前后台金额对不上的。
2.2 颜色尺码与库存：从单表字段到SKU表
服装商品绕不开颜色和尺码的规格选择。最简单的做法是在goods表里加两个字段color和size，用逗号分隔可选值，比如color存"黑色,白色,藏青"，前台展示成单选按钮。这种方案做起来很快，但库存只能按整件商品算，没办法精确到"黑色XL码还剩5件"。
稍微进阶一点的做法是加一张goods_sku表，每个规格组合一条记录，字段包括sku_id、goods_id、spec_value、price、stock。spec_value用约定好的文本格式存，比如颜色:黑色|尺码:XL，这样在订单里记录商品快照时可以直接存成字符串，不用频繁联表。前台用户选定某个规格组合后，商品详情页通过AJAX查询对应SKU的库存和价格，把实时数据刷出来。
"木兮"这一类源码多数处于单表字段和SKU表之间的过渡状态。如果是拿来跑业务，我强烈建议至少把SKU表补上，否则服装店没法解决"一个款式多个尺码分别管理库存"这个核心诉求。
2.3 订单表与订单商品表：一张主表加一张子表
订单部分的设计直接决定这套系统的严谨程度。常规做法是拆成orders和order_goods两张表。orders表记录订单整体信息：order_id、order_sn、user_id、total_amount、pay_status、shipping_status、order_status、add_time。order_goods表记录订单里的每件商品快照：id、order_id、goods_id、sku_id、goods_name、spec_info、price、number。
为什么要在子表里冗余存一份goods_name和price，而不是下单时只存商品ID？因为商品以后可能改价、改名、甚至下架，如果订单只是引用商品表，历史订单显示的信息就会跟着变，这对财务对账是不可接受的。订单表里保存商品快照，是电商系统的基本原则之一。
订单状态一般用一个TINYINT字段表示，比如0待付款、1待发货、2待收货、3已完成、4已取消。状态的含义在代码里最好用常量数组统一维护，避免到处写魔法数字。order_sn是订单号，建议生成规则包含日期和随机串，例如date('YmdHis') . rand(1000, 9999)，这样既好看又不容易撞号。
2.4 用户表、收货地址表与购物车表
用户模块相对简单，user表保存user_id、username、password、mobile、email、reg_time。这里必须提醒一句，密码存储不要用明文，也不要只做简单的MD5。至少要用password_hash()配合password_verify()来做，如果这套源码还在用md5($password)，接手之后第一件事就是把它换掉。
收货地址表user_address记录address_id、user_id、consignee、mobile、province、city、district、address、is_default。省市区三字段建议用文本存储，省得联行政区划表；能精确到街道地址就够了，别过度设计。
购物车表cart要兼容游客场景，所以既要有user_id（登录用户），也要有session_id（游客标识）。字段包括cart_id、user_id、session_id、goods_id、sku_id、number。当用户登录后，可以把当前session_id下的购物车数据合并到这个用户下，这一步在用户点击登录成功的回调里处理。
3. 前台核心链路：从浏览商品到成功下单的完整流程
3.1 商品列表页：分类筛选、分页与排序的实现思路
前台首页和列表页是用户接触系统的第一站。列表页的典型URL是index.php?act=list&cat_id=2&page=1，通过$_GET['cat_id']接收分类ID，拼SQL时用WHERE限定分类。这里有个容易出问题的点：如果只是WHERE cat_id = 2，那二级分类下的商品在一级分类列表里就不会显示。简单可用的解法是把这个分类下面的所有子分类ID查出来，拼成一个IN (2, 5, 6)。
分页逻辑一般是当前页$page，每页数量$pageSize，通过LIMIT ($page-1)*$pageSize, $pageSize实现。要算总页数就得先执行一条SELECT COUNT(*)的查询，再ceil($total / $pageSize)得到页数。分页函数建议抽到common.php里，返回一个包含数据和分页HTML的数组，这样列表页代码能干净很多。
排序维度通常支持三个：按上架时间、按销量、按价格。实现时千万不要用ORDER BY $_GET['sort']直接拼SQL，因为排序字段一旦被外部控制，很容易被构造出恶意SQL。正确做法是用白名单数组限制允许的字段，非法值回退到默认排序。
3.2 商品详情页：规格切换与加入购物车
商品详情页是转化率的关键。前台打开index.php?act=detail&goods_id=18后，页面要做三件事：根据goods_id查商品主信息、查该商品下的SKU列表、查商品相册图片。
规格切换这块，前端通常这么配合：页面加载时把所有可选的规格组合连同价格、库存作为JSON输出到隐藏节点，用户点击"黑色""XL"这些按钮时，用JavaScript判断当前组合是否合法、库存是否大于0，并在界面直接显示"库存不足"的提示。这样做的好处是不用每次切换都发一次AJAX请求，用户体验流畅，对服务器的压力也小。
加入购物车本质是一次表单提交，传递goods_id、sku_id、number。后端处理逻辑要先做库存校验，再判断用户是否登录。已登录用户写入cart表时填user_id，游客则填session_id。这里我建议做一层统一封装，不管登录没登录，购物车的读取逻辑都优先用user_id，没有就用session_id兜底。
3.3 购物车页面与结算页的数据组装
购物车列表页的数据组装是典型的多表联查场景。一条SQL把三张表串起来：cart关联goods拿商品标题和图片，关联goods_sku拿规格描述和当前SKU价格。计算总价时，在PHP循环里逐条用price * number累加，而不是在SQL里SUM，因为商品单价来自SKU表，直接在SQL里SUM容易把规格价格搞错。
结算页要选的收货地址从user_address表里取，默认地址排序靠前。如果没有地址，要引导用户先新增。确认订单时，把商品清单、地址信息、总金额在一个页面集中展示，用户确认后提交订单。这一步是整个流程里编码最重的地方，我放到下一节专门说。
3.4 提交订单的事务处理：库存校验与防超卖
提交订单按钮一按，后端做的事情比想象中多得多。为了不出错，整个操作必须放进数据库事务里：
mysqli_begin_transaction($db); try { // 1. 查出购物车中所有商品及SKU // 2. 逐条校验库存是否充足，不足则抛出异常 // 3. 插入 orders 主表，拿到 order_id // 4. 循环插入 order_goods 子表 // 5. 逐条 UPDATE goods_sku SET stock = stock - number // 6. 清空购物车 mysqli_commit($db); } catch (Exception $e) { mysqli_rollback($db); // 跳回结算页并提示 }这里最关键的是"先校验库存再更新库存"的顺序。如果不加控制，两个用户同一时间下同一件商品的订单，就可能都通过库存校验，最后把库存扣成负数，这就是超卖。简单项目可以这样优化：校验库存后马上执行UPDATE goods_sku SET stock = stock - number WHERE sku_id = ? AND stock >= number，如果受影响行数为0，说明库存已经不够，直接回滚。这一步把"校验+扣减"合并成了原子操作，能挡住绝大多数并发问题。
注意：事务里的每一步都要用受影响的记录数和异常机制做严格判断，任何一步失败都要回滚。曾经有人图省事跳过事务，线上出现订单生成了、库存没扣、购物车也没清的状态，对账时直接懵掉。
4. 后台管理实操：商品上架、图片上传与订单发货
4.1 管理员登录鉴权
后台入口admin.php要先检查管理员是否登录，未登录就跳转到登录页。管理员表admin单独建，不跟前台用户混在一起。登录成功后把admin_id和admin_name写入session，后台每个页面顶部都做一次session检查，防止绕过登录直接访问。
这里要提醒一个常见漏洞：有些源码把登录校验只写在菜单页，而具体的功能处理页忘记了，攻击者可以通过直接构造URL调功能。接手后建议把后台所有页面的执行入口都统一收口到一个admin_init.php，这个文件做鉴权，其余页面全部引用它，从架构上堵住漏洞。
4.2 商品管理：表单、上传与缩略图
后台商品管理的核心是"新增商品"和"编辑商品"两个表单页，字段覆盖商品名、分类、价格、原价、库存、商品图、描述、上下架状态。保存逻辑要判断是新增还是编辑：新增执行插入，编辑执行更新，更新时不能改goods_id。
商品图片上传是后台最常见的功能，处理流程要覆盖四步：检查上传错误码、检查扩展名白名单、生成随机文件名、移动到upload目录。扩展名白名单只允许jpg、jpeg、png、gif，文件名用uniqid()加原始扩展名拼出来，避免用户上传中文名文件导致路径问题。
缩略图通常可选做。像"木兮"这类原生项目，如果配置了GD库，可以用imagecreatefromjpeg和imagecopyresampled生成一张列表页专用的小图，避免列表页加载原图。实测下来，100张原图每张几百K的页面，换成缩略图后加载速度能提升一个量级。
4.3 订单管理：状态筛选与发货操作
后台订单列表默认按状态筛选，对应前台订单状态流转，后台操作也同样用整数字段控制。待发货订单点"发货"时，表单录入物流公司和运单号，保存到orders表的shipping_company、shipping_sn字段，同时把订单状态从待发货改成待收货。
订单详情页要把order_goods里的商品快照、收货地址、订单金额全部展示出来，最好还加一块订单操作日志，记录什么时间谁做了什么操作。虽然会增加一张日志表，但对排查售后纠纷帮助巨大，属于成本低、收益高的功能，值得优先开发。
4.4 简易数据看板
后台首页一般放几个统计数字：今日订单数、今日销售额、待发货订单数、库存预警商品数。这些用聚合SQL即可，比如SELECT COUNT(*), SUM(total_amount) FROM orders WHERE add_time >= CURDATE() AND order_status NOT IN (4)。现在看着简单，但能让运营人员每天开机先看到业务大盘，日常管理就缺不了这块。销售走势图属于加分项，可以按天分组查订单表，把数据输出成JSON给前端图表。
5. 安全加固与上线部署：源码项目最常见的几个坑
5.1 SQL注入：拼接查询与参数绑定之别
原生PHP项目最容易出问题的就是SQL拼接。很多早期源码写的是$sql = "SELECT * FROM goods WHERE goods_id = " . $_GET['id']，这种写法一旦遇到id=1 OR 1=1，整张表的数据都能被拖出来。修复思路分两个层次。
最低限度是在每个进入SQL的变量上做转义，传统写法用mysqli_real_escape_string()包裹变量，虽然能挡住大部分注入，但仍然不够优雅。更推荐的方式是改造查询封装，让业务代码尽量用预处理语句。PDO的预处理写法对新手最友好：
$stmt = $pdo->prepare("SELECT * FROM goods WHERE goods_id = ?"); $stmt->execute([$_GET['id']]); $goods = $stmt->fetch();把关键查询改造成这种模式，注入面就基本关死了。改造量可以接受，核心是商品查询、订单查询、用户查询这几处高频点。
5.2 XSS与CSRF防护
前台所有来自数据库又需要展示到HTML的内容，比如商品名、商品描述、分类名，输出前都要过一遍htmlspecialchars()防止XSS。如果是富文本编辑器的内容，需要更细致的处理，至少要限制script标签和javascript:协议头的URL。
后台表单建议加CSRF Token校验。实现方式就是在生成表单时写入一个随机token到session，同时放到隐藏字段，提交时比对两者是否一致。这个机制能有效阻止跨站请求伪造，防止有人诱导管理员提交恶意操作。别嫌麻烦，管理员的权限太高，一旦被利用损失是直接的。
5.3 文件上传漏洞：只检查后缀远远不够
后台商品图上传如果只检查扩展名，攻击者完全可以改个名字上传一个带PHP代码的文件。完整的上传校验至少要有三重限制：文件扩展名白名单、MIME类型检查、上传目录禁止执行脚本。
上传目录禁止执行脚本这一点，Apache下可以在upload目录里放.htaccess，内容是：
php_flag engine offNginx下则在location配置里不解析该目录的PHP请求。实测下来，很多被人拿到shell的PHP商城都是栽在上传目录没有做执行限制上，这一条必须在部署时落实。
5.4 部署到服务器时的环境适配
原生PHP项目部署主要看三样：PHP版本、数据库驱动、伪静态规则。接手老源码最典型的问题是代码里还在用mysql_connect，这个函数PHP7.0就移除了，必须统一改成mysqli或PDO_MySQL。数据库连接字符集要设置为utf8mb4，否则商品描述里遇到生僻字或表情符号会直接变问号。
如果部署在Nginx环境，入口文件是index.php，只需要配置好try_files $uri $uri/ /index.php?$query_string;即可；后台入口同理。生产环境记得在php.ini里关闭display_errors，打开错误日志，不然SQL报错信息会直接暴露表结构，给攻击者递刀。
6. 二次开发指南：把"木兮"改成你自己的服装商城
6.1 换肤与页面改造
拿到源码先改外观是最直观的诉求。由于模板层和业务逻辑没有完全分离，换肤时需要同时调整HTML结构和CSS两个部分。建议做法是保留原来的页面输出结构，只替换CSS文件；如果要大幅改HTML，则对照模板里输出的变量名，把新HTML里的对应位置套进去即可。
新增字段相对要麻烦一点，比如想在商品表加一个"材质"字段，顺序是：先在数据库goods表加material字段，再到后台商品添加和编辑表单加输入框，再到前台详情页输出。三个地方一起改，缺一个都会出现数据存了却看不到的问题。
6.2 接入微信支付或支付宝支付的思路
支付对接是服装商城必须补的功能。如果要接入，核心链路是：用户提交订单后生成order_sn，跳转到支付收银台，支付完成后第三方服务会把回调请求发到你的服务器，回调里验签通过后更新订单状态。
重点要处理好回调的幂等性，也就是同一个订单的支付通知可能会收到多次，必须判断订单当前状态，只有待付款状态才更新为已付款，避免重复处理。需要准备商户号、应用私钥、平台公钥、回调URL，这些配置项统一放在一个payment_config.php文件里，别散落在各处。
6.3 性能优化与功能演进方向
如果担心网站访问量大起来会撑不住，可以从三个方向递进优化。第一层是给常用的商品详情查询加缓存，项目刚起步时可以用文件缓存或apc，数据量大了再换Redis。第二层是给goods表的cat_id、goods_id和orders表的order_sn、user_id加上索引，很多商城变慢并不是PHP慢，而是全表扫描。
功能上值得扩展的优先级也很明确：优惠券功能需要加coupon和user_coupon两张表，秒杀活动需要给商品加活动价和活动库存字段，搜索功能可以先用LIKE '%关键词%'顶一阵，真正做到一定规模后再考虑接入专业搜索服务。
我在实际拆解和改造这套源码的过程中，最大的感受是：原生PHP购物系统的价值不在代码有多花哨，而在于逻辑直白，能让人快速建立电商业务的全景认知。如果你也是第一次接触这类项目，建议按"数据库→公共函数→前台流程→后台流程"的顺序去读，把订单那条链路彻底吃透，其他的都是围绕它展开的。最后再分享一个小技巧：改造前先在本地用Git把原始源码提交一个版本，这样每次改动都能对比回退，比任何备份习惯都靠谱。
