Day01-Day08 全系统业务关联与面试总复习

这份文档用于把八天课程从“每天一个模块”重新串成“一个完整项目”。单独看 SRM、PMS、WMS、OMS、TMS、FMS 都容易变成局部功能，但真实供应链系统的价值在于：供应商、采购、仓库、商品、订单、物流、财务、数据分析、权限安全这些模块能够围绕同一批业务数据连续流转。

阅读这份文档时，可以先抓住三条主线：

货物流：供应商供货，采购入库，仓库管理库存，订单发货，物流配送，退货回仓。
信息流：供应商资料、SKU 主数据、订单、库存、运单、账单、KPI 指标在各系统之间流转。
资金流：采购应付、平台应收、物流应付、退款、VAT、利润快照和现金流预测。

系统之间的调用方式不是固定一种，而是根据业务场景选择：

调用方式	适用场景	典型例子
Feign 同步调用	调用方必须立即拿到结果，才能决定当前操作是否继续	OMS 创建订单时调用 WMS 冻结库存；PMS 创建采购单时查询已审核供应商
RocketMQ 异步消息	当前主流程不需要等待下游立即完成，允许最终一致	OMS 订单完成后通知 FMS 结算；TMS 运单签收后通知 OMS 更新签收
Seata 分布式事务	跨服务操作必须同时成功或同时失败	OMS 创建订单 + WMS 冻结库存；PMS 收货确认 + WMS 增加库存
XXL-Job 定时任务	周期性扫描、补偿、统计、预警	供应商评分、资质到期提醒、轨迹拉取、KPI 预警、报表缓存
外部 API / Webhook	与电商平台、物流商、汇率服务等外部系统交互	Amazon 订单同步、物流商在线下单、汇率同步、平台账单导入

第一部分全系统业务关联图

1.1 全系统主业务链路图

这张图只展示主链路，不把所有支撑关系都画进去。这样可以清楚看出一笔业务从“供应商引入”到“采购入库”，再到“订单履约、物流配送、财务结算、BI 分析”的完整路径。

flowchart LR
    subgraph UP["上游采购协同"]
        SRM["SRM 供应商管理<br>供应商引入 审核 资质 评分 Portal"]
        PMS["PMS 采购管理<br>采购申请 询价比价 采购单 收货 应付"]
    end

    subgraph MID["中游商品库存订单"]
        PIM["PIM 商品管理<br>SPU SKU 多语言 价格 商品状态"]
        WMS["WMS 仓储管理<br>仓库 库位 库存 入库 出库 盘点"]
        OMS["OMS 订单管理<br>平台接单 库存冻结 风控 拆合单 售后"]
    end

    subgraph DOWN["下游履约结算"]
        TMS["TMS 物流管理<br>物流渠道 运单 轨迹 费用 退货物流"]
        FMS["FMS 财务结算<br>平台对账 利润 应收应付 VAT 现金流"]
        BI["BI 数据分析<br>KPI 看板 销售预测 补货建议 ABC 分类"]
    end

    SRM -->|"Feign 同步<br>查询已审核供应商"| PMS
    PIM -->|"Feign 同步<br>提供 SKU 主数据"| PMS
    PMS -->|"Feign + Seata<br>采购收货和入库"| WMS
    PIM -->|"Feign 同步<br>商品信息和销售属性"| OMS
    OMS -->|"Feign + Seata<br>创建订单冻结库存"| WMS
    WMS -->|"RocketMQ<br>出库完成通知"| TMS
    TMS -->|"RocketMQ<br>运单号和轨迹状态"| OMS
    OMS -->|"RocketMQ<br>订单完成和退款事件"| FMS
    PMS -->|"RocketMQ 或 Feign<br>采购应付和付款状态"| FMS
    TMS -->|"RocketMQ<br>物流费用确认"| FMS
    FMS -->|"XXL-Job ETL<br>利润 现金流 VAT 数据"| BI
    WMS -->|"XXL-Job ETL<br>库存 周转 盘点数据"| BI
    OMS -->|"XXL-Job ETL<br>销量 退款 履约数据"| BI
    BI -->|"Feign 或人工确认<br>补货建议生成采购申请"| PMS

主链路可以这样理解：

SRM 先解决“和谁合作”的问题，只有审核通过、资质有效、没有被停用的供应商，才能进入 PMS 的采购流程。PMS 解决“买什么、向谁买、买多少、什么时候到货”的问题。采购货物到仓后，WMS 负责收货、质检、上架、增加库存，并记录库存流水。PIM 管理商品和 SKU 主数据，OMS 接收外部电商平台订单后，需要引用 PIM 的商品信息，并调用 WMS 冻结库存，避免超卖。仓库发货后，TMS 创建运单、同步轨迹和核算物流费用。订单完成、退款、物流费用、采购应付最终进入 FMS 做对账、利润和资金管理。BI 不直接处理业务单据，而是从各业务系统抽取数据，形成 KPI、预测和补货建议，再反向驱动 PMS 发起补货。

1.2 外部系统与平台边界图

供应链 SaaS 并不是电商平台本身。买家下单、支付、退款申请一般发生在 Amazon、TikTok Shop、Shopee、Shopify、Temu 等外部平台。SaaS 系统的职责是把订单、库存、物流、财务和供应链履约统一管理起来。

flowchart LR
    subgraph EXT["外部系统"]
        ECOM["电商平台<br>Amazon TikTok Shop Shopee Shopify Temu"]
        CARRIER["物流商系统<br>DHL UPS USPS 顺丰国际 4PX 云途"]
        BANK["银行和支付账户<br>平台打款 付款流水"]
        TAX["税务和合规系统<br>VAT OSS 海关申报"]
        RATE["汇率服务<br>官方汇率或第三方 API"]
        SUPPLIER["供应商 Portal 用户<br>报价 确认 发货 对账"]
    end

    subgraph SAAS["柔性供应链 SaaS"]
        PIM["PIM 商品"]
        OMS["OMS 订单"]
        SRM["SRM 供应商"]
        PMS["PMS 采购"]
        WMS["WMS 仓储"]
        TMS["TMS 物流"]
        FMS["FMS 财务"]
    end

    PIM -->|"API<br>商品资料发布和库存同步"| ECOM
    ECOM -->|"Webhook 或 API 拉取<br>订单 退款 平台状态"| OMS
    SUPPLIER -->|"Portal API<br>维护资料 报价 确认采购单"| SRM
    SUPPLIER -->|"Portal API<br>发货通知 对账确认"| PMS
    TMS -->|"外部 API<br>在线下单 获取运单号 面单"| CARRIER
    CARRIER -->|"Webhook 或定时 API<br>轨迹节点 实际费用"| TMS
    ECOM -->|"账单文件或结算 API<br>平台收入 佣金 退款 广告费"| FMS
    BANK -->|"导入或 API<br>实际到账和付款流水"| FMS
    RATE -->|"定时 API<br>多币种汇率"| FMS
    FMS -->|"导出申报数据<br>财务专员或税务顾问提交"| TAX

这里要特别区分三个边界：

第一，供应链系统不是交易平台。买家面向的是 Amazon、TikTok Shop、Shopee 这类电商平台，不直接进入 SaaS 系统。OMS 接收订单、退款、发货状态，但交易关系仍然在电商平台侧产生。

第二，供应链系统不是物流商系统。TMS 可以调用物流商 API 创建运单、获取面单、拉取轨迹、导入费用账单，但最终揽收、运输、派送、计费仍然由物流商完成。

第三，供应链系统不是税务机关系统。FMS 可以计算 VAT 申报数据、生成 OSS 格式导出、记录申报历史，但实际申报和缴税通常由财务专员或税务顾问登录官方系统完成。

1.3 采购入库链路图

采购入库是 SRM、PMS、WMS、FMS 最典型的跨系统链路。

flowchart TB
    SRM["SRM<br>供应商审核通过"]
    PIM["PIM<br>SKU 主数据"]
    PMS1["PMS<br>采购申请"]
    PMS2["PMS<br>询价比价和采购订单"]
    SUP["供应商 Portal<br>确认采购单和发货"]
    WMS1["WMS<br>到货收货和质检"]
    WMS2["WMS<br>上架入库 增加库存 写库存流水"]
    FMS["FMS<br>生成采购应付账款"]
    SRM_SCORE["SRM<br>月度绩效评分"]

    SRM -->|"Feign 同步<br>只允许选择审核通过供应商"| PMS1
    PIM -->|"Feign 同步<br>采购明细引用 SKU"| PMS1
    PMS1 -->|"本地流程<br>审批通过后发起询价"| PMS2
    PMS2 -->|"Portal 通知<br>供应商确认和发货"| SUP
    SUP -->|"Portal API<br>发货信息回传 PMS"| PMS2
    PMS2 -->|"Feign + Seata<br>确认收货时创建入库动作"| WMS1
    WMS1 -->|"本地事务<br>质检结果和入库单明细"| WMS2
    WMS2 -->|"同步返回或 MQ<br>入库结果回写采购单收货数量"| PMS2
    PMS2 -->|"MQ 或 Feign<br>收货后生成应付"| FMS
    PMS2 -->|"XXL-Job 月度统计<br>交付及时率 合格率 价格稳定性"| SRM_SCORE

采购入库的关键点是：采购单是 PMS 的业务单据，库存是 WMS 的真实库存，供应商能力评价回到 SRM，付款和账期进入 FMS。

在技术选型上，创建采购单时查询供应商和 SKU 一般用 Feign，因为要立即校验供应商是否可用、SKU 是否存在。确认收货并增加库存时，如果 PMS 和 WMS 是独立数据库，就需要使用 Feign + Seata 保证“采购单收货数量更新、WMS 库存增加、库存流水写入”同时成功或同时失败。收货完成后生成应付账款，可以用 MQ 通知 FMS，因为财务应付允许稍后生成，只要消息可靠即可。

