企业官网建设流程全解析

拿到一个毕设题目，我最怕的不是系统做不出来，而是做出来之后自己根本讲不清楚“为什么这么设计”。这次这套“SpringBoot+Vue+MySQL企业资产管理系统”，表面上是一个典型的全栈CRUD项目，但真往深了做，里面藏着权限模型、流程审批、报表统计、前后端联调、部署上线一整串硬功夫，每一项都能在答辩台上被老师翻来覆去地问。这篇内容就是帮你把这些硬功夫一次性打通。

这套系统解决的痛点非常实际：传统企业用Excel管理固定资产，资产台账混乱、借用归还不留痕、盘点对不上账、报废审批靠纸质单子跑腿。做成管理系统之后，资产从入库、领用、借用、维修到报废形成一个完整的线上闭环，每一步操作都有记录，谁经手的、什么时候发生的、当前在谁手里，一查便知。所以这个题目不是简单的增删改查，它对应的是真实企业管理中的资产全生命周期管理需求。

适合参考这套方案的，是正在做毕设的在校生、想练手全栈项目的初级开发者，以及需要给公司内部做资产管理工具但预算有限的技术同学。你不需要有多深的算法功底，只要能耐下心把SpringBoot和Vue的基础链路跑通，再把业务表设计得合理一点，整套系统就能立起来，而且立得相当稳。

1. 项目背景与技术选型：为什么这套组合最稳妥

1.1 毕业设计选题的常见误区

做毕设最容易踩的坑，是一上来就追新。前两年微服务火，人人都要拆Spring Cloud，把自己折腾得死去活来；这两年AI火，又想往上套一些不切实际的功能。但毕业设计的核心评价标准从来不是“用的技术多新”，而是“你能否讲清楚系统的完整链路、能否解决一个真实问题、能否经得起追问”。

企业资产管理系统这个选题好在哪？第一，业务场景足够清晰，每个人都能理解资产管理的痛点，答辩时不用费劲解释业务背景；第二，功能边界明确，入库、领用、借用、维修、报废、盘点、报表，一条线串下来逻辑完整；第三，技术栈经典，SpringBoot、Vue、MySQL这三样是当前企业级开发的主流组合，出去找工作面试也会问到，做一遍等于提前复习了面试题。

1.2 为什么是SpringBoot+Vue+MySQL

先说后端。SpringBoot在Java生态里已经处于事实标准的地位，内嵌Tomcat、自动配置、起步依赖这些特性，让开发者从繁琐的XML配置里解放出来。对我来说更重要的是，SpringBoot的生态太成熟了，遇到问题一搜一大片解决方案，对新手极其友好。你用SSH（Struts+Spring+Hibernate）或者SSM手写配置，光配置文件就能劝退一半人，而且答辩时老师大概率会追问“为什么要用这个框架”，你回答“SpringBoot简化了配置、内置了服务器、生态完善”，这个答案本身就很有说服力。

再说前端。Vue的核心优势是渐进式、响应式、组件化。渐进式意味着你可以只在一个页面里引入它，也可以用它构建完整的单页应用，学习曲线很平滑。组件化让页面复用变得简单，比如资产列表、用户列表、审批列表这些页面的表格和弹窗，抽成组件后一个模板到处用。Vue在国内的社区活跃度极高，Element UI/Element Plus组件库就是专门为Vue打造的中后台UI方案，做管理系统几乎是开箱即用。

数据库选MySQL更不需要纠结。它开源免费、跨平台、性能稳定，而且在中国开发者群体里普及率极高。学校的课程教的是它，企业的生产库用的也是它，你学会了MySQL的东西，出去工作不会白学。有人纠结要不要用Oracle或者PostgreSQL，说实话，对毕设这个体量来说，MySQL完全够用，而且你写出“MySQL支持事务、支持索引优化、支持主从复制，满足本系统的数据一致性和并发需求”这种话，老师是认可的。

1.3 完整交付物的价值

这套项目的交付物不止是能跑起来的代码，还包含数据库脚本、毕业论文、部署文档。很多同学低估了“部署文档”和“论文”在这类项目里的分量。代码写得再漂亮，部署文档一塌糊涂，老师本地跑不起来，印象分直接打骨折。反过来，如果部署文档写得很细致，老师照着三步就能启动系统，他对你项目的完成度评价会明显上一个台阶。

