企业官网建设流程全解析

先说个大多数做过毕设的人都认可的结论：Java + Spring Boot + Vue，是当前计算机毕业设计里最稳的一套技术组合。你拿这套组合去做一个交通安全知识学习平台，本质上就是在做一个前后端分离的内容管理系统加在线答题系统，涉及用户注册登录、知识内容展示、分类检索、在线测试、学习记录管理、后台数据维护这些经典功能模块。如果你正在找一套结构完整、能跑通、能写文档、能答辩的参考项目，这一类的源码和开发思路非常值得认真拆一遍。我这篇文章就从一个实际带过不少毕设项目、也独立开发过多个同类系统的开发者角度，把这个项目的设计思路、核心实现、部署细节、常见坑全部捋一遍，希望对正在做毕业设计或者刚接触前后端分离开发的同学有实质帮助。

1. 项目整体思路与核心模块拆解

1.1 为什么是 Spring Boot + Vue 这套组合

先聊一个可能很多人心里都有的问题：市面上的毕设技术方案那么多，为什么偏偏 Spring Boot + Vue 这么流行？答案说穿了就是一个词：省心。

Spring Boot 最核心的价值是简化了传统 SSM 项目里大量繁琐的 XML 配置，它默认内嵌了 Tomcat 容器，JDK 装好之后，一条java -jar命令就能把后端跑起来。对于毕设场景来说，最怕的不是功能有多难，而是“环境配了三天还没跑起来”。Spring Boot 把这种不确定性降到了最低，几乎可以保证“代码到手就能启动”。

Vue 这边则是前端框架里上手门槛相对平滑的一个。它用组件化的方式组织页面，你可以把一个后台管理页面拆成“表格组件、搜索栏组件、弹窗表单组件、分页组件”，每个部分单独开发和维护。配合 Element UI 这类现成的 UI 组件库，很多页面根本不需要从零写 CSS，直接拿组件拼装就行。

再说项目本身。交通安全知识学习平台属于典型的业务系统，核心价值在于“内容管理”和“在线练习”。这类系统用前后端分离架构非常合适：后端专门提供数据接口，前端负责页面展示和交互动效。你选择一个角色登录系统，用户端看到的是知识浏览和在线答题页面，管理员端看到的是用户管理、分类管理、题库管理这些维护界面。两边数据是同一套数据库，但展示和使用方式完全不同，做完以后功能层次非常清晰，写论文的时候也好分章节描述。

如果用一句生活化的类比来理解：Spring Boot 相当于一个已经备好菜、甚至帮你把灶台都架好的预制菜包，你只需要按说明烧热油下锅就行；Vue 则是可以反复拆装的乐高积木，每个页面都是一块积木，搞清楚了怎么拼，做大系统和小系统只是拼的块数不同。

1.2 系统角色与功能模块划分

交通安全知识学习平台从使用方来看，至少要拆成两个角色：普通用户（也就是学习者和答题者）和管理员。角色划分不是随便定的，它决定了整个系统的权限边界和数据流转方式。

用户端要解决的痛点是“用户不知道学什么、学了没记录、考试没反馈”。所以核心功能应该包含：注册登录、浏览交通安全知识、按照分类筛选内容、参加在线安全知识答题、查看答题成绩、查看个人学习记录和统计图表。管理员端要解决的痛点是“内容怎么维护、用户怎么管理、答题情况怎么掌握”。对应功能包括：知识内容的新增编辑删除、分类维护、题目维护、用户列表管理、答题记录查看、整体数据统计。

我习惯把功能整理成一张模块表，写文档和开发的时候都对着这张表来：

这样的功能划分有几个好处：第一，每个模块都有明确的前端页面和后端接口对应，开发时不容易漏功能；第二，数据上形成了“用户—内容—行为—统计”的完整闭环，后端Service层不会出现“光有接口没业务逻辑”的空壳；第三，答辩的时候能清楚讲出“系统有多少角色、每个角色能做什么、数据是怎么流动的”，这是评委最关心的东西。

1.3 数据库设计是项目的命根子

很多同学一上来就着急写代码，结果写到一半发现表结构不合理，又要回头改数据库，改完接口跟着改，前端再跟着改，费了双倍时间。我自己的习惯是：启动项目之前，先花半天时间把表结构定下来，这是一个性价比极高的投入。

