1. 项目概述与需求拆解1.1 岳记客栈管理系统到底要解决什么问题很多刚接触全栈开发的朋友一听到客栈管理系统就觉得是不是又要做一堆CRUD没技术含量。说实话我从第一版做到第三版这个认知直到现在还在刷新。客栈管理表面上就是登记入住、退房结账但真正深入进去你会发现业务流程远比想象中复杂——房间状态实时变化、订单和入住记录关联、房价随淡旺季浮动、退房时的水电费计算每一环都在考验你的数据库设计和代码组织能力。那次接到岳记客栈这个项目业主提了几个特别接地气的需求前台小妹要能快速开单不用Excel记到半夜老板在手机上想看一眼今天的入住率财务月底要能一键导出报表而不是对着纸质的记录本翻到眼瞎。这些诉求落到技术上就转化成了三个核心模块前台运营、客房管理、统计报表。用Spring Boot加Vue做这套系统最大的好处就是前后端分离。我用第一版单体应用踩过坑——改个页面样式都要重新打包后端部署一次费半小时。前后端分离之后后端专注提供标准化接口前端只管页面交互和数据渲染互不干扰迭代速度快很多。1.2 这类系统适合谁来学习和参考如果你正在准备毕业设计或者刚入职想练手全栈项目岳记客栈管理系统是一个特别合适的练手案例。它比单纯的管理系统多一点业务逻辑复杂度比如房间状态流转又比电商系统简单很多非常适合在短时间内掌握Spring Boot和Vue的完整开发链路。另外要强调的是这个项目的业务边界非常清晰作为教学案例来拆解再合适不过。你不需要理解复杂的支付回调、多级分销这些互联网业务专注搞懂房间状态怎么管理、订单怎么闭环就能把整个系统的业务逻辑吃得透透的。后面想扩展也方便——加个餐饮模块、会员模块都是顺着现有结构往里面填代码的事。2. 技术选型与前后端架构设计2.1 为什么选Spring Boot而不是Spring MVC或SSHSpring Boot这些年能火起来最大的原因就是它把配置简化到了极致。岳记客栈这个项目我大概算了一下如果用传统的Spring MVC加XML配置光各种配置文件和依赖管理就要折腾大半天换成Spring Boot初始化一个可运行的Web项目只需要几秒钟application.yml里配好端口号和数据源就能直接跑起来。这里面有一个很重要的概念叫约定优于配置。Spring Boot默认了一套规范——比如静态资源放在resources/static下、模板引擎默认用Thymeleaf、启动类放在所有包的最外层。你只要遵守这套约定框架自动帮你完成大量装配工作。这对小型管理系统来说非常友好我可以把精力放在业务逻辑而不是环境搭建上。另外岳记客栈管理系统需要对接MySQL数据库Spring Boot的自动配置机制配合Spring Data JPA或者MyBatis-PlusCRUD操作写起来简直不要太舒服。再加上Spring Boot内嵌了Tomcat打成一个jar包直接部署省掉了单独装Tomcat、配置Web服务器的麻烦这对后期部署到小客栈本地的一台Windows机器上非常实用。2.2 Vue在前后端分离中的角色Vue在前端项目中的定位很明确负责视图层的渲染和用户交互。你可能会问为什么不用传统的服务端渲染比如JSP或者Thymeleaf我的考虑是客栈前台的界面需要在不同设备和浏览器上都保持流畅尤其是前台小妹同时开着几个页面操作页面的响应速度和交互流畅度非常重要。Vue的双向数据绑定机制让我特别省心。比如在入住登记页面上前台选中一个房间右边的入住表单会自动带上房间号填写完客人信息系统实时校验必填项。这些交互如果用原生JavaScript写DOM操作的代码量会多得让人崩溃但在Vue里只需要维护一个data对象页面元素通过指令自动同步代码量至少减少一半。我在这套系统里同时用到了Vue Router做前端路由和Axios做HTTP通信。Vue Router负责页面的跳转逻辑——比如从房间列表跳到新建订单页面参数怎么传递权限拦截怎么做Axios负责和后端的API接口通信处理请求头、拦截器、错误统一提示。这两个配合起来前端的骨架和网络层就都解决了。2.3 完整的技术栈清单岳记客栈管理系统我最终采用了一套非常经典、社区资料也特别丰富的技术组合。后端方面以Spring Boot 2.7.18为基础采用Java 8语言版本我认为这是很多教材和生产环境中最稳妥的组合资源齐全且很少遇到版本太高导致各种兼容性问题的坑。ORM框架选择了MyBatis-Plus而非原生MyBatis它内置的单表CRUD方法能让代码减少三成左右。连接池用的是Druid既能监控SQL性能又方便看慢查询日志。数据库MySQL 8.0存储引擎InnoDB字符集utf8mb4。前端这套组合相对固定Vue 2.6配Vue Router 3和AxiosUI组件库用的Element UI。这套体系在社区中迭代非常成熟遇到问题几乎都能搜索到现成的答案。文本编辑器用的富文本组件vue-quill-editor用于维护公告和房间介绍图表统计我用了ECharts把入住率、收入趋势这些数据做成可视化图表老板看了直呼专业。层级技术组件版本核心用途后端框架Spring Boot2.7.18提供RESTful API、依赖注入、自动配置ORMMyBatis-Plus3.5.3简化CRUD、分页查询数据库MySQL8.0持久化存储业务数据连接池Druid1.2.20连接管理、SQL监控前端框架Vue2.6.14页面交互与数据渲染UI组件Element UI2.15.14表格、表单、弹窗等基础组件前端路由Vue Router3.5.1页面跳转与参数传递HTTP客户端Axios0.27.2前后端接口通信图表ECharts5.4.3统计报表可视化3. 后端Spring Boot项目的一步步搭建3.1 项目初始化的两种方式和选择Spring Boot项目初始化我用过两种方式。第一种是在IDEA里直接创建勾选Spring Initializr选择Java版本和依赖IDE会自动拉取Maven依赖并生成标准的项目结构。第二种是去Spring官网的start.spring.io页面生成压缩包下载后导入IDE。我个人的习惯是用IDEA直接建因为可以在创建时就选好需要的Web、MySQL、MyBatis-Plus这些组件不用后面手动在pom.xml里补依赖。创建完项目后第一件事是确认pom.xml里的依赖是否完整。这个项目里我用的核心依赖包括Spring Boot的Web Starter、MyBatis-Plus的Starter、MySQL驱动、Lombok、Druid连接池。这里有个实际经验Lombok一定要装IDE的插件才能正常编译很多新手第一次跑项目报找不到getter和setter方法八成就是没装这个插件。项目结构上我推荐的包组织方式是这样controller包放接口入口service包写业务逻辑mapper包放数据库操作接口entity包对应数据库表结构的实体类config包放配置类common包放统一返回结果和异常处理。分层清晰的最大好处是后面加一个房间换房功能我知道应该在controller加一个接口方法在service里写换房的业务逻辑在mapper里增加SQL语句定位代码的时间非常短。3.2 数据库设计细节房间、订单和关联关系岳记客栈的数据库设计我花了整整两天时间打磨核心围绕着房间状态和订单生命周期展开。第一张表room是房间表字段有id、room_number房间号、room_type单人间、双人间、家庭房、price门市价、status空闲、已预订、已入住、打扫中、floor楼层、description房间介绍。status字段是整个系统的心脏几乎所有操作都在更新这个字段。第二张表orders是订单表字段包括订单编号order_no、客人姓名customer_name、手机号phone、入住时间check_in_time、退房时间check_out_time、房间id room_id、订单状态status、订单金额amount、备注remark。订单表的设计我特别注意了要冗余保存客人的基本信息和房价快照避免客人退房后修改资料导致历史订单数据错乱。第三张表是我觉得很有必要的check_in_record也就是入住记录表记录每一次实际的入住行为包括入住时间、预离时间、实际退房时间。为什么要单独拆这张表因为一个订单可能对应多次入住——比如客人续住一天中间需要更新状态如果只靠订单表本身的字段很难追溯完整的历史状态流转。房间和订单之间是一对多的关系一个房间在不同时间可以对应多个订单但在同一时间段内只能有一个有效订单。为了确保这一点我在数据库层面没有做复杂约束而是在业务逻辑里通过状态判断来保证——在创建订单时检查该房间当前status是否为空闲或已预订如果是已入住或者打扫中就直接拒绝下单并返回提示信息。3.3 RESTful接口设计和统一返回格式后端接口设计我遵循标准的RESTful风格以资源为核心用HTTP方法表达操作语义。房态相关接口包括GET /api/rooms获取房间列表、POST /api/rooms新增房间、PUT /api/rooms/status修改房间状态订单相关接口包括POST /api/orders创建订单、PUT /api/orders/checkout退房结账、GET /api/orders/list分页查询订单、GET /api/orders/export导出报表。在实际开发中我发现接口返回的数据格式如果不统一前端处理起来会非常痛苦。所以我定义了一个公共的Result类统一返回code状态码、message提示信息、data实际数据三个字段。无论查询成功、参数校验失败还是服务器内部异常前端都可以通过判断code值做统一的逻辑处理。这个习惯我在后面的项目里一直保持代码的规范性和可维护性都提升明显。Axios的拦截器也是我比较看重的一个工具。在请求拦截器里我统一把token加到请求头中这样后端可以通过token识别当前操作人员身份记录操作日志在响应拦截器里我统一处理业务异常码比如登录过期时自动跳转到登录页网络错误时弹出全局提示前端的代码量因此减少了很多。3.4 MyBatis-Plus让数据库操作化繁为简说实话如果这个项目用原生MyBatis来写光mapper的XML文件估计就能让人写到怀疑人生。MyBatis-Plus的BaseMapper接口内置了insert、deleteById、selectById、updateById、selectPage这些基础方法单表操作完全不需要写SQL直接调用即可。比如分页查询订单列表只需要new一个Page对象调用orderMapper.selectPage(page, wrapper)一个完整的分页查询就完成了。条件构造器LambdaQueryWrapper是我用得最多的功能。要查询今天入住的房间类型为单人间的订单代码就是wrapper.eq(Order::getRoomType, 单人间).eq(Order::getCheckInTime, today)可读性非常高而且用Lambda表达式直接引用实体的方法名避免了硬编码字符串字段名的低级错误。多条件组合查询也能通过链式调用轻松搞定。我还在实体类上的status和createTime这些字段上加了TableField注解配置了自动填充策略插入数据时createTime和updateTime自动生成时间戳不需要手动set。这个小技巧虽然简单但积累下来能减少很多重复的模板代码。4. 前端Vue项目从零到完整实现4.1 Vue项目创建和目录组织创建Vue项目我推荐用官方脚手架。执行npm install -g vue/cli安装脚手架工具然后使用vue create hotel-admin创建项目。这里有一个选择项需要提前想好Vue 2还是Vue 3。如果是学习参考、匹配大量现成教程Vue 2是更稳妥的选择如果是新项目并且团队已经熟悉组合式API可以考虑Vue 3。岳记客栈这个项目我用的Vue 2因为Element UI版本对Vue 2支持最稳定踩坑成本最低。项目目录结构上src目录里我分了api、assets、components、router、store、utils、views这几个核心文件夹。api文件夹集中管理所有和后端交互的接口调用方法每个模块一个文件——room.js放房间相关接口order.js放订单相关接口statistics.js放统计接口这样后期接口有变动时只需改一处。views文件夹是按业务页面划分的每个页面一个子文件夹里面放页面主组件和可拆分的小组件。比如room目录下包括了RoomList.vue房间列表、RoomDetail.vue房间详情、RoomForm.vue新增编辑表单order目录下包括了OrderList.vue订单列表首页、CheckInForm.vue入住登记表单、CheckoutConfirm.vue退房确认对话框。这种组织方式让我在维护代码时能很清晰地找到对应的文件。4.2 Vue Router配置和路由拦截Vue Router的配置是这个前端项目的骨架我把它单独放在了router/index.js文件里。系统的主要页面都配置了路由登录页 /login、首页 /dashboard、房间管理 /rooms、订单管理 /orders、入住登记 /checkin、数据报表 /statistics。为了提高首次加载速度我用了路由懒加载的方式即只有在访问对应路径时才加载对应的组件文件而不是一次性打包所有页面代码。路由守卫是保护整个系统安全的第一道防线。在beforeEach全局前置守卫里我检查了当前访问的页面是否需要登录权限。如果token不存在且访问的不是登录页就直接重定向到 /login。还有一个细节是页面标题的设置在meta字段里配置了每个页面的title路由跳转成功后通过document.title动态更新浏览器标签栏的标题交互体验会显得更专业。实际开发中路由配置容易踩的坑是路径参数传递。在订单详情页从列表页跳转时需要带上订单id我用的是路由通配符的方式定义路径为/orders/detail/:id跳转时通过this.$router.push({ path: /orders/detail/ row.id })传递参数详情页通过this.$route.params.id读取。这个方法比query字符串更清晰URL也更美观。4.3 Element UI搭建业务页面Element UI在客栈管理系统里的使用贯穿了所有页面。表格组件el-table是订单列表页的灵魂props列配置里设置好prop和label:data传入从后端查询的列表数据再配合el-pagination做分页组件一个功能完整的订单列表页面就能快速成型。我还用到了el-tag组件做状态标签的样式渲染——不同的订单状态动态绑定不同的type已入住显示蓝色、已退房显示绿色、已取消显示灰色视觉效果一目了然。表单组件el-form搭配el-form-item做入住登记这里最关键的技巧是校验规则的定义也就是validator函数。手机号的格式校验用正则表达式身份证号做位数校验入住日期必须晚于当前时间。这些规则写好后用户在提交表单时会实时触发校验不符合规则字段下方会红字提示有效防止了脏数据流到后端。弹窗组件el-dialog用于房间详情展示和修改确认。退房结账之前我会弹出一个确认框列出客人的住宿天数和消费明细让前台确认之后再提交能有效避免误操作。这个交互虽然简单但真实使用下来好评率非常高老板觉得系统很严谨。4.4 Axios接口调用和数据交互前端和后端的接口交互我统一封装在了api文件夹中。每一步的请求都用Promise的方式封装好返回的数据直接给调用方使用。比如获取房间列表的接口方法是export function getRoomList(params) { return request({ url: /api/rooms, method: get, params }) }里面的request实例是axios.create出来的封装对象设置了baseURL指向后端服务的地址超时时间设为10秒。实际开发中有一个非常容易被忽略的问题跨域请求。前端开发服务器默认运行在8080端口后端接口运行在8081端口浏览器会拦截跨域的Ajax请求。解决方式有两种一种是在后端添加CORS配置类允许跨域另一种是在Vue的devServer配置中设置proxy代理。我推荐用后者的方式配好之后前端代码里的接口路径都是相对路径部署时也不用改代码。数据交互中还要注意接口响应数据的结构一致性。我们后端Result类统一返回了code、message、data三个字段所以前端的request封装里我加了response拦截器——如果code等于200直接return response.data.data把真正的业务数据返回给页面如果code非200用Element UI的Message组件弹出message字段的提示如果HTTP状态码是401跳转登录页并清除本地存储的token。这样页面代码里只需要关心业务数据本身不用处理各种异常分支。5. 核心业务功能的代码实现5.1 入住登记复杂业务的前后端配合入住登记是客栈管理系统中业务逻辑最复杂的操作也是我代码写得最仔细的地方。前端的CheckInForm表单页面上前台需要选择房型然后通过el-select选择具体的可用房间。这里做了一个联动——选择房型之后调用后端接口查该房型下所有空闲状态的房间roomList里dynamic渲染下拉选项。选好房间后表单的房价字段会自动带出房间的价格当然也允许手动调整应付折扣场景。提交入住登记时前端先做一轮表单校验然后调用POST /api/orders接口。后端接口的处理逻辑包含了事务操作这一点极其重要创建订单记录、将房间状态从空闲改为已入住、生成一条入住记录这三个操作必须在一个事务里完成。如果订单创建成功但房间状态没更新就会出现前台数据混乱的问题。我是在Service方法的Transactional注解下完成这三个操作的任何一个步骤抛出异常前面的操作都会回滚保证数据一致性。有一个细节是订单号是怎么生成的。格式为YZ加时间戳加四位随机数例如YZ202407151430120123这样保证每个订单号唯一而且从订单号就能看出下单时间。代码实现就是用LocalDateTime格式化为yyyyMMddHHmmss字符串再拼接一个Random生成的四位数字存到orderNo字段中。5.2 退房结账金额计算的边界条件退房结账功能看着简单真正写起来才发现有很多隐藏的坑。正常情况下客人在退房时分两种情况按预离日期退房或者提前退房。按预离日期退房时应付金额等于每天房价乘以住宿天数。提前退房涉及一个规则——按实际住宿天数重新计算金额如果比预订时优惠的价格高则需补齐差价。为了防止歧义我把这块规则写在了系统配置表中老板可以在后台设置提前退房是否收取全额房费的开关。金额计算中最容易出错的是跨天问题。比如客人凌晨0点半入住按行业惯例当天不算完整一天从当天中午12点以后才算一天。岳记客栈的计费规则是当日入住次日12点前退房算一天超过12点加收半天房费。所以计算住宿天数时我做了退房时间到入住时间的小时差判断精确到分钟根据超过的时间分档计算费用确保金额准确到每一分钱。结账确认通过之后后端接口做了三件事更新订单状态为已退房并记录实际退房时间和实收金额将房间状态改为打扫中这样房间不会立即出现在空闲列表里避免保洁还没打扫完就有新客人入住在收入统计表里写入一条收入记录为财务模块提供基础数据。这三个操作同样放在事务中我测试过很多次逻辑是完备的。5.3 房态管理多维状态的可视化展示房态可视化是岳记客栈管理系统最有亮点的功能。我在前端页面上用卡片式布局渲染了所有房间每个房间卡片上用不同底色表示状态绿色是空闲、橙色是已预订、红色是已入住、灰色是打扫中。客人和前台进入系统后整个客栈的入住情况一眼就能看完。后端为此提供了房间状态统计接口返回每个状态下房间的数量前端通过计算属性自动更新数据。ECharts饼图展示今日房态分布折线图展示近7日入住率变化趋势柱状图展示近7日收入情况。老板说这是全系统他最常看的页面因为不用等前台汇报打开电脑就能掌握客栈运营情况。房态更新有一个关键的并发问题需要特别提醒。当两个前台同时操作同一间房时可能会引发状态冲突。比如A把房间302从空闲改为已入住同时B也在为302创建订单。我在update语句中加了条件判断UPDATE room SET status已入住 WHERE id#{roomId} AND status空闲只有当前状态还是空闲时才能更新成功。受影响行数为0时说明另一个操作已经抢先了后操作的一方需要重新选择其他房间。5.4 数据统计报表模块的实现心得统计报表模块是老板最看重的功能每天经营数据都要从这里导出。我设计了五个指标今日订单数、今日入住率、今日营业收入、本月累计收入和近期趋势图。为了避免每次打开报表页面都要实时计算大量数据造成数据库压力我采用了一个折中方案收入统计表日常只记录原始流水报表页面查询时动态聚合计算数据量在几千条时MySQL的聚合查询性能完全足够。订单导出功能用到了Apache POI后端生成Excel文件并返回给前端下载。导出范围支持按日期筛选默认导出本月所有订单。这里有一个性能优化点一次性导出大量数据时不能把所有数据都加载到内存再写入Excel而应该用分页查询逐批处理每查出一千条就写入一次避免内存溢出。客栈这种体量虽然不用这么复杂但养成这个设计习惯后我在后面做其他项目时受益匪浅。6. 部署上线与常见问题排查6.1 开发环境搭建的细节问题很多朋友问我为什么跟着教程一步步来项目还是跑不起来我总结了一下岳记客栈系统开发环境的搭建过程中有四个地方最容易出问题。Node.js版本和Vue CLI的兼容性。Vue CLI 4以上的版本要求Node.js 10以上但Node.js版本过高也可能出现兼容问题。我建议使用Node.js 16.20搭配Vue CLI 5.0.8这个组合在我测试过程中非常稳定。如果npm安装依赖时报Python或node-gyp相关的错误大概率是某些原生模块需要编译环境可以在终端执行一遍全局安装windows-build-tools解决。第二个容易出问题的是IDEA的Lombok插件。Spring Boot项目使用了Lombok后IDEA必须安装Lombok插件并在设置中开启Annotation Processing否则编译时找不到getter和setter方法。这是一个非常隐蔽又极其常见的坑很多新手在这里卡了一整天。第三是MySQL的字符集设置。建库时一定要指定utf8mb4字符集创建表的Collation也选择utf8mb4_general_ci。如果不设置插入中文数据时就可能报Incorrect string value错误。我通常会在配置文件中加上连接参数的characterEncodingutf8前后端都统一UTF-8编码。最后是Druid连接池的依赖和配置文件。使用Druid时如果只引入Starter但没填写初始化参数运行时会使用默认值偶尔会报连接获取超时的错误。我的建议是至少在配置文件中明确指定initialSize、minIdle、maxActive这三个参数哪怕就设置为1、1、20也比默认值稳妥。6.2 把系统部署到服务器上当系统在开发环境跑通之后部署上线就剩下两个核心步骤前端打包和后端打包。前端执行npm run build打包完成后会生成一个dist目录里面的静态文件可以部署到Nginx或者其他Web服务器上。后端项目在IDEA里执行mvn clean package -DskipTests会生成一个可执行的jar包然后通过java -jar hotel-management.jar启动。我推荐的部署架构是Nginx作为前端静态资源的服务器同时配置反向代理把以 /api 开头的请求转发到后端的Spring Boot服务上。这样前端域名和接口域名统一避免了前端请求的跨域问题。Nginx配置需要格外小心location匹配规则我之前因为location的路径写错导致接口请求全部返回404排查了很久。生产环境的数据库密码和开发环境不同一定不要把真实的数据库密码硬编码在配置文件中。我在Spring Boot里利用了多环境配置——application-dev.yml用于本地开发application-prod.yml用于生产环境启动时通过--spring.profiles.activeprod参数指定使用哪个配置。这样既保证了灵活性也避免了敏感信息泄露。6.3 实战中遇到的典型问题速查我在开发岳记客栈系统的过程中记录了不少实际操作时踩过的坑。这里整理成一个速查表希望能帮你节省一些排查时间。问题现象可能原因排查与解决方案后端启动失败报端口占用8080或8081端口被其他进程占用执行netstat -ano查看占用端口的PID结束对应进程或修改application.yml的server.port前端请求接口报404路由路径错误或后端接口路径不匹配检查Axios请求路径与后端Controller类的RequestMapping是否完全一致使用浏览器的Network面板查看实际请求URL数据库插入中文报错数据库表字符集不是utf8mb4修改表字符集ALTER TABLE 表名 CONVERT TO CHARACTER SET utf8mb4Maven依赖下载失败网络问题或镜像源不稳定在settings.xml中配置阿里云镜像源重新右键Maven Reimport上传文件大小受限Spring Boot默认上传限制为1MB在配置文件中设置spring.servlet.multipart.max-file-size为10MB页面样式错乱Element UI版本与Vue版本不兼容确认Element UI为2.x版本并匹配Vue 2.x清空浏览器缓存后刷新还有一个在部署阶段容易忽略的问题Spring Boot打成jar包后运行默认只加载classpath下的静态资源如果前端dist目录的文件没有整合到后端jar包中访问主页就会显示404。我的做法是在后期优化时使用前后端分离独立部署的方式来解决这个问题让Nginx直接托管前端的dist文件效果上令人满意。6.4 系统安全与性能优化的扩展思路岳记客栈管理系统作为企业内部使用的小型系统安全方面做到基础的密码加密存储和接口鉴权就够用了。我在password字段存的是MD5加密后再加盐的值而不是明文。如果后续要其他同事维护建议升级为BCrypt加密安全性更好这是Spring Security里自带的密码加密器。接口鉴权方面我用JWT做了一个简单的token认证机制。用户登录成功后后端返回一个带过期时间的token前端存储在localStorage中每次请求时放在Authorization头部由一个拦截器验证token的有效性。这样即使请求被截获攻击者也无法在token过期后继续访问系统。性能优化上我的经验是给订单表的查询字段加上索引。客栈每天产生的订单量即使到几十条加上索引后分页查询速度也几乎无感。另外一个优化点是浏览器端的缓存策略——静态资源通过Nginx设置了Cache-Control头图片、CSS、JS这些资源在客户端缓存一周重复访问时的加载速度提升明显。7. 一些开发经验与实际感悟整套系统从需求分析到部署上线前前后后大概用了三周时间。我个人的体会是这类管理系统的核心难点不在某个技术单点而在整个业务闭环的梳理和模块间的数据一致性维护。比如订单状态和房间状态如何联动退房时金额怎么算才不出错这些事情看起来琐碎但恰恰是系统能不能真正落地使用的关键。做客栈管理系统最大的成就不是用了多新的技术而是真正帮老板解决了实际运营问题。前台从原来纸质登记簿加Excel记账到现在电脑上一点就完成开单老板从原来每周要盘一次账到现在打开手机就能看报表。技术是为业务服务的这句话在这套系统上体现得淋漓尽致。最后分享一个建议如果你也想做类似的系统不要急着写代码。先花时间把业务流程画清楚把数据库表设计好把每个状态之间的转换关系理清楚。前期设计工作做扎实了后面写代码的效率会高得多改代码的次数也会少很多。这也是我在岳记客栈项目上学到的最重要的一课。