最近帮几批学生和同事梳理JavaWeb方向的毕业设计我发现万达商铺租赁管理系统这种题目出现的频率相当高。项目本身不算复杂核心就是SSM框架加一套商铺租赁业务闭环——商铺管理、租户管理、租赁合同、租金账单、缴费记录和统计报表。但同样是做这个题目有人能做出能答辩、能演示、能讲清楚设计逻辑的完整系统有人却卡在框架配置、表结构、Mapper映射这些地方反复返工。差距不在代码量而在是否真正理解了这个业务系统该怎样拆解、怎样设计、怎样落地。这篇文章我不讲虚的直接从我自己做这类系统的经验出发把从需求建模、数据库设计到核心功能实现、论文写作的完整路径捋一遍。适合正准备动手做SSM毕业设计或课程设计的同学也适合想快速接手商铺租赁类管理系统的开发者做参照。1. 为什么SSM在商铺租赁这类管理系统里依然能打1.1 被说过时的SSM为什么还是毕设和中小项目的首选先说个现实情况。现在一提到JavaWeb开发很多人第一反应是Spring Boot好像不用Spring Boot就不够新潮。但你去翻阅大量本科毕业设计和中小型商用后台系统SSMSpring SpringMVC MyBatis依然是出现频率最高的组合之一。原因不复杂Spring负责Bean管理和事务控制SpringMVC负责请求路由MyBatis负责数据持久化三层边界非常清晰无论在教学、论文论述还是实际维护中都容易表达清楚。更关键的是商铺租赁管理系统这类业务的核心是业务规则和数据库设计不是高并发、高可用、分布式。单机加一台数据库服务器支撑一个商场的租赁管理绰绰有余。在这个体量下SSM的灵活性和可控性反而成了优点。你做SSM能手动控制每一个Bean的装配方式能清楚看到SpringMVC的请求流转路径能亲手写Mapper XML里的每条SQL——这些底层细节的学习价值恰恰是Spring Boot自动配置帮不上忙的地方。论文答辩时导师问你这套架构是怎么工作的你能从配置到运行讲得明明白白这就是SSM的实际优势。1.2 一次完整的请求在SSM里是怎么流转的把这个问题讲清楚论文里的系统架构图基本也就画出来了。以查询商铺列表为例完整链路是这样的前端JSP页面发起HTTP请求请求到达DispatcherServlet前端控制器由它根据HandlerMapping找到对应的Controller方法。Controller层接收参数后不直接操作数据库而是调用Service接口Service实现类里通过Transactional声明事务再调用Mapper接口。MyBatis这时会通过动态代理找到对应的Mapper XML文件解析其中的SQL语句执行查询后把ResultSet映射为实体对象逐层返回。最终Controller把数据放到ModelAndViewViewResolver解析JSP视图渲染成页面反馈给浏览器。一个典型的配置大概是这样的!-- spring-mvc.xml 核心配置片段 -- mvc:annotation-driven / context:component-scan base-packagecom.wanda.shop.controller / bean classorg.springframework.web.servlet.view.InternalResourceViewResolver property nameprefix value/WEB-INF/jsp/ / property namesuffix value.jsp / /bean!-- spring-mybatis.xml 数据源与会话工厂配置 -- bean iddataSource classcom.alibaba.druid.pool.DruidDataSource property namedriverClassName valuecom.mysql.cj.jdbc.Driver / property nameurl valuejdbc:mysql://localhost:3306/wanda_lease?useUnicodetrueamp;characterEncodingutf8 / property nameusername valueroot / property namepassword value你的密码 / /bean bean idsqlSessionFactory classorg.mybatis.spring.SqlSessionFactoryBean property namedataSource refdataSource / property namemapperLocations valueclasspath:mapper/*.xml / /bean bean classorg.mybatis.spring.mapper.MapperScannerConfigurer property namebasePackage valuecom.wanda.shop.mapper / /bean这里要注意一个新手常犯的错误mapperLocations的路径写错导致Mapper接口和XML文件找不到对应关系。我建议XML统一放在src/main/resources/mapper目录下并且Mapper XML的namespace必须严格等于Mapper接口全限定名ID必须等于接口方法名。否则启动不报错一调用就报Invalid bound statement排查起来非常头疼。1.3 想换成Spring Boot迁移成本其实不高如果你所在学校要求必须用Spring Boot或者你自己想往更主流的技术栈靠SSM这套代码迁移过去并不难。因为Service层、Mapper层、实体类、JSP页面几乎不用改要改的主要是配置方式和依赖管理。具体来说web.xml没了spring-mvc.xml和spring-mybatis.xml里的配置换成Spring Boot的自动配置、application.yml数据源配置和启动类上的MapperScan注解。Spring Boot的启动类大致是这样SpringBootApplication MapperScan(com.wanda.shop.mapper) public class LeaseApplication { public static void main(String[] args) { SpringApplication.run(LeaseApplication.class, args); } }一个核心建议如果你的题目模板是SSM答辩要求也是围绕SSM展开就不要在技术上临时换框架。稳妥第一。但如果时间充裕把两个版本都做出来在论文里增加一个SSM与Spring Boot的对比分析小节反而是加分项。2. 商铺租赁的业务模型拆解建表之前先想清楚这几个对象2.1 商铺、租户、合同、账单四张核心表搭起整个骨架在做这个系统时最容易犯的错是上来就写代码、建表做到一半才发现字段不够用业务逻辑和表结构对不上。我吃过这个亏后来总结下来万达商铺租赁管理系统最核心的业务对象就四类商铺、租户、租赁合同、租金账单。商铺是最基础的资源对象字段包括商铺编号、所在楼层、铺位位置、建筑面积、租金单价、物业费单价、商铺状态租户是承租方字段包括租户名称、法定代表人、联系电话、信用等级、入驻时间租赁合同是商铺和租户之间的核心关联对象记录合同编号、关联商铺、关联租户、起租日期、到期日期、租金递增比例、押金金额、合同状态租金账单则把合同约定的费用按月或按周期拆出来字段包括账单编号、所属合同、费用类型、计费周期、应收金额、已收金额、账单状态。在此基础上可以增加缴费记录表、操作日志表、角色权限表作为扩展。这四张表的关系一句话可以概括一个商铺在不同时间段可以对应多份合同一份合同关联一个商铺和一个租户一份合同按周期拆出多个月度账单。用ER图表达时商铺和合同是一对多租户和合同是一对多合同和账单是一对多。2.2 表结构设计的几个关键字段约定直接给出一份我建议的建表核心片段你可以在自己的项目里直接改造复用CREATE TABLE shop ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键, shop_no varchar(32) NOT NULL COMMENT 商铺编号, floor varchar(20) DEFAULT NULL COMMENT 所在楼层, position varchar(50) DEFAULT NULL COMMENT 铺位位置描述, area decimal(10,2) DEFAULT NULL COMMENT 建筑面积(平方米), rent_price decimal(10,2) NOT NULL COMMENT 租金单价(元/月/平方米), property_fee decimal(10,2) DEFAULT NULL COMMENT 物业费单价, status tinyint(4) DEFAULT 0 COMMENT 状态0空置 1已租 2停用 3装修中, current_tenant_id bigint(20) DEFAULT NULL COMMENT 当前租户ID(冗余), del_flag tinyint(4) DEFAULT 0 COMMENT 逻辑删除0未删 1已删, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_shop_no (shop_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商铺信息表;CREATE TABLE lease_contract ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键, contract_no varchar(32) NOT NULL COMMENT 合同编号, shop_id bigint(20) NOT NULL COMMENT 商铺ID, tenant_id bigint(20) NOT NULL COMMENT 租户ID, start_date date NOT NULL COMMENT 起租日期, end_date date NOT NULL COMMENT 到期日期, rent_price decimal(10,2) NOT NULL COMMENT 合同月租金单价, property_fee decimal(10,2) DEFAULT NULL COMMENT 物业费单价, increase_ratio decimal(5,4) DEFAULT 0.0000 COMMENT 年递增比例, deposit decimal(18,2) DEFAULT NULL COMMENT 押金, pay_method tinyint(4) DEFAULT 1 COMMENT 付款方式1月付 2季付 3半年付 4年付, status tinyint(4) DEFAULT 0 COMMENT 合同状态0执行中 1已到期 2已续租 3已退租, del_flag tinyint(4) DEFAULT 0, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_contract_no (contract_no), KEY idx_shop_status (shop_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT租赁合同表;几个值得注意的约定金额字段一律用decimal(18,2)绝对不要用float或double。浮点数在二进制下存在无法精确表示的精度误差算租金、算押金时会出现0.10.2不等于0.3这种尴尬问题这在财务相关系统里是不可接受的。状态字段用tinyint加注释不用字符串。数字状态码方便写switch也方便扩展比如商铺状态从0到3之间调整不影响已有代码。所有表加del_flag逻辑删除标记物理删除是最后手段后面我会专门讲为什么。create_time和update_time统一用数据库时间戳默认值减少Java代码里手写时间赋值。合同表里冗余了shop_id和tenant_id但不冗余商铺名和租户名。列表展示时如果需要显示名称可以用JOIN查或者单独存一个快照字段。我倾向用JOIN保持数据一致性的责任在数据库。2.3 商铺状态和合同状态必须联动不能各管各的很多初学者把商铺表和合同表当两个孤立的字典来设计这是个大坑。实际业务里商铺的状态是由合同的状态驱动的。一个商铺如果存在一份执行中状态的合同那它在商铺表里的状态就应该是已租合同一旦到期变为已到期商铺就应该回到空置或进入待续租状态。比较好的设计是在Service层维护这个联动关系而不是靠人工在后台页面里改。例如签约成功时同时更新商铺表的status1、current_tenant_id新租户ID退租时更新合同状态为已退租同时把商铺状态改回0、清空当前租户ID。这里一定要放在同一个事务里保证数据一致性。在后面讲事务边界时我会再展开。到期预警也是这类系统的一个常见需求。实现思路很简单查询合同表中end_date在30天内且状态为执行中的记录在首页或合同列表标注即将到期提前提醒运营人员联系续租。这块逻辑写在Service层写一个定时任务每天扫描一次即可。如果学校要求用定时任务框架可以引入quartz或Spring自带的Scheduled都是一两页代码的事。3. 核心模块实现路线从合同录入到租金报表的完整闭环3.1 合同录入与商铺占用冲突校验并发场景下不能只靠页面判断合同管理是整个系统最核心的模块。录入一份新合同时至少要处理这几个问题合同编号自动生成避免重复、商铺必须存在且状态为空置、起租日期不能晚于到期日期、同一商铺在同一时间段不能存在重叠的合同。前几个都容易做难的是同一商铺同一时间段不能重叠。很多人的写法是这样的先在页面查询商铺状态如果是空置就允许录入录完再把商铺状态改成已租。这个方案在单用户操作时没问题但一旦两个运营人员同时操作同一个商铺就可能出现两个人都查到空置然后两条合同都插入成功的情况。更稳的做法是双重保障。第一层是在数据库层面加唯一约束或代办逻辑用lease_contract表加一个uk_shop_time唯一索引把shop_id和合同时间段通过起止日期列做约束。MySQL的普通唯一索引没法直接约束区间重叠所以实际中更常用的是在insert之前用一条带条件的SQL做原子校验SELECT COUNT(*) FROM lease_contract WHERE shop_id #{shopId} AND status IN (0, 2) AND del_flag 0 AND #{newStartDate} end_date AND #{newEndDate} start_date如果count大于0说明存在时间重叠的合同直接抛出业务异常拒绝插入。这条SQL利用了B树索引和行锁机制在并发下相对安全。第二层是在Service方法上加Transactional并把insertContract和updateShopStatus放进同一个事务保证合同创建和商铺占用标记要么都成功要么都失败。合同编号生成我建议用当前时间戳随机数或业务前缀yyyyMMdd自增序号比如HT20250614001。注意在插入前先查重因为数据库只能保证唯一索引不重复不能帮你生成有序编号。3.2 租金账单自动生成业务规则写在Java里而不是SQL里租金账单是这类系统里最有技术含量也最容易出错的部分。账单不是人工一条条录的而是根据合同自动生成的。这里就面临一个选择生成规则写在SQL里还是写在Java里我的建议是写在Java里并且写成可测试的独立工具类或Service方法。原因有三个。第一租金规则包含各种条件分支固定月租、按季度递增、首月免租、15号前起租按整月计算、15号后起租按半月计算、物业费和租金分开计费等。把这些分支逻辑堆在SQL的CASE WHEN里SQL会变得极难阅读测试和排查都痛苦。第二Java代码可以写单元测试用几组合同数据验证计算结果这是SQL做不到的。第三答辩时导师问你租金怎么算的你直接打开代码讲分支逻辑比讲一大段SQL直观得多。下面是一个简化的租金计算逻辑public BigDecimal calcMonthRent(LeaseContract contract, LocalDate monthDate) { // 基础月租金 面积 * 单价 BigDecimal baseRent contract.getArea().multiply(contract.getRentPrice()); // 年递增从合同生效年度算起每满一年上浮 increaseRatio int years (int) ChronoUnit.YEARS.between(contract.getStartDate(), monthDate); if (years 0) { BigDecimal ratio BigDecimal.ONE.add(contract.getIncreaseRatio().multiply(BigDecimal.valueOf(years))); baseRent baseRent.multiply(ratio).setScale(2, RoundingMode.HALF_UP); } // 首月按实际租赁天数折算如果起租日不是1号 if (monthDate.equals(YearMonth.from(contract.getStartDate()).atDay(1))) { int totalDays YearMonth.from(contract.getStartDate()).lengthOfMonth(); int daysFromStart contract.getStartDate().lengthOfMonth() - contract.getStartDate().getDayOfMonth() 1; baseRent baseRent.multiply(BigDecimal.valueOf(daysFromStart)) .divide(BigDecimal.valueOf(totalDays), 2, RoundingMode.HALF_UP); } return baseRent; }这只是简化版本实际项目里还会涉及季付、半年付、年付的折扣比例以及周期起始日对齐的问题。建议把账单生成做成一个批量方法输入合同ID生成该合同从起租日期到到期日期之间的全部账单。生成逻辑里要注意跨年和跨月的边界尤其2月天数变化。Spring自带的Scheduled可以每月1号定时扫描所有执行中的合同自动创建当月账单这个机制非常实用。3.3 权限设计RBAC模型加拦截器Controller层不能裸奔商铺租赁管理系统至少要有三类角色系统管理员、财务人员、运营人员。管理员管商铺和合同财务管账单和缴费运营管租户和合同到期提醒。这里最适合用经典的RBAC权限模型用户表、角色表、用户角色关联表加一个菜单权限或功能权限表。技术实现上登录成功后把用户ID和角色ID放进Session然后写一个HandlerInterceptor拦截器在preHandle里做两件事一是检查用户是否已登录Session里是否存在用户对象二是检查当前请求的URL对应的功能是否需要权限。配合SpringMVC配置把拦截器注册进去mvc:interceptors mvc:interceptor mvc:mapping path/**/ mvc:exclude-mapping path/login/ mvc:exclude-mapping path/css/**/ mvc:exclude-mapping path/js/**/ mvc:exclude-mapping path/images/**/ bean classcom.wanda.shop.interceptor.LoginInterceptor/ /mvc:interceptor /mvc:interceptors拦截器代码里最基础也是最重要的逻辑是静态资源一定要排除否则登录页面都会因为加载CSS失败而显示不正常。这个问题我在第一次做项目时被坑了整整半天后来养成习惯每次配拦截器第一件事就是加静态资源排除。再进一步可以做数据范围权限。比如财务人员只能看自己负责楼层的账单运营经理可以看全广场的数据。这时用AOP自定义注解配合ThreadLocal拿到当前登录用户ID在SQL查询条件里动态拼接楼层或区域过滤条件。这一块是加分项写进论文能明显提升技术深度。3.4 可视化报表MySQL聚合查询加上前端图表组件报表模块是这类管理系统里最能体现系统价值的部分。管理层关心的核心指标就几个月度租金收入、商铺空置率、到期合同数、欠费租户列表。租金收入按月汇总的SQL大概是这样的SELECT DATE_FORMAT(pay_time, %Y-%m) AS month, SUM(pay_amount) AS total_income FROM payment_record WHERE del_flag 0 AND pay_time BETWEEN #{startDate} AND #{endDate} GROUP BY DATE_FORMAT(pay_time, %Y-%m) ORDER BY month空置率计算需要结合商铺总数和当前空置数SELECT (SELECT COUNT(*) FROM shop WHERE status 0 AND del_flag 0) AS empty_shop_count, (SELECT COUNT(*) FROM shop WHERE del_flag 0) AS total_shop_count前端我用的是ECharts因为它的KPI大屏效果不错而且对JSP页面友好直接在页面上引入echarts.min.js初始化一个div容器把Controller通过AJAX或ModelAndView传过来的JSON数据塞进option里就行。这里有个实操技巧Controller返回数据建议统一封装成Result对象包含code、message、data三个字段前端判断code是否为200再渲染图表这样接口返回统一调试也方便。4. 真实开发中踩过的坑以及答辩导师最爱追问的几个点4.1 金额计算必须用BigDecimaldouble是财务系统的天敌前面建表时已经强调过金额字段用decimal这里再补充Java侧的规范。Java里做租金、押金、物业费的计算一律BigDecimal禁止用double和float。很多同学会在租金计算里写double total rent * area * 12看似没问题一旦涉及除法和乘法混合运算精度误差累积到分位就会暴露。正确姿势BigDecimal totalRent BigDecimal.valueOf(180.5) .multiply(BigDecimal.valueOf(62.3)) .multiply(BigDecimal.valueOf(12)) .setScale(2, RoundingMode.HALF_UP);顺带说一句BigDecimal的构造方法要用valueOf或者new BigDecimal(180.5)不要直接new BigDecimal(180.5)因为后者传入的double本身已经有精度损失结果依然不精确。这点无论是开发还是答辩都是一个很值得讲的细节。4.2 SimpleDateFormat线程安全问题与日期计算在SSM项目里SimpleDateFormat被很多人当成静态工具来用这其实有线程安全隐患。SimpleDateFormat内部维护了Calendar对象多线程共享时会相互覆盖状态导致解析出错。正确做法是用DateTimeFormatterJava 8开始推荐或者每次使用时new SimpleDateFormat()。如果项目JDK版本是8以上直接用java.time包下的LocalDate和DateTimeFormatter是最好的选择。日期计算的核心场景包括合同起止日期的天数差、每月账单周期计算、到期日提前N天提醒、跨月跨年的租金折算。LocalDate startDate contract.getStartDate(); LocalDate endDate contract.getEndDate(); long days ChronoUnit.DAYS.between(startDate, endDate);这里提醒一个小细节between的结果不包括结束日期当天如果计算租赁多少天要1。不同数据库和不同代码库的日期边界规则容易不一致建议在项目里统一封装一个日期工具类所有边界计算都走这一个类避免各处算出的结果不一样。4.3 逻辑删除和唯一索引的冲突怎么解决我给表都加了del_flag做逻辑删除但这里有一个隐藏坑如果某张表有唯一索引比如shop_no逻辑删除后这条记录还在表里再次插入一个相同编号的商铺时会直接违反唯一索引约束。实际业务中商铺编号一般不会改写但合同编号、租户编号就有可能出现删除后重新录入的场景。解决办法有几个思路一是唯一索引改为(shop_no, del_flag)这种复合唯一索引删除时del_flag置为1新插入时del_flag为0组合起来不冲突二是删除时把原编号改成带后缀的历史编号比如HT20240001_DEL_20250614三是干脆用物理删除操作日志表记录变更痕迹。三种方案各有适用场景我比较推荐第一种简单直接不需要额外维护历史编号字段。4.4 事务边界签约、改商铺状态、生成首期账单必须绑在一起在3.1里我提过签约时要联动更新商铺状态这里把事务边界完整展开。一次签约动作涉及三个写操作插入合同记录、更新商铺表状态为已租并设置当前租户ID、生成第一期租金账单。这三个操作任何一个失败其他两个都必须回滚。用Transactional标注Service方法时要注意几个细节。第一Transactional只能作用于public方法且通过Spring代理调用才生效同类内部方法之间互相调用事务会失效。第二事务默认只在抛出RuntimeException时回滚如果代码里手动try-catch捕获了异常但没有重新抛出事务不会回滚。这是很多项目里数据怎么没回滚的经典原因。第三事务要放在Service层不要放在Controller层因为一个Controller方法可能调用多个Service方法如果把事务放在Controller上边界太粗不利于精细控制。4.5 答辩时导师最爱追问的几个问题根据我带过的答辩经验万达商铺租赁管理系统这类题目导师的追问集中在这些点上两个运营人员同时签同一个商铺怎么防止重复合同——答数据库唯一索引、原子校验SQL、事务回滚的三层保障。租金递增是怎么实现的第一年、第二年、第三年租金分别多少——把计算工具类的代码打开现场演算一组数据。商铺到期前怎么提醒——答定时扫描合同表、计算到期剩余天数、标记预警状态。日志和删除怎么做的——答逻辑删除字段加操作日志表删除不真删保留审计线索。数据库为什么用MySQL为什么字段用decimal——答业务体量、精度要求、文档生态。这些问题的答案其实都藏在项目细节里你只要按照前面说的方式把业务逻辑真正实现了一遍而不是照抄代跑通答辩时就不会心虚。5. 把代码变成论文图表规范和测试部分的写法5.1 论文结构怎么排才算像一篇管理系统论文管理系统类论文的结构在高校里已经形成了相对固定的范式符合范式反而容易过盲审。我建议的章节排布是绪论背景、国内外现状、研究内容、需求分析可行性分析、功能需求、非功能需求、用例图、系统设计总体架构、功能模块划分、数据库设计、类设计、系统实现每个核心模块的实现思路、核心代码片段、界面截图、系统测试测试环境、测试用例表、测试结果分析、总结与展望。这里重点说下需求和实现的对应关系。很多学生论文里需求分析和系统实现各说各话需求分析里写了支持租金自动计算实现部分却只有一张列表页面截图。正确做法是需求分析的每个功能点在系统设计里都要有对应的模块在系统实现里都要有对应的代码和截图在测试里都要有对应的用例。这个对应关系是论文质量的重要评判维度。5.2 架构图、ER图、时序图画图比写代码更考功夫论文里的图主要有三类画法各有讲究架构图强调分层。SSM项目的架构图通常分四层表现层JSP、Controller、业务层Service接口与实现、持久层Mapper接口、Mapper XML、数据层MySQL。层与层之间用箭头标注调用方向和依赖关系。画图时注意箭头方向从Controller指向Service再从Service指向Mapper不要画反。ER图强调实体关系。把商铺、租户、合同、账单四张核心表画出来标注主键外键和一对多关系。这里可以结合的技巧是ER图里只画实体、属性和关系表结构细节留给数据库设计章节的文字描述。时序图强调核心流程。建议画两到三张关键的时序图比如签约流程时序图租金账单生成时序图。时序图能直观展示方法调用顺序大片文字说不清的内容一张图就能搞定。画图工具方面PowerDesigner、Visio、draw.io、ProcessOn都可以。我个人的建议是draw.io免费且导出的矢量图清晰度高插入Word时不会失真。5.3 测试部分怎么写才有说服力很多学生的测试部分只有一张表格写登录功能测试通过就完了。这是远远不够的。一份有说服力的测试报告至少要包含功能测试用例表每个模块至少3到5条用例要覆盖正常路径和异常路径。拿合同录入举例正常用例是录入一份有效合同提示成功并生成首期账单异常用例是起租日期晚于到期日期系统拦截报错同一商铺时间重叠系统提示该商铺已被占用。通过和失败的结果都要记录。边界值测试租金递增满一年、跨年账单、2月29日这种日期边界都是可以写进测试用例的点。兼容性和安全性测试简要说明不同浏览器页面是否正常、密码是否加密存储、Session超时是否跳转登录页。这些表格写出来论文的测试章节会充实很多。5.4 写作时的几个注意事项写论文时最需要避免的是大段贴代码。代码是论文的补充材料不是正文。正确做法是贴关键代码片段加解释解释要围绕为什么这样设计而不是逐行翻译代码。比如贴租金计算工具类代码时重点写清楚为什么用BigDecimal、为什么年份差用ChronoUnit.YEARS、递增基数为什么是合同生效日而不是自然年。另外一个容易踩的坑是术语混用。比如Spring和SpringMVC、MyBatis和MyBatis-Plus这些概念必须区分清楚。你用的是SSM三件套还是加入了MyBatis-Plus扩展论文里要明确说明。很多学生项目里其实已经用了MyBatis-Plus的BaseMapper但论文里还只写MyBatis这就是明显的技术术语不严谨。数据方面也要严谨。系统里的测试数据建议多造一些有业务意义的商铺名和租户名楼层分布合理、租金有梯度。答辩演示时随便几条测试1测试2数据会让系统显得很假而一套看起来像真实商场的模拟数据会明显提升演示效果。写在最后做这类系统最值得投入的地方我自己做这类项目的体会是商铺租赁管理系统的技术难点并不在于某个框架的高阶用法而在于你能不能把业务规则真正想清楚、做闭环。合同、账单、商铺状态、租户信息之间是彼此咬合的一处状态不同步后面查问题就是连锁的。所以花在建表设计、状态联动、事务边界上的时间永远是这个项目性价比最高的投入。如果在做好基础功能后还有余力建议往两个方向扩展一是引入工作流概念把合同的审批、退租流程做得更像真实业务二是做一个基于ECharts的运营驾驶舱把租金收入和空置率做成可视化大屏。这两个方向都不难但对论文深度的提升非常明显。希望这篇经验梳理对正在做这个题目的同学有帮助。做系统是这样认认真真把每一个业务闭环跑通答辩时自然有话讲论文自然有内容写。