我在设计这套交付物的时候，刻意把部署文档写成了保姆级攻略：从JDK安装、MySQL建库、导入SQL脚本、配置application.yml、启动后端、npm install、启动前端，到最终的浏览器访问地址，每一步都有截图位置说明和预期效果描述。这样做不仅仅是为了让老师能跑起来，更是为了你自己在三个月后回头看这个项目时，能快速找回上下文。技术债会遗忘，但一份好文档不会。

2. 系统功能架构与模块拆解

2.1 核心业务模块

企业资产管理系统的业务核心是“资产全生命周期管理”，我拆成了六大模块：系统管理、资产管理、资产分类、借用管理、维修管理和报表统计。系统管理管的是用户、角色、菜单权限；资产管理管的是资产台账的增删改查、资产卡片详情、二维码标签生成；资产分类做树形层级管理，比如“电子设备-电脑-笔记本电脑”这种三级分类；借用管理处理借用申请、审批、归还登记、逾期提醒；维修管理记录报修、维修进度、维修费用；报表统计用ECharts展示资产分布、分类占比、部门资产存量等图表。

每个模块不是一个单表CRUD就完事了，而是要处理模块之间的数据联动。举个例子，资产借用时，不仅要插入一条借用记录，还要同步修改资产信息表里的“当前状态”字段，从“在库”改成“已借用”；归还时再改回来。这个联动关系如果没想清楚，到了后期写代码就会出现数据不一致的问题：资产明明被借走了，台账上还显示在库。

2.2 角色权限设计

权限模型我用的是经典的RBAC（基于角色的访问控制），三张核心表：用户表、角色表、用户角色关联表，再往上加一层菜单权限表（或权限表）和角色菜单关联表。这样做的好处是用户和权限不直接挂钩，而是通过角色中转，方便后续扩展。

系统里我规划了三种角色：管理员、资产管理员、普通员工。管理员拥有全部权限，包括用户管理、角色分配、系统配置；资产管理员负责资产台账维护、借用审批、维修处理；普通员工只能查看资产列表、发起借用申请、查看自己的借用记录。前端根据登录用户的角色动态生成菜单，后端接口通过Spring Security或自定义拦截器校验权限，双重保障，答辩时把这一块讲清楚，老师会认为你是真的理解了权限控制，而不是把按钮藏着就算完了。

2.3 业务流程闭环

一个完整的资产借用流程是这样的：员工登录系统后，在资产列表里找到想借的设备，点击“申请借用”，填写预计归还日期和用途，系统生成一条待审批的借用单；资产管理员收到待办提醒，查看资产当前状态和借用申请详情，选择同意或驳回；同意之后，资产状态变为“已借用”，资产管理员在线下把实物交给员工；员工使用完毕后在系统里发起归还，资产管理员确认资产完好后点击“确认归还”，资产状态恢复为“在库”。

如果只看表面，这跟普通的CRUD没什么区别，但把状态流转画出来就会发现，每一步操作背后都有状态字段的变化和操作记录的写入。我强烈建议你画一张状态机图放在论文里：在库、已借用、维修中、已报废，这些状态之间的转换条件是什么，由哪个角色触发。这张图画出来，论文的“业务流程设计”章节就立住了。

3. 数据库设计：资产管理的核心底盘

3.1 核心表结构概览

数据库设计是整个系统最见功力的地方，也是老师最爱追问的部分。我设计的表结构大体如下：

• sys_user（用户表）：id、username、password、real_name、phone、email、department_id、status、create_time
• sys_role（角色表）：id、role_name、role_code、description、create_time
• sys_user_role（用户角色关联表）：id、user_id、role_id
• sys_menu（菜单表）：id、parent_id、menu_name、path、component、icon、sort、visible
• sys_role_menu（角色菜单关联表）：id、role_id、menu_id
• asset_category（资产分类表）：id、parent_id、category_name、sort
• asset_info（资产信息表）：id、asset_no、asset_name、category_id、specification、price、purchase_date、department_id、custodian_id、status、location、remark
• asset_borrow（资产借用表）：id、asset_id、borrow_user_id、borrow_time、expect_return_time、actual_return_time、borrow_reason、status、approve_user_id、approve_remark
• asset_repair（资产维修表）：id、asset_id、repair_user_id、repair_desc、repair_cost、repair_time、finish_time、status
• asset_scrap（资产报废表）：id、asset_id、scrap_user_id、scrap_reason、scrap_time、approve_status