供应商绩效评分不是每次采购实时计算，而是由 SRM 的定时任务按月统计。它需要读取 PMS 的采购交付数据、WMS 的质检结果、FMS 的对账或付款数据，计算准时交付率、质量合格率、价格稳定性、协同响应等维度，最后形成 S/A/B/C 评级。

1.4 订单履约链路图

订单履约是 PIM、OMS、WMS、TMS、FMS 的核心协同链路。

flowchart TB
    ECOM["外部电商平台<br>订单和退款"]
    OMS_IN["OMS<br>Webhook 接收 签名验证 幂等入库"]
    PIM["PIM<br>商品 SKU 价格 重量 合规属性"]
    OMS_ORDER["OMS<br>订单状态机 风控 拆单合单"]
    WMS_FREEZE["WMS<br>冻结库存"]
    WMS_PICK["WMS<br>拣货 打包 出库 扣减库存"]
    TMS_CREATE["TMS<br>推荐物流渠道 创建运单 获取面单"]
    CARRIER["物流商<br>揽收 运输 派送"]
    TMS_TRACK["TMS<br>轨迹拉取和异常检测"]
    OMS_DONE["OMS<br>更新发货 签收 完成 退款状态"]
    FMS["FMS<br>订单收入 退款 利润核算"]

    ECOM -->|"Webhook 或 API<br>订单 退款 状态"| OMS_IN
    OMS_IN -->|"MQ 异步<br>快速返回平台 防止超时重发"| OMS_ORDER
    PIM -->|"Feign 同步<br>校验商品和读取 SKU 属性"| OMS_ORDER
    OMS_ORDER -->|"Feign + Seata<br>创建订单同时冻结库存"| WMS_FREEZE
    OMS_ORDER -->|"MQ<br>发货任务或出库任务"| WMS_PICK
    WMS_PICK -->|"本地事务<br>扣减实物库存和冻结库存"| WMS_PICK
    WMS_PICK -->|"RocketMQ<br>出库完成 包裹信息"| TMS_CREATE
    PIM -->|"Feign 同步<br>重量 体积 电池 液体 HS 编码"| TMS_CREATE
    TMS_CREATE -->|"外部 API<br>在线下单 获取运单号和面单"| CARRIER
    TMS_CREATE -->|"RocketMQ<br>运单号 trackingNo 回写"| OMS_DONE
    CARRIER -->|"Webhook 或定时 API<br>物流轨迹"| TMS_TRACK
    TMS_TRACK -->|"RocketMQ<br>发货 签收 异常轨迹"| OMS_DONE
    OMS_DONE -->|"RocketMQ<br>订单完成 退款 售后事件"| FMS
    TMS_TRACK -->|"RocketMQ<br>物流费用确认"| FMS

订单履约链路里，最容易被问到的是“为什么有的地方用 Feign，有的地方用 MQ”。

订单创建时冻结库存必须用同步方式，因为 OMS 必须立即知道库存是否足够。如果库存不足，订单不能创建成功；如果订单创建成功但库存没有冻结，就会出现超卖。因此这里使用 Feign 同步调用 WMS，并用 Seata 保证 OMS 订单入库和 WMS 冻结库存的原子性。

订单接入平台 Webhook 后，通常会先验证签名和幂等，然后快速返回 200，再把原始请求放入 MQ 异步处理。原因是外部平台 Webhook 有超时限制，如果 SaaS 在 HTTP 请求里完成所有业务，平台可能因为超时重发，造成重复订单。

订单发货、物流轨迹、财务结算更适合用 MQ。比如 TMS 已经在物流商系统创建好运单，如果回写 OMS 失败，不可能要求物流商回滚这个运单。更合理的做法是 TMS 本地保存运单，然后通过可靠消息通知 OMS，失败后重试补偿，保证最终一致。

1.5 库存与补货闭环图

库存不是孤立数据，它会被订单消耗，被采购补充，被 BI 分析后再次驱动采购。

flowchart LR
    OMS["OMS<br>订单销量 取消 退款"]
    WMS["WMS<br>实物库存 冻结库存 在途库存 不良品 预留库存"]
    BI["BI<br>销售预测 库存周转 ABC 分类"]
    PMS["PMS<br>补货建议转采购申请"]
    SRM["SRM<br>供应商等级和供货能力"]
    FMS["FMS<br>利润率 现金流 采购预算"]

    OMS -->|"XXL-Job ETL<br>销量和退款数据"| BI
    WMS -->|"XXL-Job ETL<br>库存快照和周转数据"| BI
    FMS -->|"XXL-Job ETL<br>利润和现金流数据"| BI
    BI -->|"算法计算<br>安全库存 建议采购量 建议采购时间"| PMS
    SRM -->|"Feign 同步<br>可合作供应商和评级"| PMS
    FMS -->|"Feign 或审批流<br>预算和付款风险"| PMS
    PMS -->|"采购入库<br>补充库存"| WMS
    WMS -->|"库存可用量变化<br>支撑订单履约"| OMS

库存闭环的业务逻辑是：

OMS 提供销量和退款趋势，WMS 提供真实库存、冻结库存、在途库存和库存周转，FMS 提供利润率、现金流和采购预算。BI 结合这些数据计算补货建议，比如未来 14 天预计销量、安全库存、采购提前期、供应商交期、当前在途库存。系统不会直接自动下采购单，而是生成采购建议，由采购负责人确认后进入 PMS 的采购申请流程。

这条链路适合面试中讲“柔性供应链”的价值。柔性不是简单“库存少”，而是系统能根据销售速度、库存状态、供应商交付能力和资金情况动态调整采购计划，减少缺货和滞销。

1.6 财务结算与数据分析链路图

FMS 的核心不是“记账”，而是把订单收入、平台扣费、采购成本、物流成本、广告费、VAT、汇率变化整合起来，形成可追溯的利润和现金流。

flowchart TB
    OMS["OMS<br>订单收入 退款 售后"]
    PMS["PMS<br>采购应付 付款状态"]
    WMS["WMS<br>库存成本 退货残值"]
    TMS["TMS<br>预估运费 实际运费 物流账单"]
    PLATFORM["电商平台账单<br>佣金 广告费 退款 结算净额"]
    BANK["银行流水<br>平台到账 供应商付款 物流付款"]
    RATE["汇率服务<br>每日汇率"]
    FMS["FMS<br>对账 利润 应收应付 VAT 现金流"]
    BI["BI<br>利润看板 KPI 经营分析"]

    OMS -->|"RocketMQ<br>订单完成和退款事件"| FMS
    PMS -->|"MQ 或 Feign<br>采购应付和付款申请"| FMS
    WMS -->|"ETL 或 Feign<br>出库成本 退货质检结果"| FMS
    TMS -->|"RocketMQ<br>物流费用确认和差异"| FMS
    PLATFORM -->|"文件导入或 API<br>平台结算报告"| FMS
    BANK -->|"导入或 API<br>实际到账和付款流水"| FMS
    RATE -->|"XXL-Job<br>同步汇率"| FMS
    FMS -->|"XXL-Job ETL<br>利润快照 应收应付 现金流 KPI"| BI

FMS 的数据来源非常多，所以必须保留来源单据 ID 和原始文件地址。比如平台账单对账时，系统会导入 Amazon 结算报告，把账单主表和账单明细表落库，再和 OMS 订单、TMS 物流费用、广告费、退款数据做匹配。不是所有差异都代表错误，有些是跨结算周期、平台冻结、退款未完成、币种折算、物流商补收费用导致的时间差或金额差。

BI 不建议直接在线扫描所有业务明细表。更稳妥的做法是由 XXL-Job 定时 ETL，把订单、库存、财务、物流、采购数据汇总到指标表或快照表，再给 Dashboard 查询。热点报表可以缓存到 Redis，避免每次打开看板都执行大 SQL。

1.7 权限安全与 SaaS 运营支撑图

权限安全和 SaaS 运营不参与某一张业务单据的流转，但它支撑所有业务模块。没有权限、租户隔离、套餐限制、审计日志和监控，这套系统无法作为 SaaS 产品交付给多个企业客户。

flowchart TB
    subgraph SUPPORT["支撑系统"]
        AUTH["Auth 权限安全<br>登录 Token RBAC 数据权限 审计"]
        OPS["SaaS 运营<br>租户注册 套餐 到期 用量限制"]
        GATEWAY["Gateway 网关<br>统一入口 鉴权 限流 路由"]
        MONITOR["监控告警<br>技术指标和业务指标"]
    end

    subgraph BUSINESS["业务系统"]
        SRM["SRM"]
        PMS["PMS"]
        WMS["WMS"]
        PIM["PIM"]
        OMS["OMS"]
        TMS["TMS"]
        FMS["FMS"]
        BI["BI"]
    end

    GATEWAY -->|"统一路由<br>Token 解析 基础限流"| AUTH
    AUTH -->|"ThreadLocal<br>tenantId userId role permission"| SRM
    AUTH -->|"ThreadLocal<br>tenantId userId role permission"| PMS
    AUTH -->|"ThreadLocal<br>tenantId userId role permission"| WMS
    AUTH -->|"ThreadLocal<br>tenantId userId role permission"| PIM
    AUTH -->|"ThreadLocal<br>tenantId userId role permission"| OMS
    AUTH -->|"ThreadLocal<br>tenantId userId role permission"| TMS
    AUTH -->|"ThreadLocal<br>tenantId userId role permission"| FMS
    AUTH -->|"ThreadLocal<br>tenantId userId role permission"| BI
    OPS -->|"套餐功能和数量限制<br>供应商数 仓库数 订单量 BI能力"| BUSINESS
    BUSINESS -->|"审计日志和业务指标<br>操作记录 错误率 失败率"| MONITOR

