带过这么多届课程设计和毕业设计之后，我越来越觉得“SSM + 管理类系统”这个组合几乎是每个做Web开发的人都会遇到的标配。而商铺租赁管理系统恰好是这类项目中比较有代表性的一个，业务场景够真实、功能边界够清晰、技术栈又非常经典，用来练手或者直接作为毕设题目都非常合适。
这篇文章我会从一个实际开发者的角度，把基于SSM的商铺租赁管理系统从需求拆分、技术选型、数据库设计到核心代码落地的完整思路拿出来聊聊，顺便把我踩过的坑和排查经验也一起整理进去。不管你是正要开始做这个课题的学生，还是想快速理解SSM项目架构的初学者，这篇文章都应该能帮你在动手前把方向理清楚，少走弯路。
1. 先说说为什么要做这个系统
很多同学选题的时候容易选那种“看着高大上、实则无从下手”的题目，比如智能推荐、分布式电商这种，结果做着做着发现业务逻辑复杂到根本收不住，最后变成了一个功能残缺的半成品。商铺租赁管理系统这类题目则完全不同，它属于典型的“业务明确、链路完整、技术覆盖适中”的管理信息系统，特别适合作为系统性学习Java Web开发的练手项目，也适合用来展示你对业务和代码的综合把控能力。
1.1 商铺租赁管理的真实痛点
商铺租赁听起来就是“签合同、收租金”这么简单，但真正管过或者调查过这个行业的人都知道，这里面的琐碎程度远超想象。商场运营人员手里可能同时管着几十甚至上百个商铺，每个商铺有独立的租户、押金、租期、租金标准、缴费周期和合同状态，再加上转租、退租、续签这些变动，如果全部靠Excel表格来管，很容易出现几类问题：
- 合同到期时间记不清，漏掉续签窗口期，导致商铺空置损失。
- 租金收缴进度靠手动追踪，哪家拖了费、哪家押金抵扣了多少，久了对不上账。
- 合同和缴费记录分散在纸质文件或者不同人的电脑里，复盘数据非常困难。
- 租户信息和商铺信息变更频繁，缺乏历史记录和流转痕迹。
这个系统要解决的，本质上就是“把分散在Excel、纸质合同和小本本里的信息，统一收拢到一个在线平台上，让每一步操作都有记录、有状态、可追踪”。这也是我经常和学生强调的一点——任何管理系统在需求分析阶段，最重要的不是急着画界面，而是搞清楚现有流程里到底“乱在哪里、痛在哪里”，你的设计才有针对性。
1.2 为什么选SSM这套组合
SSM是Spring + SpringMVC + MyBatis的组合，在Java Web领域火了很多年，现在依然是大量企业级系统和新手教学项目的首选。原因很简单：它的每一层都解决了特定问题，组合起来正好够用。
Spring负责对象管理和事务控制，让整个应用的依赖关系变得清晰可控；SpringMVC负责请求路由和参数绑定，把浏览器发来的HTTP请求映射到对应的处理方法上；MyBatis负责数据库操作，用Mapper接口加XML的方式把SQL语句和Java代码解耦。三者在项目中各有定位，单拎出来任何一个替代品（比如用Spring Boot替换掉整个SSM、用JPA替换MyBatis）也都能做系统，但SSM“各管一段、分层清晰”的特点，让学习者更容易理解Web开发的经典三层架构。
再说实际的市场层面，虽然Spring Boot现在已经非常流行，但大量存量项目仍然是SSM架构，很多企业的技术面试也还会问SSM相关的原理问题。把一个SSM项目吃透，理解它背后依赖注入、AOP、ORM这些核心思想，再切换到Spring Boot其实非常平滑。反过来，如果你一上来就直接用Spring Boot的自动配置，反而容易忽略掉底层装配的过程。这个项目的价值不在于“用最时髦的技术”，而在于“把最经典的技术用扎实”。
2. 整体设计与技术选型思路
在真正动手写代码之前，我习惯先把系统拆成几个层次去思考：用户角色有哪些、核心业务流程是什么、数据如何流转、页面如何处理。这个阶段不需要写一行代码，但直接决定了后续开发的顺利程度。
2.1 SSM的核心分工与协作方式
在做这个系统的时候，官方一点的说法叫“前后端分离思想下的服务端分层架构”，实际上就是从请求到响应的完整链路拆解。
一次用户操作，比如管理员在页面上点击“新增商铺”，浏览器会发出一个HTTP请求，SpringMVC的前端控制器DispatcherServlet先拦截到这个请求，再通过HandlerMapping找到对应的Controller方法。Controller负责接收参数、调用Service层的方法，Service层处理具体的业务逻辑（比如校验商铺编号是否重复），需要访问数据库时就调用Mapper接口——注意这里只是接口，真正执行SQL的是MyBatis在启动时生成的代理实现。最后Controller把处理结果封装成ModelAndView或者JSON数据返回给页面，前端渲染后展示给用户。
如果简化成一句话：页面负责展示和交互，Controller只做调度不做业务，Service专注业务规则，Mapper专注SQL语句。这种分层的核心价值在于“职责单一”，每一层都能独立测试和维护，也方便团队成员分工协作。很多同学在写代码时喜欢把业务逻辑直接堆在Controller里，虽然功能也能跑通，但项目稍微变大之后就会出现大量重复代码，改一个业务规则要到处找，后面维护极其痛苦。
2.2 数据库设计与ER思路
商铺租赁管理系统的数据库设计是整个项目的地基，我的习惯是先画ER图理清实体关系，再落成表结构。核心实体大概有这些：
- 用户表（管理员、运营人员账号）
- 商铺信息表（商铺编号、位置、面积、状态）
- 租户信息表（租户姓名、电话、证件号码）
- 租赁合同表（关联商铺和租户，记录租期、租金标准、押金）
- 付款记录表（每笔租金收缴、押金收支）
- 消息通知表（到期提醒、缴费提醒的发送记录）
实体之间的关系也比较清晰：一个商铺可以有多条租赁合同（历史租约+当前租约），一条合同对应一个租户，一条合同会对应多条付款记录。这里要注意一个关键设计点——商铺和租户之间不是简单的一对一关系，因为商铺会转租、退租后再租，所以需要“合同表”作为中间纽带，让两边的历史都能追溯。
数据库设计过程中最容易踩的坑是“只想着满足当前页面展示，忽略业务扩展”。比如“商铺状态”这个字段，很多同学设计时给个int类型就完事，但实际业务里商铺可能处于“未出租”“已出租”“已到期待续签”“维修中”等状态，每个状态对应不同的可用操作，这种状态流转在后面业务逻辑里就要做约束。如果你在设计时能把状态枚举清楚，后面写代码就会顺畅很多。
3. 核心功能模块与关键链路
功能模块的划分直接决定系统能不能覆盖真实管理链路。我通常会把商铺租赁管理系统分成几个核心模块，每个模块聚焦一类业务操作，模块之间通过数据和状态串联。
3.1 登录认证与权限控制
管理类系统的第一步永远是身份认证。SSM项目里最常规的做法就是用拦截器实现登录校验：定义一个HandlerInterceptor，在preHandle方法里检查Session中是否存在登录用户，如果没有就把请求重定向到登录页。权限控制的话可以给用户增加一个“角色”字段，比如管理员和普通运营人员，在拦截器里就可以判断哪些操作需要管理员权限。
这里我提醒过很多次：千万不要把登录校验只写在页面上。前端可以隐藏按钮，但真正的安全性必须在服务端控制。拦截器的拦截范围也要注意，register、login这些接口必须放行，静态资源（js、css、图片）也要排除掉，否则页面样式加载不出来，排查半天才发现是拦截器把所有静态资源也拦了。
3.2 商铺信息管理与合同管理
商铺管理模块的核心是维护店铺的档案信息。除了基本的编号、名称、位置、面积，我会建议加上“当前状态”和“关联合同”这两个维度。为什么？因为运营人员打开商铺列表时，最关心的不只是商铺的静态信息，而是这个铺子现在是否在租、租给谁、租金是多少、什么时候到期。这样商铺列表和租赁合同模块之间就有了天然的数据联动。
合同管理是整个系统里业务规则最复杂的模块。一份合同从创建到结束，状态流转大概是：待生效 → 生效中 → 到期/已终止。终止的场景又分为正常到期、提前退租、违约终止等。每种状态下都有不同的操作约束，比如：
- 一个商铺在同一时间段只能存在一条“生效中”的合同。
- 合同即将到期时，可以发起续签，续签本质是创建一条新合同。
- 合同终止时必须结算剩余租金和押金退还逻辑。
这块业务如果只做成“增删改查”，那系统就会显得没有深度。我建议在需求设计阶段就把状态流转图画清楚，用一张状态枚举表来约束每个状态允许执行的操作。这样不仅仅是为了应付答辩，更是为了代码的可维护性。
3.3 租金计算与到期提醒逻辑
租金模块听起来就是“金额 = 单价 × 面积 × 月份数”，但实际业务中往往会遇到押金抵扣、滞纳金、优惠减免、电费物业费合并收缴这些复杂情况。作为课程设计或毕设，我建议至少把“应收金额、实收金额、未收金额”这几个字段分开存储，不要每次临时计算，因为一旦账单被修改过，临时算出来的数字很难保证和页面之前展示的一致。保留每一笔缴费记录的实收金额和支付时间，后续对账的时候有据可查。
到期提醒功能是这个项目的一个加分项。最简单的实现方案就是维护一张定时任务表，每天扫描合同表里距离结束日期小于N天的合同，生成提醒记录插入消息表。如果用Spring自带的@Scheduled注解就能实现，只要在Spring配置里开启定时任务开关即可。提醒方式可以先做站内消息，在系统首页显示待办提醒列表，如果学有余力还能接入邮箱通知。这个功能的业务价值非常直观，能很好地展示系统设计对真实业务的思考。
3.4 数据统计与可视化看板
管理系统的另一项刚需是统计功能。商铺出租率、租金收缴率、合同到期分布、每月的租金收入趋势，这些都是运营方非常关注的指标。统计功能在SSM项目里的实现思路不复杂，核心是SQL的聚合查询：用GROUP BY按时间维度分组，用SUM和COUNT统计对应的金额和数量。比如月租金收入统计，SQL大致可以写成按年、按月分组汇总实收金额。
图表展示方面，可以在JSP页面中嵌入ECharts来画折线图和柱状图，后端通过接口返回JSON数据，前端用Ajax请求接口，拿到数据后交给ECharts渲染。这里要注意一个细节——接口返回的JSON结构要设计得稳定，尽量固定成“日期列表 + 金额列表”，前端直接使用，格式清晰还省去二次处理。很多同学在前后端联调时出现图表数据对不上，往往就是JSON结构没有事先约定好。
4. 核心业务代码落地与配置方案
光梳理思路不落地代码等于纸上谈兵，但直接贴一大段代码又容易让人看得一头雾水。这一章我把这个项目里最核心、也最值得参考的代码片段拆开来讲，重点放在为什么这么写以及有哪些细节值得注意。
4.1 数据库表结构定义的几个关键点
先看几张核心表的定义，以租赁合同表为例：
CREATE TABLE t_contract ( id INT PRIMARY KEY AUTO_INCREMENT, shop_id INT NOT NULL COMMENT '商铺ID', tenant_id INT NOT NULL COMMENT '租户ID', contract_no VARCHAR(50) NOT NULL COMMENT '合同编号', start_date DATE NOT NULL COMMENT '租期开始日', end_date DATE NOT NULL COMMENT '租期结束日', monthly_rent DECIMAL(10,2) NOT NULL COMMENT '月租金', deposit DECIMAL(10,2) NOT NULL COMMENT '押金', status TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0待生效 1生效中 2已到期 3已终止', create_time DATETIME NOT NULL, update_time DATETIME NOT NULL );几个容易踩坑的细节：金额字段千万不要用float或double，Java的二进制浮点数会有精度问题，我强烈建议用DECIMAL，比如DECIMAL(10,2)，既能满足金额范围，又不会出现0.1+0.2不等于0.3这种尴尬情况；状态字段用TINYINT并加注释，不要用字符串存“已生效”这种中文值，数据库里存编码、页面上转义，这是设计习惯问题；日期类型用DATE还是DATETIME要区分清楚，单纯日期用DATE，需要精确到时分秒的就用DATETIME。
我的建表习惯是每张表都带id自增主键和create_time、update_time，再加一个逻辑删除字段deleted（需要的时候用，基础课程设计可加可不加）。别小看这些基础字段，后面做统计、排序、排查数据时就会体会到它们有多方便。
4.2 Spring与MyBatis整合的核心配置
很多同学在SSM整合阶段卡住，一启动就报一堆Bean创建异常，绝大多数问题都出在配置文件上。我通常的做法是在applicationContext.xml里配置组件扫描、数据源和事务管理器，在spring-mvc.xml里单独扫描Controller层，两者扫描范围要分开，否则容易出现事务失效的问题。
<!-- applicationContext.xml --> <context:component-scan base-package="com.example.ssm"> <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/> </context:component-scan> <bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource"> <property name="driverClassName" value="com.mysql.cj.jdbc.Driver"/> <property name="url" value="jdbc:mysql://localhost:3306/shop_rent?useSSL=false&serverTimezone=Asia/Shanghai"/> <property name="username" value="root"/> <property name="password" value="123456"/> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> </bean> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.example.ssm.mapper"/> </bean>注意事项方面，MySQL 8.0以上的驱动类名要写com.mysql.cj.jdbc.Driver，并且必须配置serverTimezone，否则会报时区异常；mapperLocations的路径和实际放置Mapper XML的目录必须一致，而且编译后要在classpath下面，我见过很多次Mapper接口存在但XML找不到的情况；Druid连接池的配置写起来简单，但密码不要写明文在生产环境使用，课程设计倒是无所谓，不过这个安全习惯要养成。
4.3 合同状态流转的Service层实现
状态流转是业务核心，写Service的时候最好先把动作定义清楚。比如合同续签操作，本质上要做三件事：把旧合同状态改为“已到期”或“已终止”，创建一条新合同记录（新租期、新租金），如果涉及押金变动还要生成一条押金调整的付款记录。 Action类的逻辑用伪代码表示就是：
public void renewContract(Contract contract) { // 1. 校验旧合同状态必须是“生效中” Contract old = contractMapper.selectById(contract.getId()); if (old == null || old.getStatus() != 1) { throw new BusinessException("当前合同状态不可续签"); } // 2. 校验当前商铺没有其他生效中合同 int activeCount = contractMapper.countActiveByShopId(old.getShopId()); if (activeCount > 0) { throw new BusinessException("该商铺已有生效中的合同"); } // 3. 更新旧合同状态 old.setStatus(2); // 到期 contractMapper.updateStatus(old); // 4. 插入新合同 contract.setStatus(0); contractMapper.insert(contract); // 5. 记录操作日志 logMapper.insert(...); }这段逻辑里最关键的就是第2步校验。为什么？因为“一个商铺同一时间只能有一个生效合同”属于业务规则，不是数据库能自动约束的（除非你用排除索引，但那样会显著增加复杂度），所以必须放在Service层用代码保证。这也是Service层存在的意义——承载业务规则。很多初学者用一个Mapper搞定所有事不是不行，但后续每次改动都要在Controller里翻来翻去，改一个逻辑就要改动页面、Controller、Mapper三处相关代码，非常容易漏改。
4.4 租金计算时段的工具方法
租金计算中有一个让不少人头痛的点：月中起租或退租时，非整月的租金怎么算？比如租户从某月15号开始租，当月租金到底是按整月算还是按天折算？不同项目有不同的规则，我这里提供一个常用的按月折算方式：
public static BigDecimal calcMonthlyRent(BigDecimal monthlyRent, LocalDate start, LocalDate end) { YearMonth ymStart = YearMonth.from(start); YearMonth ymEnd = YearMonth.from(end); // 同一个自然月内，按天占比计算 if (ymStart.equals(ymEnd)) { int days = end.getDayOfMonth() - start.getDayOfMonth() + 1; return monthlyRent .multiply(BigDecimal.valueOf(days)) .divide(BigDecimal.valueOf(ymStart.lengthOfMonth()), 2, RoundingMode.HALF_UP); } // 跨月场景第一个月按比例，中间月份整月计算，最后一个月按比例 // 这里为简化就按首月比例+尾月比例+整月数来计算 BigDecimal firstMonth = monthlyRent .multiply(BigDecimal.valueOf(ymStart.lengthOfMonth() - start.getDayOfMonth() + 1)) .divide(BigDecimal.valueOf(ymStart.lengthOfMonth()), 2, RoundingMode.HALF_UP); BigDecimal lastMonth = monthlyRent .multiply(BigDecimal.valueOf(end.getDayOfMonth())) .divide(BigDecimal.valueOf(ymEnd.lengthOfMonth()), 2, RoundingMode.HALF_UP); BigDecimal fullMonths = monthlyRent.multiply(BigDecimal.valueOf( ChronoUnit.MONTHS.between(ymStart, ymEnd) - 1)); return firstMonth.add(fullMonths).add(lastMonth); }这段代码的价值在于把“非整月如何算租”这种边界情况定义清楚了。真实业务中一定会有这种不规律时间段的计费需求，提前写好工具方法能省掉大量重复劳动。JJ注意分情况讨论，方法里要写清楚注释，否则三个月后你自己回来看可能也想不起来当初为什么这么写。
5. 开发中高频踩坑与排查实录
这部分我单独拿出来写，是因为在实际指导项目过程中，几乎没有哪个项目能一路顺畅写完。下面这些问题都是我和学生们真实遇到过的，频率非常高，如果提前知道，能省下好几个晚上的排查时间。
5.1 日期类型导致的JSON格式化问题
现象是前端页面显示的日期变成了“2025-05-01T00:00:00”这种带T的格式，非常影响阅读。原因是后端返回的日期类型默认序列化格式。解决方案是在项目的Jackson配置中统一指定日期格式，或者在日期字段上使用@JsonFormat注解：
@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8") private LocalDateTime createTime;同时要注意：类字段如果用的是java.util.Date，建议改成java.time.LocalDate/LocalDateTime。MyBatis在3.5.0以上版本对Java 8时间类型的支持已经很好，不需要额外处理，但数据库驱动版本太老也会出现LocalDateTime映射异常，这个坑通常是数据库驱动版本不兼容导致的，升级驱动一般能解决。
5.2 一商铺多合同并发冲突
我参与过的一个模拟项目中，测试人员连续点击“签约”按钮两次，结果同一个商铺生成了两条生效中的合同。原因就是合同状态校验和插入操作不是原子的，两个请求同时通过了“没有生效中合同”的校验，然后各自插入了一条记录。
解决这个问题有两种思路：一是给商铺ID加数据库层唯一约束（比如给shop_id和status生成唯一索引，只允许一个生效中记录），但这样可能需要冗余字段；二是在Service层加同步锁，比如使用synchronized关键字或者基于Redis的分布式锁。对于单体SSM项目，最简单可靠的方案其实是数据库的“悲观锁”或“唯一索引”。我在实际项目里推荐的做法是：数据库加唯一约束兜底，业务层加状态校验，双保险。这个经验在技术上叫“并发控制”，在业务上叫“防止重复签约”，面试时能讲出来会加分。
5.3 MyBatis的模糊查询和动态SQL细节
Mapper文件中写模糊查询时，最常见的错误是直接拼接字符串导致SQL注入风险。正确写法是使用CONCAT函数：
<select id="selectByName" resultType="com.example.ssm.entity.Tenant"> SELECT * FROM t_tenant WHERE name LIKE CONCAT('%', #{keyword}, '%') </select>动态SQL方面， 和 标签的配合可以让我们省去拼接WHERE和AND的烦恼。还有一个细节：如果实体类的属性名和数据库字段名不一致，要么给数据库字段起别名，要么在mybatis-config.xml中开启驼峰映射配置：
<setting name="mapUnderscoreToCamelCase" value="true"/>这个配置能自动把数据库的create_time映射成Java对象的createTime，不需要每个字段都手写resultMap，简洁非常多。
5.4 开发环境跨端口联调与浏览器兼容
我见过很多学生项目里前端页面写的是完整路径，比如http://localhost:8080/login，这样做在开发环境没问题，但部署到服务器后所有路径都要改。更合理的做法是所有请求路径写成相对路径，比如login、/admin/dashboard这类非完整URL，这样前后端不管部署在什么位置都能正确跳转。
关于跨域，如果页面和后端接口不在同一个端口（比如前端用Vue开发服务器端口是8081，后端8080），就需要在后端配置CORS跨域支持。SSM项目里最简单的方案是写一个过滤器类，添加响应头Access-Control-Allow-Origin。不过如果直接用JSP做页面，后端和页面在同一个应用里，通常不需要考虑跨域问题，这个问题更多出现在前后端分离的改造场景。浏览器兼容方面，如果用了一些比较新的ES6语法或者CSS特性，记得检查目标浏览器是否支持，特别是JSP页面在老版本IE环境下的兼容性。
5.5 事务失效问题排查
这个坑在SSM项目里特别隐蔽。表现是Service方法里前一步插入了数据，后一步抛出异常，但前一步的数据并没有回滚，数据库里残留了脏数据。排查思路：先确认Spring事务管理的配置是否正常，看事务管理器是否注入到了数据源；再确认Service方法是否被正确扫描，@Transactional注解是否写在了类或方法上；最后还要确认你在applicationContext.xml中是否扫描到Service层类。如果事务没有生效，多半是扫描配置出了问题，比如Service和Mapper的包扫描范围不对，导致Spring没有创建代理对象。
还有一个很容易忽略的小问题——事务方法是public修饰的吗？如果写成private或者包内调用（同一个类中方法调用事务方法），Spring默认基于JDK动态代理的机制是拦截不到的，事务就会失效，这个知识点虽然基础但经常出现在“为什么我加了@Transactional还是不回滚”的问题里。
6. 项目还能怎么扩展和深化
如果你做的是毕设或者求职项目，这个系统在完成了基础功能之后，还有几个方向可以继续深化，能让项目的技术含量高一个台阶。
6.1 引入Shiro或Spring Security强化权限管理
之前说的权限控制用拦截器实现，其实是一种比较“手工化”的方案。如果想让项目更规范，可以引入Shiro或Spring Security来做认证和授权管理。这样一来，角色权限、URL级别的访问控制、会话管理都可以交给安全框架处理，项目本身对权限策略的描述也清晰很多。虽然学习和配置成本会高一些，但对SSM项目来说是一个很自然的进阶方向。
6.2 集成消息中间件或异步任务
到期提醒如果只靠定时任务扫描数据库，在数据量小的时候没问题，但如果合同数量很大，频繁全表扫描会浪费资源。可以优化策略：把提醒任务拆成两阶段，定时任务只负责查询未来N天内到期的合同，然后发送异步消息；再配合一个独立的短信或邮件接口做通知。如果项目里引入了RabbitMQ或Redis的延迟队列，就更有技术亮点了。当然，对入门项目来说这部分属于加分项，量力而行。
6.3 数据权限和操作日志
真实商铺租赁系统里，一个运营平台不可能只有两个固定角色，通常是大区经理、招商专员、财务专员这些不同角色分别管理不同范围内的商铺。这时候就需要数据权限——比如招商专员只能看到自己名下负责的商铺。实现方式可以在商铺表中增加owner_id字段，在查询时加数据权限过滤。这个功能展示了系统设计者对业务的理解深度，课程设计做到这步已经是优秀水平。
操作日志方面，可以建立一个日志表，记录关键操作的“谁在什么时间对什么数据执行了什么操作”，尤其是合同状态变更、租金收款这类敏感操作。这不仅仅是答辩时说的高大上功能，在实际项目里真的是刚需。
个人实操体会
如果让我给准备做这个题目的同学一个最重要的建议，那就是别急着追求技术栈的新奇，先把商铺租赁的业务链条吃透。SSM这套技术组合虽然听起来不是最新的，但正因为它的每个组件都足够经典，你才能在项目里看到“分层架构、依赖注入、ORM映射、事务管理、定时任务”这些后端开发的核心概念是如何落地的。做的过程中遇到的每一个报错、每一种业务约束和并发冲突，都是在真实工作里会遇到的场景，解决掉它们，胜过背十遍面试题。
如果还有余力，建议把项目从JSP改成前后端分离试试，比如前端用Vue，后端只提供JSON接口。你会发现Controller这部分的工作方式会发生巨大变化，对API设计、跨域、异常处理的体会会更深。这个课题的容错率其实很高，从一开始就踏踏实实把一个模块做完整，比把所有模块都做成半成品强得多。最后祝你顺利做出来，有什么问题欢迎在实际开发中多调试、多验证，动手才是最快的成长路径。