这十张表基本覆盖了系统的核心业务场景。要注意的是，我没有用物理外键约束，而是只在逻辑层面维护表间关联。为什么？因为物理外键在插入、更新时有额外的约束检查开销，而且在做数据迁移、批量导入时特别容易卡住，很多互联网公司的生产库都是禁用物理外键的。但是答辩时你要能说清楚“逻辑外键”这个设计思路，不然老师可能会觉得你不懂数据库约束。

3.2 关键字段与类型选择

字段类型选对了能省很多事。先说主键，我统一用BIGINT自增，简单直接。有人喜欢用雪花ID，但那是分布式场景下的方案，单机项目用自增ID完全够，而且SQL写起来清爽。再说金额字段，资产价格用DECIMAL(10,2)而不是FLOAT或者DOUBLE，因为浮点数在计算时会有精度丢失的问题，DECIMAL是定点数，能够精确表示小数，财务报表上的金额绝对不能有分毫之差。状态字段我用TINYINT或VARCHAR的枚举值，比如资产状态0表示在库、1表示已借用、2表示维修中、3表示已报废，代码里定义常量或枚举类统一管理，避免魔法值散落各处。

时间字段统一用DATETIME，不要用TIMESTAMP。DATETIME的范围是1000年到9999年，TIMESTAMP最大只能到2038年，而且DATETIME不依赖数据库时区，不会出现因为服务器时区设置导致的显示错乱。我在实际开发中踩过TIMESTAMP的坑，部署到云服务器后时间差了8个小时，排查了半天发现是时区问题，后来果断全部换成DATETIME，世界清净了。

3.3 设计思路与数据落地

为了让这套系统能直接跑通，数据库脚本我做了精心整理，包含了所有建表语句和初始化数据。初始化数据这块特别重要，很多同学交付的数据库脚本只有表结构，老师导入之后系统登录页面都打不开，因为根本不存在的用户能登录。我预置了一个管理员账号、一个资产管理员账号、一个普通员工账号，密码统一用BCrypt加密后的密文存在库里，这样既安全又能开箱即用。

同时我还造了一批模拟资产数据，涵盖电子设备、办公家具、交通工具等分类，数量在50条左右，分布在不同的部门和状态。这些数据有实际意义：登录之后首页能看到图表，去做查询功能时有数据可查，演示审批流程时有资产可借。不要小看这批模拟数据，它直接影响你演示时的流畅度。空跑一个系统给老师看，和带数据跑系统，观感差距是巨大的。

4. 后端核心模块实现

4.1 SpringBoot项目初始化与分层

项目初始化我选择用SpringBoot 2.7.x版本，不要追最新的大版本。2.7.x是目前社区兼容性最稳的版本，各种第三方集成demo基本都是基于这个版本写的，遇到问题copy别人的方案直接生效，不用改配置。如果有人让你用Spring Boot 3.x，你要注意它基于JDK 17，且javax包名换成了jakarta，很多老教程里的代码直接粘过来会报错。毕设求稳，2.7.x是首选，JDK用1.8，这是无数生产环境验证过的黄金组合。

代码结构我用经典的四层架构：Controller层负责接收请求和返回响应；Service层写业务逻辑；Mapper层（Dao层）操作数据库；Entity/Model层定义实体类。Controller只做参数接收和结果封装，不写业务代码；Service只处理业务，不直接拼接SQL；Mapper只做数据访问。这样分层的好处是职责单一、方便测试、出问题能快速定位。我见过很多同学一个Controller里写了上千行，Service形同虚设，老师追问“你的分层体现在哪里”的时候，那场面真的尴尬。

4.2 登录鉴权与JWT

登录鉴权我一开始想过直接用Session，操作简单，但前后端分离的场景下Session有个天然痛点：跨域要配置CORS，Session共享要额外处理，移动端和Web端共用一套接口时Session也不方便。后来我换成了JWT方案：用户登录成功后，服务端生成一个Token串返回给前端；前端把Token存在LocalStorage里，每次请求时把Token放在请求头的Authorization字段里；后端写一个拦截器，除了登录接口和静态资源外，其他接口统统校验Token的有效性。

JWT的好处是无状态，服务器不需要存Session，天然适合前后端分离和水平扩展。但用JWT有几个细节要注意：Token要设置过期时间，我设置的是24小时；密钥不要硬编码在代码里，放到application.yml配置文件中；校验Token失败的统一返回401状态码，前端拦截路由跳回登录页。这些细节写进论文“系统安全设计”章节，又是一个加分项。

