传统药店正在加速线上化。
从“到店买药”，到“线上下单 + 骑手配送 + 电子处方审核”，背后依赖的不是简单商城，而是一套完整的 数字药店系统。

很多团队在做医药电商时都会踩坑：
商品结构混乱
库存不准，经常超卖
处方订单流程复杂
会员无法沉淀复购
本质原因只有一个：
底层模块设计没有从医药行业特性出发。
本文结合一套成熟的数字药店系统源码，拆解四个核心模块的技术实现思路，并附关键代码示例。

一、系统整体架构设计

先看整体分层：

用户层：小程序 / APP / H5
          ↓
业务层：商品服务 / 库存服务 / 订单服务 / 会员服务
          ↓
中台层：支付 / 处方审核 / 配送调度 / 消息中心
          ↓
数据层：MySQL + Redis + MQ

推荐架构：
Spring Boot + MySQL + Redis + RabbitMQ
或微服务：Spring Cloud / Dubbo
原因很简单：
药店属于 高并发 + 强库存一致性 + 强合规 场景，必须服务拆分。

二、商品模块设计（支持药品特性）

药品不同于普通商品，必须支持：
处方药/非处方分类
批准文号
生产厂家
效期管理
是否需要处方
表结构设计

CREATE TABLE drug_product (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(255),
  category_id BIGINT,
  prescription_type TINYINT, -- 0 OTC 1 处方药
  approval_no VARCHAR(100),
  manufacturer VARCHAR(255),
  spec VARCHAR(100),
  price DECIMAL(10,2),
  status TINYINT,
  created_at DATETIME
);

商品查询接口示例

@GetMapping("/products")
public Page<ProductVO> list(ProductQuery query){
   
    return productService.pageQuery(query);
}

Service 层：

public Page<ProductVO> pageQuery(ProductQuery query){
   
    return productMapper.selectPage(query);
}

关键点：
必须支持
分类筛选
关键字搜索
医保标签
是否处方药过滤
否则无法满足真实购药场景。

三、库存模块设计（防超卖核心）

医药零售最大问题是：
库存不准 = 直接损失利润 + 合规风险
因此必须：
Redis 预扣 + 数据库最终一致性 + 分布式锁
库存表

CREATE TABLE drug_stock (
  product_id BIGINT,
  warehouse_id BIGINT,
  stock INT,
  lock_stock INT,
  PRIMARY KEY(product_id, warehouse_id)
);

字段解释：
stock：可售库存
lock_stock：锁定库存（已下单未支付）
扣减库存核心代码

public boolean deductStock(Long productId, Integer num){
   
    String key = "stock:" + productId;

    Long remain = redisTemplate.opsForValue().decrement(key, num);

    if(remain < 0){
   
        redisTemplate.opsForValue().increment(key, num);
        throw new RuntimeException("库存不足");
    }

    // 异步落库
    mqSender.send("stock.update", new StockDTO(productId, num));

    return true;
}

消费者落库：

@RabbitListener(queues="stock.update")
public void updateStock(StockDTO dto){
   
    stockMapper.deduct(dto.getProductId(), dto.getNum());
}

这样可以做到：
高并发不超卖
数据库压力小
性能提升 10 倍以上

四、订单模块设计（药店最复杂模块）

药店订单流程：
普通商品：下单 → 支付 → 配送
处方药：上传处方 → 审核 → 支付 → 配送
比普通商城多一个“审核节点”。
订单状态机设计

public enum OrderStatus {
   
    WAIT_PAY,
    WAIT_REVIEW,
    REVIEW_PASS,
    WAIT_DELIVERY,
    FINISH,
    CANCEL
}

创建订单核心代码

@Transactional
public Long createOrder(CreateOrderDTO dto){
   

    // 扣库存
    stockService.deductStock(dto.getProductId(), dto.getNum());

    Order order = new Order();
    order.setUserId(dto.getUserId());
    order.setAmount(dto.getAmount());

    if(dto.isPrescription()){
   
        order.setStatus(OrderStatus.WAIT_REVIEW);
    }else{
   
        order.setStatus(OrderStatus.WAIT_PAY);
    }

    orderMapper.insert(order);

    return order.getId();
}

设计重点：
处方药必须强制审核
不可直接支付
需留审计日志
否则不合规。

五、会员模块设计（复购增长核心）

很多药店上线系统后没效果，本质问题是：
只卖药，不运营会员。
数字药店真正利润来自：
慢病复购
家庭常备药
私域营销
会员表设计

CREATE TABLE member (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  phone VARCHAR(20),
  level INT,
  points INT,
  balance DECIMAL(10,2),
  created_at DATETIME
);

积分累计示例

public void addPoints(Long userId, BigDecimal amount){
   
    int points = amount.multiply(new BigDecimal("1")).intValue();
    memberMapper.addPoints(userId, points);
}

可扩展：
会员等级折扣
优惠券
周期购药提醒
慢病复购推荐
这些才是真正的利润来源。

六、总结

一个成熟的数字药店系统源码，本质是四大能力：
商品标准化管理
库存精准控制
订单合规流转
会员长期沉淀
如果只是做一个普通商城，根本跑不通医药场景。
真正可商用的系统，一定是：
支持处方审核
支持多门店库存
支持配送调度
支持会员复购运营