交通安全知识学习平台的核心表大概有这几张：

• 用户表：存储账号、密码、昵称、头像、角色、状态、创建时间。
• 分类表：存储知识分类，比如交通标志、驾驶安全、行人出行、法律法规、事故案例。
• 知识内容表：存储标题、封面图、所属分类、正文内容、浏览量、发布时间。
• 题目表：存储题干、选项A/B/C/D、正确答案、题目类型（单选、判断）、所属分类。
• 答题记录表：存储某次答题的整体信息，包括用户ID、总题数、答对题数、得分、答题时间。
• 答题明细表：存储每次答题中用户对于每一道题的选择和判断结果，用来做错题回看和数据分析。

为什么要单独拆答题记录和答题明细两张表？这个要重点说明一下。如果只设计一张答题表，把用户选的答案直接拼成一个字符串存进去，看起来省事，但后续想做“查看每次考试每道题的对错”“统计哪个知识点错得多”就非常费劲，SQL和Java代码都会变得很别扭。拆成两张表后，一次考试对应一条记录，一条记录对应多行明细，这就是典型的父子表结构，既符合数据库范式，又方便统计。

用户表、知识表、题目表本身通过逻辑外键关联，比如内容表存一个category_id，查询的时候和分类表做连表查询；答题明细表存question_id和record_id，回看时可以通过这两个字段拼出完整上下文。表设计的核心原则就一句话：别过度设计，但要保证每个功能模块的数据都有地方放，并且放得有层次。交通安全这个主题本身有天然的业务边界，比如“知识点分类”和“题库分类”可以复用同一套分类逻辑，但答题记录和学习记录必须独立，这两块是用户行为数据，和静态内容不能混在一起。

2. 后端核心功能实现细节

2.1 Spring Boot 项目初始化与分层

初始化一个 Spring Boot 项目，最直接的方式是去 Spring Initializr 网站生成一个基础工程，或者直接用 IDEA 的脚手架创建。项目名建议用traffic-safety-platform这种能看懂的名字，包名按com.example.traffic来组织，避免出现包名和项目不匹配的尴尬情况。

依赖选择上，基础必备的有这几个：Spring Web 提供 MVC 能力；MyBatis Plus 负责数据库操作；MySQL Driver 连接 MySQL；Lombok 简化实体类代码。如果涉及登录鉴权，可以引入 JWT 相关依赖；如果想让接口文档更规范，可以加上 Knife4j 或者 SpringDoc。不需要一上来把所有依赖都加齐，需要什么加什么，这样项目结构才清爽。

包结构建议这样分：controller放接口入口，service放业务逻辑，mapper放数据库操作，entity放数据库实体类，dto放前端传参对象，vo放返回给前端的视图对象，config放配置类，common放统一返回结果、异常处理、工具类。很多同学把所有代码堆在几个类里，一个 Controller 写几百行，看着项目文件少，真正排查问题的时候特别痛苦。分层的目的不是为了显得专业，而是为了把“接参数、写逻辑、查数据”三件事分离开，哪一层出了问题就去哪一层找。

实体类字段和数据库字段要用 MyBatis Plus 的注解对应好。比如：

@Data @TableName("knowledge") public class Knowledge { @TableId(type = IdType.AUTO) private Integer id; private String title; private String cover; private Integer categoryId; private String content; private Integer viewCount; private Date createTime; }

这样写的好处是，Mapper 里通过 MyBatis Plus 自带的selectById、selectPage、selectList就可以完成大部分单表操作，不需要手写 XML。遇到复杂的多表关联查询，再单独写一个<select>标签，方便灵活组合条件。

2.2 用户登录鉴权的两种常用方案

用户登录是所有业务系统的第一道门。这个项目涉及两个角色，登录后系统必须知道当前请求来自谁、是什么角色，才能决定允许访问哪些接口。

最常用的方案有两种，一种是 JWT，一种是用 Session + 拦截器。JWT 的思路是：用户登录成功后，后端把用户ID、角色、过期时间等信息加密生成一个 token 字符串返回给前端，前端把它存在 localStorage 里，之后每次请求在请求头里带上Authorization: Bearer <token>。后端写一个拦截器，每次收到请求先解析 token，解析成功就放行，并把用户信息放入请求上下文。

