企业官网建设流程全解析

做毕设这件事，很多同学一上来就纠结"我要做个多新颖多复杂的系统"，结果选题太大兜不住，前两周全耗在环境搭建和改配置上，最后连核心业务都没跑通。今天聊的这套"基于SpringBoot的报刊厅实体书刊订购系统"，是Java Web方向里相当经典的一类选题——业务模型完整、功能边界清晰、用的全是主流技术栈，特别适合拿来完整走一遍"需求分析-表结构设计-接口开发-联调测试"的流程。这套系统解决的是线下报刊厅、书报亭在纸质期刊订阅管理上的老问题：手工记账容易漏、续订提醒全靠脑子记、配送安排靠一张纸传来传去。把它做成系统后，"期刊管理-读者订阅-配送计划-签收确认"这条链路就完全闭环了。不管你是准备拿它当毕业设计，还是单纯想搞懂一个带"订阅+配送"业务模型的SpringBoot项目该怎么落地，这篇文章都值得你花十分钟看完，每个环节我都尽量给出可以直接抄走的实现方案。

1. 项目全景与需求拆解

1.1 这套系统到底在解决什么问题

先别急着写代码，把业务想清楚比什么都重要。报刊厅这种场景其实很有代表性：它的商品是周期性产生的实体期刊，读者不是买一件走人，而是订一段时间——比如订三个月月刊，或者订一年的日报。这就带来三个明显的痛点。

第一个痛点是订阅记录的管理方式太原始。很多报刊厅老板到现在还是用一本纸质笔记本记账，谁订了什么刊、订到几月份、哪天该送哪一期，全都靠人脑和手写记录。一旦杂志种类超过几十种、读者数量上百人，这套手工模式就彻底崩溃了。漏送一期、忘记续订提醒，每一个小失误都会直接变成客诉。

第二个痛点是订阅到期后的续订提醒基本靠运气。读者订了一年的杂志，到期了如果老板不记得提醒，这笔生意就悄悄流失了。系统里如果能把到期时间算清楚，自动标出"即将到期"的订阅单，对经营者来说就是实实在在的挽留收入的手段。

第三个痛点是配送安排没有计划性。每天该给哪些读者送哪几本杂志、谁已经签收、谁一直没收到，这些信息如果不能按日期和线路去安排，配送人员就只能凭经验乱跑。所以这套系统的设计目标很明确：把"读者档案、期刊目录、订阅订单、配送计划、签收确认"这几块串成一条流水线，让经营者打开后台就知道今天该做什么、哪些订阅要到期了、哪些配送还没完成。

1.2 功能模块规划：三类角色与六大模块

系统里我把使用者分成三类：系统管理员负责期刊目录和基础数据维护，报刊厅前台或经营人员负责处理线下订阅和查看统计，配送人员负责查看每日配送任务和处理签收。如果做得再细一点，还可以加一个读者角色让读者自己查看订阅进度，但毕设阶段通常先不开放门户，后台管理端把核心流程做透就够了。

功能模块的划分我建议按下边六块来做，这也是答辩时功能结构图的标准切法：

这六个模块里，真正能体现项目含金量的是订阅管理和配送管理，尤其是配送计划的自动生成。因为期刊是有出版周期的，读者订了半年月刊，系统就应该自动生成6条配送计划，而不是人工一条条去录入。这个"自动生成"的机制，是整个项目业务逻辑的核心，也往往是答辩时老师最感兴趣的地方。

2. 技术栈选型与项目骨架搭建

2.1 为什么这个场景适合SpringBoot

聊技术选型前，我先把这个场景的特点说清楚：这是一个典型的业务管理系统，没有高并发、没有复杂的分布式需求，重点在于快速开发、结构清晰、业务逻辑完整。基于这个前提，SpringBoot几乎是这个场景下的最优解。

SpringBoot最直接的优势是省去了大量SSM时代的配置工作。你还记得传统SSM整合要写多少东西吗？web.xml、spring-mvc.xml、spring-mybatis.xml、数据源配置、事务配置，每一个都要手工去拼，出了问题还不好排查。SpringBoot用起步依赖（Starter）把常用组件的自动配置包好了，一个spring-boot-starter-web就自带内嵌Tomcat和SpringMVC，application.yml里配一下数据源，项目就能跑起来了。对需要一个学期内拿出完整成品的毕设来说，这个效率差距是决定性的。

