一个购物网站的购物源代码，核心就三块：商品展示、网站购物车、源代订单结算。购物听起来简单，网站但真正写起来，源代坑都在细节里。购物我去年帮朋友改过一个二手书交易站，网站后台用PHP，源代前端jQuery，购物代码翻到第三遍才把库存扣减的网站并发问题按住。那会儿才明白，源代购物车看着不起眼，购物其实是网站整个系统里最容易出乱子的地方。

先看商品列表页。源代数据库里一张products表，字段无非是id、name、price、stock、image_url。但图片存储方式有讲究——直接存二进制进数据库？别干这种傻事。文件系统存路径，数据库只存文件名，这样查询快，备份也灵活。前端渲染时用循环把商品卡片吐出来，比如：

<div class="product-card"> <img src="/uploads/<?php echo $row['image_url']; ?>" alt="<?php echo $row['name']; ?>"> <h3><?php echo $row['name']; ?></h3> <p class="price">￥<?php echo number_format($row['price'], 2); ?></p> <button class="add-to-cart" data-id="<?php echo $row['id']; ?>">加入购物车</button> </div> 

那个data-id属性很关键。点击按钮时，JavaScript不直接跳转，而是发一个fetch请求到cart_add.php，把商品id传过去。后端收到后，先查session里有没有购物车数组，没有就新建。这里有个小陷阱：如果用户没登录，购物车存session；登录了，得同步到数据库的cart表。我见过不少站点偷懒只存session，结果用户换台电脑购物车就空了，骂声一片。

购物车页面本身不复杂，麻烦的是价格计算。单价乘数量，再加总。但优惠券、满减、运费规则一叠加，代码就开始膨胀。我习惯把计算逻辑抽成一个calculate_total()函数，参数是购物车数组和用户信息。这样改规则时只动一个地方。有个细节：浮点数算钱容易出0.1+0.2=0.30000000000000004的幺蛾子，所以金额统一用整数分存储，显示时再除以100。

订单结算才是重头戏。用户点“提交订单”后，后端要干一串事：验证库存、锁定库存、生成订单号、写订单主表和明细表、清空购物车、调支付接口。顺序不能乱。库存锁定必须用SELECT ... FOR UPDATE或者乐观锁版本号，否则两个用户同时买最后一件商品，超卖就发生了。我朋友那个站最初没加锁，结果同一本二手书卖出去三次，最后只能挨个打电话道歉。

支付回调那块更得小心。支付宝或微信异步通知过来，你得先验签，再查订单状态是否已处理。重复通知很常见，所以回调接口必须幂等——同一个订单号第二次进来直接返回成功，别重复发货。代码里通常写个if ($order['status'] != 'pending') exit('success');挡在前面。

前端交互上，加入购物车后最好给个轻提示，别用alert()，太粗暴。一个小toast浮层，1.5秒自动消失，体验好得多。购物车数量变化时，右上角的小红点要实时更新，这得靠JavaScript监听fetch的返回结果，然后改DOM。别整页刷新，用户会烦。

最后说安全。SQL注入靠预处理语句挡，XSS靠htmlspecialchars()过滤输出，CSRF靠token。这三样少一个，购物网站就是筛子。我见过一个站，商品搜索框直接拼接SQL，别人输入' OR 1=1 --就能把整张用户表拖走。源代码里这种低级错误，改起来不难，但一开始就得养成习惯。

写购物网站源代码，别追求花哨架构。先把库存扣减、订单状态机、支付回调这三条线跑通，再考虑加缓存、上队列。我那个朋友后来把库存扣减改成Redis原子操作，QPS上去了，但订单落库还是得靠MySQL事务兜底。技术选型没有银弹，合适就行。