引言

在过去的一段时间里，我独立构建了与公司核心ERP无缝对接、承载复杂业务逻辑的线上平台。这个项目从一开始的简单的目标到一个能够与公司核心ERP无缝对接、承载复杂业务逻辑的线上中台，历经了诸多的需求变化与功能迭代。

选择WordPress作为基础平台，听起来似乎有些“非主流”，但事实证明，通过深度的架构改造和定制开发，WordPress完全有能力承载复杂应用。鉴于有限的时间里尽量要使功能快速上线，也测试过基于woocommerce的开发，但对于复杂的ERP相关逻辑显得繁琐而臃肿，使用其他框架时又需要额外再开发一套后台，因此采用WordPress为底座，自定义路由，并使功能模块化对接的开发思路。

一、 选择“应用化”架构

传统的WordPress主题和插件生态系统，在面对复杂的业务需求时大多显得力不从心。为了保证系统的性能、可维护性和扩展性，我做了一系列的改造和自定义。

1.  **自定义路由系统**: 我摒弃了WordPress原生的页面（Page）和文章（Post）路由，实现了一套基于GET参数的轻量级页面路由器（`?p=my-orders`）。这让应用的不同模块（如订单、售后、合作商中心）得以完全解耦，每个模块都可以拥有自己独立的模板和逻辑。

2.  **模块化的业务逻辑**: 我创建了一个`apps/`目录，并引入了基于命名空间（Namespace）的自动加载机制。所有的核心业务逻辑，如订单处理 (`Apps\Web\Orders`)、售后服务 (`Apps\Web\Aftersales`)、AJAX接口 (`Apps\Ajax\Orders`) 等，都被封装在独立的类中。使得代码职责分明，极大地提升了开发效率和后期的可维护性。

3. **沉浸式用户体验**: 为了让普通用户（特别是合作商）拥有无缝的应用体验，我屏蔽了WordPress顶部的Admin Bar，并构建了完全独立的前端用户中心。用户登录后，进入的是一个为他们量身定制的操作后台，而非WordPress的标准仪表盘。

二、 相关功能

需要深度贴合业务的定制功能，以下是几个最具代表性的模块：

1. 合作商体系：不是经销商，也不是普通客户

B2B业务的核心是与合作商的关系管理。为此，我设计了一套精细化的权限和支持系统：

*   **分类授权**: 管理员可以为每个合作商授权特定的产品分类。合作商登录后，无论是产品列表、筛选器还是搜索结果，都将被严格限制在授权范围内。这套权限校验贯穿了前端UI和后端API，无法被绕过。

*   **实时库存查询**: 我为合作商开发了一个专属的库存查询页面，该页面能**实时、直接**查询公司内部ERP数据库，为他们提供最准确的库存信息，这对于B2B业务的决策至关重要。

2.经销商体系：

 独立与合作商与普通客户，作为分销或合作的一方，不同经销商可能应对不同的价格或者折扣体系，后期可能按照年度价格、折扣价格、单一产品优惠价格等开展，已预留了部分逻辑，其他逻辑除授权商品外，类似于合作商逻辑

3.商品管理：

所有商品皆实际来源与ERP数据，并能进行自定义编辑和搭配管理，自定义了商品属性，使商品能单独或统一显示特征属性，实现了产品的复合销售、单一销售、搭配销售等情况，实现了从ERP批量创建实际商品或更新商品数据等情况。

4. 售后管理：从“物流拦截”到“订单拆分”

多种状态的细分售后流程，以应对各种复杂的客户场景。设计示例：

*   **运输中拦截**: 针对已发货但未签收的订单，系统支持“物流拦截”类型的售后申请。这会自动触发内部流程，联系物流公司进行拦截，并将订单状态同步更新，避免了以往混乱的人工沟通。

*   **部分发货自动拆分**: 当一个订单项被部分发货时，系统会自动将该订单项**拆分**为两个新的记录：“已发货项”和“未发货项”。前者关联运单号，后者留在订单中等待后续处理。这保证了每个运单号都精确对应一个独立的、可追踪的订单项，为后续的售后和库存管理提供便利。

