这套题目在毕设圈里属于“常青树”级别了。每年到毕业季总有学生拿着“基于SpringBootVue的学生宿舍管理系统”来找我要么是自己在网上淘了一套源码要么是导师给了个题目自己还没想清楚从哪儿下手。说实话这个选题本身不算新颖但它胜在业务场景清晰、技术栈主流、功能可扩展空间大——如果你不是只想“交差”而是真的想弄明白一个前后端分离项目是怎么从零跑起来的那这套东西非常适合用来做技术框架的练手和毕设地基。很多人拿到源码后第一反应是“怎么启动”第二反应是“答辩老师问怎么办”。这篇文章我不打算复述什么安装步骤也不做那种“点击下一步就完事”的傻瓜教程。我会把这个学生宿舍管理系统拆开从后台表设计、接口逻辑到前端页面路由、最终部署上线把每一条核心链路和技术选型理由都讲清楚。尤其是那些卖了源码却讲不清原理的坑我会在这里一并填上帮你把项目变成真正能拿到答辩现场讲的东西。1. 系统功能设计与业务拆解1.1 从业务需求倒推功能模块学生宿舍管理系统业务场景很固定学校后勤或者宿管中心需要对学生入住、退宿、宿舍分配、报修、水电费、访客进出这些事进行统一管理。你要是去一个真实的宿管办公室坐一下午就会发现他们的日常基本是查谁住了哪个寝室、楼栋还有多少空床位、灯管坏了报修有没有人处理、月底算一下水电费。整套系统的功能边界其实就是把这些手工操作用软件替代掉。对于毕业设计而言功能做到什么程度合适我有一个比较实际的判断标准能覆盖核心业务闭环但不要贪多。所谓核心闭环就是“宿舍资源——学生——入住记录”这条主链再把报修、水电费、公告这类高频场景挂上去。至于自动分配算法、人脸识别门禁、大数据可视化这种属于加分项不是必要项优先级应该排在基础的增删改查和权限控制后面。在这个项目里我推荐的功能模块可以切成下面这六块用户与权限学生、宿管、系统管理员三种角色登录后看到不同的菜单和操作按钮学生管理学生信息的增删改查、导入导出、按学院/班级筛选宿舍管理楼栋、楼层、房间、床位的层级维护实时显示空余床位分配与退宿手动分配、调宿、退宿登记宿舍分配记录留痕业务场景报修工单、水电费抄表、公告通知、访客登记个人中心密码修改、本人住宿信息查看、学生自己的报修记录1.2 角色权限为什么是第一个要考虑的模块很多新手拿到项目先去看页面我觉得顺序应该反过来先想清楚角色权限。宿舍管理系统最大的特点是数据有归属、操作有边界。学生只能看自己的信息和寝室宿管可以管理自己负责的楼栋能处理报修但不宜改水电单价管理员则拥有全部权限包括新增宿管账号、配置楼栋数据。这个需求在一开始就决定了系统的数据结构。第一用户表里必须有角色字段或者用独立的角色表和用户-角色关联表。第二前端路由需要动态生成根据角色返回不同的菜单。第三后端接口必须做角色校验不能只靠前端隐藏按钮来防越权。我在做这套系统时采用了Spring Security JWT的方案。流程是登录成功后后端签发一个token前端每次请求在Header里带上token后端通过拦截器解析token、拿到角色、判断接口权限。相比Session方案JWT最大的好处是无状态服务端不用存会话水平扩展的时候比较方便。对于前后端分离的架构来说这也是最主流的做法。1.3 功能列表的“够用”和“出彩”功能做多少直接关系到你中期检查和论文的工作量。我的建议是以下这个清单属于“够用”基准线模块必要功能加分功能宿舍管理楼栋/房间/床位增删改查、条件查询宿舍状态图入住/空置/维修学生管理学生信息CRUD、分页搜索、班级筛选Excel批量导入、头像上传分配管理手动分配、退宿、记录查询自动分配、分配冲突校验报修管理提交报修、派单、处理状态流转维修人员角色独立水电管理抄表、费用计算、账单列表缴费状态标记、逾期统计系统管理用户管理、角色权限、登录日志操作日志、公告发布表里的“加分功能”不需要一次性做完可以在基础功能稳定之后挑一两个实现。如果时间紧张优先做Excel导入和报修状态流转这两个在答辩时最容易跟老师展开讨论也容易展示业务逻辑的完整度。2. 技术选型SpringBoot Vue这套组合为什么主流2.1 SpringBoot解决的是后端“配置地狱”问题我见过不少早期JavaWeb项目配置文件动辄十几二十个项目还没写功能光调环境就能耗掉几天时间。SpringBoot出现后这种情况好了很多。它的核心理念是约定优于配置把常用的第三方库做成Starter通过起步依赖自动装配开发者只需要关注自己的业务代码。再结合MyBatis-Plus做数据持久层会让开发体验好很多。MyBatis-Plus把单表的增删改查全部封装好了你不用再手写一大堆重复的SQL继承一个BaseMapper接口就可以直接调用selectById、insert、deleteById这些方法。我刚入门时是手写MyBatis XML的后来切到MyBatis-Plus后最大的感受就是代码量变少分页查询也不需要自己拼LIMIT了。2.2 前端为什么选Vue而不是别的Vue在国内校园生态里的普及度比较高学习曲线也比较缓。它采用组件化开发页面可以拆成独立的组件比如“学生列表”是一个组件“宿舍卡片”是另一个组件互相之间通过props和自定义事件通信。Vue全家桶里最核心的是Vue Router和Vuex/Pinia。Vue Router负责前端路由跳转区分/login、/dashboard、/dormitory这些页面地址状态管理库负责在多个组件之间共享数据比如当前登录用户的信息、角色、token放在全局状态里任何一个组件都能拿到。如果项目选Vue 3状态管理就用Pinia它是Vue官方推荐的新方案语法比Vuex更简洁、支持完整的TypeScript类型推导。2.3 为什么这套组合在校园项目中如此常见从长期带毕设、看开源项目的角度观察SpringBootVue能火的根本原因是前后端生态成熟、岗位需求匹配、学习资料丰富。企业里大量中小管理系统就是这种架构你在简历上写“熟悉SpringBootVue开发前后端分离项目”比写“会用JSP/Servlet拼页面”要有说服力得多。这套技术栈还有一个间接好处它的底层工具链非常完善。比如后端有Lombok减少样板代码前端有Element UI/Element Plus提供了现成的表格、表单、弹窗组件Vite启动开发服务器只要几百毫秒。开发效率高意味着你能把更多精力花在宿舍管理系统的业务逻辑和界面友好度上而不是陷在环境配置里出不来。这也是我在给毕设选型时最看重的一点。3. 数据库表设计与核心关系梳理3.1 关键表结构和字段说明数据库是整套系统的地基表设计得好不好直接影响后面写业务代码的心智负担。我在设计宿舍管理系统时采用了用户与业务数据分离的思路用户表只存登录信息学生的详细信息放在扩展表里这样以后想扩展教师、宿管等角色时不用反反复复改动用户结构。下面给出几张核心表的字段设计思路。第一张是系统用户表sys_user。字段包含主键id、用户名、密码加密存储、真实姓名、角色标识、手机号、创建时间。这里注意密码一定要用BCrypt加密或者MD5加盐数据库里绝不能存明文这个在毕业答辩里也经常被老师问到。第二张是学生信息表student。字段包括学号、姓名、性别、学院、专业班级、联系方式、入住状态、关联的用户id。之所以单独立表是因为一个学生后期可能关联着报修记录、缴费记录把主键id关联到业务表可以保证数据一致性。第三张是宿舍表dormitory。这个表要尽量贴近真实物理环境。字段包括房间编号、所属楼栋id、楼层、房间类型四人间/六人间/八人间、床位数、已入住人数、是否维修状态。这里的“已入住人数”是典型的冗余字段在分配和退宿时同步更新。虽然违反了部分范式但能大幅简化查询逻辑避免每次查剩余床位都要COUNT一下。然后是入住记录表occupancy_record。这张表是学生和宿舍的关联桥梁记录分配的起始时间、结束时间、操作人、退宿原因等。有了这张表学生的住宿历史就可以回溯宿管能清楚地看到某一间寝室住过哪些人。3.2 为什么外键和索引要这么设数据库初学者喜欢到处加外键觉得这样才能保证数据完整性。在实际项目里我反而建议业务表主要通过逻辑外键关联数据库层面不要轻易物理外键约束。原因很简单宿舍管理系统涉及分配、调宿、退宿频繁变更的场景下物理外键会带来额外的锁开销和删除限制而且一旦数据中间出问题排查起来很麻烦。但索引一定要得上。以我的习惯occupancy_record表的student_id和dormitory_id是要建索引的因为报修、缴费查询时经常通过这两个字段做关联。sys_user表的username也必须唯一索引这是登录时的首要查询条件。毕业设计里数据量不大索引优化可能体会不深但把索引设计清楚论文的“数据库设计”那一章会好看很多。为了照顾新手理解我用SQL给宿舍表举个例子CREATE TABLE dormitory ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键, building_id bigint(20) NOT NULL COMMENT 所属楼栋ID, room_no varchar(20) NOT NULL COMMENT 房间编号如5-301, floor tinyint(4) DEFAULT NULL COMMENT 所在楼层, room_type tinyint(4) DEFAULT 4 COMMENT 房间类型4/6/8人间, bed_count int(11) NOT NULL COMMENT 床位数, used_beds int(11) NOT NULL DEFAULT 0 COMMENT 已入住人数, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 状态1可用 0维修 2停用, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_building_id (building_id), KEY idx_room_no (room_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT宿舍房间表;3.3 数据库初始化脚本的重要性前阵子有个学弟拿网上的源码跑结果启动时报了一堆SQL异常最后发现是数据库里缺少初始化数据。这个现象在毕设圈挺常见的。所以我在发放源码的时候强烈建议配套一份init.sql脚本里面包含建库、建表以及必须的初始管理员账号。初始化脚本里尽量把这些东西都放进去系统管理员账号admin/admin123密码使用BCrypt加密后的字符串、楼栋和楼层的示例数据、几位测试学生、几间测试宿舍、一两张已经入住的记录。用这些数据启动项目后你就能立刻进入界面验证功能而不是对着空列表发呆。4. 后端核心实现与接口逻辑4.1 项目初始化和依赖配置后端项目我习惯用Spring Initializr生成当然你也可以直接从已有的骨架改。无论如何pom.xml里下面这几个依赖是绕不开的spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、lombok以及可选的spring-boot-starter-validation参数校验。如果你用的是Redis做缓存还要引入spring-boot-starter-data-redis。配置文件方面注意把数据库连接、MyBatis-Plus配置拆清楚。一个典型的生产级application.yml配置长这样server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/dormitory_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这里map-underscore-to-camel-case很关键它能把数据库字段的create_time自动映射到Java实体类的createTime避免你写一堆TableField注解。4.2 Controller层与统一返回结构设计前后端分离的项目后端接口返回的数据结构必须统一。我见过有些项目每个接口返回类型都不一样前端调用时一会取data一会取rows维护起来非常痛苦。推荐的做法是定义一个通用结果类RT包含code、message、data三个字段成功时返回200失败时返回自定义错误码。Controller层的接口设计可以遵循最朴素的REST风格。比如GET /api/student/page是分页查询学生POST /api/student新增学生PUT /api/student修改学生DELETE /api/student/{id}删除学生。动词交给HTTP方法表达路径只写资源名词这种风格在答辩时也容易说清楚。做这个系统时我在Controller里会加三层校验入参格式校验Validated、业务逻辑校验比如宿舍容量是否已满、权限校验通过Spring Security的PreAuthorize注解。三层校验一层都不能少否则你在前端随便传个非法数据后端可能直接抛异常或者把脏数据存进数据库。4.3 宿舍分配的业务逻辑实现如果说整个系统里哪个环节最能体现业务设计能力我觉得是宿舍分配。它不是一个简单的insert而是要处理一系列判断和状态流转。我以往的完整逻辑是入参校验学生是否存在、是否已经分配过宿舍、宿舍编号是否存在宿舍容量校验已入住人数是否小于床位数执行分配插入occupancy_record表更新宿舍数据该房间的used_beds加1更新学生状态把学生的入住状态改为“已入住”记录操作日志谁在什么时间给谁分配了哪间宿舍这一连串操作涉及多张表的更新必须是事务性的否则中途出错就会出现学生有记录但宿舍没床位、或者宿舍占用数不准的情况。在SpringBoot里做事务很简单在Service层方法上加上Transactional注解即可。但如果方法内部不要捕获异常后吞掉否则事务会失效这一点踩过坑的人都懂。为了提高容错率我还会在分配时加一个悲观锁的选项查询宿舍时使用SELECT ... FOR UPDATE并发控制。毕设场景下并发量不大这行代码不必做进最终版本但了解它答辩时可以提“在高并发场景下可以通过加锁或乐观锁防止超分”这就是额外的加分点。4.4 分页查询与条件搜索的统一封装后端接口里使用频率最高的就是列表查询。学生列表、宿舍列表、报修列表、缴费列表形态基本一致前端传页码、每页条数、若干筛选条件后端返回当前页数据和总数。MyBatis-Plus自带的Page对象帮了大忙。在Service层写这样一段代码Override public IPageStudentVO queryStudentPage(StudentQuery query) { PageStudent page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperStudent wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.hasText(query.getName()), Student::getName, query.getName()) .eq(StringUtils.hasText(query.getClassName()), Student::getClassName, query.getClassName()) .eq(query.getStatus() ! null, Student::getStayStatus, query.getStatus()) .orderByDesc(Student::getCreateTime); IPageStudent studentPage studentMapper.selectPage(page, wrapper); // 将实体转换为VO返回避免直接将数据库结构暴露给前端 return StudentConverter.INSTANCE.toVO(page); }这里有两个技术细节值得讲。第一是LambdaQueryWrapper它以Lambda表达式引用实体字段名避免了硬编码字符串写错不报错的问题。第二是实体和VO分离前端要展示的名称、学院中文描述可能和数据库字段不一致用一个转换器去映射之后即使数据库表结构变了也不会直接波及到接口返回格式。5. 前端页面实现与前后端联调5.1 项目结构规划和路由设计前端我基于Vue 3 Vite Element Plus来搭建。很多人刚用Vite时会被它的目录结构搞晕其实它的核心目录就是src/router路由、src/views页面、src/components公共组件、src/api接口请求、src/store状态管理。我最想强调的一点是一定要在项目里建立src/api目录把接口请求按模块拆分。比如api/student.js里专门放学生相关的请求api/dormitory.js里放宿舍相关的请求这样后端接口改了也好统一调整而不是在几十个页面文件里到处找axios.get。路由设计要处理动态路由和权限。简单做法是登录后根据角色的返回值在前端用addRoute动态注册可访问的路由。比如管理员可以注册“用户管理”和“宿舍管理”学生就只能注册“我的寝室”“我的报修”。然后配合router.beforeEach全局路由守卫在跳转前检查token是否存在、路由是否被注册过实现未登录拦截效果。5.2 请求封装和拦截器配置如果直接在每个页面里写axios.get代码会非常冗余而且token处理、错误处理会重复。习惯做法是封装一个request.jsimport axios from axios; import { ElMessage } from element-plus; import { useUserStore } from /store/user; import router from /router; const request axios.create({ baseURL: /api, // 通过Vite代理转发避免跨域 timeout: 10000 }); request.interceptors.request.use(config { const userStore useUserStore(); if (userStore.token) { config.headers.Authorization Bearer ${userStore.token}; } return config; }); request.interceptors.response.use( response { const res response.data; if (res.code ! 200) { ElMessage.error(res.message || 请求失败); return Promise.reject(new Error(res.message)); } return res.data; }, error { if (error.response error.response.status 401) { ElMessage.error(登录已过期请重新登录); router.push(/login); } else { ElMessage.error(网络错误请稍后重试); } return Promise.reject(error); } ); export default request;这段代码里最有价值的部分是响应拦截器。当用户token过期时后端返回401所有页面都能统一跳到登录页而不用每个页面自己写一遍异常处理。接口请求的baseURL设置成/api开发环境通过Vite的proxy配置把请求转发到http://localhost:8080既解决了跨域又给生产部署留了弹性空间。5.3 页面布局和关键页面实现思路系统页面整体采用“左侧菜单栏右侧内容区”的后台管理系统经典布局。用Element Plus的Container布局很容易搭出这种结构。菜单根据角色动态渲染顶部放用户信息、退出按钮和系统名称。拿“宿舍分配”这页来说页面左侧是楼栋和房间的层级列表点击某个房间右侧会显示这个房间的详细信息和已入住学生列表再提供一个“分配学生”的按钮点击后弹出对话框输入或搜索学号、姓名进行分配。这个页面的数据交互涉及三级联动点楼栋显示楼层、点楼层显示房间、点房间显示详情处理起来思路要清晰建议在页面里拆分组件BuildingTree.vue负责楼栋树RoomInfo.vue负责房间信息父子组件通过事件通信数据状态用Pinia管理。前端页面里最容易出bug的是“提交成功后页面数据不刷新”。解决方法很朴素在提交成功回调里重新调用一次列表接口或者更新组件数据。这个细节很多初学者会忽略答辩时演示“分配成功后宿舍列表还是原来的样子”就有点尴尬了。5.4 前端开发环境注意事项前端环境的问题比后端多至少下面这几项要先确认Node.js版本要跟Vite匹配我推荐用Node 18或20的LTS版本npm install时如果网络慢把源切换到国内镜像启动开发服务器用npm run dev默认端口5173如果后端端口是8080一定要在vite.config.js里配好代理不然前端请求会404或者跨域报错Vite的配置文件其实很简单如下export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } });有人说“电脑配置低跑不动前端”其实Vite在开发环境比Webpack快得多它用原生ESM模块机制启动几乎秒开热的编辑更新也是毫秒级。用到生产环境时npm run build会打包出一堆静态文件扔给Nginx托管就行这也是后面部署环节要讲的事。6. 部署、答辩与常见问题实战经验6.1 项目打包部署的两种方式毕设的系统最终要能在老师面前跑起来所以“怎么部署”必须提前搞清楚。通常有两种形式。一种是开发模式后端通过Maven的spring-boot:run启动前端通过npm run dev启动浏览器打开Vite的地址访问。这种模式适合开发和演示但打开两个终端窗口老师会看着比较乱。另一种是生产模式后端用Maven打成可执行的jar包前端打包成dist静态目录然后部署在一台服务器上。我推荐的方式是Nginx托管前端静态文件并配置反向代理把/api请求转发到后端端口。Nginx配置片段如下server { listen 80; server_name your-domain-or-ip; location / { root /opt/dormitory-front/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; } }用生产模式部署的好处是稳定而且跟将来简历上写的“上线部署”经历能对上。对毕业设计来说本地演示用开发模式也完全足够看你的精力来定。6.2 常见问题与解决办法速查我根据以往带项目的经验整理了一个常见问题清单这些问题几乎每个学生都遇到过。如果启动不起来或者页面报错先对照这个表排查一遍现象原因解决办法后端启动报数据库连接失败MySQL没启动或账号密码错误启动MySQL服务检查yml配置提示Could not determine recommended JdbcType实体类字段跟数据库字段不匹配检查字段类型和命名补齐注解登录时报密码错误密码没有用同一种加密方式确认注册和校验都用BCrypt加密前端请求接口返回404后端没启动或代理没配好先curl测后端接口再检查vite代理跨域报错前端端口和后端端口不一致用Vite代理或后端配置CorsFilter刷新页面后404前端路由history模式未配置Nginx配置try_files回退index.html报错端口被占用8080或5173被其他程序占用netstat -ano查端口换端口或杀进程分页查询数据为空当前页参数没传、条件过滤太严格控制台看请求参数去掉条件再试MyBatis-Plus主键类型报错主键生成策略没配置TableId(type IdType.AUTO)或雪花ID配置其中“刷新页面后404”这个比较隐蔽。Vue Router默认是HTML5 History模式刷新页面时浏览器会去请求真实路径于是Nginx找不到对应文件就返回404。解决办法是加一条try_files $uri $uri/ /index.html;把所有路由回退到前端入口由前端路由自己解析。6.3 答辩时的讲法和技术亮点提炼答辩本质上是要你在五分钟内证明“这个系统是我设计并实现的我理解里面的技术方案”。先不要紧张顺着下面这条线讲就很有逻辑性首先说业务背景宿舍管理吵杂低效这个系统要把流程线上化然后讲需求分析谁是使用者他们各自需要什么再讲技术选型为什么挑SpringBoot和Vue接着是核心模块演示最好挑宿舍分配或者报修流程把“数据库表怎么变”“接口怎么处理”完整讲下来最后是部署和总结。在讲技术亮点时你可以重点提这几点基于RBAC模型的权限控制把用户、角色、菜单分开管理使用MyBatis-Plus的条件构造器和分页插件简化数据访问层开发前端采用动态路由不同角色看到的界面不同接口返回结构统一配合Vue请求拦截器统一处理token和异常宿舍分配采用事务控制保证多表更新的一致性每一点你都要能展开讲一分钟左右并且准备一个“源码里哪里体现了这一点”的答案。比如讲RBAC时能说出sys_role_user和sys_menu_role两张表的关联结构比空谈概念好很多。6.4 拿到一套源码后怎么快速吃透它这是最实在的问题。现在大家普遍是先找一套源码然后自己改。我的建议是不要把源码当成黑盒启动起来了就不管了。你可以按下面这个顺序去拆先看数据库表数一数有几个表画一下表关系图。再看看后端Controller层把每个接口的功能注释标注出来。然后从前端路由出发一个页面一个页面去追“点击了哪个按钮、调用了哪个接口、操作了哪张表”。等到你能不看代码说清楚“分配宿舍的完整链路”时这套系统才真正属于你。改的时候也不要大改先从小功能入手。比如把界面上的“学生”改成“住户”给宿舍列表新增一个“按楼层筛选”的条件或者给报修单加一个“评价功能”。这些改动虽小但能逼你走一遍从数据库到后端再到前端的全链路比看十遍文档都管用。6.5 关于“买源码”这件事的一些个人建议说实话我见过太多学生花冤枉钱买了一套“号称全源码”的东西结果发过来只有代码没有文档SQL也是一团乱。所以如果你打算获取现成资源有几条判断标准可以看一是必须包含完整的数据库脚本init.sql能一次性初始化全部表结构二是后端启动依赖要写清楚JDK版本、Maven版本、MySQL版本都得说明三是前端模块要完整不能只有登录页后面全是静态假数据四是必须附带操作手册或环境搭建文档。拿到手之后第一件事不是跑界面而是重建数据库再启动后端再启动前端逐步排查问题。这样即便你有问题去找卖家也能清楚地知道自己卡在哪一步而不是只会发一句“死活跑不起来”。我一直觉得毕设这段经历的价值不在于最终那个“及格”的结果而是在过程中把学校教的理论和实际项目的距离拉近一点把“面向期末考试”的编程变成“面向真实需求”的工程。宿舍管理系统确实不算什么大赛项目但只要你肯深挖它在权限设计、事务处理、前后端联调、部署上线这几个环节里藏着的知识量足够让你脱一层皮也是真的能学到东西的。如果你现在手上正拿着这样一套源码我希望你按这篇文章的思路重新审视一遍别急着跑通先掰开揉碎看看它是怎么被设计出来的。等你把它变成“你的”系统那种感觉和单纯运行别人的代码完全不一样。这个项目后续可以往移动端、人脸识别门禁、楼栋能耗统计方向扩展遇到卡壳的时候欢迎回来看看这篇心法相信会有不一样的收获。