权限安全的核心是四层：

身份认证：用户登录后生成 AccessToken 和 RefreshToken，后续请求通过 Token 识别用户。
功能权限：RBAC 控制用户能不能进入某个菜单、点击某个按钮、调用某个接口。
数据权限：在租户内部继续限制数据范围，比如运营只能看自己负责店铺，仓库管理员只能看自己负责仓库。
审计日志：供应商审核、库存调整、付款审批、角色授权、套餐变更等高风险操作必须记录。

SaaS 运营的核心是租户生命周期和套餐限制。租户注册后初始化管理员、角色、菜单、字典和默认配置。试用到期、套餐到期、超过用量限制时，系统可以提醒、限制新增、进入只读状态或引导续费。所有业务表都必须带 tenant_id，不能只依赖前端传参做隔离。

1.8 系统间调用关系总表

下面这张表把所有核心跨系统关系集中列出来。面试时如果被问“你这个模块和其他模块怎么交互”，可以从这里挑对应模块展开。

起点系统	目标系统	关联业务	推荐技术方式	为什么这样设计
SRM	PMS	PMS 创建采购申请、询价单、采购单时选择供应商	Feign 同步	必须立即判断供应商是否审核通过、是否停用、资质是否过期
PMS	SRM	供应商月度绩效评分读取采购履约数据	XXL-Job + Feign 分页查询	评分是周期性统计，不需要实时计算
PIM	PMS	采购明细引用 SKU、采购价格和基础属性	Feign 同步	采购单保存 SKU ID，创建时要校验 SKU 是否存在
PIM	WMS	库存表和库存流水引用 SKU 信息	Feign 同步或本地冗余	WMS 要知道 SKU 名称、规格、单位、条码，常用字段可冗余提高查询效率
PIM	OMS	订单创建时校验商品状态、价格、SKU 属性	Feign 同步	OMS 必须立即判断商品是否可售
PIM	TMS	创建运单时读取重量、体积、电池、液体、HS 编码	Feign 同步	物流渠道过滤和清关申报依赖商品属性
PIM	FMS	SKU 级利润核算需要商品分类和 SKU 信息	ETL 或 Feign 查询	财务报表按 SKU、品类、店铺维度分析
PMS	WMS	采购到货后收货、质检、入库、增加库存	Feign + Seata	采购单收货数量和 WMS 库存必须保持一致
WMS	PMS	入库结果回写采购单，支持部分收货和异常收货	同步返回或 MQ	入库成功后 PMS 更新 received_qty 和采购单状态
PMS	FMS	收货后生成采购应付账款，付款后更新采购付款状态	MQ 或 Feign	应付生成可异步，付款状态需要明确回写
FMS	PMS	财务付款确认后回写采购单付款状态	Feign 或 MQ	PMS 需要展示未付款、部分付款、已付款
外部平台	OMS	订单、退款、平台状态同步	Webhook + MQ 或 API 定时拉取	Webhook 要快速返回，业务处理放到 MQ 消费端
OMS	PIM	查询商品信息、价格、SKU 状态	Feign 同步	订单创建必须立即校验商品是否可售
OMS	WMS	订单创建冻结库存	Feign + Seata	库存不足要立即失败，订单和库存冻结要保持原子性
OMS	WMS	订单取消释放库存	MQ 异步	取消后释放库存允许最终一致，失败可重试
OMS	WMS	发货任务、拣货出库、扣减库存	MQ 异步或 WMS 主动处理	发货链路高频，适合削峰和解耦
WMS	OMS	出库完成后更新订单发货状态	RocketMQ	WMS 不应该被 OMS 接口稳定性阻塞
WMS	TMS	出库完成后通知 TMS 创建运单任务或确认交运	RocketMQ	物流商 API 不稳定，适合异步处理和重试
OMS	TMS	OMS 拆单后传递包裹、地址、发货要求	Feign 或 MQ	需要立即预估运费时用 Feign，只是发货任务用 MQ
TMS	OMS	运单号、面单、发货状态、签收状态回写	RocketMQ	物流状态变化频繁，异步最终一致更合适
TMS	FMS	物流费用确认、物流账单差异、物流应付	RocketMQ	费用确认不应阻塞运单主流程
OMS	FMS	订单完成、退款完成后触发财务核算	RocketMQ	财务结算失败不影响订单状态完成
WMS	FMS	出库成本、库存成本、退货残值	ETL 或 Feign	利润核算需要成本数据，但不一定实时查询明细
外部平台	FMS	平台结算报告、佣金、广告费、退款、打款净额	文件导入或平台 API	平台账单是财务对账的真实来源之一
银行账户	FMS	平台实际到账、供应商付款、物流付款流水	文件导入或银行 API	现金流要以实际到账和实际付款为准
FMS	BI	利润快照、现金流、应收应付、VAT 数据	XXL-Job ETL	BI 查汇总数据，不直接扫财务明细
OMS	BI	销量、订单完成率、退款率、履约时效	XXL-Job ETL	用于销售预测、运营 KPI、异常预警
WMS	BI	库存周转、缺货风险、盘点差异、ABC 分类	XXL-Job ETL	用于补货建议和库存健康度分析
TMS	BI	物流时效、签收率、异常率、渠道成本	XXL-Job ETL	用于物流渠道优化
SRM	BI	供应商等级、交付稳定性、质量表现	XXL-Job ETL	用于供应商结构分析和采购风险预警
BI	PMS	补货建议转采购申请	Feign 或人工确认	BI 给建议，采购负责人确认后进入 PMS 流程
Auth	所有业务系统	登录认证、功能权限、数据权限、租户隔离	Gateway + Sa-Token + AOP + MyBatis 插件	统一身份和权限，避免每个模块重复实现
SaaS 运营	所有业务系统	套餐功能、数量限制、租户到期、只读控制	AOP + Redis 缓存 + 数据库配置	SaaS 商业化能力必须贯穿所有模块
监控告警	所有业务系统	接口错误率、订单失败、库存同步失败、轨迹拉取失败、账单解析失败	Prometheus + Grafana + 告警规则	上线后要能及时发现技术和业务异常

1.9 Feign、MQ、Seata 的选择口诀

这套项目里，系统之间不是“能用 MQ 就都用 MQ”，也不是“微服务之间都用 Feign”。可以用下面的判断方式：

需要立即知道结果，用 Feign。

例如订单创建时冻结库存、采购单选择供应商、运单创建前查询商品重量。调用方必须根据返回结果决定当前操作是否继续，所以不能异步。

两个系统必须同时成功，用 Seata。

例如订单创建和库存冻结，采购收货和库存增加。如果一个成功另一个失败，就会出现严重数据不一致，这种链路可以使用 Seata AT 模式做分布式事务。

下游失败不应该阻塞主流程，用 MQ。

例如订单完成后财务结算、TMS 轨迹签收后通知 OMS、物流费用确认后通知 FMS。这类业务允许短暂不一致，通过消息重试、消费幂等、本地消息表、死信队列保证最终一致。

周期性统计、扫描、补偿，用 XXL-Job。

例如供应商评分、资质到期提醒、物流轨迹批量拉取、KPI 预警、报表缓存预热、库存 ABC 分类。定时任务要考虑分片、分页、幂等和失败重试。

第二部分每个系统核心业务总结

2.1 Day01 项目认知与架构底座

Day01 不是一个独立业务系统，而是整个项目的底座。它要解决的是三个问题：这个项目服务谁、解决什么业务痛点、用什么技术架构支撑后续八个业务模块。

业务定位

项目面向跨境电商卖家。卖家可能同时在 Amazon、TikTok Shop、Shopee、Shopify、Temu 等平台销售商品，但采购、仓库、库存、订单、物流、财务并不会天然打通。如果没有供应链系统，卖家会遇到库存不准、平台超卖、采购补货滞后、物流费用不透明、财务对账困难、利润算不清等问题。

柔性供应链的核心不是“库存越少越好”，而是让系统具备快速响应能力。销售上升时能及时补货，销售下降时能控制采购；某个供应商交付异常时能快速切换备选供应商；某个物流渠道停用时能切换其他渠道；某个平台销量突增时能动态调整库存分配。

业务全景

整个项目可以按供应链上下游理解：

上游是 SRM 和 PMS，解决供应商合作、采购需求、询价比价、采购下单、收货和应付。
中游是 PIM、OMS 和 WMS，解决商品资料、订单接入、库存管理、入库、出库、盘点。
下游是 TMS 和 FMS，解决物流履约、轨迹、物流费用、平台账单、利润和资金。
BI 负责把业务数据变成指标、预测和补货建议。
Auth 和 SaaS 运营负责多租户、权限、安全、套餐、部署和运维。

技术底座

项目采用微服务架构。前端请求先经过 Nginx，再到 Gateway，由 Gateway 统一路由、鉴权、限流和跨域处理。业务服务通过 Nacos 注册发现，通过 OpenFeign 做同步调用，通过 RocketMQ 做异步解耦，通过 Seata 处理少数强一致的跨服务事务。MySQL 保存业务数据，Redis 用于缓存、分布式锁、幂等和限流，XXL-Job 负责定时任务。

多租户底线

所有业务表都要有 tenant_id。同一套系统服务多个卖家，每个卖家是一个租户。字段隔离方案适合本项目和中小型 SaaS，因为成本低、部署简单、扩展方便。真正查询数据时不能只靠前端传租户 ID，后端必须从登录 Token 解析租户身份，并通过 MyBatis-Plus 多租户插件或业务代码强制追加租户条件。

五流合一

