一个常见的困境很多电商项目在上线一两年后都会遇到同一个问题业务方向变了系统却改不动。典型场景包括原本做直营现在想开放商户入驻B2C 跑顺了客户开始要批发价、询价、账期线上卖得好线下门店也想接进来做自提或同城配送国内站稳了准备做跨境多语言、多币种成了刚需老板的需求往往很直接能不能在现有系统上加技术团队的回答也往往很现实当初没按这个设计改动面很大。于是陷入两难继续硬改风险越来越高推倒重来时间和成本都承受不起。真正的问题不是功能少了一个很多团队的第一反应是补功能加个商户后台、加个询价入口、加个门店模块。但电商系统的难点从来不只是有没有这个页面而是底层能力是否从一开始就被当成可组合的能力而不是写死的业务形态。举几个容易被忽视的差异业务变化表面需求实际影响开放商户入驻多一个商家后台商品归属、订单分账、结算规则、权限隔离都要重构切入 B2B加个批发价询价、起订量、客户等级、对公流程会牵动下单链路做 O2O加个门店列表库存共享、履约方式、配送范围、收银对接都是新逻辑做跨境换语言包币种、税费、物流规则、合规展示往往牵一发动全身如果系统最初只服务单店直营这些能力通常不是开关没开而是架构上就没留位置。后面每补一块都像在旧房子上接新房间越接越乱。为什么多开几个版本也不是好办法一种常见做法是B2C 一套、B2B 一套、O2O 一套各维护各的代码。短期看似乎边界清晰长期几乎一定会遇到公共能力重复建设登录、商品、订单、支付、售后每个版本都要修一遍问题修复不同步A 版本修了库存漏洞B 版本还留着交付成本失控新客户要B2C 一点批发能力到底基于哪个版本改测试和运维压力倍增同一套业务逻辑要测 N 遍、发 N 遍对于想持续演进的电商产品来说这相当于把业务灵活性问题转嫁给了组织协作成本。更稳妥的思路把业态差异当成能力组合成熟一些的电商产品通常不会把专业版、平台版、批发版、跨境版做成完全割裂的项目而是会区分两层一层是稳定的交易内核用户、商品、购物车、下单、支付、售后——这些不管做什么业态本质流程是相通的。一层是可开关的扩展能力商户入驻、店铺体系、询价、批量采购、跨境配置、门店履约、供应商协同等按需启用而不是重写。这样做的好处很实际新客户交付时不是从零开发而是选能力、配参数、做少量定制老客户业务升级时不是换系统而是逐步打开新能力研发团队只维护一套核心链路Bug 修复和能力迭代都能复用这不是理论上的完美架构而是控制长期成本的一种工程选择。给决策者的三个判断问题如果你正在评估现有系统能不能支撑下一步业务可以先问三个问题1. 新业务是加功能还是换一种卖法只是多一种优惠券和多一种商户结算模式复杂度完全不是一个量级。2. 现有系统的权限、商品、订单、资金四条线能不能独立扩展如果任何一条线都要大面积改动说明当初设计时把业态写死了。3. 如果 6 个月后还要再变一次团队还能承受吗电商很少有一成不变的业务模式系统必须假设还会变。写在最后电商项目最怕的不是一开始做得不够大而是一开始把路走窄了。当企业从卖货走向做平台、从零售走向批发、从线上走向线上线下一体系统能不能跟上往往决定了业务扩张是顺畅推进还是每次都像一次小型重构。如果你也正处在业务已经变了系统还没变的阶段不妨先别急着补页面先把哪些能力是共用的、哪些能力是可选的梳理清楚。这一步做对了后面会省很多冤枉钱。本文为电商产品与技术实践分享欢迎交流讨论。