作者：一个踩过坑的开发者
前言：如果你正在开发一套多门店管理系统（推拿、美容、餐饮等），并且还在纠结“从零造轮子还是用开源框架”，这篇文章值得你花10分钟读完。

---

一、为什么要写这篇文章？

三个月前，我们接到一个真实的项目需求：
为一家拥有10多家连锁店的推拿头疗采耳品牌开发一套完整的门店管理系统。

具体需求包括：

• 用户端（微信小程序 + App）

• 技师端（安卓App）

• 店长端（Web）

• 总部管理界面（Web）

• 中台（账目、经营管理）

• 扫码核销 + 硬件计时器对接

团队配置：两个大学生 + 一个推荐人（负责对接客户）。

预算不高，时间紧，需求还在不断变化。
我们选择了若依框架（RuoYi-Vue）作为技术底座。

现在系统已经顺利交付并上线运营。这篇文章将完整复盘我们踩过的坑、找到的技巧，以及“AI + 若依”这套组合拳如何帮我们两个人完成原本需要5人团队的工作量。

---

二、为什么选择若依？我们对比了4个方案

方案	优点	缺点	我们的选择
纯AI生成代码	生成速度快	代码松散，权限、安全需要从头搞	❌ 放弃
自研Spring Boot	完全可控	工作量太大，6个端 + 多门店 = 至少3个月	❌ 放弃
其他开源框架（JeecgBoot、El-Admin）	各有特色	学习成本高，生态不如若依成熟	⚠️ 犹豫
若依框架 + AI辅助	开箱即用 + 灵活扩展	需要理解若依的设计思想	✅ 最终选择

核心原因：
若依已经帮我们解决了最头疼的 RBAC权限、数据字典、代码生成器、定时任务，这些如果从零写，至少要花2周时间。

---

三、这套系统到底有多少个“端”？

很多人在做多门店系统时容易混淆角色和端。我们梳理后明确：

端名称	形态	用户	核心功能
用户端	微信小程序 + Android App	到店消费的顾客	注册、预约技师、查看活动、评价
技师端	Android App	门店技师	上钟提醒、工资查看、入职信息管理
店长端	Web + H5	单店管理者	排班管理、上钟记录、房间管理
总部后台	Web（PC端）	总部运营/财务	所有门店数据汇总、财务报表、活动配置
中台	后端服务（无独立前端）	系统内部	账目清算、工资计算、硬件对接

关键点：中台不是一个独立的界面，而是跑在若依后端里的业务逻辑模块。
具体来说，它就是一个SalaryService.java和一个OrderSettlementService.java，被所有前端共用的。

---

四、若依框架如何支撑多门店（多租户）？

原生若依是单公司的结构，但我们可以通过简单的改造实现多门店隔离。

4.1 数据隔离方案（三选一）

方案	实现方式	优缺点
独立tenant_id字段（我们采用）	所有业务表加tenant_id，查询时自动过滤	✅ 简单、性能好 ❌ 需要改造若依的DataScope
独立数据库	每家门店一个独立库	✅ 绝对隔离 ❌ 运维成本高，跨店统计困难
独立Schema（PostgreSQL）	同一数据库不同Schema	✅ 隔离性好 ❌ 国内云厂商支持不统一

4.2 两个核心改造点

改造一：扩展BaseEntity，增加租户字段

java

public class BaseEntity implements Serializable {
    // 若依原有字段...
    private String tenantId;  // 新增：租户ID（门店标识）
}

改造二：改造若依的DataScopeAspect，增加租户过滤逻辑

java

// 在原有的数据权限过滤中，自动加上tenant_id条件
if (StringUtils.isNotBlank(user.getTenantId())) {
    sqlString.append(" AND ${alias}.tenant_id = '").append(user.getTenantId()).append("' ");
}

效果：
店长登录后，只能看到自己门店的数据；总部登录后，可以看所有门店的数据。
全程不需要在每个Mapper里写where tenant_id = ?，若依自动帮你拼接。

---

五、两个人如何分工？

角色	主要工作	若依框架提供的能力	AI辅助的部分
后端一人	业务逻辑开发、数据库设计	代码生成器、定时任务、权限注解	工资算法、复杂SQL、硬件接口Mock
前端一人	小程序、App、Web多端	若依自带的Vue前端模板	组件生成、API调用代码、样式调整
推荐人（外援）	需求沟通、客户对接、硬件协调	—	—

关键：我们没有专职的测试和运维。
若依自带的后台监控、日志系统、数据监控页面对我们帮助巨大。

---

六、AI到底帮我们做了什么？

6.1 写业务逻辑（最实用的部分）

案例：技师工资计算

需求：

• 提成比例按服务项目的15%

• 当月服务超50人，超出部分提成增加到20%

• 迟到扣50元，客户投诉扣100元

我们给AI的提示词：

text

在若依框架的Service层实现技师工资计算功能。
参考若依现有代码风格（使用@Autowired注入Mapper，使用@Transactional管理事务）。
输入：技师ID、月份（YYYY-MM）
输出：税前工资、各项扣款、实发工资

