《用若依框架开发多门店SaaS系统的完整实战指南——两个大学生如何从零到交付》

作者一个踩过坑的开发者前言如果你正在开发一套多门店管理系统推拿、美容、餐饮等并且还在纠结“从零造轮子还是用开源框架”这篇文章值得你花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单店管理者排班管理、上钟记录、房间管理总部后台WebPC端总部运营/财务所有门店数据汇总、财务报表、活动配置中台后端服务无独立前端系统内部账目清算、工资计算、硬件对接关键点中台不是一个独立的界面而是跑在若依后端里的业务逻辑模块。具体来说它就是一个SalaryService.java和一个OrderSettlementService.java被所有前端共用的。四、若依框架如何支撑多门店多租户原生若依是单公司的结构但我们可以通过简单的改造实现多门店隔离。4.1 数据隔离方案三选一方案实现方式优缺点独立tenant_id字段我们采用所有业务表加tenant_id查询时自动过滤✅ 简单、性能好❌ 需要改造若依的DataScope独立数据库每家门店一个独立库✅ 绝对隔离❌ 运维成本高跨店统计困难独立SchemaPostgreSQL同一数据库不同Schema✅ 隔离性好❌ 国内云厂商支持不统一4.2 两个核心改造点改造一扩展BaseEntity增加租户字段javapublic 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注解帮了大忙javaAnonymous 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%长期佣金从每期收款中直接分出去。如果重来一次我们会在报价时增加两项硬件对接单独收费5000-8000元异地部署差旅费如果需要去现场调试九、效果和复盘9.1 数据上线后1个月接入门店11家注册技师82人日均订单340单系统可用性99.2%有一次因云服务器自动重启导致半小时宕机9.2 做得好的地方若依框架的选择是正确的基础功能0开发成本AI辅助开发效率高工资模块原本预估3天实际1天搞定MVP策略成功先上线核心流程预约→上钟→核销第二期再补工资和硬件深度对接9.3 可以改进的地方硬件对接应该单独报价我们低估了调试的时间多租户改造应该在第一天完成我们中途才加上tenant_id导致一些表需要回填数据缓存策略应该提前设计技师端“实时工资”查询压力比预期大后来加了Redis缓存才解决十、给想走这条路的人的3个建议若依框架是用来“少写代码”的不是用来“不写代码”的。理解它的数据权限、代码生成器、定时任务这三个核心能力能帮你节省70%的时间。AI是你的副驾驶不是自动驾驶。不要期待AI一次性生成完整可运行的模块它的价值在于帮你快速生成复杂算法和样板代码而不是取代你的设计能力。硬件对接和支付集成一定要单独评估。这两个环节最容易超支也最容易被客户忽略。在需求确认阶段就明确告知客户“这部分可能需要额外的工作量”避免后期扯皮。写在最后这套系统从开始到交付我们两个人用了6周时间每天投入6-8小时。如果没有若依框架这个周期至少会延长到3个月。如果没有AI辅助我们要么再多加一个人要么累到脱一层皮。开源框架 AI工具已经让两个人的小团队具备了完成中型商业项目的能力。希望这篇文章能给正在犹豫“要不要用若依”的你一些参考。评论区欢迎交流你也在用若依做多门店系统吗遇到过哪些坑欢迎留言讨论。本文首发于CSDN转载请注明出处。若依官方文档RuoYi-Vue