Session 方案则是登录成功后把用户信息放进服务端的 Session 对象，同时给浏览器种一个 Cookie，后续请求靠 Cookie 里的 SessionID 找回用户信息。前后端分离项目用 Session 需要额外处理跨域携带 Cookie 的问题，相对麻烦一些。所以我更推荐 JWT，它无状态、易扩展、跨域友好。

两种方案的对比可以整理成一张表：

登录密码一定不能明文存储。哪怕这是一个课程设计，也至少要使用 BCrypt 这类加盐哈希算法处理密码。Spring Security 自带的BCryptPasswordEncoder可以直接用，注册时加密存储，登录时用matches方法校验。这一步虽然小，但答辩时被问到“你的系统安全吗”，至少能有话可说。

2.3 题库与答题判分的实现思路

题库模块是这个项目的业务核心之一，设计好了能体现不少工作量。题目表需要支持两种常见题型：单选题和判断题。单选题有四个选项和一个正确选项，判断题本质上也可以看成两个选项的单选题，所以共用一张表完全够用。字段建议这样设计：question_text存题干，option_a、option_b、option_c、option_d存选项，correct_answer存正确选项字母或“正确/错误”标识，question_type区分单选和判断，category_id表示题目所属分类。

在线考试的流程可以拆成两段：开始考试时，后端按分类和数量随机抽取题目返回给前端；提交答卷时，前端把“题目ID + 用户所选答案”组成的列表提交给后端，后端逐题比对正确答案，算出总得分和答对题数，然后把答题记录和答题明细一起写入数据库。

这里有一个所有新手都会踩的坑：随机抽题到底怎么实现？如果在表中加一个“随机数”字段再查询，逻辑会绕很多。简单实用的做法是使用 MySQL 的ORDER BY RAND()随机排序后取指定条数：

SELECT * FROM question WHERE category_id = ? ORDER BY RAND() LIMIT 10

这种写法对数据量几百条到几千条的系统完全够用，性能不会有肉眼可见的问题。不要为了炫技去写复杂的算法。

判分逻辑写起来也不复杂，但必须注意事务控制。一次提交中，不仅要写答题记录主表，还要插入多条答题明细，并在每道题上做逻辑判断。这两个步骤要么都成功，要么都失败，不能出现“主表写入成功，明细表写入失败”这种半截数据。解决办法就是在 Service 方法上加@Transactional注解，让整个提交操作处于同一个数据库事务中。

@Transactional public SubmitResult submitExam(ExamSubmitDTO dto) { ExamRecord record = new ExamRecord(); record.setUserId(dto.getUserId()); // 计算得分逻辑 for (QuestionAnswer answer : dto.getAnswers()) { Question q = questionMapper.selectById(answer.getQuestionId()); boolean isCorrect = q.getCorrectAnswer().equals(answer.getUserAnswer()); // 插入明细 ExamDetail detail = new ExamDetail(); detail.setCorrect(isCorrect ? 1 : 0); examDetailMapper.insert(detail); } examRecordMapper.insert(record); return result; }

2.4 学习记录与统计报表接口设计

知识浏览和学习记录这一块，数据流比答题简单，但接口设计上要提前想清楚。用户进入知识详情页，应该产生一条浏览记录；用户开始学习后，前端每隔一段时间向后端上报学习时长；个人中心展示累计学习时长、答题次数、平均正确率等指标。

统计报表接口最关键的坑在于日期处理。很多同学Excel、ECharts都能做，但一到按天统计就写出特别奇怪的SQL。其实最常用的就是GROUP BY结合日期函数，比如统计最近7天每天的学习时长：

SELECT DATE(study_date) AS day, SUM(duration_minutes) AS total_minutes FROM study_record WHERE user_id = ? AND study_date >= DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(study_date) ORDER BY day

这里提醒一下：MySQL 的DATE()函数会把2025-01-01 08:30:00截断成2025-01-01，配合GROUP BY就能实现按天聚合。如果你的数据库存的是 datetime，直接在 Java 里格式化再分类统计会很慢，能交给 SQL 做的就交给 SQL 做。

接口返回格式统一也很有必要。我会在common包下定义一个Result<T>类，包含code、message、data三个字段，控制器所有方法都返回这个包装对象。这样前端 axios 拦截器只用解析一套格式，处理错误和成功的逻辑就可以写在同一个地方。还有一个细节，统计数据会涉及多个数值指标，比如用户总数、知识总数、答题总数、今日活跃人数，这种聚合查询建议单独建一个StatisticsVO来承载，而不是用 Map 到处拼，Map 写起来快，后面维护的时候字段名一拼错就麻烦了。

3. 前端页面搭建与交互实现

3.1 Vue 项目结构与路由设计

前端我建议直接使用 Vite 作为构建工具创建 Vue 3 项目。Vue 3 的 Composition API 配合<script setup>写起来比 Options API 更简洁，而且开发时的热更新速度明显比 Webpack 快，调试体验好很多。

工程目录大致这样组织：src/views放页面级组件，src/components放可复用组件，src/api放接口请求封装，src/router放路由配置，src/utils放 axios 实例和工具函数。页面和接口拆分清楚后，开发和排查都很快。

路由设计要跟角色对应。首页是知识广场，展示分类和知识卡片；知识详情页按 ID 接收参数；在线答题页需要登录才能访问；个人中心页展示学习记录和成绩；管理员相关的页面统一放在/admin路径下。路由守卫是一个必须实现的功能，未登录用户访问个人中心和答题页时，直接跳转到登录页：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.meta.requiresAuth && !token) { next('/login') } else { next() } })