这个项目贯穿五种流：商流、物流、资金流、信息流、单据流。商流体现订单和销售；物流体现采购入库、仓库出库、运输签收；资金流体现平台打款、供应商付款、物流费用；信息流体现商品、库存、供应商、运单、账单数据；单据流体现采购单、入库单、出库单、运单、账单、付款单。面试时把五流讲清楚，会比单纯说“我做了 CRUD”更有项目感。

2.2 SRM 供应商管理系统

SRM 解决的是“供应链上游和谁合作”的问题。采购不是随便找一个供应商下单，而是要经过供应商准入、资质审核、联系人维护、报价协同、绩效评分、分级管理和风险预警。

供应商全生命周期

供应商一般从草稿开始，由采购专员录入基础信息、联系人、收款账户、主营品类和资质文件。提交审核后进入待审核状态，采购负责人或租户内部审核角色查看营业执照、认证证书、合作范围、账期、银行账号等资料。审核通过后供应商变为正常合作状态，可以被 PMS 采购模块选择；审核拒绝则退回修改；资质过期、连续低评级或合作风险较高时，可以进入预警、暂停或停用状态。

这个生命周期必须使用状态机控制。不能允许前端直接传一个状态值，把待审核供应商改成已通过。后端要维护合法流转白名单，例如草稿可以提交审核，待审核可以通过或拒绝，已通过可以停用，已停用不能直接变成已通过。并发审核时要用乐观锁或状态条件更新，避免两个负责人同时审核导致重复创建账号或重复发送通知。

供应商资质与文件安全

资质文件包括营业执照、质量认证、授权证书、检测报告等。上传文件不能只看扩展名或浏览器传来的 MIME 类型，因为这些都可以伪造。后端需要校验文件大小、扩展名、Magic Bytes、存储路径和访问权限。文件一般存储到 OSS，本地只保存文件 URL、文件类型、有效期、审核状态和上传人。

资质到期提醒适合用 XXL-Job。每天凌晨扫描 30 天内到期的资质，按租户、供应商、文件类型去重发送站内信或邮件。任务要支持分页和幂等，不能因为任务重跑就重复通知同一个人。

供应商 Portal

供应商 Portal 是供应商侧协同入口。供应商不是 SaaS 的租户员工，它只能看到与自己有关的采购单、送货单、对账单和通知。Portal 账号可以在供应商审核通过后创建，也可以审核前先创建一个低权限临时账号，审核通过后再开通完整功能。

如果同一个供应商给多个租户供货，业务上可以有一份全局主体资料，也可以在每个租户下建立一条合作关系。当前实现更容易落地的方式是：每个租户维护自己的供应商合作记录，供应商 Portal 登录后根据 tenant_id + supplier_id 强制隔离数据。

绩效评分与分级

供应商评分不是供应商自己填的，而是系统根据业务数据自动计算，再由采购负责人参考使用。常见维度包括准时交付率、质量合格率、价格稳定性、响应速度。评分来源会关联 PMS 的采购履约数据、WMS 的质检数据、FMS 的对账付款数据。

评级策略不能完全由 SaaS 平台强制“一刀切”。比较合理的设计是系统自动预警和限制默认流程，例如 C 级供应商提示风险、减少推荐、暂停自动生成新采购单，但租户管理员可以通过特殊审批继续采购。这样既体现系统风控，又保留企业自己的业务决策权。

2.3 PMS 采购管理系统

PMS 解决的是“买什么、向谁买、买多少、什么时候到货、什么时候付款”的问题。它连接 SRM、PIM、WMS 和 FMS，是供应链补货和采购履约的核心。

采购需求来源

采购需求有三类来源。第一类是人工申请，采购专员根据业务判断手动创建采购申请。第二类是库存预警，当 WMS 库存低于安全库存或预计可售天数不足时，系统生成采购建议。第三类是 BI 销售预测，根据未来销量、在途库存、采购提前期和安全库存计算建议采购量。

采购申请不会直接变成采购订单。它需要经过审批、询价、比价、供应商选择、采购单创建等环节。这样可以避免采购金额失控，也能保证供应商选择有依据。

询价比价

询价不是只比最低价。真实采购要综合考虑价格、交期、质量、供应商等级、历史履约、最小起订量 MOQ、账期等因素。系统可以设计综合评分算法，例如价格权重 40%，交期 25%，质量 20%，供应商评级 15%。最终推荐分数最高的供应商，但采购负责人仍可人工确认。

采购订单状态机

采购订单状态比普通订单复杂，因为它支持部分收货、部分付款、供应商确认和退货。典型状态包括待确认、待发货、部分到货、全部到货、部分付款、已付款、已关闭、已取消。状态机要解决两个问题：防止非法跳转，清楚表达业务进度。

例如采购 1000 个耳机，供应商第一次只发 600 个，WMS 收货后 PMS 明细表的 received_qty 增加 600，采购单变成部分到货。第二次再收 400 个，明细全部收齐后才变成全部到货。付款也可能先付一部分，所以收货状态和付款状态不能简单混在一个字段里。

采购入库与 WMS 联动

采购货物到仓后，仓库人员根据采购单创建或确认收货单，填写各 SKU 的合格数量和不合格数量。合格数量进入可售库存或待上架库存，不合格数量进入不良品库存。这个过程会同时影响 PMS 的采购单收货数量、WMS 的库存数量和库存流水。

如果 PMS 和 WMS 是独立服务并且独立数据库，采购入库可以用 Feign + Seata 处理强一致。任何一步失败，采购单收货数量和库存都要回滚。入库完成后再通过 MQ 通知 FMS 创建应付账款，因为应付生成允许最终一致。

应付账款

应付账款表示采购方欠供应商的钱。它通常在收货确认后生成，而不是采购单刚创建就生成。账期可以来自供应商合作协议，例如月结 30 天、到货后 15 天付款。FMS 或 PMS 的定时任务会提前提醒财务专员处理付款。付款完成后，采购订单状态更新为部分付款或已付款。

2.4 WMS 仓储管理系统

WMS 解决的是“货在哪里、有多少、能不能卖、怎么出入库、库存是否准确”的问题。它是多平台库存统一管理的核心。

仓库与库位

仓库可以是自建仓、三方仓、海外仓、FBA 仓、保税仓等。自建仓和普通 3PL 仓更适合按本系统的入库、上架、拣货、盘点流程管理。保税仓涉及海关监管，出入库、盘点、退货可能有更严格的监管流程，系统通常需要对接保税仓或海关系统，而不是完全套用普通仓流程。

库位表代表仓库里的具体存放位置，可以理解为“某个区域、某排货架、某层、某格”。一个库位不一定只能放一个 SKU，取决于仓库策略。精细化仓通常要求一个库位一个 SKU，方便拣货和盘点；临时区、退货区、散货区可能允许混放，但系统要记录清楚批次和数量。

库存五种数量

WMS 不能只保存一个 quantity。真实库存至少要区分：

实物库存：仓库里真实存在的数量。
冻结库存：已经被订单占用但还没出库的数量。
在途库存：采购或调拨已经发出但还没到仓的数量。
不良品库存：质检不合格或退货不可售的数量。
预留库存：人为预留给活动、大客户或特殊订单的数量。

可售库存一般等于实物库存减去冻结、不良品和预留。订单创建时冻结库存，不立即扣减实物；仓库出库时同时扣减实物和冻结；订单取消时释放冻结库存。这样可以避免订单取消时反复修改实物库存，也能清楚区分“仓库里有货”和“可卖给新订单的货”。

入库、出库和库存流水

入库包括采购入库、退货入库、调拨入库。出库包括销售出库、调拨出库、报损出库。每次库存变化都必须写库存流水，记录变动前数量、变动数量、变动后数量、业务单号、操作人和时间。库存流水应该只增不改不删，用于审计和问题追溯。

出库通常使用 FIFO 先进先出策略，优先出最早入库或最早到期的批次。这样可以减少库存积压和过期风险。拣货时还可以按库区、排号、层号排序，减少仓库人员行走距离。

库存并发与性能

多平台订单同时进入时，最容易出现超卖。冻结库存要用数据库原子更新，例如在 WHERE 条件中判断可售库存是否足够，满足才执行 frozen_qty = frozen_qty + quantity。如果更新行数为 0，说明库存不足。

热点 SKU 的库存查询可以用 Redis 缓存。更新库存后不要直接改缓存，比较稳妥的是先更新数据库，事务提交后删除缓存，下次查询再加载。库存流水表数据量会非常大，可以按月分表，历史数据归档到 OSS 或冷库。

与其他模块关系

PMS 入库会增加库存，OMS 创建订单会冻结库存，OMS 取消订单会释放库存，WMS 出库会通知 TMS 发货，退货入库会回写 OMS 售后状态，库存快照和周转数据会进入 BI，库存成本会被 FMS 用于利润核算。

2.5 PIM 商品管理系统

PIM 解决的是“卖什么、商品信息如何标准化、不同平台如何复用商品资料”的问题。它是商品主数据中心，不是电商平台本身。

SPU 与 SKU

SPU 表示标准产品单元，维护商品共性信息，例如商品标题、品牌、类目、主图、详情、材质。SKU 表示库存量单位，维护具体可销售规格，例如颜色、尺寸、型号、条码、重量、体积、成本价和销售价。

例如一款 T 恤是一个 SPU，红色 M 码、红色 L 码、黑色 M 码分别是不同 SKU。订单、库存、采购、物流、财务最终都要落到 SKU，因为库存数量、采购成本、销售价格和物流重量都是 SKU 级别的。

分类属性模板

不同类目的商品属性不同。服装关注颜色、尺码、材质；电子产品关注电压、插头、是否带电池；美妆产品关注容量、成分、保质期。PIM 通过分类属性模板控制不同类目需要填写哪些属性，避免所有商品都用一张大宽表。

多语言与多平台发布