另外SpringBoot的生态覆盖也非常完善。集成MyBatis Plus时，只需要引一个依赖、配一个分页插件，基础的增删改查和分页查询就全都有了；做定时任务时，一个@Scheduled注解就能实现订阅到期检查和配送任务生成。这些在SSM年代都要靠大量板式代码去实现的内容，在SpringBoot里几乎就是写几个注解的事。

团队协作的友好度也值得一提。现在大多数管理端项目都用"前后端分离"模式开发，SpringBoot天然适合作为纯后端服务对外提供JSON接口，前端用Vue这类框架去对接。就算你是单人做毕设，先写后端接口、再搭配前端页面，这种分工也能让项目结构更接近真实开发环境。

2.2 前端方案对比与核心配置

前端方案上，毕设管理端主要有三条路可以走，我把优劣和适用场景放在一起对比：

我个人的建议是：如果时间紧张、想尽快跑通主流程，Thymeleaf足够了，毕竟页面长得再朴素，业务逻辑才是答辩的重点；如果你预算两周以上的时间给前端，可以选Vue3 + Element Plus，现场演示时页面效果会明显加分。

下面是pom.xml里的核心依赖，我直接给出一份可用的配置：

<dependencies> <!-- Web 启动器，自带内嵌Tomcat和SpringMVC --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- MyBatis Plus，快速实现单表CRUD和分页查询 --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <!-- MySQL驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <!-- Lombok，省略实体类的getter/setter --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <!-- 参数校验 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> </dependencies>

application.yml里的几个关键配置项也顺手列一下，踩过的坑我都标在注释里：

spring: datasource: url: jdbc:mysql://localhost:3306/newspaper_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: global-config: db-config: id-type: auto configuration: # 开发阶段打开SQL日志，联调排错非常有用 log-impl: org.apache.ibatis.logging.stdout.StdOutImpl server: port: 8080

配置里最容易踩的坑是数据库连接的serverTimezone。之前我遇到过一次因为没加北京时间时区参数，所有日期字段都差了8个小时，查了半天才知道是时区问题。字符编码、时区这两项建议一开始就配好，越到后期排查越麻烦。

3. 数据库设计与核心表结构

3.1 实体关系梳理：订阅单怎么把业务串起来

数据库设计是整个项目的地基，地基画歪了，后面写代码的每一天都会难受。我建议先画ER图理清实体关系，再落表结构。这个项目的核心实体有五张表：管理员表、读者表、期刊表、订阅订单表、配送计划表。

这几张表之间的关联关系是：一个读者可以有多条订阅记录，一种期刊也可以对应多条订阅记录，所以读者和期刊是多对多的关系，而订阅订单表就是它们之间的桥梁表；一个订阅单在有效期内会生成多条配送计划，一条配送计划只属于一个订阅单，所以订阅订单和配送计划是一对多的关系。

这种设计有一个明显的好处：把"读者要什么"和"配送员送什么"彻底解耦。订阅订单负责记录业务约定（谁订了什么刊、什么时候开始、什么时候结束），配送计划负责安排执行动作（哪一天送、送了没有、签收人是谁）。两者分开后，就算一本期刊临时改期，也不影响已生成的订阅订单数据，只需要调整配送计划即可。

3.2 核心表结构与字段设计逻辑

直接给出可以直接执行的核心建表语句。第一张是订阅订单表：