4.3 资产CRUD与条件查询

资产管理的核心是资产的增删改查，但“查”不能只是list一下全部数据，必须具备条件组合查询。我实现了一个“资产综合查询”接口，支持按资产编号、资产名称（模糊匹配）、分类、部门、使用人、状态、购入时间范围等多个条件任意组合筛选，底层用MyBatis-Plus的QueryWrapper动态拼条件。

这里有个实战经验值得分享：MyBatis-Plus里字符串类型的条件要用StringUtils.hasText()来判断是否传参，不要直接等于空字符串或者null，否则会出现“传了空字符串查不出数据”的坑。分页查询我用的MyBatis-Plus内置的分页插件，传入当前页码和每页条数，返回总记录数、总页数、当前页数据。分页这个功能看起来简单，但它是管理系统的标配，列表页数据量大时不可能一次性全部查出，必须分页，这个思路要清晰。

4.4 资产借用审批流程

借用审批是系统里唯一带点“流程”色彩的模块，也是答辩时老师最喜欢深挖的地方。我的实现方式是创建一个资产借用主表，记录借用单号、申请人、申请时间、期望归还时间、借用理由、审批状态、审批人、审批意见。审批状态我用四个值：0待审批、1已同意、2已驳回、3已归还。每次审批操作都去更新这个状态，并在备注字段留下审批意见。

审批的关键在于数据一致性。同意借用时要同时做两件事：更新借用单状态为“已同意”、更新资产信息的当前状态为“已借用”。这两步操作必须放在同一个事务里，任何一步失败都要整体回滚。代码层面实现很简单，Service方法上标注@Transactional注解即可，但背后“为什么需要事务”这个问题的答案你要能答出来。我特意在论文里用了一个小节讲事务在这里的作用，这也是系统“可靠性”的一个体现。

4.5 统计报表与数据导出

报表模块我用的是ECharts，前端异步获取统计接口返回的数据后渲染图表。后端主要提供三类统计接口：资产总数与总值统计、资产分类分布统计、各部门资产数量统计。这三个接口都是MySQL聚合查询，用GROUP BY+COUNT/SUM就能实现。

数据导出做成Excel也很重要，很多企业用户有导出台账的需求。我用的方案是Apache POI，写一个工具类，把查询结果集逐行写入Workbook，设置响应头为application/vnd.openxmlformats-officedocument.spreadsheetml.sheet，前端用window.open或axios的blob方式触发下载。POI的写法比较繁琐，但胜在稳定和可控，而且这个功能在答辩演示时非常抢眼——你点一下“导出Excel”，表格数据刷刷地变成了文件，老师会觉得你的系统“有真实落地感”。

5. 前端Vue实现与页面打磨

5.1 技术栈与工程结构

前端我使用的是Vue 2.6 + Element UI 2.15的组合，配套Vue Router管理路由、Vuex管理全局状态、Axios发起HTTP请求、ECharts渲染图表。为什么不用Vue 3和Element Plus？因为Vue 2的生态资料太丰富了，你遇到的问题99%都能搜到现成的解决方案，对毕设场景来说，稳定可复现比版本新更重要。如果你时间充裕、想在新项目里积累Vue 3经验，也可以切换到Vue 3 + Element Plus + Pinia，思路完全一样，只是API写法略有不同。

工程结构上我用Vue CLI创建项目，按模块划分目录：api目录按业务模块拆分接口请求文件，router目录配置路由表，views目录放页面组件，components目录放公共组件，utils目录放工具函数（如request.js封装Axios实例），store目录放Vuex状态管理。这套目录结构是目前中后台项目的主流做法，面试问到“你的前端工程化怎么做的”，你可以照这个结构讲。

5.2 路由与权限控制

前端路由分成两类：公开路由和权限路由。公开路由只有登录页和404页。权限路由是根据当前登录用户的角色动态生成的：用户登录成功后，后端返回他的角色和对应的菜单权限，前端根据这些数据调用router.addRoutes动态挂载路由表。

这个方案做下来，不同的角色登录后看到的菜单是不一样的。普通员工看不到“用户管理”，管理员能看到全部菜单。这里要特别强调：前端隐藏菜单只是锦上添花，真正的权限控制必须放在后端接口层，否则别人直接调接口一样能拿到数据。我在请求拦截器里统一处理了401状态码，Token过期后自动清除本地登录信息并跳回登录页，保证整个流程是闭环的。