AI在10秒内生成了完整的Service代码，包括：

• 查询订单的Mapper逻辑

• 提成计算循环

• 扣款统计

• 事务回滚处理

我们只需要把AI生成的代码复制到SalaryServiceImpl.java中，稍作调整即可运行。

6.2 生成若依风格的CRUD

若依自带代码生成器可以生成基础增删改查，但复杂关联查询还是要手写。
这时候AI就可以帮我们快速生成：

text

在若依框架中，写一个MyBatis查询：
查询门店的所有技师，并关联查出技师当月的订单数量、好评总数、服务总时长。
返回格式：技师名称 + 订单数 + 好评数 + 总时长

生成的SQL和Mapper代码可以直接粘贴使用。

6.3 辅助调试和解释代码

遇到若依的某个类不知道干什么用的，直接把代码贴给AI，让它解释。
比如我们当时不理解DataScopeAspect的工作原理，AI帮我们逐行解释并给出了改造成多租户的思路。

---

七、我们遇到的最大坑：硬件计时器对接

7.1 问题描述

客户之前采购了一批硬件计时器，需要：

• 扫码核销后，自动触发计时器开始计时

• 计时器结束时，回传服务时长到后台，更新订单并重算技师提成

坑点：

• 硬件厂商提供的API文档是繁体中文，且部分接口描述不清晰

• 计时器的回调接口需要在公网可访问，我们在内网开发时花了很长时间做内网穿透

• 计时器和系统的状态同步问题：如果硬件断网，上钟记录会丢失

7.2 若依的解决方案

若依的@Anonymous注解帮了大忙：

java

@Anonymous
@PostMapping("/hardware/callback")
public AjaxResult hardwareCallback(@RequestBody CallbackData data) {
    // 计时器回调接口，不需要登录鉴权
    // 更新订单时长的逻辑
}

用若依自带的 Quartz定时任务 实现了降级方案：
每隔5分钟检查一次“已开始但未结束”的上钟记录，如果超过预计服务时间仍未收到回调，主动向硬件查询状态（或标记为异常订单，人工处理）。

7.3 给后来者的建议

签合同前，一定要拿到硬件厂商的API文档，并让客户确认对接工作量单独报价。
否则会像我们一样，在硬件调试上多花了一周的时间。

---

八、报价参考（给接外包的同学）

我们最终报价 5万元，包含：

• 6个端的前后端代码

• 1个月免费维护

• 部署到客户服务器（腾讯云）

现金流按 3-3-3-1 分期收款：

• 签约30%（1.44万）

• 完成核心原型30%（1.44万）

• 上线验收30%（1.44万）

• 尾款10%（0.48万）

给推荐人（中间人）的费用： 20%长期佣金，从每期收款中直接分出去。

如果重来一次，我们会在报价时增加两项：

1. 硬件对接单独收费（5000-8000元）

2. 异地部署差旅费（如果需要去现场调试）

---

九、效果和复盘

9.1 数据（上线后1个月）

• 接入门店：11家

• 注册技师：82人

• 日均订单：340单

• 系统可用性：99.2%（有一次因云服务器自动重启导致半小时宕机）

9.2 做得好的地方

• 若依框架的选择是正确的：基础功能0开发成本

• AI辅助开发效率高：工资模块原本预估3天，实际1天搞定

• MVP策略成功：先上线核心流程（预约→上钟→核销），第二期再补工资和硬件深度对接

9.3 可以改进的地方

• 硬件对接应该单独报价：我们低估了调试的时间

• 多租户改造应该在第一天完成：我们中途才加上tenant_id，导致一些表需要回填数据

• 缓存策略应该提前设计：技师端“实时工资”查询压力比预期大，后来加了Redis缓存才解决

---

十、给想走这条路的人的3个建议

1. 若依框架是用来“少写代码”的，不是用来“不写代码”的。
   理解它的数据权限、代码生成器、定时任务这三个核心能力，能帮你节省70%的时间。

2. AI是你的副驾驶，不是自动驾驶。
   不要期待AI一次性生成完整可运行的模块，它的价值在于帮你快速生成复杂算法和样板代码，而不是取代你的设计能力。

3. 硬件对接和支付集成一定要单独评估。
   这两个环节最容易超支，也最容易被客户忽略。在需求确认阶段就明确告知客户“这部分可能需要额外的工作量”，避免后期扯皮。

---

写在最后

这套系统从开始到交付，我们两个人用了 6周 时间（每天投入6-8小时）。

如果没有若依框架，这个周期至少会延长到3个月。
如果没有AI辅助，我们要么再多加一个人，要么累到脱一层皮。

开源框架 + AI工具，已经让两个人的小团队具备了完成中型商业项目的能力。
希望这篇文章能给正在犹豫“要不要用若依”的你一些参考。

---

评论区欢迎交流：
你也在用若依做多门店系统吗？遇到过哪些坑？欢迎留言讨论。

---

本文首发于CSDN，转载请注明出处。
若依官方文档：RuoYi-Vue