用PHP写购物系统，基于最怕的网上不是代码量，而是购物把简单的事搞复杂。我见过一个日订单三千的系统站点，核心逻辑就三个文件：商品展示、基于购物车、网上订单落库。购物没有框架，系统没有Composer，基于连路由都是网上靠GET参数拼出来的。跑得稳，购物改起来也快。系统后来接手的基于人非要用Laravel重构，三个月后上线，网上第一周就出了两次库存超卖。购物问题不在框架，在人把注意力从业务逻辑挪到了架构表演上。

商品表结构直接决定后面顺不顺。sku、价格、库存三个字段必须拆开，别想着用JSON塞进一个字段里。我吃过亏，早期用serialize存规格，结果运营要按尺码筛库存，SQL写得像天书。后来改成独立sku表，商品主表只留标题和描述，查询效率翻倍。库存扣减用UPDATE goods SET stock = stock - 1 WHERE id = ? AND stock > 0，返回影响行数判断是否成功。别先SELECT再UPDATE，并发一上来准超卖。

购物车别急着往数据库写。用户没登录之前，session里存一个数组就够了。结构简单：$_SESSION['cart'][$sku_id] = ['qty' => 2, 'price' => 59.9]。合并逻辑写在登录后的回调里，把session数据跟用户表里的购物车做一次upsert。有人喜欢用Redis存购物车，可以，但小站点没必要。session文件在/tmp下读写，性能不差，关键是少一个依赖。

订单号生成有个小技巧。别用自增ID直接暴露，也别用uniqid()——它基于微秒，高并发下会撞。我习惯用date('YmdHis') . mt_rand(1000, 9999)，再加一个用户ID后四位。重复概率极低，出问题也能靠时间戳追溯。订单主表存总价、状态、收货信息，订单详情表存sku快照。快照必须存，别只存sku_id。商品改价改名之后，历史订单得能还原当时的样子。

支付回调是坑最多的地方。微信和支付宝都会重复通知，同一个out_trade_no可能来五次。处理逻辑第一句永远是查订单状态，已支付就直接返回success。别在回调里做复杂业务，更新订单状态、减库存、发消息，这三件事拆成队列任务。用PHP写个简单的file_put_contents日志记录每次回调的原始数据，排查问题时比翻数据库快得多。

后台管理别追求大而全。商品上下架、订单发货、退款处理，三个页面能覆盖八成日常操作。权限控制用最笨的办法：用户表加一个role字段，值为admin才能进后台。别上RBAC，别搞权限节点树。见过一个五人团队花两周做权限系统，结果运营只有一个管理员账号，所有操作都走同一个登录。

模板渲染直接用PHP原生短标签。<?= $goods['title'] ?>比Smarty快，比Twig少一层编译。注意转义，htmlspecialchars该加就加。前端用Bootstrap拉个栅格，商品列表三列排开，移动端自动折行。别自己写CSS框架，时间花在刀刃上。

最后说部署。一台1核2G的云服务器，装nginx + php-fpm + mysql，跑这个系统绰绰有余。php-fpm进程数设成pm.max_children = 10，mysql的innodb_buffer_pool_size给512M。静态资源走nginx直接返回，别经过PHP。每天凌晨用mysqldump备份一次数据库，传到对象存储。够用了。