5.3 核心页面与组件设计

前端页面的设计要抓住管理系统的核心范式：“左侧菜单+顶部导航+中间内容区”的经典布局。内容区里用得最多的是三件套：表格、表单弹窗、分页。

资产列表页是最核心的页面，我用了Element UI的el-table展示台账数据，列包括资产编号、名称、分类、价格、状态、所属部门、存放位置、操作按钮。顶部是筛选区域，包含资产名称输入框、分类下拉框、状态下拉框、查询/重置按钮。新增和编辑共用一个el-dialog表单弹窗，通过控制一个dialogVisible变量来切换，提高了代码复用。状态列用el-tag渲染不同颜色，在库绿色、已借用橙色、维修中红色、已报废灰色，一眼就能看清资产状态全貌。借用申请页则突出流程引导，把资产信息、申请人、借用时间、归还时间、借用理由整合在同一个表单里，提交后跳到“我的借用”页面查看审批进度。

5.4 前端体验优化细节

页面做完仅仅是开始，真正拉开差距的是细节。我做前端体验优化时关注了几个点：所有表单项要加必填校验和正则校验，比如手机号、金额、日期格式，提交前拦截，减少后端报错；操作按钮要有Loading状态和二次确认弹窗，比如删除资产必须弹窗让用户确认“确定删除该资产吗？”，防止误操作；列表数据为空时不能干巴巴地展示空白表格，要有一个空格子图和一句提示文案；接口请求的全局Loading进度条用NProgress插件实现，顶部显示蓝色进度条，页面切换不再显得“卡死了”。

这些细节看起来不起眼，但老师演示系统的时候，操作的每一步都要有反馈，他就觉得这个系统“完成度很高”。答辩展示和真实产品之间差的往往不是技术，就是这些细致入微的体验处理。

6. 本地部署与线上发布全流程

6.1 环境准备

要跑起来这套系统，你需要准备的环境如下：JDK 1.8、Maven 3.6+、MySQL 5.7或8.0、Node.js 14+（npm随附）。后端开发工具用IDEA（社区版就行），前端开发工具用VSCode，数据库管理工具用Navicat或者MySQL Workbench，接口调试工具用Postman或Apifox。这些工具都是这个领域的主流，你安装配置过程中遇到任何问题，网上都有大量解决方案。

我特别想提醒一个环境问题：MySQL 8.0和MySQL 5.7在驱动配置上有差异。8.0的驱动类是com.mysql.cj.jdbc.Driver，URL需要指定serverTimezone=Asia/Shanghai，否则可能报时区错误；5.7的驱动类是com.mysql.jdbc.Driver。如果你的数据库是8.0，但照着5.7的教程配，大概率连不上。我见过太多同学栽在这个问题上，所以特意在这里标出来。

6.2 打包构建与部署上线

本地跑通只是第一步，完整的部署流程是：后端用Maven的package命令打成可执行的jar包，把jar包上传到服务器（或让老师在本地直接运行）；前端用npm run build进行生产构建，生成dist静态资源目录。传统方式是把dist目录里的文件拷贝到Nginx的html目录下，然后配置Nginx反向代理：前端静态资源由Nginx直接返回，接口请求/api前缀的路径代理转发到后端的localhost:8080，同时配置proxy_set_header传递Host和IP信息。

Nginx的关键配置我摘出来给你参考：

server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html index.htm; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

try_files $uri $uri/ /index.html这个配置非常关键，它处理了Vue Router的History模式刷新404问题。不加这行，你在页面里点击跳转没问题，但按F5刷新就直接白屏，这个问题在毕设里特别常见。

6.3 部署文档的写法与思路

部署文档我按“环境准备-数据库初始化-后端启动-前端启动-访问验证”五个步骤来组织。每一步都给出精确的指令和预期结果，比如“执行java -jar asset-manage-1.0.0.jar后，看到Started Application in x.xxx seconds字样，说明后端启动成功”。预期结果非常关键，它让操作者能自我验证步骤是否完成，而不是卡在一个步骤不知道该不该往下走。

为什么要花这么大篇幅写部署？因为老师拿到你的压缩包之后，第一件事肯定是尝试跑起来。如果他花了一个小时还跑不起来，对你的印象分就崩了。反过来说，老师二十分钟就跑通了系统，你的演示环节就有一个充足的时间展示功能。这比论文里花团锦簇的文字更能打动人心。

