不是拼起来的功能堆栈——租户隔离、分润口径、库存与履约链路在设计上互相咬合，改动任何一处都能追溯到对账务的影响。
单库多店铺架构，店铺维度的数据过滤由框架层统一注入，业务代码无法绕过。越权访问在架构上被排除，而不是靠每一处都写对。
分润比例、层级与对象全部来自配置，规则调整改配置不改代码。结算触发点唯一，退款只做冲正、不重算历史订单，每一笔流水可追溯。
店铺订单可转由云仓供货商发货。下单即从店铺的云仓余额按成本价扣款，订单过售后期后按供货价结算给供货商，进销差价即平台利润。
权限点声明一次，权限树、菜单与路由守卫自动生效。新增页面或按钮不需要改任何权限配置，也不会因为漏配而出现越权入口。
平台、商家、供货商、前置仓与各级代理各有独立后台，看到的是同一份数据的不同视角，账目口径全局一致。
C 端商城覆盖浏览、下单与会员中心；服务端 App 让商家与代理在手机上处理订单、库存与经营数据。
九个交付端覆盖从供货到消费的完整链路，每个角色只看到自己该看的那部分。
平台运营方：管理店铺、商品、财务与权限，掌握全局数据。
入驻商家：开店上货、接单履约、查看结算与经营数据。
云仓供货商：维护供货价、处理云仓订单发货与售后期。
前置仓：仓库、库区库位、入库出库、盘点与分拣配送。
区域代理：辖区内的店铺与业绩管理。
推广代理：拉新推广与业绩结算。
产品代理：代理产品与对应订单的管理。
消费者：商品浏览与搜索、下单、优惠券、评价晒单、会员中心。
商家与代理：移动端处理订单、库存、资料与经营数据。
这套系统真正的难点不在页面数量，而在三个地方：钱怎么分、货怎么转、数据怎么隔。
订单实付金额乘以让利比例，按配置分配给各级分润对象。比例、层级、参与角色全部落在配置表里，调整分润政策不需要改一行业务逻辑。
结算触发点全系统唯一：订单过售后期才结算。退款走冲正，只对已入账金额做反向调整，历史账目不会被重算，因此任何时点的对账结果都稳定可复现。
店铺不必自己囤货。订单转给云仓供货商发货后，系统立刻从店铺的云仓预存余额里按成本价扣款——扣的是店铺的钱，不是买家的钱。
扣款额与结算额是两条独立的金额线：按成本价扣、按供货价结，中间的差额就是平台利润。供货商货款在订单过售后期后自动结算入账。
所有业务表都带店铺维度，过滤条件由数据访问层的基类统一注入，业务代码里写不出绕过隔离的查询。
这意味着隔离强度不取决于开发者是否记得加条件——加不加都加上了。对多店铺平台来说，这是比权限系统更底层的一道防线。
后台、商城与移动端共用同一套服务端与同一份数据契约，口径不会因端而异。
多角色统一入口登录，按角色自动收敛菜单与操作范围，无需分别部署。
金额全程以精确数值与整数分运算，从结构上杜绝累计误差，账目可以对到分。
可部署在自有服务器上，数据留在自己手里，不与外部服务产生关联。