打开手机应用商店搜“商城”，属于商城能翻出几百个长得差不多的电商App。真正跑在业务一线的软件B2C电商软件，和这些模板套壳的属于商城东西完全两码事。它得扛住双十一零点的电商并发下单，得让运营在后台三分钟内改完首页banner，软件还得保证用户从加购到支付不丢单。属于商城这些事，电商没做过的软件人觉得简单，做过的属于商城人知道每一环都是坑。

先说商品模块。电商表面看就是软件增删改查，实际上SKU体系的属于商城设计直接决定后期能不能活。我见过一个做母婴品类的电商团队，早期图省事，软件把“颜色”和“尺码”塞进同一个属性字段里，结果用户筛选“红色”时，所有红色尺码的纸尿裤全冒出来，转化率掉了一半。后来重构，把销售属性、非销售属性、规格图片分开建表，前端筛选逻辑才顺过来。B2C商城的商品模型，必须支持多规格、多图、富文本详情、关联推荐，少了哪个，运营都会骂人。

订单系统更磨人。一个订单从创建到完成，中间要经过库存锁定、优惠计算、支付回调、拆单发货、售后逆向。库存锁定这一步，用数据库行锁还是Redis分布式锁，差别巨大。行锁在秒杀场景下直接拖垮数据库，Redis锁又得处理锁超时和续期。我们之前用Redisson做库存扣减，压测时发现网络抖动导致锁释放延迟，超卖了三单。后来改成Lua脚本原子操作加本地库存分段，才把超卖率压到零。支付回调必须做幂等，微信和支付宝都会重复通知，没做幂等的系统，用户付一次钱能生成两笔订单，财务对账时想死的心都有。

营销模块是B2C商城的灵魂。优惠券、满减、秒杀、拼团、砍价，每个玩法背后都是一套独立的计算引擎。优惠券要支持叠加规则、互斥规则、品类限制、时间限制。我见过最离谱的bug是：用户领了“满100减20”和“满200减50”两张券，系统把两张券的优惠金额都算上，但门槛只校验了100。用户花50块买走200块的东西，运营半夜被叫起来改代码。营销引擎的规则校验顺序必须严格：先校验门槛，再校验互斥，最后计算最优组合。顺序错了，资损就来了。

后台管理界面往往被低估。运营不需要懂技术，他们需要拖拽式装修、所见即所得的页面编辑、实时数据看板。一个做服装的客户，每次上新都要换首页风格，如果后台改个banner还要找开发，运营效率直接归零。我们给后台集成了PageBuilder，运营自己拖组件、传图片、配链接，十分钟搞定一个活动页。数据看板要实时，至少五分钟延迟以内，不然运营做秒杀时看不到库存消耗速度，补货都来不及。

性能方面，B2C商城最怕的是热点商品。一个爆款上架，所有流量打到一个SKU上，数据库连接池瞬间打满。解决办法不是加机器，是加缓存。商品详情页静态化，库存走Redis，订单走消息队列削峰。我们做过一个测试：单机Redis扛住八万QPS的库存查询没问题，但MySQL单机超过三千QPS就开始抖。所以缓存策略必须是：能缓存的绝不查库，能异步的绝不同步。消息队列用RocketMQ还是Kafka，看业务量，日订单十万以下RocketMQ足够，事务消息还更省心。

最后说一句大实话：B2C电商软件没有“做完”的那天。业务在跑，需求就在变。今天加个直播带货，明天接个社区团购，后台字段永远在加。选型时别追求大而全，先跑通核心交易链路，再按业务节奏迭代。那些一上来就吹“全渠道、全链路、全场景”的方案，多半是卖PPT的。真正能用的商城软件，是运营愿意天天打开、开发愿意维护、老板看得见GMV的那一套。