7. 常见问题与排查技巧实录

7.1 前后端跨域问题

跨域是前后端分离项目的第一个拦路虎。现象是前端能打开页面，但请求接口时浏览器控制台报错No 'Access-Control-Allow-Origin' header is present。解决方案有两个层面：后端写一个CorsConfig配置类，注册CorsFilter，允许指定来源跨域请求；或者在前端开发环境配Vue CLI的devServer代理，把/api开头的请求代理到后端地址，这样开发环境就没有跨域问题了。

我建议的做法是两个都配上，开发时用前端代理，部署时用Nginx代理，上线后后端CorsConfig也要保留，防止有单独请求后端接口的场景。跨域的底层原理是浏览器的同源策略，服务端之间的请求其实不存在跨域限制，这个点答辩时讲出来，老师会觉得底层原理你是懂的。

7.2 数据库连接失败与编码问题

数据库连不上是最常见的启动失败原因，排查顺序如下：先确认MySQL服务是否启动；再确认用户名密码是否正确；然后确认URL写的是否正确，尤其是端口号，MySQL默认3306，但有些人的机器上装过其他服务，端口会被改掉；最后确认jar包里的驱动版本和数据库版本是否匹配。

另一个高发问题是中文乱码。我处理的方法是：建库时指定编码CREATE DATABASE asset_db DEFAULT CHARACTER SET utf8mb4;，连接URL里加useUnicode=true&characterEncoding=utf8，SpringBoot里配置spring.http.encoding.force=true。三层都锁死UTF-8，乱码问题基本就绝迹了。特别说明一下为什么用utf8mb4而不是utf8，因为utf8在MySQL里最多存3个字节，而生僻字和Emoji需要4个字节，utf8mb4是utf8的超集，是当前最稳妥的选择。

7.3 前端打包后页面空白的问题

这是一个极其常见的问题：本地用npm run serve跑得好好的，一打包部署到服务器，打开页面就是白屏。背后的原因有几种：第一，publicPath路径配置错了，默认是/，但你的静态资源放在服务器的子目录下，访问不到；解决办法是在vue.config.js里把publicPath改成相对路径./。第二，路由模式用了History模式，但服务器没有配置try_files回退到index.html；解决办法要么用Hash模式，要么像前面那样配Nginx的try_files。第三，静态资源文件加载404，检查Nginx的root路径是否真能对应到dist目录。

我排查这类问题时有一个习惯：先按F12打开浏览器控制台，看Network标签页里到底是哪个请求返回了404。一张白屏，背后至少有三层问题，找到具体是哪个URL失效了，就找到了问题的七寸。

7.4 时间日期显示与格式化问题

管理系统里到处是时间字段：创建时间、借用时间、归还时间、维修时间。后端从数据库查出来是java.time.LocalDateTime对象，序列化成JSON给前端时，默认格式是一长串带T的ISO字符串，比如2025-06-01T10:30:00，用户体验极差。解决办法是在application.yml里配置Jackson的全局日期格式：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

这样后端返回的时间就统一变成了2025-06-01 10:30:00的格式。前端再用el-date-picker做日期选择器，配合value-format="yyyy-MM-dd HH:mm:ss"属性，前后端的时间格式就能完全对齐，不会出现在表单里选完日期提交后变成NaN的情况。

7.5 项目中容易忽略的暗坑汇总

我用一张表把容易踩的坑汇总一下，全是真实项目里炸过的雷：

每次排查完一个坑，我都建议顺手在部署文档里补一笔，这叫“吃一堑长一智”。你交付给别人的文档如果是踩过坑之后写出来的，含金量会明显不一样。

以后再做类似的管理系统，你可以在这套底座上继续扩展，比如加一个资产盘点模块，扫二维码批量盘点；或者接一个企业微信通知，审批消息实时推送到手机端；也可以把报表模块升级成多维度分析，用更复杂的SQL和ECharts做出更炫酷的驾驶舱。好的毕设不是做得多花哨，而是链路完整、逻辑清晰、还能经得住追问。我个人在实际操作里最大的体会是：这套系统做完之后，再去看看SpringBoot的自动配置源码、Vue的响应式原理、MySQL的索引优化，会有一种“哦，原来这里当时是这么回事”的通透感。这大概就是把一个项目做扎实最大的回报了。