在接到基于微信小程序实现传染病防控宣传管理系统这个标题的时候我第一反应是这不就是典型的小程序后台管理双向需求项目吗但真把这个项目从零到一完整做下来你会发现它比想象中要复杂得多——尤其是涉及公共卫生宣传这种特殊业务场景时C端用户的使用习惯、B端管理员的运营诉求、还有内容审核的安全边界每一项都在逼着你重新审视系统设计。这个项目我当时是带着两个同学一起做的前后花了大概六周时间从需求分析到论文输出完整走了一遍。今天就把整个项目的思考过程、技术选型、核心代码思路以及踩过的坑一次性拆开讲清楚。不管你是准备拿它做毕业设计还是想在公司内部落地一个类似的宣传管理平台这篇文章应该都能让你少走不少弯路。1. 内容整体设计与思路拆解1.1 核心需求解析这个系统到底要解决什么问题先别急着写代码我们得先搞清楚一个本质问题为什么需要一个传染病防控宣传管理系统传统的防控宣传是什么样子的社区贴公告、村里发传单、单位组织看视频。这些方式有几个通病——覆盖面有限、无法追踪触达效果、内容更新滞后、缺乏互动反馈。举个例子某社区想通知居民流感疫苗开始预约了传统方式可能是楼道贴一张通知看到的人有多少没人知道。但通过小程序推送后台能清清楚楚看到这条消息触达了1342人其中有896人点开阅读有312人直接跳转到了预约页面。这个数据闭环是传统宣传方式完全做不到的。所以这个系统的核心价值不是做一个能看文章的小程序而是搭建一个宣传内容可管理、触达效果可追踪、用户反馈可收集的完整闭环。这也是为什么我们在设计时把管理后台看得比小程序前端更重——没有管理后台的有效支撑前端做得再花哨也是空中楼阁。1.2 角色与功能矩阵谁是使用者他们需要什么我把整个系统的用户分成三类角色每一类的诉求和操作路径都不一样普通居民用户这是C端核心他们需要的是快速获取权威信息。典型路径是打开小程序 - 浏览最新公告 - 查看防控知识 - 参与问卷答题。他们最在意的是内容是否通俗易懂、操作是否够快、信息是否官方可信。社区/单位管理员这是B端运营者他们负责内容发布、活动创建、数据查看。典型路径是登录后台 - 编辑公告 - 定向推送 - 查看触达数据。他们最需要的是批量操作工具和直观的数据看板。系统超级管理员这是平台维护者负责账号分配、全局配置、内容审核。他们需要的不仅是功能完整更重要的是操作留痕——谁在什么时候发了什么内容都必须有日志记录。基于这三个角色功能模块的划分就非常清晰了用户端围绕浏览互动做设计管理端围绕内容数据做设计超级管理员端围绕权限审计做设计。1.3 为什么选小程序而不是App或H5这个选择题其实不难做。我接触过不少类似的宣传系统有人非要用App理由是功能强大。但咱们冷静想想一个面向社区居民的健康宣传工具用户凭什么专门下载一个App安装成本太高了很多人看到下载安装这个动作就直接放弃了。小程序的三大优势在这个场景下体现得淋漓尽致即用即走扫码或搜索就能打开不用安装用完关掉下次再来。这对中老年用户尤其友好他们最怕复杂操作。轻量化触达结合微信的订阅消息能力可以做到精准推送通知触达率远超App推送。传播便利一个卡片甩到微信群、朋友圈点开就能看裂变传播几乎零成本。H5当然也可以做但说实话在微信生态里原生小程序的体验流畅度和接口丰富度比如订阅消息、微信登录、开放标签是H5没法比的。所以我们最终敲定原生小程序Java后端这个组合。1.4 项目整体架构与模块划分整个系统分为两大部分用户端微信小程序 管理端Web系统。后端共用一套服务通过不同接口路径区分端侧。用户端小程序包含四个核心模块首页信息流展示最新通知公告、防控动态支持分类筛选知识库防控常识、疾病百科、科普视频按病种分类管理互动中心问卷调查、健康打卡、谣言粉碎机、在线咨询个人中心我的浏览记录、我的答题记录、我的订阅设置管理端Web系统包含五个核心模块内容管理公告发布与编辑、文章管理、视频管理、分类管理用户管理用户列表、用户画像、分组标签管理互动管理问卷管理、答题记录查看、打卡统计数据统计访问量趋势、内容阅读量排行、用户活跃度系统设置管理员账号管理、角色权限配置、操作日志审计2. 技术选型与核心原理分析2.1 前端技术栈小程序端的选型思路小程序端用的是原生微信小程序框架没有引入第三方框架。说实话现在有不少人推荐用uni-app这类跨端框架考虑到这篇项目的实际场景——只需要在微信生态内运行不考虑App和H5多渠道发布原生框架反而更合适。原生框架的优势在于性能最优没有中间转换层的性能损耗微信新特性如订阅消息、云调用支持最快调试方便微信开发者工具原生支持有个需要注意的点小程序的目录结构一定要按照功能模块拆分好否则后期代码维护会非常痛苦。我当时用的结构是├── pages/ // 页面文件 │ ├── index/ // 首页 │ ├── knowledge/ // 知识库 │ ├── interact/ // 互动中心 │ └── mine/ // 个人中心 ├── components/ // 公共组件 │ ├── article-card/ // 文章卡片 │ └── notice-bar/ // 通知栏 ├── utils/ // 工具函数 ├── api/ // 接口请求封装 └── app.js // 全局逻辑强调这个结构看起来简单但很多初学者容易忽略一个问题小程序每个页面的独立性很强如果不提前做好公共组件的抽离到后期会出现大量重复代码。比如文章卡片这个组件首页、知识库、搜索结果页都要用到如果每个页面都复制一遍同样的布局代码改一次样式就是一场灾难。2.2 后端技术栈为什么选择Java Spring Boot后端技术选型时我们在Spring Boot和Node.js之间纠结了一阵子。最终选了Spring Boot主要考虑到团队更熟悉Java生态而且这个系统的定位是正规的管理平台Java在事务处理、权限框架Spring Security、稳定性和社区生态方面更有优势。主框架搭配如下组件技术选型用途说明核心框架Spring Boot 2.x应用主框架安全框架Spring Security JWT认证授权ORM框架MyBatis-Plus数据库操作数据库MySQL 8.x数据持久化缓存Redis 2.x会话管理/热点数据接口文档Knife4jSwagger增强API文档与管理这里多说一句MyBatis-Plus的选择理由对比Spring Data JPA它的侵入性更低SQL可以细粒度控制这对于数据统计类的复杂查询场景非常重要。再加上它的代码生成器可以一键生成entity、mapper、service、controller四层骨架代码开发效率能提升不少。2.3 部署架构与接口通讯设计系统部署采用经典的前后端分离架构。后端打jar包部署在服务器上前端小程序通过HTTPS请求访问后端接口管理端Web页面可以单独部署成静态资源或集成在后端项目中。接口通讯上我们做了几点设计考虑第一统一返回结构。所有接口返回格式为{ code, message, data }三层结构code为0表示成功非0表示失败。这样前端不用纠结各种花里胡哨的返回格式。第二接口版本控制。在请求路径中加入版本号比如/api/v1/notice/list万一以后接口升级可以平滑兼容旧版本。第三敏感接口权限校验。所有涉及用户数据或管理操作的接口都要通过JWT令牌校验权限未登录用户只能访问公开的信息接口。下面是一个典型的接口返回示例{ code: 0, message: success, data: { id: 1001, title: 秋冬季流感防控温馨提示, coverImage: https://xxx.com/cover.jpg, createTime: 2025-11-01 10:00:00 } }3. 核心数据模型设计与数据库实现3.1 数据库表结构划分数据库设计是整个项目的根基表结构设计不好后期改起来要命。我按业务模块划分核心数据表大概有十余张。这里挑几张最有代表性的展开说明。用户信息表t_user这是最基础的表存储微信授权用户信息。设计时要注意不要硬编码微信号字段因为小程序拿到的用户信息是加密的需要由微信接口以code换取的openid来标识唯一用户。所以我们的表结构包含openid、昵称、头像、手机号、所在区域、年龄分组等字段其中openid设置唯一索引。公告信息表t_notice这是内容类表的核心。字段包括标题、正文内容、封面图、类型通知/公告/动态、发布状态、置顶标识、浏览量、发布时间等。设计时有个小诀窍一定要加status字段并预留状态位比如0草稿、1待审核、2已发布、3已下线这样内容发布流程才能做到有状态流转。知识文章表t_article存储防控知识库的文章内容字段与公告表类似但增加了disease_type字段按病种分类流感、艾滋病、结核病、病毒性肝炎等。同时要有source字段标识内容来源确保发布内容有据可查。问卷表设计问卷模块需要三张表配合问卷主表t_survey、问题表t_survey_question、答题记录表t_survey_record。问卷主表存标题、描述、状态问题表存题干、题型单选/多选、选项答题记录表存用户答案和得分。这里多对多的关系查询会比较多MyBatis-Plus的Wrapper查询就派上用场了。3.2 数据库设计的几个关键要点第一个要点是时间字段统一用datetime类型不要用timestamp避免2038年问题。别笑这种系统是要长期运营的该考虑的还是得考虑。第二个要点是所有的内容表都要加create_time和update_time两个字段MyBatis-Plus可以配合自动填充功能插入和更新时自动写入省事还不会漏。第三个要点是索引策略。经验法则所有查询字段都建议加索引但不要滥用。比如openid字段主查询、status字段作为状态筛选、create_time字段做时间排序这三个是重点索引。至于正文内容这种大文本字段索引没意义全文搜索这种需求直接用模糊查询就行。3.3 核心表建表SQL示例分享一张公告表的建表SQL作为参考模板CREATE TABLE t_notice ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键ID, title varchar(200) NOT NULL COMMENT 公告标题, content text COMMENT 公告内容, cover_image varchar(500) DEFAULT NULL COMMENT 封面图片地址, notice_type tinyint(4) DEFAULT 1 COMMENT 类型1通知 2公告 3动态, status tinyint(4) DEFAULT 0 COMMENT 状态0草稿 1待审核 2已发布 3已下线, is_top tinyint(1) DEFAULT 0 COMMENT 是否置顶0否 1是, view_count int(11) DEFAULT 0 COMMENT 浏览量, publisher_id bigint(20) DEFAULT NULL COMMENT 发布人ID, publish_time datetime DEFAULT NULL COMMENT 发布时间, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), KEY idx_status (status), KEY idx_create_time (create_time), KEY idx_type_status (notice_type, status) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT公告信息表;有几个细节值得注意一是字符集用utf8mb4而不是utf8因为utf8在MySQL里其实不是真正的四字节UTF-8遇到生僻字或特殊符号会报错二是联合索引idx_type_status因为列表页最常见的查询是查询某个类型下已发布的公告这个联合索引能完美命中三是view_count字段故意设计成冗余存储而不是实时统计避免大数据量下count查询拖慢列表接口。4. 核心功能模块实现与操作流程4.1 用户端小程序核心功能实现首页信息流设计首页是整个小程序的门面用户打开第一眼看到什么决定了会不会留下来。我们采用的是经典的信息流布局顶部Banner轮播 公告通知栏 分类Tab 文章卡片列表。Banner轮播放的是当前最重要的活动或紧急通知比如某某疫苗开打啦或者秋冬季传染病防控专项行动启动。Banner图由管理端后台上传。公告通知栏用跑马灯效果展示最新三条公告这一块不需要用户点击进去就能看到关键信息。文章卡片列表用垂直滚动卡片包含封面图、标题、摘要、发布时间、浏览量。这里有个交互细节用户下拉刷新时调用分页接口第一页上拉触底时加载下一页。分页参数用page和pageSize后端用MyBatis-Plus的Page对象实现物理分页千万不能用内存分页——数据量一大内存分页直接崩。知识库模块实现知识库要达到的效果是即使是老人也能找到自己想要的内容。所以分类一定要直观按疾病类型分为流感、肝炎、结核病、性病/艾滋病、其他传染病等大类大类下面再细分标签。列表接口的设计要点是支持多条件筛选按病种查、按关键词查、按最新/最热排序。这里我在后端封装了一个条件构造器核心代码逻辑如下public PageResultArticleVO searchArticles(ArticleQuery query) { LambdaQueryWrapperArticle wrapper new LambdaQueryWrapper(); // 关键词搜索 if (StringUtils.hasText(query.getKeyword())) { wrapper.like(Article::getTitle, query.getKeyword()) .or().like(Article::getContent, query.getKeyword()); } // 病种筛选 if (query.getDiseaseType() ! null) { wrapper.eq(Article::getDiseaseType, query.getDiseaseType()); } // 状态过滤 wrapper.eq(Article::getStatus, 2); // 只查已发布 // 排序 if (hot.equals(query.getSort())) { wrapper.orderByDesc(Article::getViewCount); } else { wrapper.orderByDesc(Article::getCreateTime); } // 分页 PageArticle page new Page(query.getPageNum(), query.getPageSize()); PageArticle result articleMapper.selectPage(page, wrapper); return convertToPageResult(result); }这种Lambda方式的好处是类型安全字段名写错了编译期就能发现比字符串硬编码可靠得多。互动中心模块实现互动中心包含三个主要功能问卷调查、健康打卡、谣言粉碎机。问卷调查功能背后是问卷表三张表的配合。用户提交答案后后端要么直接入库要么参与计分。比如我们设计了一套防控知识测试问卷总共10题60分以上算及格及格后发放一张防控达人电子徽章——这个徽章可以分享到朋友圈变相完成了二次传播。健康打卡功能相对简单用户每日点击打卡记录打卡时间。后端按天做唯一约束——一个用户一天只能打一次卡这个约束既可以用数据库唯一索引实现也可以在接口层面做校验。我两种都做了用数据库兜底用接口层做用户体验优化提前提醒您今天已打卡。4.2 管理端Web核心功能实现内容发布流程管理端的内容发布我设计为三步走新建草稿、提交审核、审核发布。为什么要审核因为健康内容太特殊了一旦出现错误信息传播范围广、危害大。所以权限设计上普通管理员只能创建草稿和提交审核只有审核管理员才能执行发布操作。这个流程在功能层面体现为内容列表页每条数据有一个状态标签不同状态显示不同操作按钮。草稿状态显示编辑和提交审核待审核状态显示查看详情和审核通过/驳回已发布状态显示下线和编辑生成新版本。操作状态流转清晰权限互不越界。数据统计与可视化数据统计是管理后台最提现价值的部分。我们做了三个维度的看板内容维度每篇公告/文章的浏览量、分享量、点赞量排行用户维度新增用户趋势、活跃用户数、用户年龄段分析互动维度问卷参与人数、答题正确率、打卡率可视化实现用ECharts后端提供聚合查询接口。这里有个性能优化技巧统计接口不要实时查明细表可以用定时任务每晚跑批把统计数据固化到汇总表里前端查询汇总表秒开。文章浏览量和用户活跃度这种实时变化数据也可以用Redis做计数器定时同步回MySQL。订阅消息推送H2平台上面向C端的订阅消息推送是一个核心能力。比如管理员发布了一篇新的流感防控文章怎么高效触达用户我们通过订阅消息模板实现用户在小程序里主动订阅防控知识更新通知后端在发布文章时调用微信接口给所有订阅过该主题的用户下发一条模板消息。这里有个业务细节值得注意微信订阅消息是一次性订阅用户订阅一次只能收到一条消息。所以设计上我们在用户订阅时引导用户勾选总是保持以上选择这样才能做到多次推送。但按照微信规则勾选总是只能是在小程序内有实际订阅行为的用户才能触发因此UI文案要引导用户主动打开订阅开关。4.3 论文部分的组织思路这个标题还包含了论文说明说明项目要求输出配套设计论文。从论文组织角度看我按下面五章展开第一章绪论交代项目背景、研究意义、国内外现状第二章相关技术介绍小程序框架、Spring Boot、MySQL第三章系统需求分析功能性需求、非功能性需求、用例图第四章系统设计总体架构、功能模块设计、数据库设计第五章系统实现关键功能实现截图、核心代码说明、测试结果论文与代码的关系要把握好代码是支撑论文是归纳。论文里不要贴大段代码而是用截图关键逻辑描述的方式呈现核心逻辑用流程图或时序图表示。我见过太多人论文里贴了50页代码导师看到直接头疼。正确做法是让代码藏在文字描述背后论文的可读性反而更高。5. 小程序端关键技术登录、接口封装与性能优化5.1 微信登录流程的实现细节微信小程序的登录流程有一套标准规范wx.login()获取code - 后端用code换openid和session_key - 后端生成自定义登录态JWT返回给小程序 - 小程序后续请求携带JWT。这个过程不是所有新手一次就能跑通的我把我实现的完整登录流程梳理如下。首先小程序端请求登录的代码片段// 小程序端 const login () { wx.login({ success: async (res) { const code res.code // 调用后端登录接口用code换token const loginRes await request.post(/api/v1/auth/login, { code }) if (loginRes.code 0) { wx.setStorageSync(token, loginRes.data.token) // 可选获取用户资料 getUserProfile() } } }) }后端接收code后调用微信接口换openid// 后端 public String login(String code) { // 向微信接口发送请求 String url https://api.weixin.qq.com/sns/jscode2session?appid{0}secret{1}js_code{2}grant_typeauthorization_code; // 正常项目中使用RestTemplate或OkHttp发起请求 MapString, Object result wxApiClient.getSession(code); String openid (String) result.get(openid); // 判断用户是否存在不存在则注册 User user userMapper.selectByOpenid(openid); if (user null) { user createUser(openid); } // 生成JWT令牌 return jwtUtils.generateToken(user.getId(), user.getRole()); }5.2 接口请求的统一封装小程序端所有HTTP请求都必须走统一的封装层我在utils/request.js中做了三层封装公共header注入、token自动携带、错误统一处理。核心逻辑const request (options) { return new Promise((resolve, reject) { const token wx.getStorageSync(token) wx.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { Content-Type: application/json, Authorization: token ? Bearer ${token} : }, success: (res) { if (res.data.code 401) { // token过期跳转登录 wx.navigateTo({ url: /pages/auth/login }) reject(res.data) } else if (res.data.code 0) { resolve(res.data.data) } else { wx.showToast({ title: res.data.message, icon: none }) reject(res.data) } }, fail: (err) { wx.showToast({ title: 网络异常请稍后重试, icon: none }) reject(err) } }) }) }这个小封装帮我省掉了大量重复的错误处理代码而且全项目统一错误提示样式。后面几十个页面调用接口都只关心业务成功后的数据处理逻辑。注意如果后端返回401一定要做token失效的全局处理否则用户token过期时间长了就会出现各种莫名其妙的请求失败排查起来非常麻烦。5.3 小程序性能优化的几个经验性能优化这块我是在项目上线前专门花了几天时间做的主要解决了三个问题图片懒加载与CDN加速。最初图片都是后端返回相对路径小程序端拼接完整地址加载。后来发现首页首批图片加载特别慢因为一次性加载了近十张封面图。优化方案是封面图缩略图接口返回时直接压缩尺寸比如300x200列表页只显示缩略图点击进入详情页再加载原图同时所有静态资源都放了CDN这一步操作简单但效果最明显——首页打开时间从3秒左右降到了1秒以内。列表页信息的按需加载。列表接口如果一次返回所有字段包括content这种大文本字段传输体积会特别大。优化方案是列表接口的VO对象中只放id、title、cover_image、create_time、view_count这几个关键字段详情页再通过详情接口获取完整内容。这个改动让列表接口响应体缩小了80%以上。分包加载策略。小程序主包体积限制是2MB但我们放了ECharts图表、封面图资源等很快就超标了。解决方法是分包主包只放tabBar页面和基础公共代码把知识库、互动中心等二级功能页面全部拆到分包里。分包按需加载后小程序冷启动速度快了不少。微信官方开发文档说分包预加载还可以配置preloadRule让用户点击某些入口时提前下载分包这个也顺手配上了。6. 常见问题与排查技巧实录6.1 微信登录偶发获取不到openid这个问题在开发阶段出现过好几次。表现是用户点登录按钮没有任何反应后台日志报错code无效。排查步骤先确认wx.login()是否在用户点击事件回调里调用。微信要求敏感接口必须在用户主动触发的事件中调用在页面onLoad里异步调用容易偶发失败。确认code是否使用了两次。wx.login()返回的code只能使用一次如果前端因为网络原因重试请求换了第二套逻辑去换取openid第一次就失效了。解决方式是前端做好请求等待控制避免重复提交。后端要用正确的appid和secret。这个错得太低级不细说但确实遇到过有人把key贴错了排查了半天。6.2 订阅消息用户收不到订阅消息推送收不到是这类系统最常见的问题。我排查经验如下第一检查用户是否真的完成了订阅动作。很多人做了一堆强制授权引导但用户点掉之后实际上没有触发wx.requestSubscribeMessage成功回调。前端要做订阅结果的埋点统计。第二检查模板ID是否匹配。微信要求后端调用订阅消息接口时模板ID必须是通过审核的模板ID而且关键字段的参数要在模板中有对应占位。第三检查用户是否取消了勾选总是保持以上选择。如果用户没有勾选总是那每次只能收到一条发完就没了。我们运营反馈有些用户收不到查下来确实是这个原因。6.3 服务器频繁内存溢出项目部署后有一个版本出现了内存溢出的问题。分析下来原因是图片上传接口没有做文件大小限制有人传了十几兆的大图图片处理代码直接把整个文件读入内存做压缩多并发请求下内存就爆了。修复方案有两步上传接口加MultipartFile大小校验超过2MB直接拒绝。图片压缩改为边读边处理不要一次把整个文件读入内存。用Java的ImageIO读取时先做降采样再压缩减少内存占用。按个人经验这类系统上线后最容易出问题的永远不是核心业务逻辑而是资源消耗型的边缘功能比如文件上传、大字段查询、异步任务并发这些。做代码评审时一定要把这些“弱者”揪出来单独检查。6.4 问卷调查数据统计偏差问卷统计数对不上也是踩过的一个坑。最初统计答题人数时我用的是SELECT COUNT(DISTINCT user_id) FROM t_survey_record WHERE survey_id ?这个没问题。但后面增加了一个重新答题功能允许用户多次刷题统计口径就乱了——到底算人数还是人次解决方案是明确两个指标分开统计参与人数用COUNT(DISTINCT user_id)参与人次用COUNT(*),两个指标都展示在后台看板上运营人员自己按需解读。功能设计层面还会有另一个坑每次答题要记录的是最新一次还是第一次的成绩这里我加了一个score_type字段来标记避免后续需求变更时数据没法对。6.5 常见问题速查表问题现象可能原因解决方案小程序真机预览接口请求失败未配置合法域名或域名未备案在小程序管理后台配置request合法域名确保域名HTTPS化用户头像无法正常显示微信头像接口权限调整改用头像URL直传方式或让用户微信授权获取新头像管理端登录后页面空白JWT过期但前端未拦截在Axios拦截器里加入401统一处理跳转重新登录内容发布后小程序端看不到数据库status字段非已发布状态检查发布流程状态流转逻辑确认事务提交成功数据统计报表加载慢明细表数据量过大改用汇总表定时任务预计算或对查询语句做索引优化订阅消息发送超时传入的openid列表过大分批发送每批不超过100个openid这里我特别建议每个做这类系统的同学从开发第一天就维护一份类似的排错笔记。很多问题不是发现一次就能彻底解决的隔一段时间换个环境可能又会冒出来。有了速查表不管过多久回去维护项目都能快速定位问题。7. 项目落地过程中的几点真实体会这个项目从需求确立、技术选型、编码开发到测试部署整个周期六周左右。实际开发过程中我最大的感受是这类管理系统项目的核心难点从来不在技术上而在业务理解上。如果只是照着需求文档码代码写出来的东西可能功能齐全但不好用。什么是不好用比如管理员想批量给某小区用户推送通知你得先支持用户按区域分组才能做到比如运营人员想看某篇文章在某个时间段内的阅读趋势你得在设计表结构时就想清楚数据存储粒度。这些业务洞察早期的需求分析阶段就得想清楚否则后期返工成本非常高。另外一个重要的经验是给非技术背景的最终用户尤其是社区工作者做系统交互细节要尽量朴实。我们第一版上传图片用的是标准的input组件的file类型但对50多岁的管理员来说这个入口太隐蔽了。后来改成了点击上传图片区域的大按钮设计用户跳出率立马降下来了。这个小改动是一个下午做出来的但对用户体验的提升非常显著。给正在做或准备做类似项目的朋友几点个人建议第一技术栈不要追求新要追求稳。Spring Boot MyBatis-Plus MySQL这套组合虽然老但是社区成熟、踩坑资料多、招人容易。项目交付后维护成本低才是最重要的。第二管理端的UI不用太奢华功能清晰即可。我见过有人花了两周时间做了个炫酷的大屏驾驶舱结果实际用起来核心录入功能却做得很粗糙——这就本末倒置了。第三微信小程序开发有个好处是自带调试工具和真机预览能力一定要利用好这两个工具来排查问题特别是一些真机预览才能暴露的功能用开发工具模拟是发现不了的。我在真机调试时发现过图片压缩在安卓上兼容性问题、iOS下日期格式化差异等这些如果不提前测试上线后就是事故。最后分享一个技巧开发这种项目时建议前端、管理端、后端分别建立独立的Git分支管理策略每个功能模块一个feature分支合并到dev分支后集成测试。我们当时三个人协作因为前期分支管理做得好后期几乎没有出现代码互相覆盖的情况配合效率比所有人都直接提交master高太多了。很多做毕设项目或者小团队项目的同学觉得Git不重要但当项目规模到了一定程度版本管理直接决定了开发效率这个说法真是血泪教训换来的。这套系统做完之后前端页面几十个后端接口上百个说实话完成那天有一种如释重负的感觉。但回头复盘这个项目最大的收获不是代码量而是把一个复杂业务从0到1落地的完整思维过程——如何拆解需求、如何设计数据模型、如何权衡技术方案、如何排坑解决线上问题这套能力是看再多文档都学不来的。希望这篇分享对你的项目能有一点帮助。