跨境商品需要多语言标题、卖点、详情和图片。PIM 中的 product_i18n 表保存不同语言版本，但电商平台不会主动读取 SaaS 数据库。真正上架时，要通过平台 API 把商品资料发布到 Amazon、Shopify、TikTok Shop 等平台，或者导出平台要求的模板文件再上传。

供应链系统维护商品资料，是为了统一管理商品主数据、减少多平台重复录入，并为 OMS、WMS、TMS、FMS 提供一致的 SKU 信息。商品上下架在 SaaS 系统里更多是“内部可售状态”和“平台发布状态”的管理，不是强行干涉电商平台，而是记录和驱动平台 API 同步。

价格体系

价格查询不是为了替代电商平台成交价，而是为了内部经营管理。PIM 需要维护基础售价、平台售价、促销价、币种、国家和生效时间。OMS 接单后会保存平台真实成交价，FMS 利润核算以订单真实金额和平台账单为准。PIM 价格主要用于上架前定价、利润预估和平台发布。

与其他模块关系

PMS 采购 SKU，WMS 管理 SKU 库存，OMS 根据 SKU 接单和冻结库存，TMS 根据 SKU 重量、体积、电池液体属性过滤物流渠道，FMS 按 SKU 核算利润，BI 按 SKU 做销量预测和 ABC 分类。

2.6 OMS 订单管理系统

OMS 解决的是“多平台订单统一接入、统一履约、统一状态跟踪”的问题。它不是电商平台交易系统，而是卖家内部的订单履约中心。

多平台订单接入

订单可以通过两种方式进入系统：平台 Webhook 推送，或者系统定时调用平台 API 拉取。Webhook 接收后要先做签名验证，确认请求确实来自平台；再做幂等校验，避免平台超时重发导致重复订单；然后快速返回 200，把原始请求放入 MQ，由消费者异步转换、校验、保存订单。

不同平台订单字段不一样，OMS 要做统一模型。比如 Amazon、Shopify、Shopee 的订单号、买家地址、SKU、币种、金额、税费、物流要求都可能不同，系统需要用适配器把外部订单转换成内部订单主表和订单明细。

订单与库存

订单创建后必须冻结库存。冻结库存要同步调用 WMS，因为如果库存不足，订单不能进入正常履约。这个链路通常使用 Feign + Seata，保证 OMS 创建订单和 WMS 冻结库存同时成功或同时失败。

发货后扣减库存可以异步处理。仓库出库完成后 WMS 扣减实物库存和冻结库存，再通过 MQ 通知 OMS 更新发货状态。订单取消时释放冻结库存，也可以用 MQ 做最终一致。

订单状态机

订单状态包括待处理、待风控、待备货、待发货、已发货、已签收、已完成、已取消、退款中、已退款等。状态机的作用是防止非法跳转，例如待付款不能直接变成已签收，已完成订单不能随意取消。

订单状态还会触发后置动作。例如进入待发货时通知 WMS 拣货，进入已发货时等待 TMS 运单轨迹，进入已签收后启动售后周期，超过退货周期后更新为已完成并通知 FMS 结算。

拆单、合单和风控

拆单用于多仓发货、库存不足拆分、超大件拆分、平台限制拆分。一个父订单可以拆成多个子订单，每个子订单独立出库和物流。合单用于同一买家、同一地址、短时间内多个订单合并发货，减少物流成本。

风控规则可以检查黑名单地址、高风险国家、金额异常、SKU 禁售、物流限制等。风控一般不直接删除订单，而是把订单打标为待人工处理。

售后退款

退款实际发生在电商平台，OMS 接收退款通知并同步内部状态。未发货退款释放冻结库存；已发货仅退款不影响库存；退货退款要等待 WMS 退货入库和质检，合格品恢复可售，不合格品进入不良品库存。退款完成后还要通知 FMS 调整收入和利润。

2.7 TMS 物流管理系统

TMS 解决的是“用哪条物流渠道发货、如何创建运单、如何追踪轨迹、如何核算物流费用”的问题。

物流商、渠道和费率

物流商是 DHL、UPS、USPS、顺丰国际、4PX、云途等承运方。物流渠道是物流商下面的具体服务产品，例如标准小包、专线、快递、带电渠道、敏感货渠道。物流费率表保存卖家和物流商约定的合同价、报价表或接口同步价，用于创建运单前预估费用和后续对账。

费率表不是 SaaS 平台自己决定快递价格。最终费用以物流商账单为准，但系统必须先有预估价，否则无法做智能渠道推荐、利润预估和异常费用识别。

渠道规则引擎

创建运单前，TMS 会根据目的国家、重量、体积、材积重、是否带电、是否液体、是否敏感货、时效要求、物流商可用状态、价格等条件筛选渠道。筛选后再计算评分，综合考虑费用、时效、稳定性和历史异常率，推荐最优渠道。

渠道禁运规则来自物流商报价表、物流商 API、人工配置和历史失败数据。渠道停用不能只靠人工维护，系统要通过 API 同步、失败率监控和运营配置共同管理。

运单创建与幂等

运单创建涉及 TMS 和外部物流商。TMS 端要先做幂等，防止同一订单或同一包裹重复创建运单。可以用租户 ID、订单号、包裹号建立唯一索引，也可以用 Redis 分布式锁防止集群并发。

物流商端幂等更复杂。TMS 调用物流商 API 超时后，物流商可能已经创建成功但 TMS 没收到响应。是否能通过客户订单号查询已创建运单，取决于物流商是否提供查询接口。如果提供，重试前可以先查；如果不提供，就需要在 TMS 侧标记处理中、人工确认或使用物流商支持的幂等字段。

轨迹追踪

轨迹可以由物流商 Webhook 推送，也可以由 TMS 定时拉取。定时拉取要按物流商分组、分页查询待更新运单，并为不同物流商设置独立线程池和限流参数，避免某一个物流商慢或限流影响全部任务。

物流商返回的轨迹状态各不相同，TMS 要标准化成内部状态，例如已创建、已揽收、运输中、清关中、派送中、已签收、异常、退回。签收和异常轨迹通过 MQ 通知 OMS。

费用核算和退货物流

TMS 会在创建运单时计算预估费用，物流商账单到达后导入实际费用，再做差异分析。差异可能来自计费重量变化、偏远附加费、燃油附加费、退件费、改派费、汇率变化等。差异在容忍范围内可以自动确认，超过阈值需要人工复核。

退货标签是给买家寄回商品用的退货面单。卖家可以提前生成 Prepaid Label，也可以在买家申请退货后生成。退货入库后，WMS 质检结果会影响 OMS 退款状态和 WMS 库存状态。

2.8 FMS 财务结算系统

FMS 解决的是“钱从哪里来、扣了哪些费用、欠谁多少钱、利润到底是多少”的问题。跨境财务复杂在平台多、币种多、费用多、结算周期不一致。

平台账单对账

电商平台会周期性生成结算报告，里面包含订单收入、平台佣金、广告费、仓储费、退款、赔付、税费、结算净额等。财务专员可以导入账单文件，系统也可以通过平台 API 拉取。finance_platform_bill 保存账单批次主信息，finance_bill_item 保存账单明细。

对账不是简单 100% 匹配。系统有订单但平台账单没有，可能是订单未进入本期结算、平台冻结复查、跨结算周期、买家未确认收货。平台账单有但系统没有，可能是漏单、历史订单、平台补扣费用。金额不一致可能是汇率、退款、广告费、物流补收、平台佣金调整导致。

SKU 级利润核算

利润不能只按订单总金额算。一个订单里可能有多个 SKU，每个 SKU 成本、物流、佣金、广告分摊都不同，所以要做 SKU 级利润快照。收入来自 OMS 和平台账单，采购成本来自 PMS/WMS，物流成本来自 TMS，平台费用来自平台账单，汇率来自汇率表，VAT 来自税务规则。

利润快照可以在订单完成、账单确认、物流费用确认时多次更新。预估利润用于运营决策，确认利润用于财务报表。

多货币和汇兑损益

跨境卖家会遇到 USD、EUR、GBP、JPY、CNY 等多币种。系统通常保存原币金额和本位币金额。订单发生时按当日汇率折算，实际到账时按到账日汇率折算，两者差额就是汇兑损益。

汇兑损益不是系统能“修复”的错误，而是经营中真实发生的收益或损失。财务系统需要记录、归因、汇总，帮助经营者判断汇率变化对利润的影响。

应收应付和现金流

应收账款主要是平台待打款，来源于平台结算周期。平台不是每天实时把钱打给卖家，而是按自己的结算周期扣除费用后打款。应付账款包括供应商采购款、物流商费用、广告费、服务费等。现金流预测要把未来几天预计平台到账和预计付款放在一起，判断资金是否紧张。

VAT 合规

VAT 数据由系统根据订单销售国家、税率、退款和申报周期计算并导出。系统计算的是申报依据和内部留痕，不代表税务机关已经生成缴款单。实际申报通常由财务专员或税务顾问登录官方系统完成，申报完成后再把状态、申报金额、缴税凭证记录回 FMS。

2.9 BI 数据分析系统

BI 解决的是“经营情况看不清、问题发现太晚、补货靠经验”的问题。它不是业务录入系统，而是把各模块数据汇总成指标、报表、预警和决策建议。

ETL 数据架构

BI 不适合每次查询都直接扫 OMS、WMS、FMS 的明细表。更合理的方式是通过 XXL-Job 做 ETL：从业务表抽取数据，清洗口径，转换指标，加载到报表宽表、快照表或指标表。Dashboard 查询的是汇总后的结果，性能更稳定。

核心 KPI

供应链 KPI 包括销售额、订单量、退款率、履约时效、缺货率、库存周转天数、采购准时率、供应商合格率、物流签收时效、物流异常率、毛利率、现金流覆盖天数等。KPI 的目的不是“做图好看”，而是帮助管理者发现异常并做决策。