3.2 用户端核心页面要点

用户端是系统的“门面”，页面做得好不好直接影响演示效果和整体评分。首页建议由几个区域组成：顶部导航栏放系统名称、菜单和用户信息；中间放一个轮播图区域，展示交通安全宣传图片；下方按分类展示热门知识卡片。首页的数据来源是后端提供的轮播图接口和热门知识接口，不需要太复杂，重点是布局整洁。

知识列表页要做好分类筛选。左侧或顶部展示分类菜单，中间是按分类过滤后的知识卡片列表，卡片上放封面图、标题、简介、浏览量和发布时间。点击卡片跳转到详情页。详情页使用v-html渲染富文本内容。这里要特别提醒：后端返回的正文如果是 HTML 片段，前端用v-html渲染没问题，但千万不要用v-html渲染用户输入的原始内容而不做清洗，不然会有 XSS 安全风险。毕设阶段至少要做到后端保存内容时过滤掉危险标签。

在线答题页是交互最复杂的部分。它需要做到：显示剩余时间倒计时，一次只显示一道题，选中答案后可以切换到下一题，支持修改答案，交卷前再次确认。倒计时可以用setInterval实现，交卷时把remainingTime一并提交到后端。时间到了自动交卷的逻辑也要写，避免用户停在页面不动导致考试永远不会结束。

3.3 管理端 CRUD 页面的通用套路

管理端看起来页面多，但仔细分析会发现，所有的管理页面都逃不出同一个套路：表格展示 + 分页 + 搜索 + 新增/编辑弹窗 + 删除确认。我强烈建议你自己封装一个TablePage组件，把分页逻辑和加载状态统一处理，后续做每个管理页面时只需要传入表格列配置、接口函数和表单字段配置，能省下大量重复劳动。

以分类管理为例，页面逻辑是这样的：进入页面后调用分类分页接口，拿到records填充表格；点击新增按钮弹出空表单；点击编辑按钮弹出已填入当前数据的表单；提交时根据是否有 ID 决定调用新增还是更新接口；删除操作要弹出确认框，防止误操作。如果分类下已经有知识内容，删除时必须有提示，要么禁止删除，要么把关联的内容一起处理，不然会出现前台页面出现“空白分类”的脏数据。

题库管理的重点在于表单字段较多。题目新增页面至少要包含：题目类型选择、题干输入、四个选项输入、正确选项选择、所属分类选择。用el-form的校验规则可以保证表单必填项完整，比如题干和正确答案不能为空。这里建议设计一个“预览答题效果”的按钮，在保存前先按照当前题型在弹窗里模拟一下选项样式，体验一下就知道了。

3.4 前后端联调与跨域问题处理

