企业官网建设流程全解析

简介：基于SpringBoot与Vue的酒店客房管理系统完整毕业设计源码包，面向Java开发学习者与毕业设计选题学生，覆盖客房信息管理、用户管理、订单处理等常见业务场景。压缩包共904个文件，约18.44MB，包含178个Java后端源码、60个Vue前端组件、153个JS脚本及62个HTML页面，并配有可通过SQLyog或Navicat导入的MySQL数据库脚本，以及Maven工程配置，代码结构清晰，可直接导入Eclipse或IDEA运行。资源内另含16个map文件、5个bak备份文件及3个bat批处理脚本，便于快速搭建环境、还原项目或参考目录结构。目前已有69人学习使用，适合作为毕业设计参考、SpringBoot与Vue前后端分离项目的入门实践资料，也可用于酒店客房相关系统的二次开发与功能扩展。

1. 为什么值得自己写一套酒店客房管理系统：先想清楚再动手

拿到“酒店客房管理系统”这个需求，很多人的第一反应是找个现成的管理系统改改。但真做起来你会发现，市面上的成品系统要么功能冗余、权限模型僵化，要么报价里带着一堆你用不上的模块。基于Web的酒店客房系统设计与实现，核心价值不在“管理”两个字，而在把订房、入住、退房、房态变更这一条业务链，用可控的代码完整落一遍。尤其对Java开发者和刚接触企业级Web项目的人来说，这套系统是少有的能把Spring Boot、MyBatis、数据库事务和前端交互串起来的练手项目——业务够真实，边界够清晰，做好了直接能部署给小型酒店用。

这篇文章我会按自己实际做过的方案来讲：从功能拆解、数据库设计，到核心接口代码、部署细节，再到真会遇到的并发翻车和日期边界问题。适合两类读者：一类是想拿一个能写进简历的Java Web项目的人，另一类是确实要给自家或朋友的酒店做内部管理系统、不想被商业软件绑架的人。下面进入正题。

2. 系统设计与技术选型：先画清边界，再写代码

2.1 功能边界：客房管理系统到底管什么

酒店客房管理系统的常见误区是一上来就画大饼，把会员积分、餐饮预订、报表大屏全塞进去。我一般建议第一版只做四件事：客房信息管理、预订管理、入住退房管理、房态看板。把这四条线跑通，系统就有了骨架；其他功能都是后续往骨架上挂肉。

客房信息管理负责维护房型、门牌号、设施描述和价格；预订管理处理“客人打电话或在前台登记预订”这个动作，关键字段是入住人、联系电话、预订入住日期和离店日期；入住退房管理把预订状态转为在住，并在离店时计算房费、释放房间；房态看板则是给前台看的实时状态页——哪些房间脏、哪些净、哪些占用，一屏看清。

角色的权限边界也要提前定好。我的做法是分三种角色：前台（能操作预订、入住、退房）、客房部（只能修改房态，比如把脏房设为净房）、管理员（管房型、价格和账号）。不要搞细粒度权限，多数小酒店的店员就几个人，太复杂的权限模型反而让员工懒得用系统。

2.2 技术栈选型：Spring Boot + MyBatis + MySQL 的搭配理由

这套系统的技术选型，我推荐Spring Boot 2.7 + MyBatis + MySQL 8.0 + Thymeleaf（或Vue，取决于团队熟悉度）。Spring Boot负责把工程跑起来，MyBatis用于数据访问，MySQL存业务数据。前端方面，如果不想前后端分离，Thymeleaf模板渲染即可，部署成本低；如果计划以后接小程序或App，用Vue + 后端REST API会更方便。我在这篇文章里按前后端不分离的方案讲，因为对新手更友好，部署时只需一个Java进程。

MyBatis在这个项目里比JPA更合适。原因是客房系统的SQL场景很典型：多表联查（房间+房型+订单）、动态条件更新（改房态时只更新变化字段）、统计类SQL（计算某日入住率）。MyBatis的XML里可以直接写这些SQL，控制力强，出了问题也好排查；JPA的自动生成SQL在复杂查询下反而难调优。