销售预测和智能补货

销售预测可以用移动平均、加权移动平均、指数平滑等基础算法。系统先清洗异常值，例如某天大促销量异常高，不能直接当作日常需求；再结合节假日、平台活动、历史同期数据调整预测值。

智能补货基于预测销量、安全库存、当前库存、冻结库存、在途库存、供应商交期和最小起订量计算建议采购量。建议不是自动下单，而是生成采购建议，由采购负责人确认后进入 PMS。

ABC 库存分类

ABC 分类按销售额、利润贡献或出库频次把 SKU 分为 A、B、C 三类。A 类 SKU 数量少但贡献高，需要高频盘点、更严格缺货预警、更优先补货；B 类正常管理；C 类可能销量低、周转慢，要控制采购甚至清仓。ABC 分类会定期更新，A 类可能下降为 B 类，C 类也可能因为销量增长升级。

报表缓存

经营首页、库存看板、利润看板这类高频报表可以缓存到 Redis。缓存可以由定时任务提前预热，也可以首次查询后写入。缓存更新要根据数据实时性要求选择策略：经营总览可以 5 到 15 分钟更新一次，财务确认报表可以按日更新，实时库存看板则要谨慎缓存。

2.10 Auth 权限安全与 SaaS 运营

Day08 是所有模块上线运行的支撑层。它解决的是“谁能登录、能做什么、能看哪些数据、租户如何运营、系统如何安全上线”的问题。

登录认证与 RBAC

登录时需要租户编码、用户名和密码，因为不同租户可能都有 admin。密码使用 BCrypt 存储，不能明文也不建议普通 MD5。登录成功后生成随机 AccessToken，并将 Token 与用户登录态保存到 Redis；RefreshToken 用于续签。

RBAC 把权限分配给角色，再把角色分配给用户。采购专员、仓库管理员、运营专员、物流专员、财务专员、租户管理员、供应商 Portal 用户都应该有不同权限。前端隐藏按钮只是体验优化，真正的权限校验必须在后端接口层完成。

租户隔离与数据权限

多租户隔离解决 A 公司不能看到 B 公司数据的问题。数据权限解决同一租户内部不同岗位看到不同范围的问题。例如美国站运营只能看美国店铺订单，广州仓管理员只能看广州仓库存，供应商 Portal 用户只能看自己的采购单和对账单。

接口安全

接口安全包括限流、SQL 注入防护、XSS 防护、敏感字段脱敏、重复提交拦截、审计日志。登录、验证码、文件上传、报表导出、批量导入都应该有不同限流阈值。供应商审核、库存调整、付款审批、角色授权等高风险操作必须写审计日志。

SaaS 运营

租户注册后要初始化管理员、角色、权限、菜单、字典和默认配置。套餐限制包括供应商数量、仓库数量、订单量、可对接平台数量、是否开通 Portal、是否使用高级 BI。套餐到期后可以先提醒，再限制新增，最后进入只读状态。

部署上线

生产部署要包含 Nginx、Gateway、业务服务、MySQL、Redis、RocketMQ、Nacos、监控和日志。Docker 解决环境一致性，docker-compose 适合课程和中小规模部署，CI/CD 负责自动测试、构建镜像、推送镜像和部署。上线后要监控技术指标和业务指标，例如接口错误率、订单失败率、库存同步失败、账单解析失败、轨迹拉取失败。

第三部分每个系统的面试总结

3.1 项目整体架构面试总结

简历定位

可以写成“跨境电商 SaaS 柔性供应链平台”，不要只写“后台管理系统”。项目亮点是多租户、微服务、供应链全链路、跨平台订单、库存一致性、物流对接、财务对账和 BI 决策。

推荐表达

我参与的是一个面向跨境电商卖家的 SaaS 供应链平台。系统把供应商、采购、仓储、商品、订单、物流、财务和 BI 打通，解决多平台销售下库存不准、采购补货滞后、物流费用不透明、财务利润算不清的问题。技术上采用 Spring Boot、Spring Cloud、Nacos、Gateway、OpenFeign、RocketMQ、Redis、MySQL、XXL-Job、Seata 和 Sa-Token，支持多租户隔离、权限控制、异步解耦和分布式事务。

高频问题

Q1：这个项目和普通电商系统有什么区别？

答：普通电商系统面向买家交易，重点是商品展示、购物车、支付和营销。这个项目面向跨境卖家内部管理，重点是供应商、采购、库存、订单履约、物流、财务和数据分析。买家仍然在 Amazon、TikTok Shop 等平台下单，我们系统接收订单后完成内部履约。

Q2：为什么微服务里有 Nginx 还需要 Gateway？

答：Nginx 更偏边缘层，负责 HTTPS、静态资源、反向代理和基础转发。Gateway 是微服务入口，负责服务路由、统一鉴权、租户上下文、限流、灰度和接口级控制。Nginx 可以在 Gateway 前面，后面也可以挂多个 Gateway 实例做高可用。

Q3：Feign、MQ、Seata 怎么选？

答：需要立即返回结果用 Feign，例如订单创建时冻结库存；下游失败不应阻塞主流程用 MQ，例如订单完成后通知财务；跨服务必须同时成功或失败用 Seata，例如订单创建和库存冻结。核心判断是实时性、一致性和链路长度。

Q4：多租户怎么做？

答：本项目采用字段隔离，所有业务表带 tenant_id。登录后从 Token 解析 tenantId 放到上下文，查询时由多租户插件或业务代码自动追加 tenant 条件。独立数据库方案隔离性更强，适合大客户私有化或强合规场景，但成本更高。

3.2 SRM 面试总结

适合写简历的方向

供应商管理模块适合强调状态机、文件安全、OSS、XXL-Job、供应商评分、Portal 数据隔离、审核幂等。

简历写法

负责供应商管理模块，完成供应商准入、资质文件、审核工作流、供应商 Portal、绩效评分和分级预警。使用状态机控制供应商生命周期，使用 OSS 存储资质文件，使用 XXL-Job 分片任务计算月度评分，使用乐观锁和幂等设计防止重复审核。

高频问题

Q1：供应商审核为什么要用状态机？

答：供应商状态有草稿、待审核、已通过、已拒绝、预警、停用等，不能靠前端传状态直接更新。状态机维护合法流转路径，后端统一校验，可以防止待审核直接变停用、已停用直接变已通过这类非法操作。

Q2：两个负责人同时审核通过怎么办？

答：审核接口要做幂等和并发控制。可以用 where id = ? and status = 待审核 and version = ? 做条件更新，只有一个请求能成功。审核通过后的创建 Portal 账号、发通知、写审核日志也要根据唯一键或业务状态防重复。

Q3：供应商评分没有采购数据怎么办？

答：不能直接给 0 分。没有采购数据不代表供应商表现差，只能说明本周期没有样本。合理做法是保留上期评分，并在评分记录里标记“本月无采购数据”。如果连续多月无采购，可以标记为不活跃供应商。

Q4：资质文件如何防止伪造类型？

答：不能只看文件后缀或 MIME 类型，因为都可以伪造。后端要校验扩展名、大小、Magic Bytes，必要时做病毒扫描。文件存 OSS，访问通过后端鉴权生成临时 URL，不能直接暴露永久公共地址。

Q5：C 级供应商是否一定不能采购？

答：系统可以默认预警、减少推荐、暂停自动生成采购单，但不应该完全替代企业决策。租户管理员可以通过特殊审批继续采购，并记录原因。这样既有风控，又保留业务弹性。

Q6：供应商 Portal 如何隔离数据？

答：Portal 用户不是租户内部员工，它除了 tenant_id 以外，还必须绑定 supplier_id。查询采购单、送货单、对账单时后端强制追加 tenant_id + supplier_id，不能相信前端传参。

3.3 PMS 面试总结

适合写简历的方向

采购管理模块适合强调采购状态机、询价比价算法、PMS/WMS 分布式事务、部分收货、应付账款账期管理。

简历写法

负责采购管理模块，覆盖采购需求、询价比价、采购订单、供应商确认、采购入库、采购退货和应付账款。设计采购订单状态机和综合比价算法，使用 Feign + Seata 实现采购入库与 WMS 库存一致，使用 XXL-Job 实现应付账款到期提醒。

高频问题

Q1：采购需求从哪里来？

答：有三类来源：人工创建、库存预警、BI 销售预测。人工创建适合临时采购；库存预警来自 WMS 安全库存；销售预测来自 BI 根据销量和交期计算的补货建议。

Q2：询价比价为什么不只看价格？

答：最低价不一定最优。采购还要考虑交期、质量、供应商等级、历史履约、MOQ 和账期。综合评分能避免只选低价导致延迟交付或质量问题。

Q3：采购订单为什么支持部分收货？

答：真实供应商可能分批发货。采购 1000 件商品，第一次到 600 件，第二次到 400 件。系统要在明细表记录采购数量、已收数量、未收数量，根据明细汇总判断采购单是部分到货还是全部到货。

Q4：采购入库为什么需要分布式事务？

答：确认收货会同时影响 PMS 采购单收货数量和 WMS 库存。如果 PMS 更新成功但 WMS 增加库存失败，就会出现采购单显示已收货但仓库没库存。独立服务独立数据库时，可以用 Seata 保证同时成功或回滚。

Q5：应付账款什么时候生成？

答：通常在收货确认后生成，而不是采购单创建时生成。因为付款依据通常是实际到货和质检结果。应付金额根据合格数量、采购单价、税费、折扣和账期计算。

Q6：付款后如何更新采购单？

答：财务确认付款后，FMS 回写 PMS，更新应付账款状态和采购单付款状态。如果只付一部分，采购单是部分付款；全部付清后才是已付款。