前后端分离项目只要一联调，跨域问题是绕不开的。跨域的本质是浏览器的同源策略：当页面运行在http://localhost:5173，请求后端http://localhost:8080时，协议、域名、端口不完全一致，浏览器就会拦截响应。解决方式最常用的是配置开发代理，这可以完全不修改后端代码。

Vite 的vite.config.js里通过 proxy 把/api前缀的请求转发到后端：

server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

后端接口路径统一以/api开头，前端请求http://localhost:5173/api/user/login，代理会自动转发到http://localhost:8080/api/user/login，这样浏览器看到的请求是同源的，跨域问题自然就消失了。前端 axios 实例也建议统一配置：

const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = 'Bearer ' + token } return config }) request.interceptors.response.use(res => { if (res.data.code === 401) { router.push('/login') } return res.data })

这个拦截器解决了两件重要的事：一是所有请求自动带上登录 token，不用每个接口手写一遍请求头；二是后端返回登录失效状态时统一跳转登录页，不会让页面一直停留在“伪登录”状态。

4. 项目打包部署与文档整理

4.1 后端打包部署流程

项目开发完成后，给评委演示的机器不可能是开发者的电脑，所以必须掌握打包部署。后端打包很简单，在项目根目录执行：

mvn clean package -DskipTests

执行完成后target目录下会生成一个xxx.jar文件，这就是可以直接运行的产物。如果本地装了多个 JDK 版本要注意pom.xml里的<java.version>配置和实际环境的 JDK 版本保持一致，否则打出来的包可能因为编译级别问题在服务器上报错。

服务器部署前，需要确认三件套：JDK、MySQL、可选 Redis。将这些环境装好后修改application.yml中的数据库连接信息，把localhost改成服务器地址，用户名和密码改成服务器数据库的实际账号，然后上传 jar 包执行：

nohup java -jar traffic-safety-platform.jar --spring.profiles.active=prod > app.log 2>&1 &

生产环境连接数据库时，推荐在 URL 上追加时区参数serverTimezone=Asia/Shanghai，避免数据库时间字段与本地时间出现八小时差。

4.2 前端构建与 Nginx 配置

前端构建更直接，进入前端工程目录执行npm run build，几分钟后生成dist目录，这就是需要部署到服务器的静态文件。如果直接把dist里的文件丢到服务器上用浏览器打开index.html，会发现页面白屏、路由404，因为前端项目使用了 HTML5 History 模式路由。解决方案是使用 Nginx 配置将所有未匹配路径都重写到index.html：