*  **在线订单与ERP实时联动** ：在线订单的创建、更改、售后等都将实现反应至ERP中，实现库存、订单、售后的同步更新或提示/预警

5. 智能库存策略：

公司在多个电商平台有同时销售的情况，因库存同步延迟而导致的超卖问题：

*   **临界库存 (`CRITICAL_STOCK`)**: 对于公司自产的商品，当创建订单时，会自动减去一个“临界值”（例如2件）。这2件库存作为缓冲，极大地降低了多平台并发下单时的超卖风险，并在特定操作时返回ERP实时库存去作缓存或更新。

*   **差异化策略**: 对于无法补货的进口商品，则不采用临界库存策略，而是使用真实库存判断，卖完即止。

三、 ERP相关系统集成

1.  **与ERP的实时对话**: 如前所述，库存查询等关键功能直接与ERP的SQL Server数据库进行实时通信，确保了数据的高度一致性，部分数据做了缓存，在固定时效里有效。

2.  **UDP实时通知**: 当用户执行关键操作（如下单、取消订单、修改地址）时，系统会通过UDP协议，向内部ERP客户端（狐表FoxTable）**实时推送**一条加密的通知消息。这使得内销人员可以第一时间在自己的ERP软件中收到提醒并进行处理，缩短业务响应时间。

四、结构：

========================================

|       系统基本框架          |

========================================

1. 用户与访问层 (User & Access Layer)

  |

  |— 客户 / 合作商 (Customer / Partner)

  |— 管理员 / 店铺经理 (Admin / Shop Manager)

  |

  `—> [浏览器 Web Browser] —> [Web服务器 Nginx]

2. 应用层 (Application Layer – “order” Theme)

  |

  |— [Web服务器 Nginx]

  |     |

  |     `—> (HTTP请求) —> [自定义路由器 PageRouter (?p=…)]

  |

  |— [自定义路由器 PageRouter]

  |     |

  |     `—> (路由分发) —> [模板层 (Views) templates/*.php]

  |

  |— [模板层 (Views)]

  |     |— (调用业务逻辑) —> [应用逻辑 (Controller)]

  |     `— (发起AJAX请求) —> [AJAX接口 (API)]

  |

  |— 核心业务模块 (Core Modules)

        |

        |— [应用逻辑 (Controller) – apps/web/*, apps/admin/*]

        |     `— (处理业务规则)

        |

        `— [AJAX接口 (API) – apps/ajax/*]

              `— (处理前端请求, 调用应用逻辑)

3. 数据与集成层 (Data & Integration Layer)

  |

  |— [应用逻辑] 和 [AJAX接口]

  |     |

  |     |— (读/写) —> [主数据库 (MySQL)]

  |     |                |– 订单 (pre_orders)

  |     |                |– 售后 (pre_aftersales)

  |     |                |– 产品 (pre_products)

  |     |                `– 用户 (wp_users)

  |     |

  |     |— (实时读库存) —> [外部: ERP数据库 (SQL Server)]

  |     |

  |     |— (发送UDP通知) —> [外部: 狐表ERP客户端]

  |     |

  |     `— (读/写文件) —> [文件系统 (File System)]

  |                           `– (含受保护的支付凭证)

—————————————-

数据流向简介:

1. 用户通过浏览器访问，请求使用自定义路由器。

2. 路由器根据URL加载对应的模板文件进行显示。

3. 模板调用应用逻辑获取数据，并通过AJAX接口与后端进行异步通信。

4. 应用逻辑和AJAX接口负责处理所有业务规则，并与数据层交互。

5. 数据层不仅包括本地MySQL数据库，还实时连接外部的ERP数据库进行库存查询，并向ERP客户端发送UDP通知，实现集成。

**结语**

从架构设计到功能实现，再到与现有系统的集成，这个项目遇到诸多问题，需求也不断的变更，总算成型并通过了测试。它证明了以WordPress为基础，通过现代化的软件工程实践，完全可以构建出满足复杂业务需求应用。

这次开发历经了对技术的深度实践，更对业务流程有了较深理解。希望我的分享能给同样在探索用WordPress构建复杂应用的朋友们带来一些启发。