数据库用MySQL就行，不需要引入Redis或消息队列。小酒店并发量有限，一台2核4G的服务器就能撑住。前期加缓存除了增加复杂度，没有任何实际收益——这是我做过不少项目后比较坚定的一个判断。

2.3 数据库设计：5张核心表与状态机设计

数据库是这个系统的命根子，我把它拆成5张表：room（房间表）、room_type（房型表）、customer（客人表）、reservation（预订表）、stay_record（入住记录表）。为了跑通第一版，不加会员表、价格策略表，那些后期可以再演进。

先看建表脚本。注意这里用了InnoDB、utf8mb4，并且给关键字段加上了索引：

CREATE TABLE room_type ( id INT AUTO_INCREMENT PRIMARY KEY, type_name VARCHAR(30) NOT NULL COMMENT '房型名称：大床房/标间/套房', bed_count TINYINT NOT NULL DEFAULT 1, area DECIMAL(5,2) COMMENT '房间面积㎡', base_price DECIMAL(10,2) NOT NULL COMMENT '门市价', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='房型表'; CREATE TABLE room ( id INT AUTO_INCREMENT PRIMARY KEY, room_no VARCHAR(10) NOT NULL COMMENT '房间号，如 501', room_type_id INT NOT NULL, floor_no TINYINT COMMENT '所在楼层', status TINYINT NOT NULL DEFAULT 0 COMMENT '0可售 1占用 2脏房 3维修', remark VARCHAR(100), UNIQUE KEY uk_room_no(room_no), KEY idx_type(room_type_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='房间表'; CREATE TABLE customer ( id INT AUTO_INCREMENT PRIMARY KEY, customer_name VARCHAR(30) NOT NULL, phone VARCHAR(20) NOT NULL, id_card VARCHAR(30) COMMENT '证件号码', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_phone(phone) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='客人表'; CREATE TABLE reservation ( id INT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL COMMENT '预订单号', room_id INT NOT NULL COMMENT '预分配的房间', customer_id INT NOT NULL, check_in_date DATE NOT NULL, check_out_date DATE NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT '0待入住 1已入住 2已取消 3已离店', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no(order_no), KEY idx_room_date(room_id, check_in_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='预订表'; CREATE TABLE stay_record ( id INT AUTO_INCREMENT PRIMARY KEY, reservation_id INT, room_id INT NOT NULL, customer_id INT NOT NULL, real_check_in DATETIME NOT NULL, real_check_out DATETIME, total_amount DECIMAL(10,2) COMMENT '实际消费金额', status TINYINT NOT NULL DEFAULT 0 COMMENT '0在住 1已退房', KEY idx_room(room_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='入住记录表';

这里有几个设计考量。room表的status字段用的是状态值而不是字符串，这样在Java枚举里可以直接映射，避免字符串散落在业务代码中。reservation表同时存room_id和check_in_date，并通过联合索引(idx_room_date)支撑“查某房间在某个时间段是否被占用”的高频查询。表之间没有设置物理外键，因为MyBatis体系下程序控制关联更灵活，物理外键在后期做数据清洗时会成为负担。

客房系统的状态机是这个设计里最关键的概念。我把房间状态定义成五种：可售、占用、脏房、维修，以及预订中（在reservation表里体现）。前台空闲时房间是“可售”；客人订房后，房间进入“预订中”（此时房间实体不变，但reservation表有未取消记录）；客人办入住，房间变“占用”；退房后变“脏房”；保洁打扫完，改回“可售”。这个状态流转要在后面接口里严格控制，不能让脏房直接跳到占用，否则前台排房会出乱子。

3. 代码落地：从工程骨架到跑通第一个接口

3.1 用 Spring Initializr 生成工程骨架的步骤与配置

这一步没什么玄学，就是标准流程。打开start.spring.io，Artifact填hotel-admin，依赖选Spring Web、MyBatis Framework、MySQL Driver、Thymeleaf、Validation。生成后导入IDEA，先不要急着写业务代码，而是把配置文件和启动类跑通。

application.yml里的配置如下：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/hotel_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver thymeleaf: cache: false mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.hotel.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

需要注意url里的serverTimezone=Asia/Shanghai，这能避免MySQL连接时区报错；map-underscore-to-camel-case设为true后，数据库的room_no字段可以自动映射到Java的roomNo属性，省去大量resultMap。log-impl设为StdOutImpl后，开发阶段每个SQL都会打印到控制台，查问题非常方便；上线前记得关掉或改为logback。

这一步跑通后，entity、mapper、service、controller四层包结构创建好，就能进入第一个核心业务：客房查询。

3.2 实体类与Mapper层：MyBatis映射和动态SQL

先写Room实体类。Java实体类字段不用手写一堆getter/setter，用Lombok的@Data注解即可。这里有个细节：枚举字段在MyBatis中默认按name存，需要加typehandler配置。我用的是Integer状态码，避免这个麻烦：

@Data public class Room { private Integer id; private String roomNo; private Integer roomTypeId; private Integer floorNo; private Integer status; private String remark; // 非表字段，联查时用 private String typeName; private BigDecimal basePrice; }

接着是RoomMapper接口和XML。这里动态SQL的价值体现出来了。查可用房间时，要根据入住日期、离店日期筛选出“在该时间段内没有被占用和预订”的房间。SQL逻辑是：房间状态为可售，并且不存在一条预订记录，其入住日期在目标区间内：

<select id="selectAvailableRooms" resultType="com.example.hotel.entity.Room"> SELECT r.*, rt.type_name AS typeName, rt.base_price AS basePrice FROM room r JOIN room_type rt ON r.room_type_id = rt.id WHERE r.status = 0 <if test="roomTypeId != null"> AND r.room_type_id = #{roomTypeId} </if> AND NOT EXISTS ( SELECT 1 FROM reservation res WHERE res.room_id = r.id AND res.status IN (0, 1) AND res.check_in_date &lt; #{checkOutDate} AND res.check_out_date &gt; #{checkInDate} ) AND NOT EXISTS ( SELECT 1 FROM stay_record sr WHERE sr.room_id = r.id AND sr.status = 0 ) ORDER BY r.room_no </select>

重点关注那段NOT EXISTS子查询。预定重叠的判断条件是“新入住日期小于已有离店日期，且新离店日期大于已有入住日期”——这是区间重叠判断的标准写法。比较符号在XML中要转义成<和>，否则XML解析报错。这里把预订记录和在住记录分开查，是为了防止预订和入住数据不统一造成的错开问题。

Mapper接口的写法：

@Mapper public interface RoomMapper { List<Room> selectAvailableRooms(@Param("checkInDate") LocalDate checkInDate, @Param("checkOutDate") LocalDate checkOutDate, @Param("roomTypeId") Integer roomTypeId); }

参数里传LocalDate而不是String是值得坚持的好习惯。日期对象可以让MyBatis自动做类型转换，避免因字符串格式不一致导致SQL注错或比较失败。

3.3 业务层与控制器：预订、入住、退房的核心流程

业务层是整套系统的关键。以预订为例，Service层的核心方法是createReservation。它要做三件事：校验日期合法性、查询该房间该时段是否可订、插入预订记录并生成订单号。

@Service public class ReservationService { @Transactional(rollbackFor = Exception.class) public Reservation createReservation(ReservationRequest req) { // 1. 日期校验：入住日期必须早于离店日期，且不能是过去时间 if (!req.getCheckInDate().isBefore(req.getCheckOutDate())) { throw new BusinessException("入住日期必须早于离店日期"); } // 2. 再次检查房间可用性，防止并发预订 List<Room> available = roomMapper.selectAvailableRooms( req.getCheckInDate(), req.getCheckOutDate(), req.getRoomTypeId()); Room targetRoom = available.stream() .filter(r -> r.getId().equals(req.getRoomId())) .findFirst() .orElseThrow(() -> new BusinessException("该房间在所选时段不可预订")); // 3. 生成订单号并插入 Reservation reservation = new Reservation(); reservation.setOrderNo(generateOrderNo()); reservation.setRoomId(targetRoom.getId()); reservation.setCustomerId(req.getCustomerId()); reservation.setCheckInDate(req.getCheckInDate()); reservation.setCheckOutDate(req.getCheckOutDate()); reservation.setStatus(0); reservationMapper.insert(reservation); return reservation; } private String generateOrderNo() { return "R" + System.currentTimeMillis() + String.format("%04d", new Random().nextInt(10000)); } }

注意@Transactional注解。由于预订操作涉及检查房间和插入记录两步，如果这两步之间发生异常，会产生脏数据。事务保证这段逻辑要么全部成功，要么全部回滚。rollbackFor = Exception.class尤其关键，因为Spring默认只回滚RuntimeException，checked exception不会触发回滚——这是很多人踩过的坑。

控制器层就薄了，接收参数、调用Service、返回页面：

@Controller @RequestMapping("/reservation") public class ReservationController { @PostMapping("/create") public String create(@Valid ReservationRequest req, RedirectAttributes attrs) { try { reservationService.createReservation(req); attrs.addFlashAttribute("successMsg", "预订成功"); } catch (BusinessException e) { attrs.addFlashAttribute("errorMsg", e.getMessage()); } return "redirect:/reservation/list"; } }

这里用RedirectAttributes而不是ModelAndView，是因为“提交后刷新页面会重复提交”这个问题。redirect加flash attribute是标准的Post-Redirect-Get模式，能让前台的预订体验流畅很多——这算是我从几版被吐槽的系统中总结出来的经验。

4. 把页面和后端接起来：前台操作与数据展示

4.1 房态看板页：一屏看清所有房间状态

前台最常用的页面，是把所有房间按楼层显示在一个网格里，每个格子一个房间，用不同颜色区分状态。房间状态是高频变化数据，这个页面要求打开后3秒内显示完成。我用Thymeleaf模板加简单JavaScript轮询来实现。

核心HTML结构如下：

<div class="room-grid" th:each="floor : ${floors}"> <h3><span th:text="${floor.floorNo}">5</span> 层</h3> <div class="rooms-in-floor"> <div class="room-cell" th:each="room : ${floor.rooms}" th:classappend="'status-' + ${room.status}" th:data-room-id="${room.id}" th:text="${room.roomNo}"> 501 </div> </div> </div>

关键点是th:classappend="'status-' + ${room.status}"。这样只用一个CSS类名切换，就完成了“可售绿色、占用红色、脏房橙色、维修灰色”的视觉区分。不要用内联style来写颜色，后期要改配色时会想哭。

页面用setInterval每10秒请求一次/room/status接口，返回JSON后局部更新状态。注意这里不能整页刷新，否则前台正在操作的弹窗会被打断。局部更新的JavaScript逻辑：

setInterval(function() { fetch('/room/status') .then(res => res.json()) .then(data => { data.forEach(item => { const cell = document.querySelector(`.room-cell[data-room-id="${item.id}"]`); cell.className = 'room-cell status-' + item.status; }); }); }, 10000);

这个接口在Controller层的实现很简单，但查询SQL要高效。一次性查出所有房间及其状态，不要在循环里逐条查数据库，否则页面会慢到让前台想砸电脑。

4.2 权限拦截器与登录态管理：不该让客房部看到房价

权限拦截是最容易被新手忽略的模块。如果系统直接裸奔，任何一个能访问IP的人都能操作数据库。我用Spring的HandlerInterceptor做登录拦截，配合Session保存当前用户信息。

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } return true; } }

然后注册到WebMvcConfigurer中，并指定放行规则：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login", "/css/**", "/js/**", "/error"); } }

角色权限的粒度：客房部的账号登录后允许访问房态看板和提交保洁完成接口，但不允许访问预订管理页和退房结算页。这个要求单靠一个登录拦截器做不到，需要再写一个角色判断。我的做法是在Session里存用户角色码（0管理员、1前台、2客房部），在需要限制的Controller方法上加自定义注解，然后再用一个HandlerInterceptor去解析注解。这样不侵入业务代码，平时维护也比较直观。

5. 避坑与排查：这 5 个坑让我改了三版代码

5.1 并发预订导致“超卖”：两间房被卖给了三个客人

现象：酒店前台两台电脑同时操作，同一个房间在同一时段被预订了两次，房态看板显示仍在售。

原因：我第一版做可用房间查询时，是先查后插，两个事务同时拿到“房间可用”的结果，又同时插入预订记录。数据库层面没有约束，业务层面也没有锁。

解决：加一张“唯一约束”不够，因为房间+日期的组合本身允许多条不同日期记录。我最终做了三层防护：一是房间预订时在Service层对room_id加SELECT FOR UPDATE锁，串行化同一房间的预订操作；二是修改SQL，用INSERT SELECT语句，把查和插合并到一个原子操作里（不回房间表场景下）；三是在应用层对同一room_id加分布式锁（单机场景用ReentrantLock即可）。最推荐的是方案二，因为它只需要改一条SQL：

INSERT INTO reservation (order_no, room_id, customer_id, check_in_date, check_out_date, status) SELECT #{orderNo}, r.id, #{customerId}, #{checkInDate}, #{checkOutDate}, 0 FROM room r WHERE r.id = #{roomId} AND r.status = 0 AND NOT EXISTS ( SELECT 1 FROM reservation res WHERE res.room_id = r.id AND res.status IN (0, 1) AND res.check_in_date < #{checkOutDate} AND res.check_out_date > #{checkInDate} )

如果受影响行数为0，说明房间已被占用，直接抛异常。这让“检查可用性”和“插入预订”变成一条SQL，从根上消除了竞态窗口。

5.2 退房日期边界：12点退房和凌晨入住怎么算

现象：客人凌晨2点入住，预订的check_in_date是今天，前台一操作就报错“入住日期不能是过去时间”。

原因：我在校验时用了LocalDate.now()和checkInDate比较。凌晨2点时，系统日期已经是当天，但酒店的业务日期还停留在前一天晚上，这个简单的日期比较不符合酒店业习惯。

解决：引入“业务日期”概念。在系统设置表里存一个可配置的营业日偏移量（默认-1，表示凌晨0点到6点仍算前一天）。校验时用业务日期+偏移量替换LocalDate.now()：

LocalDate businessDate = LocalDate.now().minusDays(configService.getDayOffset()); if (req.getCheckInDate().isBefore(businessDate)) { throw new BusinessException("入住日期不能早于业务日期"); }

这个坑不遇到凌晨入住的场景很难发现，但真实酒店每天都有夜间到店的客人。写日期相关的系统，一定要先问清楚“系统的业务日期从哪里来”。

5.3 MyBatis查询超时与数据库连接池耗尽

现象：系统运行几小时后就出现“Connection is not available, request timed out after 30000ms”的错误，重启后正常，过几小时又复现。

原因：某个Service方法里执行了耗时较长的查询（比如在循环里查100次数据库），把连接池耗尽了。排查时发现我在查询房态时，每间房查一次预订记录——这是典型的N+1查询问题。

解决：一次性JOIN关联查询，把循环里的查询改成聚合查询。另外，把HikariCP连接池的maximumPoolSize从默认10调大到20，并把connection-timeout从30秒缩短到5秒，让失败的请求快速失败而不是阻塞等待：

spring: datasource: hikari: maximum-pool-size: 20 connection-timeout: 5000 minimum-idle: 5

同时，把耗时超过2秒的慢SQL在开发环境全部打印出来逐条优化。

5.4 前端上传的房间照片变成一团乱码

现象：上传的图片在页面显示时只有一个小红叉，浏览器控制台显示文件无法识别。

原因：开发时用的IDEA内置Tomcat只允许POST请求体大小为2MB，照片稍大就直接被截断导致文件损坏。

解决：在application.yml里配置Tomcat请求体大小：

spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB

如果是Nginx反代，还需确认client_max_body_size的配置是否一致。这条排查经验价值不大但非常现实——多半因为图片压缩逻辑没做导致的，后来统一在前端压缩图片到1280px宽以下，从根本上减小了上传体积。

5.5 订单号重复导致主键冲突

现象：并发高峰时报Duplicate entry for key 'uk_order_no'，整笔预订失败。

原因：我用System.currentTimeMillis()+随机数生成订单号。单线程下没问题，多线程并发时可能出现时间戳相同、随机数也碰巧相同的情况，概率不小。

解决：换用数据库自增或UUID。我的做法是：JDK自带的UUID.randomUUID().toString().replace("-", "").substring(0, 20)生成订单号。虽然牺牲了一点可读性，但唯一性有保证。双订单号重复的问题其实是设计失误，不该用时间戳去拼。

6. 前后端联调与部署：从本地到服务器

6.1 打包与部署

代码写完后，用Maven打包成可执行Jar包。我习惯在打包前先跑一遍全量测试，再执行mvn clean package -DskipTests调试部署。Jar包名字是hotel-admin-0.0.1-SNAPSHOT.jar，直接扔到服务器上就能运行：

mvn clean package -DskipTests scp target/hotel-admin-0.0.1-SNAPSHOT.jar root@your-server:/opt/hotel/ ssh root@your-server "cd /opt/hotel && nohup java -jar hotel-admin-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod > app.log 2>&1 &"

生产环境的配置我单独放到application-prod.yml里，关闭MyBatis的SQL打印、开启Thymeleaf的模板缓存、使用独立的高权限数据库账号。nohup+重定向是零依赖的启动方式，适合初期没有部署平台的场景；后面再上systemd或Docker也不迟。

6.2 数据备份与常用管理命令

酒店系统最重要的资产是这些预订和入住记录。我的习惯是每天凌晨3点用cron任务做一次mysqldump全量备份，保留7天：

0 3 * * * mysqldump -u backup_user -p'password' hotel_db > /backup/hotel_$(date +\%F).sql find /backup -name "hotel_*.sql" -mtime +7 -delete

数据库恢复是演练出来的，不是等出事才学的。我建议每个做这套系统的人至少演练一次从备份恢复的过程：

mysql -u root -p hotel_db < /backup/hotel_2024-01-15.sql

6.3 进阶：让系统从“能跑”走向“好用”

第一版上线跑通后，值得投入的两个方向，一是报表统计，二是对接支付或小程序。

报表模块我建议做成三张表：日营业汇总（每日房费总收入、入住率、平均房价）、房型销量排行（哪些房型好卖，用于指导定价）、预订渠道统计（区分电话、OTA、直接到店）。这些统计SQL用GROUP BY+DATE_FORMAT就能实现，关键是建立物化逻辑，把每晚定时汇总的数据落到一张表里，而不是每次看报表都全表扫描。

小程序对接这块，市面上调研下来用微信开发者工具提交预约订单、查询订单状态是高频需求。这个要等Web端稳定再排上日程，避免两边数据不一致。我的做法是在第一版就预留了channel字段（预订来源），这样后续无论是小程序还是OTA对接，都能按渠道追踪数据，不用再改表结构。

最后说一个我自己改了三轮才形成的习惯：配置永远不进代码。连接串、账号密码、上传路径，一律放application.yml的外部配置里，用环境变量去引用，比如spring.datasource.password=${DB_PASSWORD}。这样代码帮别人review或换环境部署的时候，不会因为密码硬编码产生安全隐患。做这套系统跟做其他项目一样，最大的成本从来不是写代码，而是改代码——前期的表格设计、配置隔离、状态机定义越清楚，后面返工越少。希望这篇文章能帮你少走一遍我走过的弯路。

本文还有配套的精品资源，点击获取