LZ/01

CASE STUDY / COMMERCE SYSTEM

Petify

功能迭代

从用户商城到卖家后台的三端电商系统

Petify 将用户商城、卖家运营后台和 Express API 拆成三个独立应用，覆盖商品发现、筛选、购物车、订单、评价、实时客服和运营数据看板。项目使用 React、Redux、Tailwind CSS、Node.js、MongoDB、Cloudinary、Docker 与 Caddy 完成从界面到部署的全栈实践。

查看代码 打开项目 查看当前边界

01 / PRODUCT SURFACES

为什么把电商拆成三个应用

Petify 的挑战不是完成一个商品列表，而是在同一套用户、商品、订单和聊天数据上组织三种不同的使用场景：用户需要清晰的发现和购买流程，卖家需要高密度的商品与订单工作台，客服又需要低延迟的实时沟通。项目因此将用户端、卖家端和 API 独立出来，再通过 REST、Redux 和 Socket.IO 连接交易与沟通流程。

  • 将用户商城、卖家运营后台和 Express API 拆成独立的应用边界
  • 为商品发现、购物车、订单、评价和客服建立连续的用户体验
  • 使用 Redux、React Router 和 Tailwind 组织跨页面状态与响应式界面
  • 让卖家能够在同一个工作台中处理商品、订单、统计和客户消息

02 / COMMERCE FLOW

一次购买如何从商品发现进入后台协作

  1. 01

    Discover

    用户从首页 Banner、分类和商品列表开始浏览，API 返回最新、评分和折扣商品，前端通过卡片和详情页组织发现路径。

  2. 02

    Filter

    Shop 页面组合分类、价格区间、评分、关键词和价格排序，并在 Grid/List 视图和分页之间保持同一组筛选状态。

  3. 03

    Decide

    商品详情聚合图片、描述、库存、折扣、评分、评论、同类商品和同一卖家的更多商品，帮助用户完成购买判断。

  4. 04

    Cart

    用户可以将商品加入购物车或心愿单，调整数量，检查库存，并在结算页面填写配送信息。

  5. 05

    Order

    下单接口创建客户订单和卖家子订单，删除购物车项目，并通过订单状态和 Dashboard 让用户追踪处理进度。

  6. 06

    Operate

    卖家在 Dashboard、商品、分类、订单、支付统计和客服页面中完成日常运营，Socket.IO 同步在线客户与消息变化。

03 / FRONTEND ENGINEERING

代码中真实存在的产品与工程设计

  1. 01

    将用户端、卖家端与 API 作为三个产品边界

    实现frontend 和 dashboard 是两个独立的 Vite React 应用，backend 负责 Express REST API、MongoDB、文件上传和 Socket.IO；Caddy 根据 pet.linze.pro 与 seller.pet.linze.pro 路由静态资源和 API。

    价值用户商城和卖家后台可以拥有不同的信息密度、导航和交互方式，同时共享同一套业务数据和后端能力。

  2. 02

    用 Redux Toolkit 组织跨页面交易状态

    实现用户端分别维护 auth、home、cart、order、dashboard 和 chat reducer；后台则拆分 auth、product、category、seller、order 和 chat 状态。

    价值商品详情、购物车、订单、Dashboard 和聊天页面之间拥有稳定的状态入口，减少跨页面交互中的重复请求和局部状态拼装。

  3. 03

    围绕卖家日常操作设计后台工作台

    实现dashboard 使用独立路由、ProtectedRoute、Lazy Loading、商品与订单表格、搜索分页、图表和 react-window 虚拟列表组织商品、订单、支付和客服页面。

    价值后台不只是用户端的附属页面，而是针对商品管理、订单处理、销售统计和客户沟通建立了更高密度的操作流。

  4. 04

    用 REST 持久化与 Socket.IO 即时分发协作

    实现聊天控制器将 Customer、Seller 和 Admin 消息写入 MongoDB，Socket.IO 维护当前进程中的在线连接并向目标用户推送消息；前端 Redux 接收事件后更新会话列表。

    价值历史数据和实时交互拥有不同的职责边界：REST 负责可查询的消息记录，Socket.IO 负责在线场景中的低延迟反馈。

  5. 05

    将国际化、主题和响应式作为界面基础

    实现用户端使用 react-i18next 和浏览器语言检测加载中英文文案，Tailwind CSS 负责商品筛选、详情、购物车和移动端布局；后台通过 ThemeProvider 支持明暗主题和响应式 Sidebar。

    价值用户体验不局限于桌面端单语言商城，语言、设备尺寸和视觉偏好都在界面结构中拥有明确入口。

  6. 06

    把媒体上传和部署纳入交付链路

    实现Formidable 接收商品图片和头像上传，Cloudinary 托管媒体 URL；Docker Compose 编排 MongoDB 与后端，Makefile 构建前端和后台静态资源，Caddy 提供 HTTPS、SPA fallback 和反向代理。

    价值项目覆盖了从商品内容录入到静态资源发布、API 代理和服务器部署的完整交付路径，而不止停留在本地开发环境。

04 / CURRENT BOUNDARIES

前端体验完整，但交易后端仍需收敛

用户商城和卖家工作台已经形成较完整的产品骨架；身份边界、订单一致性、实时连接和支付闭环是下一轮更重要的工程问题。

  1. 高优先级

    订单接口仍然信任较多客户端数据

    placeOrder 接收客户端传入的 userId、商品结构、价格和配送信息，当前没有充分体现服务端重新读取价格、校验库存、原子扣减、订单幂等和事务边界。它已经打通购物车到订单的业务流程，但还不能包装成强一致交易系统。

  2. 高优先级

    Customer API 和后台角色边界还不统一

    部分购物车、心愿单、评论和订单接口直接使用 URL 或 Body 中的 userId，后台路由也主要依赖通用 authMiddleware。下一步需要让服务端从 Token 推导身份，并统一 Customer、Seller 和 Admin 的授权策略。

  3. 高优先级

    Socket.IO 当前是单实例且缺少连接鉴权

    在线客户、卖家和管理员保存在 Node.js 进程内的数组与单个 admin 变量中，连接事件也依赖客户端传入的 ID；没有 Redis Adapter、ACK、重试、离线队列或多实例广播能力。

  4. 中优先级

    商品筛选和 Dashboard 统计仍有查询扩展空间

    公开商品筛选先读取全部商品，再在 Node.js 内存中完成分类、价格、评分、搜索、排序和分页；Dashboard 统计也有多次读取全部订单的实现。数据量增长后应下沉到 MongoDB 查询、聚合和索引。

  5. 中优先级

    支付与生产保障尚未形成完整闭环

    当前 Stripe 代码主要完成 Seller Connect 账户开户链接，尚未看到 Checkout、Payment Intent 和 Webhook 支付确认；同时缺少完整测试、限流、健康检查、结构化日志和 CI/CD。

05 / NEXT ITERATION

下一轮应该怎么做

  1. 01

    让所有 Customer API 从认证 Token 推导用户身份，并补齐 Customer、Seller、Admin 的服务端 RBAC

  2. 02

    服务端重新计算订单金额和库存，用 MongoDB Transaction、原子扣减和幂等键保护下单流程

  3. 03

    为 Socket.IO 增加 JWT 握手鉴权、可信 Origin、room、ACK、重连和 Redis Adapter

  4. 04

    将筛选、分页和 Dashboard 统计下沉到 MongoDB 查询与聚合，并补充必要索引

  5. 05

    接入 Stripe Payment Intent/Webhook，增加订单审计、集成测试、健康检查和结构化可观测性