3.4 WMS 面试总结

适合写简历的方向

仓储管理模块适合强调库存冻结、库存流水、FIFO、Redis 缓存、RocketMQ 异步通知、按月分表、循环盘点。

简历写法

负责仓储管理模块，完成多仓库多库位、采购入库、销售出库、库存冻结、库存流水、盘点和调拨。设计五种库存数量模型，使用数据库原子更新防止超卖，使用 Redis 缓存热点库存，使用 RocketMQ 通知订单和物流系统，库存流水按月分表提升查询性能。

高频问题

Q1：为什么要冻结库存？

答：订单创建时如果直接扣实物库存，订单取消后又要加回，容易混乱。冻结库存表示这部分库存已经被订单占用但还没出库。发货时再同时扣减实物库存和冻结库存，订单取消时只释放冻结库存。

Q2：如何防止超卖？

答：冻结库存时使用数据库原子更新，在 WHERE 条件中判断可售库存是否足够。只有满足条件才更新冻结数量。如果更新行数为 0，说明库存不足。热点查询可以走 Redis，但扣减必须以数据库原子操作为准。

Q3：库存流水为什么只增不改不删？

答：库存是财务和履约的基础数据，必须可追溯。每次变动都写流水，记录变动前、变动后、业务单号和操作人。只增不改不删可以避免事后篡改，并支持还原历史库存。

Q4：Redis 缓存和数据库如何保证一致？

答：采用 Cache Aside。查询先读 Redis，未命中查数据库并写缓存。库存变动时先更新数据库，事务提交后删除缓存，下次查询重新加载。复杂库存不建议直接更新缓存，删除更稳。

Q5：库存流水表太大怎么办？

答：库存流水天然只增不删，可以按月分表，单表控制在可接受范围内。常用查询加复合索引，例如租户、SKU、仓库、时间。历史数据可以归档到 OSS 或冷库。

Q6：WMS 和 OMS/TMS 如何交互？

答：OMS 创建订单时同步调用 WMS 冻结库存；WMS 出库后通过 MQ 通知 OMS 更新发货状态，同时通知 TMS 创建或确认物流任务。这样可以把高频出库和后续订单、物流处理解耦。

3.5 PIM 面试总结

适合写简历的方向

商品管理模块适合强调 SPU/SKU 模型、分类属性模板、笛卡尔积生成 SKU、多语言内容、价格优先级、商品状态机和平台发布。

简历写法

负责商品中心模块，设计 SPU/SKU 两级商品模型、分类属性模板、多语言内容、价格体系和商品状态机。支持自动生成 SKU、多平台商品资料维护、上架前完整性校验，并为 OMS、WMS、TMS、FMS 提供统一商品主数据。

高频问题

Q1：SPU 和 SKU 区别是什么？

答：SPU 是标准产品单元，描述商品共性信息；SKU 是库存量单位，描述具体规格。库存、订单、采购、物流和利润都要落到 SKU，因为不同颜色尺寸可能库存、价格、重量和成本不同。

Q2：为什么供应链系统要管理商品上下架？

答：这里的上下架更多是内部可售状态和平台发布状态管理，不是绕过电商平台。系统维护商品完整性、价格、库存和多语言资料，再通过平台 API 或模板发布到平台。这样可以统一多平台商品资料。

Q3：电商平台如何读取多语言商品信息？

答：平台不会直接读 SaaS 数据库。SaaS 通过平台 API 把对应语言的标题、卖点、详情、图片发布到平台，或者导出平台模板再上传。product_i18n 是内部多语言资料库。

Q4：价格查询为什么放在 PIM？

答：PIM 的价格用于内部定价、平台发布和利润预估。订单真实成交价以平台订单为准，财务最终以平台账单为准。PIM 价格不是替代平台交易价，而是商品经营管理的一部分。

Q5：TMS 为什么需要 PIM 商品属性？

答：物流渠道过滤依赖重量、体积、是否带电、是否液体、HS 编码、英文申报名等商品属性。这些属性属于 SKU 主数据，所以 TMS 创建运单前要查询 PIM。

3.6 OMS 面试总结

适合写简历的方向

订单管理模块适合强调 Webhook 安全接入、幂等、状态机、库存冻结、风控规则、拆单合单、售后退款、Feign/MQ/Seata 选型。

简历写法

负责订单中心模块，完成多平台订单接入、Webhook 签名验证、订单幂等、订单状态机、库存冻结、风控规则、拆单合单和售后退款。使用 Feign + Seata 保证订单创建和库存冻结一致，使用 RocketMQ 异步处理订单发货、库存扣减和财务结算。

高频问题

Q1：Webhook 为什么要签名验证？

答：Webhook 是公网接口，如果不验证签名，任何人都可以伪造平台请求，创建假订单、占用库存、污染财务数据。常见做法是使用 HMAC-SHA256，根据平台密钥对请求体签名，后端重新计算后比对。

Q2：为什么 Webhook 要快速返回 200？

答：平台通常有 3 到 5 秒超时限制。如果 SaaS 在 HTTP 请求里做大量业务，平台可能超时重发，导致重复订单。合理做法是签名验证和基础校验通过后立即返回 200，把请求体放入 MQ 异步处理。

Q3：订单如何防重复？

答：用租户 ID、平台编码、平台订单号建立唯一索引。消费 MQ 时也要做幂等，重复消息直接跳过。接口层可以用 requestId + Redis SETNX 防重复提交。

Q4：订单创建为什么用 Feign + Seata 冻结库存？

答：库存不足时订单必须失败，所以 OMS 要同步调用 WMS。订单创建和库存冻结必须同时成功或失败，否则会出现有订单没库存，或者冻结了库存但订单不存在。Seata 可以保证跨服务原子性。

Q5：订单发货为什么用 MQ？

答：发货后扣减库存、通知物流、通知财务都不应该阻塞用户操作。MQ 可以削峰填谷，WMS、TMS、FMS 各自消费，失败后重试，保证最终一致。

Q6：退款和库存如何联动？

答：未发货退款释放冻结库存；已发货仅退款不改库存；退货退款要等 WMS 收到退货并质检。合格品恢复可售，不合格品进入不良品库存，退款结果通知 FMS 调整收入和利润。

3.7 TMS 面试总结

适合写简历的方向

物流管理模块适合强调规则引擎、物流商适配器、运单幂等、轨迹拉取线程池、限流熔断、可靠消息、本地消息表、费用对账。

简历写法

负责物流管理模块，完成物流商与渠道管理、智能渠道推荐、运单创建、轨迹追踪、异常预警、物流费用核算和退货物流。使用策略模式封装物流商适配器，使用规则引擎筛选物流渠道，使用 RocketMQ 和本地消息表保证运单状态可靠同步，使用 XXL-Job 分片和线程池批量拉取轨迹。

高频问题

Q1：物流规则引擎怎么做？

答：先硬过滤，再评分。硬过滤排除不可用渠道，例如目的国不支持、重量超限、带电不支持、渠道停用。评分阶段根据费用、时效、稳定性、异常率综合打分，推荐最优渠道。

Q2：为什么要做物流商适配层？

答：不同物流商 API 参数、鉴权、返回状态都不一样。如果业务代码直接调用各物流商，会非常混乱。适配层统一成创建运单、取消运单、查询轨迹、下载面单等标准接口，新增物流商只新增一个 Adapter。

Q3：运单创建幂等怎么做？

答：TMS 端用租户 ID、订单号、包裹号做唯一键，集群并发时加分布式锁，避免重复调用物流商。物流商端如果支持客户订单号幂等或查询接口，重试前先查；如果不支持，要标记处理中并人工确认，避免重复面单。

Q4：轨迹拉取如何提高效率？

答：定时任务先分页查询待更新运单，再按物流商分组。每个物流商设置独立线程池和限流参数，同一物流商并发数不超过接口限制，不同物流商可以并行拉取。消费结果要标准化成内部轨迹状态。

Q5：TMS 为什么适合用 MQ？

答：物流商 API 是外部系统，不稳定且不支持强回滚。运单创建成功后，如果同步回写 OMS 失败，不应该回滚物流商运单。TMS 本地落库后通过可靠消息通知 OMS/FMS，失败重试，最终一致更符合物流业务。

Q6：物流费用差异为什么会出现？

答：预估费用基于下单时的重量、体积、费率和规则。实际账单可能增加偏远附加费、燃油费、改派费、退件费，也可能因为物流商重新称重导致计费重量变化。因此需要费用对账和差异复核。

3.8 FMS 面试总结

适合写简历的方向

财务模块适合强调大文件账单解析、自动对账、SKU 级利润、汇率、汇兑损益、现金流预测、VAT 申报数据和财务可追溯。

简历写法

负责财务结算模块，完成平台账单导入、账单明细解析、自动对账、SKU 级利润核算、应收应付、多币种汇率、VAT 申报数据和现金流预测。使用 EasyExcel 解析大文件，支持 SQL 对账和 Java 业务层对账，使用利润快照表沉淀 SKU 级利润数据。

高频问题

Q1：平台账单主表和明细表是什么关系？

答：账单主表表示一次平台结算报告，保存平台、店铺、结算周期、币种、文件地址、总金额等。账单明细表保存每一笔订单、退款、佣金、广告费、税费等明细。一张主表对应多条明细。

Q2：为什么账单匹配率不是 100%？

答：平台结算有周期，订单可能未进入本期；部分订单可能被冻结复查；退款、广告费、补扣费可能跨周期；系统也可能漏单或平台补发历史费用。所以对账要识别差异类型，而不是简单认为不匹配就是错误。

Q3：几十万行账单如何导入？

答：不能一次性读入内存，容易 OOM。可以用 EasyExcel 逐行监听，分批校验、分批入库。导入过程中记录批次、成功数、失败数和错误原因，支持失败明细下载。

