去年帮一个做母婴用品的商城朋友看他的商城后台，日活不到200，网站购物车弃单率却高达78%。商城我问他用户从哪来，网站他说投了信息流广告。商城再问落地页到下单的网站路径，他发来一个截图——从点击广告到完成支付，商城用户要跳转5次，网站填3遍地址。商城问题不在流量，网站在漏斗本身漏得太狠。商城

做B2C商城，网站第一件事不是商城选Java还是PHP，是网站画清楚用户从看到商品到付完钱要经过几步。每多一步，商城转化率砍一半。这不是理论，是无数A/B测试堆出来的经验值。我见过最离谱的案例，一个卖茶叶的独立站，结算按钮藏在页面右下角一个灰色小图标里，不仔细找根本看不见。改版后把按钮放大、变红、固定在底部，当天转化率翻了3倍。技术选型再先进，也救不了这种低级错误。

后端架构上，中小型B2C别一上来就微服务。我见过太多团队被“高并发”三个字吓住，订单系统还没跑通就拆了十几个服务，结果运维成本吃掉全部利润。日订单低于5000单，单体架构加缓存足够用。MySQL读写分离配Redis存热点数据，撑住每秒几百次查询没问题。真正需要操心的是库存扣减的原子性——超卖一次，客服电话被打爆。用数据库行锁还是Redis分布式锁，取决于你的并发量级。日均千单以下，直接UPDATE stock SET count = count - 1 WHERE id = ? AND count > 0，简单可靠。

前端体验有个容易被忽略的细节：商品列表页的加载速度。用户滑动屏幕时，图片没出来，白块一闪一闪，手指就划走了。WebP格式比JPEG省30%带宽，配合懒加载和CDN，首屏时间能压到1秒内。别小看这零点几秒，移动端每延迟100毫秒，转化率掉1%。这是Google实测数据，不是拍脑袋。

支付环节的坑更多。微信支付和支付宝的回调通知必须做幂等处理，否则网络抖动导致重复通知，用户被扣两次款。我处理过一起客诉，用户买一箱奶粉，结果付了两次钱，虽然最后退了，但人家直接卸载App。回调接口里加个order_id唯一索引，重复请求直接返回成功，别再做业务逻辑。另外，支付超时时间别设太长，15分钟足够。时间越久，用户反悔概率越高。

安全方面，SQL注入和XSS是老生常谈，但越简单的漏洞越容易中招。有个做宠物用品的商城，搜索框没过滤特殊字符，被人用UNION SELECT把用户手机号全拖走了。后来查日志，攻击者只用了三行代码。参数化查询是底线，别拼SQL字符串。用户密码用bcrypt加盐哈希，别用MD5——彩虹表早就能秒破。

最后说个反常识的观察：很多B2C商城把推荐算法做得无比复杂，协同过滤、深度学习全上，结果推荐出来的商品点击率还不如“热销榜”三个字。用户来买东西，目的性往往很强，猜他喜欢什么不如直接告诉他别人在买什么。我朋友那个母婴站，把“猜你喜欢”换成“同月龄妈妈都在买”，点击率涨了40%。技术有时候要往后退一步，让位于人性。

做商城没有银弹。每个环节抠一点，转化率攒起来就是利润。那些活得好的独立站，不是技术多牛，是把“用户点进来到付完钱”这条路上的石头，一颗一颗搬干净了。