CREATE TABLE `subscription` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `reader_id` bigint(20) NOT NULL COMMENT '读者ID', `periodical_id` bigint(20) NOT NULL COMMENT '期刊ID', `start_date` date NOT NULL COMMENT '订阅开始日期', `end_date` date NOT NULL COMMENT '订阅结束日期', `total_price` decimal(10,2) NOT NULL COMMENT '订单总金额', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '状态：0待确认 1生效中 2已结束 3已退订', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`id`), KEY `idx_reader_id` (`reader_id`), KEY `idx_periodical_id` (`periodical_id`), KEY `idx_end_date` (`end_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订阅订单表';

第二张是配送计划表，它是系统业务闭环里的执行层：

CREATE TABLE `delivery_plan` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `subscription_id` bigint(20) NOT NULL COMMENT '订阅单ID', `plan_date` date NOT NULL COMMENT '计划配送日期', `actual_date` datetime DEFAULT NULL COMMENT '实际配送时间', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '状态：0待配送 1已配送 2已签收', `sign_name` varchar(50) DEFAULT NULL COMMENT '签收人姓名', `remark` varchar(255) DEFAULT NULL COMMENT '备注', PRIMARY KEY (`id`), KEY `idx_subscription_id` (`subscription_id`), KEY `idx_plan_date` (`plan_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='配送计划表';

字段设计背后的逻辑其实比表结构本身更重要。我挑几个关键设计点说一下。

status字段用的是tinyint整数，而不是字符串或布尔值。原因很简单：订阅状态不是只有"有效/无效"两个值，它有待确认、生效中、已结束、已退订等中间态，用数字类型占空间小、查询快，配合代码里的状态常量类，可读性也能保证。但要注意，代码里绝对不要直接写魔法数字，建议定义一个SubscriptionStatusConstants类，把0、1、2、3都命名清楚，否则三个月后你自己回来看代码都想不起来数字代表什么。

配送计划的status和订阅订单的status设计逻辑略有不同。订阅状态是业务状态的快照，配送状态则是执行状态的流转：待配送-已配送-已签收。这个状态流转要设计得足够简单，不要让配送人员面对一堆复杂的可选操作，一个按钮"确认签收"就够了。

另外要特别强调数据库的冗余设计。比如配送计划表里存了plan_date这个日期，其实通过订阅单的起始日期和期刊周期也能算出来，为什么还要冗余存一份？因为配送计划一旦生成就是一张"执行工单"，如果每次都靠实时计算去推导，查询效率低不说，一旦订阅单的信息被修改，历史配送记录也会被影响。冗余存储避免了这种耦合，这也是这种业务系统里非常常见的设计取舍。

4. 核心业务模块的实现细节

4.1 订阅下单流程：从选刊到生成配送计划

订阅下单是整个系统最核心的链路，我把它的完整流程拆给你看：后台录入读者信息或者选择已有读者，再选择要订阅的期刊、订阅的起止日期，系统自动计算总金额，创建订阅单，同步生成这个订阅周期内的所有配送计划。

这个流程里最需要严加处理的点有两个：一个是金额计算，另一个是事务一致性。

金额计算看起来很直白——期刊单价乘以订阅月份数。但要注意期刊的定价经常有小数，比如某本杂志定价12.5元，订阅费用在Java里一定用BigDecimal，不能直接用double或者float去乘，否则很容易出现精度问题。订阅周期的计算也要严谨：虽然是按月份算钱，但日期之间的月份差要处理好，比如1月31日到3月1日这种跨界情况，直接用Period计算月数容易出偏差。

事务一致性这块，我直接给出核心Service层的代码示例，这是创建订阅单的关键逻辑：

@Service @RequiredArgsConstructor public class SubscriptionServiceImpl implements SubscriptionService { private final ReaderMapper readerMapper; private final PeriodicalMapper periodicalMapper; private final SubscriptionMapper subscriptionMapper; private final DeliveryPlanMapper deliveryPlanMapper; @Override @Transactional(rollbackFor = Exception.class) public Subscription createSubscription(SubscriptionCreateDTO dto) { // 1. 校验读者和期刊是否存在 Reader reader = readerMapper.selectById(dto.getReaderId()); if (reader == null) { throw new BizException("读者信息不存在"); } Periodical periodical = periodicalMapper.selectById(dto.getPeriodicalId()); if (periodical == null) { throw new BizException("期刊不存在，请检查期刊目录"); } // 2. 计算订阅月数和总金额 YearMonth startMonth = YearMonth.from(dto.getStartDate()); YearMonth endMonth = YearMonth.from(dto.getEndDate()); long months = ChronoUnit.MONTHS.between(startMonth, endMonth) + 1; if (months <= 0) { throw new BizException("订阅结束日期必须晚于开始日期"); } BigDecimal totalPrice = periodical.getPrice() .multiply(BigDecimal.valueOf(months)) .setScale(2, RoundingMode.HALF_UP); // 3. 创建订阅单 Subscription subscription = new Subscription(); subscription.setReaderId(dto.getReaderId()); subscription.setPeriodicalId(dto.getPeriodicalId()); subscription.setStartDate(dto.getStartDate()); subscription.setEndDate(dto.getEndDate()); subscription.setTotalPrice(totalPrice); subscription.setStatus(SubscriptionStatusConstants.PENDING); subscriptionMapper.insert(subscription); // 4. 生成整个周期内的配送计划 generateDeliveryPlan(subscription, periodical); return subscription; } }

注意方法上的@Transactional注解，这是最关键的一行。创建订阅单和生成配送计划是两步操作，如果第一步成功、第二步失败，就会产生一个没有配送计划的孤儿订阅单。加上事务之后，这两步要么都成功，要么一起回滚，保证数据一致性。这个点也是答辩时老师大概率会追问的"你怎么保证数据一致性"的答案。

4.2 配送计划的自动生成与状态流转

配送计划自动生成是这个项目最具技术含量的一块，逻辑上要解决两个问题：按什么频率生成，以及生成到哪一天为止。频率取决于期刊的出版周期，比如月刊就是每个月的某个日期生成一期，周报就是每周的某一天生成一期。期刊表里我建议存一个publishCycle字段，用1、2、3分别代表日报、周报、月刊，再用一个publishDay表示每期的具体出版日，比如月刊的每月10号。

生成配送计划的核心逻辑用一个循环遍历订阅周期内的每个日期，逐期生成计划。我用了LocalDate的迭代方式，代码可读性和健壮性都不错：

private void generateDeliveryPlan(Subscription subscription, Periodical periodical) { LocalDate cursor = subscription.getStartDate(); LocalDate endDate = subscription.getEndDate(); List<DeliveryPlan> plans = new ArrayList<>(); while (!cursor.isAfter(endDate)) { DeliveryPlan plan = new DeliveryPlan(); plan.setSubscriptionId(subscription.getId()); plan.setPlanDate(cursor); plan.setStatus(DeliveryStatusConstants.PENDING); plans.add(plan); // 按周期跳到下一期 cursor = nextPublishDate(cursor, periodical.getPublishCycle(), periodical.getPublishDay()); } deliveryPlanMapper.batchInsert(plans); } private LocalDate nextPublishDate(LocalDate current, Integer cycle, Integer publishDay) { switch (cycle) { case 1: return current.plusDays(1); // 日报 case 2: return current.plusWeeks(1); // 周报 case 3: return current.plusMonths(1); // 月刊 default: throw new BizException("未知的出版周期类型"); } }

生成完配送计划后，还有一个容易被忽略的环节：每日自动维护。报刊厅每天早上应该看到当天有哪些配送任务待执行，这里我用一个定时任务来处理状态变更。例如每天凌晨自动把已经过了endDate的订阅单设为"已结束"，同时可以发一条到期提醒通知：

@Component @RequiredArgsConstructor public class SubscriptionScheduledTask { private final SubscriptionMapper subscriptionMapper; private final DeliveryPlanMapper deliveryPlanMapper; // 每天凌晨5点半执行 @Scheduled(cron = "0 30 5 * * ?") public void expireSubscriptions() { LocalDate today = LocalDate.now(); subscriptionMapper.expireByEndDate(today); } // 每早8点统计当日配送任务（可以扩展为推送给配送员） @Scheduled(cron = "0 0 8 * * ?") public void countTodayDeliveries() { deliveryPlanMapper.todayPlanCount(LocalDate.now()); } }

配送状态流转本身很简单：配送员登录系统，看到"待配送"列表，完成配送后点确认，状态变为"已配送"；读者签收后录入签收人，状态变为"已签收"。这里我不建议做得太复杂，不要把状态机搞成什么订单状态有八个流转出口，现场演示的时候容易把自己绕晕。保持一条直线流转，逻辑清晰、演示顺畅，比什么都重要。

4.3 统计报表：让数据反过来指导采订

报刊厅如果只做记录不做分析，系统价值就少了一大半。统计报表模块我做的是三个方向：期刊销量排行、订阅趋势分析、应收营收汇总，这些都可以通过简单的SQL聚合查询实现。

期刊销量排行直接按期刊分组统计订阅单的期数，就能得出哪些杂志最受欢迎。这个数据还可以反哺到"订货"环节——报刊厅每个月要向出版社采购下一期的实体刊物，采购数量的依据就是当前有效订阅量加上预估的临时购买量，这也是标题里"智能采订"的实际业务含义。代码层面用MyBatis Plus的QueryWrapper或者直接写一个统计SQL都能实现。

订阅趋势分析统计最近12个月的订阅单创建数量，可以把数据按月分组，前端用折线图展示出来。做图表前端的方案很多：如果用的Vue，可以用echarts，数据格式是简单的月份和数量键值对；如果用的Thymeleaf，可以利用后端模板直接渲染出简单的表格，再配合一个HTML5 canvas画简易图表。

营收汇总这块要特别注意金额类型。统计出来的金额是BigDecimal，前端展示的时候要确保没有丢掉小数位。我的做法是后端DTO里统一用String返回金额字段，避免JSON序列化时出现精度丢失问题。

5. 开发过程中的坑与排查实录

5.1 时间格式与状态枚举的"暗坑"

这个项目里时间字段特别多：订阅起始日、结束日、计划配送日、实际配送时间、创建时间、更新时间，而且有的只要日期、有的要精确到秒。开发过程中最容易出问题的地方恰恰就是这些时间。

第一个典型的坑是前端传日期字符串给后端，结果格式对不上报400错误。前端传过来的是"2024-03-15"，后端如果直接用Date类型接收就不太合适。我的解决办法是：所有DTO里的日期字段都用LocalDate接收，配合Jackson的日期格式化配置，在Controller里就校验好格式。这样数据从入口就规规矩矩的，后面存进数据库不会有歧义。

第二个坑是实际配送时间，这个字段要有完整的时分秒信息，因为需要记录"几点送到的"。如果用LocalDate接收，时间信息就全部丢光了。所以日期和时间字段要分清楚：计划日期用LocalDate，实际送达用LocalDateTime，两个不要混用。

第三个坑是时区问题引发的"日期偏移"。出现这种问题最直观的现象就是：数据库里存的是2024-03-15，查出来却变成了2024-03-15 08:00:00，前端格式化后日期还正常，但凡是计算逻辑涉及时间跨度的都会出错。解决方案就是在jdbc连接串上面加serverTimezone=Asia/Shanghai，同时在Spring的Jackson配置里也指定时区，前后端双保险。

状态枚举的"暗坑"更隐蔽。如果代码里到处写if (status == 1)，时间长了根本不知道1代表什么。我强烈建议定义一个状态常量类，把所有状态值命名化：

public class SubscriptionStatusConstants { public static final int PENDING = 0; // 待确认 public static final int ACTIVE = 1; // 生效中 public static final int FINISHED = 2; // 已结束 public static final int CANCELLED = 3; // 已退订 private SubscriptionStatusConstants() { } }

5.2 联调阶段的典型问题与排错思路

前后端联调是这个项目里耗时最多的阶段，哪怕后端接口自测全部通过，一旦和真实页面联起来，各种问题还是层出不穷。

跨域问题是分离开发时避不开的入门坑。前端跑在8081端口，后端跑在8080端口，前端直接请求后端接口，浏览器会因为同源策略拦截。解决方案有两种：一种是后端写一个CORS配置类，允许指定来源跨域访问；另一种是前端配置代理转发，把/api开头的请求转发到8080端口。前者入门简单，后者结构更工程化。

分页查询"没有生效"也是个经典问题。MyBatis Plus虽然提供了Page对象，但如果你只引入了依赖而没有注册分页插件，Page查出来的数据是全量数据，limit根本没有拼接进SQL。我见过不止一个同学在答辩前夜发现"分页怎么不动"，就是因为漏掉了下面的配置：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

演示数据的质量问题也很重要。很多毕设项目跑起来白板一块，期刊目录只有三五条，读者也是随手敲的"张三李四"，现场演示时非常拉胯。建议开发阶段就造一批真实感强的数据：期刊类型覆盖日报、周刊、月刊几种周期，至少12种刊；读者数据有20人以上，订阅记录覆盖生效中、已结束、即将到期不同状态；配送计划覆盖今天待配送、昨天已签收等不同状态。一套好的演示数据，抵得上现场滔滔不绝讲十分钟。

6. 答辩准备与项目优化方向

6.1 答辩高频问题的回答思路

这个项目答辩时，老师的问题基本会集中在需求理解和业务逻辑上，我整理了出现频率比较高的几个问题，每个都给一个可以直接参考的回答思路。

"为什么选这个课题？"——回答重心放在业务价值和场景真实性。可以说选题来源于线下报刊亭普遍存在的订阅管理痛点，系统不只是简单的增删改查，而是覆盖了订阅业务的全生命周期，包括订阅下单、费用计算、配送安排、到期处理。

"项目里的难点是什么？你是怎么解决的？"——这是必考题，回答重点必须落在配送计划自动生成这个功能上。完整的话术建议是：期刊具有周期性出版的特点，每种刊的出版周期不一样，所以系统要根据订阅起止日期动态计算每一期的配送日期，并且要处理日期计算和状态流转问题。我用LocalDate的日期运算和定时任务来实现，同时用事务保证订阅单和配送计划的一致性。

"如果数据量变大了，你怎么优化？"——这个问题考察的是扩展意识。可以从三个层面回答：查询层面已经建立了索引，尤其是按读者和按日期查询的索引；缓存层面可以引入Redis，把期刊目录和热门统计数据放进缓存；架构层面配送任务生成可以采用异步处理，避免下单操作长时间阻塞。

"订单状态有哪些？状态之间怎么流转？"——直接展示状态流转图，订阅状态从待确认到生效中，最后到已结束或者已退订；配送状态从待配送到已配送再到已签收。

6.2 后续可以扩展的优化点

毕设交完不是终点，这套系统的框架和业务模型还能往很多方向扩展，这里给你三个成本不高但效果很不错的优化方向。

第一个方向是采购建议模块。目前系统的统计报表能看得出哪些期刊订阅量大，但还没有形成"建议订货量"的能力。可以基于当前有效订阅数量和近期的历史销量，计算出一个建议采购量，在后台给经营者一个明确的提示：这本刊下期建议订货80本，其中45本是有订阅保障的，剩下35本是预留零售的。这个功能把这个项目从"管理工具"升级成"经营决策工具"，价值感会明显提升。

第二个方向是订阅到期提醒的强化。现在可以做一个待办提醒功能，在后台首页集中展示未来30天内即将到期的订阅单列表，甚至可以给读者的预留手机号发一条提醒短信。这让经营者能提前做续订动作，减少客户流失。

第三个方向是小程序端。如果想让项目看起来更完整，可以做一个面向读者的微信小程序，读者能自己查看订阅进度、在线续订、修改配送地址。后端接口可以直接复用现有的管理端接口，只需要增加一个登录鉴权和面向读者使用的接口分组。

最后分享一点我个人的体会

这套系统真正跑起来之后，我最大的感触是：毕设项目的重点从来不是代码量有多少，而是业务的完整性够不够。报刊厅这个选题看着不起眼，它却非常难得地把"计费管理、周期性任务、订单状态流转、配送执行确认"这些真实业务里最常见也最核心的要素全包含进去了。做完它之后，你再去看任何带订单、带任务、带状态的管理系统，思路都会清楚很多。最后想提醒一句：状态字段和时间字段一定一开始就规划好，别觉得后面可以回头改，改起来牵一发动全身。数据库表结构设计好了，后面的编码真的是一马平川。