server { listen 80; server_name your-domain.com; root /usr/share/nginx/html/dist; index index.html; location / { 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_pass地址后面是否带斜杠的问题，带不带/会导致转发路径拼接方式不同，实践中最稳妥的写法是后端接口全部带/api前缀，Nginx 里直接把/api/整个转发给后端服务，后端 Controller 里的映射路径依然带/api，配置最不容易出错。

前端构建的另一个高频坑是接口地址写死。如果前端代码里直接把baseURL写成http://localhost:8080，部署到服务器后页面还在请求本地地址，必然报错。正确做法是用环境变量区分开发和生产环境，在.env.production里配置：

VITE_API_BASE_URL=/api

打包后所有接口请求走相对路径，再由 Nginx 代理到后端服务，这样前端工程部署到哪里都不需要改代码。

4.3 LW 文档写作重点与答辩思路

标题里提到的 LW，对应到实际项目就是毕业设计文档或者论文。这一块是很多同学的痛点，但其实只要掌握了写作框架，内容填充起来比写代码还快。标准结构大致是：绪论（背景、意义、国内外现状）、需求分析（功能性需求、非功能性需求、用例图）、系统设计（总体架构、功能模块设计、数据库设计）、系统实现（每个模块的界面截图和关键代码说明）、系统测试（测试用例、测试结果）、总结与展望。

需求分析里一定要画用例图。用户有哪些操作、管理员有哪些操作，用一张图就能清清楚楚展示。系统设计阶段要至少有三张图：系统架构图、功能结构图、E-R图。数据库设计部分不要只贴建表语句，还要解释表之间的关系，比如答题记录和答题明细为什么是一对多。

答辩被问到最多的三个问题，提前准备：第一个是“项目的难点在哪里”，不要回答“登录”，要回答“在线答题的判分与事务控制”“数据统计接口的多表关联查询”“前后端分离跨域处理”，这些才是真实的业务难点。第二个是“如果同时有一千个人答题，你的系统会有什么问题”，这个要从数据库连接池线程数、SQL效率、程序复杂度三个角度简要回答。第三个是“某个表为什么这么设计”，只要能说清楚字段用途和表关系，就不会被难住。

文档写作有一个必须守住的底线：文档内容必须和代码行为一致。表结构不一样、功能描述超过实际实现、文档截图不是同一版系统，这些是最容易在答辩时被当场拆穿的硬伤。我见过太多同学代码写得很完整，结果文档里还写着“系统没有管理员模块”，这种低级错误对最终评分的影响极大。

4.4 演示视频录制建议

演示视频的目的不是展示录制技巧，而是让评委在最短时间内看到系统的完整功能和质量。录制前建议整理一份演示脚本，按顺序走：系统启动说明、用户注册登录、浏览首页知识、按分类查看知识详情、参加在线答题并提交、查看成绩记录、切换管理员账号登录、管理分类、管理知识内容、管理题库、查看数据统计。

录制时有两个注意事项。第一，画面要清晰，至少 1080p，鼠标点击时不要过快，给观看者留出理解时间。第二，讲步骤要跟上操作，比如“现在点击登录，输入用户名和密码，登录成功后进入首页”，一句一句说清楚每个操作在做什么。视频里可以适当展示数据库的变化，比如新增一条分类后，打开 Navicat 看一眼分类表里多了一行数据，这个画面能让评委直观感受到前后端是真实打通的，比嘴上说十句都管用。

5. 实战常见问题与避坑记录

5.1 高频报错速查表

做项目过程中遇到的报错，九成都是重复出现的。把每次排查的经验沉淀成一张速查表，对后续开发帮助极大。

5.2 代码层面容易忽略的细节

第一个容易忽略的是后端接口的入参校验。前端已经做了表单必填校验，但后端接口如果完全不做校验，万一有人绕过前端直接发请求，就可能往数据库写入脏数据。建议用@Valid结合实体类字段上的@NotBlank、@NotNull注解做基础校验，不复杂但能挡住大部分异常请求。

第二个容易忽略的是删除操作的数据安全。删除分类之前必须判断该分类下是否有知识内容；删除用户之前要考虑他的答题记录怎么处理。最简单稳妥的方案是逻辑删除，给表加deleted字段，查询的时候默认只查未删除记录，这样数据不会真正丢失，答辩时也可以说是“为了保证数据完整性和可追溯性”。

第三个容易忽略的是前后端时间格式不统一。后端返回 LocalDateTime 默认序列化结果是2025-06-01T10:30:00，前端展示出来不好看。解决方案是配置全局 Jackson 时间格式化，统一成yyyy-MM-dd HH:mm:ss；前端如果需要显示更具体的格式，再交给 dayjs 等工具处理。

5.3 时间规划与工作量评估

毕业设计到最后最缺的往往不是技术能力，而是时间。很多同学前期纠结选型，中期卡在环境，后期熬夜录视频，最终质量自然受影响。我建议按一周规划来分配精力：第一天搭环境和拉通登录注册，第二天完成后端分类和知识内容模块，第三天完成后端题库和答题接口，第四天做用户端页面，第五天做管理端页面，第六天联调并修复问题，第七天录制视频和整理文档。这个节奏对大多数同类项目都适用。

工作量评估上，我始终建议“功能完整优先于功能花哨”。一个能稳定跑通、逻辑闭环、界面干净的系统，远比一个做了十几个模块但有三个模块是半成品要强。交通安全知识学习平台最重要的核心链路就是“用户登录—看知识—做题—看结果—管理员维护—统计查看”，把这条链路打磨好了，这个毕设就已经成功了八成了。

我个人在实际做这类项目时还有一个习惯：每完成一个接口，就顺手整理一份接口清单，包含路径、请求方式、请求参数和返回结果。这份清单在联调时可以帮助快速定位问题，在写 LW 文档时可以直接用，在答辩前也可以当复习提纲。养成这个习惯之后，你会发现毕业设计整个过程会顺畅很多。