用JavaScript写购物网站，写购核心就三件事：商品数据怎么存、物网购物车状态怎么同步、写购结算时怎么把数据发给后端。物网我去年帮朋友改过一个卖手冲咖啡豆的写购小站，前端用原生JS写的物网，没上框架，写购代码不到400行，物网但该有的写购都有。下面直接拆开讲。物网

商品列表别硬编码在HTML里。写购我见过有人把每个商品写成<div>，物网改价格要翻遍整个文件。写购正确做法是物网数据驱动。定义一个数组：

const products = [ {  id: 1,写购 name: '耶加雪菲', price: 88, stock: 12 }, {  id: 2, name: '曼特宁', price: 76, stock: 8 } ];

然后用map渲染成DOM。这样加个新品只需要改数组。渲染函数大概长这样：

function renderProducts() {  const list = document.getElementById('product-list'); list.innerHTML = products.map(p => ` <div class="product" data-id="${ p.id}"> <h3>${ p.name}</h3> <p>价格：${ p.price}元</p> <button class="add-btn">加入购物车</button> </div> `).join(''); }

购物车状态用一个对象存，键是商品id，值是数量。比如{ 1: 2, 2: 1 }。别用数组，数组删条目要遍历，对象直接delete或者置零。每次点击“加入购物车”，更新这个对象，然后调用updateCartUI()。UI更新只做一件事：遍历购物车对象，算出总价，渲染到侧边栏。

这里有个容易踩的坑——事件绑定。如果用innerHTML重新渲染商品列表，之前绑在按钮上的onclick会丢失。我习惯用事件委托，把监听器挂在父容器上：

document.getElementById('product-list').addEventListener('click', e => {  if (e.target.classList.contains('add-btn')) {  const id = +e.target.closest('.product').dataset.id; addToCart(id); } });

购物车里的数量增减、删除，同理用委托。这样不管列表怎么重绘，事件永远有效。

结算部分，前端只负责收集数据。把购物车对象转成数组，带上用户选好的收货信息，用fetch发给后端：

async function checkout() {  const items = Object.entries(cart).map(([id, qty]) => ({  id: +id, qty })); const res = await fetch('/api/order', {  method: 'POST', headers: {  'Content-Type': 'application/json' }, body: JSON.stringify({  items, address: getAddress() }) }); if (res.ok) {  cart = { }; updateCartUI(); alert('下单成功'); } }

别在前端算总价然后传给后端。后端必须自己根据商品id重新查价格计算，否则用户改个JS变量就能一块钱买十斤豆子。我那个咖啡站就吃过亏，测试时把总价改成0.01，居然真提交成功了。后来后端加了校验才堵住。

库存同步是另一个麻烦事。如果两个用户同时买最后一包豆子，前端各自显示有货，提交时一个成功一个失败。我的做法是：加入购物车时不锁库存，提交订单时后端用数据库事务扣减，扣失败就返回“库存不足”。前端收到错误后刷新商品列表。简单粗暴，但有效。

最后说存储。购物车要不要存localStorage？看场景。如果用户没登录，存localStorage能保留跨会话的购物车。但登录后应该合并到服务端购物车。我一般先读localStorage，登录后发个合并请求，然后清空本地。别两边都存，不然用户换设备就乱了。

原生JS写购物网站，代码量不大，但细节全是坑。数据驱动、事件委托、后端校验这三条守住，基本就能跑。框架能帮你省事，但搞懂这些底层逻辑，换什么工具都不慌。

(责任编辑：综合)