Q4：利润为什么要做到 SKU 级？

答：订单级利润看不出哪个商品赚钱。一个订单可能多个 SKU，每个 SKU 成本、物流费、佣金和退款不同。SKU 级利润可以支撑选品、补货、清仓和广告投放决策。

Q5：汇兑损益怎么产生？

答：订单发生时按当日汇率折算，实际到账时按到账日汇率折算。两次汇率不同，就产生汇兑收益或损失。系统要记录差额，而不是把它当作计算错误。

Q6：VAT 数据是系统直接缴税吗？

答：不是。系统负责根据订单、国家、税率、退款生成申报数据和导出文件。实际申报和缴税通常由财务专员或税务顾问在官方系统完成，完成后把申报状态和凭证回填到 FMS。

3.9 BI 面试总结

适合写简历的方向

BI 模块适合强调 ETL、KPI 指标体系、报表缓存、销售预测、智能补货、ABC 分类和预警阈值。

简历写法

负责 BI 数据分析模块，建设供应链核心 KPI 看板、销售预测、智能补货建议、ABC 库存分类和报表缓存。使用 XXL-Job 定时 ETL 汇总订单、库存、物流、财务数据，使用 Redis 缓存热点报表，提高 Dashboard 查询性能。

高频问题

Q1：BI 为什么要做 ETL？

答：业务表是为交易设计的，字段分散、数据量大、查询复杂。Dashboard 如果直接扫明细表，会影响业务库性能。ETL 把明细数据抽取、清洗、转换成指标表和快照表，报表查询更快、口径更稳定。

Q2：KPI 有什么用？

答：KPI 用来衡量供应链运行健康度。比如缺货率高说明补货不及时，库存周转天数高说明积压，物流异常率高说明渠道有问题，毛利率下降说明成本或平台费用异常。

Q3：销售预测怎么做？

答：先清洗异常销量，再使用移动平均、加权移动平均或指数平滑预测未来销量。节假日、大促和历史同期数据要单独调整，否则预测会偏离实际。

Q4：智能补货建议怎么计算？

答：根据未来预测销量、安全库存、当前可售库存、冻结库存、在途库存、供应商交期和 MOQ 计算建议采购量。建议进入 PMS 前需要采购负责人确认。

Q5：ABC 分类有什么意义？

答：A 类 SKU 贡献高，要重点保障库存和高频盘点；B 类正常管理；C 类要控制采购和库存占用。ABC 分类会动态调整，和补货、盘点、库存预警策略联动。

Q6：报表缓存怎么设计？

答：经营首页、利润看板、库存看板适合缓存。可以定时任务预热，也可以首次查询后缓存。缓存时间取决于实时性要求，财务报表可以按日，经营看板可以按分钟，实时库存要谨慎。

3.10 Auth 权限安全与 SaaS 运营面试总结

适合写简历的方向

权限安全模块适合强调 Sa-Token、双 Token、RBAC、权限缓存、多租户隔离、数据权限、接口安全、审计日志、Docker 和 CI/CD。

简历写法

负责权限安全与 SaaS 运营模块，完成登录认证、RBAC 权限、数据权限、多租户隔离、套餐限制、接口限流、审计日志、监控告警和容器化部署。使用 Sa-Token 实现认证鉴权，使用 Redis 缓存权限和限流数据，使用 Docker 和 GitHub Actions 实现自动化部署。

高频问题

Q1：登录为什么要传 tenantCode？

答：SaaS 系统里不同租户可能都有相同用户名，例如都叫 admin。登录时必须先确定租户，再查询该租户下的用户，否则会串租户。

Q2：RBAC 为什么不直接给用户分配权限？

答：直接给用户分配权限维护成本高。RBAC 把权限绑定到角色，新员工只要分配角色，岗位权限变化只改角色。这样更符合企业组织管理。

Q3：租户隔离和数据权限有什么区别？

答：租户隔离解决 A 公司不能看 B 公司数据，是 SaaS 底线。数据权限是在同一租户内部控制范围，例如仓库管理员只能看自己仓库，运营只能看自己店铺。

Q4：权限缓存更新怎么处理？

答：用户登录时把角色和权限缓存到 Redis。角色权限变更后，要删除受影响用户的权限缓存，或者使用版本号机制让旧缓存失效。关键接口不能只依赖前端权限，后端必须校验。

Q5：接口限流怎么做？

答：可以用 Redis + Lua 实现滑动窗口。Key 按租户、用户、接口维度设计。登录、验证码、文件上传、报表导出、普通查询设置不同阈值，超过阈值返回 429。

Q6：审计日志记录什么？

答：记录高风险写操作，例如供应商审核、库存调整、付款审批、角色授权、套餐变更。字段包括租户、用户、IP、接口、请求参数摘要、业务单号、结果、失败原因和操作时间。敏感字段要脱敏。

Q7：Docker 部署解决什么问题？

答：Docker 解决环境一致性，避免本地能跑、服务器跑不起来。每个服务打成镜像，docker-compose 编排 MySQL、Redis、RocketMQ、Nacos、业务服务、Nginx。MySQL、Redis、MQ 要挂载 volume，避免容器删除数据丢失。

Q8：上线后监控哪些指标？

答：技术指标包括 CPU、内存、磁盘、JVM、GC、接口 P99、错误率、数据库连接池、Redis 内存、MQ 堆积。业务指标包括订单处理失败、库存同步失败、账单解析失败、物流轨迹失败、支付或付款异常。

3.11 选模块写简历的建议

如果只选一到两个模块写简历，可以按个人优势选择：

模块	适合突出	面试难点
SRM	状态机、文件安全、定时任务、供应商评分	业务深度和评分口径
PMS	采购流程、询价比价、分布式事务、应付账款	采购状态和收货付款关系
WMS	库存冻结、并发扣减、库存流水、缓存、分表	超卖、一致性、库存字段解释
PIM	SPU/SKU、多语言、价格体系、平台发布	供应链系统为什么管理商品
OMS	Webhook、幂等、订单状态机、库存冻结、MQ	Feign/MQ/Seata 选型
TMS	规则引擎、物流商适配、轨迹拉取、费用对账	外部 API 不稳定和幂等补偿
FMS	大文件导入、自动对账、利润核算、汇率 VAT	财务业务口径复杂
BI	ETL、KPI、预测、补货、报表缓存	算法和指标口径解释
Auth	RBAC、多租户、数据权限、安全、部署	安全边界和上线运维

比较稳的组合：

OMS + WMS：订单和库存强相关，最容易讲出高并发、一致性、MQ、Seata。
TMS + OMS：履约链路完整，适合讲外部 API、幂等、轨迹和状态同步。
PMS + SRM：上游供应链完整，适合讲采购业务、供应商评分和应付。
FMS + BI：适合讲数据、对账、利润、指标和经营分析。
Auth + 任一业务模块：能体现不只是写业务，还懂 SaaS 平台底座。

3.12 面试总表达模板

面试讲这个项目时，可以按“四段式”表达：

第一段讲业务背景：

“这个项目是给跨境电商卖家使用的 SaaS 供应链平台，卖家可能同时在 Amazon、TikTok Shop、Shopee、Shopify 等平台销售。系统主要解决多平台订单统一接入、库存统一管理、采购补货、物流履约、财务对账和 BI 决策的问题。”

第二段讲自己负责的模块：

“我主要负责其中的 OMS/WMS 模块。OMS 负责多平台订单接入、订单状态机、库存冻结、风控、拆单合单和售后；WMS 负责库存冻结、出入库、库存流水、盘点和库存缓存。”

第三段讲技术亮点：

“技术上我重点做了三块。第一是订单创建时使用 Feign + Seata 调用 WMS 冻结库存，保证订单和库存一致；第二是发货、取消、财务结算使用 RocketMQ 异步解耦，消费者做幂等和失败重试；第三是库存查询使用 Redis 缓存，库存变动后删除缓存，并通过数据库原子更新防止超卖。”

第四段讲结果和思考：

“这个模块最核心的难点不是 CRUD，而是跨系统数据一致性和业务状态控制。哪些地方强一致、哪些地方最终一致，要根据业务场景选择。订单创建必须立即知道库存结果，所以用同步和事务；发货后通知物流和财务可以异步，所以用 MQ 保证最终一致。”

Day01-Day08 全系统业务关联与面试总复习

第一部分 全系统业务关联图

1.1 全系统主业务链路图

1.2 外部系统与平台边界图

1.3 采购入库链路图

1.4 订单履约链路图

1.5 库存与补货闭环图

1.6 财务结算与数据分析链路图

1.7 权限安全与 SaaS 运营支撑图

1.8 系统间调用关系总表

1.9 Feign、MQ、Seata 的选择口诀

第二部分 每个系统核心业务总结

2.1 Day01 项目认知与架构底座

2.2 SRM 供应商管理系统

2.3 PMS 采购管理系统

2.4 WMS 仓储管理系统

2.5 PIM 商品管理系统

2.6 OMS 订单管理系统

2.7 TMS 物流管理系统

2.8 FMS 财务结算系统

2.9 BI 数据分析系统

2.10 Auth 权限安全与 SaaS 运营

第三部分 每个系统的面试总结

3.1 项目整体架构面试总结

3.2 SRM 面试总结

3.3 PMS 面试总结

3.4 WMS 面试总结

3.5 PIM 面试总结

3.6 OMS 面试总结

3.7 TMS 面试总结

3.8 FMS 面试总结

3.9 BI 面试总结

3.10 Auth 权限安全与 SaaS 运营面试总结

3.11 选模块写简历的建议

3.12 面试总表达模板

第一部分全系统业务关联图

第二部分每个系统核心业务总结

第三部分每个系统的面试总结