去年帮一个朋友看他的电商代码茶叶电商站，打开源码我愣了几秒——首页轮播图下面直接硬编码了12个商品卡片，网站每个卡片里的电商代码价格、库存、网站图片路径全是电商代码写死的。他跟我说，网站每次上新茶得手动改HTML，电商代码改完再上传服务器。网站一个月上新两次，电商代码每次折腾半小时。网站这还算好的电商代码，有次促销改错一个价格，网站多卖了30单亏了四千多。电商代码

电商网站代码最核心的网站问题从来不是"用什么框架"，而是电商代码数据怎么流动。商品信息、库存、订单、用户，这些东西不能长在页面里，得长在数据库里。页面只负责一件事：把数据拿过来，按模板渲染出去。

说个具体的。一个正常的商品详情页，后端大概做这几步：收到请求 → 从数据库查商品记录 → 查库存 → 查用户是否有优惠券 → 把数据塞进模板 → 返回HTML。前端拿到页面后，加购按钮绑定一个接口调用，点一下发一次请求，后端扣库存、写订单、返回结果。整个链路里，价格和库存永远是最后一步才确认的，页面上显示的数字只是"参考值"。

很多人写电商代码容易犯一个错：把业务逻辑写到前端。比如在JavaScript里算总价、判断能不能买。用户改一下浏览器里的变量，价格就变了。我见过一个独立开发者做的周边商城，购物车总价是前端算的，结果有人把单价改成0.01元下了单。后来他学乖了，所有金额计算全放后端，前端只管展示。

// 后端伪代码，下单时重新计算 function createOrder(userId, items) {  let total = 0; for (let item of items) {  const product = db.getProduct(item.id); total += product.price * item.qty; if (product.stock < item.qty) throw new Error('库存不足'); } // 应用优惠券、运费等 ... } 

数据库设计也是绕不开的坎。商品表、SKU表、订单表、订单明细表，这四张表基本是标配。有人图省事把所有信息塞一张表里，结果一个商品有多个规格时就开始难受了。比如一件T恤有S/M/L三个码，每个码库存不同，价格可能也不同。拆成商品表存公共信息，SKU表存规格和独立库存，逻辑就顺了。

还有个容易被忽略的点：图片。电商站图片多，直接存服务器本地文件夹，量一上来磁盘和带宽都扛不住。用对象存储（比如七牛、OSS）是常规做法，数据库里只存URL。上传时前端直传对象存储，后端只负责签发上传凭证，省服务器流量。

支付环节，别自己造轮子。接微信支付或者支付宝的SDK，回调地址做好验签，订单状态用异步通知来更新，不要依赖前端跳转回来改状态——用户关掉页面你就丢单了。

代码写到最后，拼的不是技术多花哨，而是细节有没有兜住。库存扣减加锁了吗？并发下单会不会超卖？订单号会不会重复？这些坑，踩过一次就记住了。