企业官网建设流程全解析

先说我做过几个类似的毕设辅导项目，看到这个题目第一反应是：选题方向是对的，但很多人交出来的东西，要么堆了一堆增删改查页面，要么科普文章嵌入得特别生硬，答辩时被老师一问业务逻辑就卡壳。这个濒危动物保护管理系统，表面看是个常规SpringBoot项目，实际上它同时踩了内容管理、公益众筹、权限控制、数据可视化这几条线，做得好不好，差别非常大。

这篇文章我按一个可答辩、可运行、可往简历上写的标准来拆解，从需求分析、数据库建模到支付沙箱对接、部署打包，把每一层的思路和坑都交代清楚。代码基于SpringBoot 2.7 + MyBatis-Plus + Vue 3这套主流组合，内容尽量贴近你真正写代码时的顺序，而不是教科书式地给你贴一堆配置。

1. 为什么选这个题目：不只为了凑一个“管理系统”

很多计算机毕设选题犯的毛病是“大而空”，比如“智慧校园系统”“企业办公自动化”，范围大到一个人做不完，最后只能拿假数据和空页面糊弄。濒危动物保护管理系统这个题目好就好在，它看着小，但用户角色清晰，业务闭环完整，技术点覆盖足够，又是一个有社会意义的领域，答辩时容易讲出亮点。

1.1 从题目拆出三条核心业务线

拿到题目不要着急写代码，先把它拆成几条独立的业务线，后面的开发才不会乱。

第一条线是科普内容线。系统需要对公众展示濒危物种的档案，包括物种名称、保护等级、分布区域、种群数量、形态特征、栖息地信息等，同时要有科普文章模块，方便运营人员发布专题内容。这条线考查的是内容管理系统的常见套路：分类、标签、富文本上传、分页检索。

第二条线是捐助业务线。公众浏览物种档案后，可以对特定保护项目发起捐助，生成捐助订单，对接支付沙箱完成模拟支付，支付成功后生成捐助凭证，后台能看到捐助流水和汇总统计。这条线是整个项目最值钱的业务部分，它把一个普通CRUD系统拉高到了“有真实业务模型”的层面。

第三条线是后台管理线。管理员要能维护物种档案、审核科普文章、查看捐助订单、管理用户状态、导出统计报表。这条线考查的是权限控制和后台功能划分，也是答辩时最容易讲清楚“我做了哪些工作”的部分。

1.2 目标用户与用例清单

从用户角色分析，这个系统至少有三类角色：普通游客、注册用户、后台管理员。

游客能浏览物种百科、阅读科普文章、查看捐助项目的公开信息，但不能发起捐助。注册用户在游客权限基础上，可以发起捐助、查看自己的捐助历史、收藏关注物种。管理员负责后台内容维护、订单审核、用户管理和数据统计。

注意一个细节：捐助是否允许游客直接参与？我建议做成“必须登录后才能捐助”。一方面这符合真实公益平台的规则，另一方面让系统多了一层“用户体系”，技术点密度上去了，答辩时也有东西可讲。如果做“游客直接捐”，用户管理模块就少了一半意义。用例清单拆完，就是技术选型。

2. 技术与架构定调：SpringBoot配Vue，理由和依赖全清单

技术选型这部分，很多同学是“跟着网课走”，问为什么用这个，答不上来。毕设答辩老师最爱问的就是“你为什么要这样选型”，所以每一项最好都能说出理由，哪怕是“生态成熟所以选了它”也是理由。

2.1 后端选型：为什么是SpringBoot而不是SSH或SSM

题目明确写了基于SpringBoot，所以主框架没有争议。SpringBoot的核心优势是自动配置和起步依赖，几行配置就能跑起一个Web项目，这对毕设项目来说，能省出大量时间做业务而不是调配置。

ORM层我推荐MyBatis-Plus，而不是纯MyBatis或JPA。MyBatis-Plus的好处是单表CRUD不用写SQL，自带分页插件，代码量直接砍半。项目里只有多表关联查询和复杂统计需要手写SQL，其余靠BaseMapper就够用。数据库用MySQL 8.0，免费、资料多、部署简单。

权限控制这一层，很多人纠结用Shiro还是Spring Security。我的建议是：如果时间紧，Shiro上手更快；如果想在简历上写个好看的技术栈，用Spring Security。这篇文章的例子按Spring Security + JWT来做，后面会详细讲配置，你照着敲就行，没有想象中难。

2.2 前端与整体结构

前端选Vue 3 + Element Plus + Vite，这套组合是目前最常见的。Vue 3的Composition API写起来逻辑更紧凑，Element Plus组件库覆盖后台管理页面的大部分UI需求，Vite做开发服务器非常快。

前后端分离后用Axios做HTTP请求，本地开发通过代理解决跨域，生产环境打包成静态文件扔到Nginx里，再通过反向代理转发/api到后端8080端口。

整个项目的包结构，我用一个常见的前后端分离单模块后端结构：

src/main/java/com/example/endangered/ ├── common/ // 通用返回结果、全局异常处理、常量定义 ├── config/ // Spring Security配置、WebMvc配置、MyBatis-Plus配置 ├── controller/ // 接口层，按业务模块分Controller ├── service/ // 业务逻辑层 ├── mapper/ // MyBatis-Plus的Mapper接口 ├── entity/ // 实体类 ├── dto/ // 请求参数和返回参数封装 ├── utils/ // JWT工具、文件上传工具等

单模块就够了，没必要上多模块Maven工程，那是企业级微服务的事，放毕设里反而是负担。

2.3 依赖版本对照清单

下面是我实际验证过能正常跑的依赖版本组合，你直接抄这份，别在最新版上折腾：

我踩过最大的版本坑：MyBatis-Plus升级到3.5.4以上后，分页插件配置方式有变化，网上很多老教程直接不能用。所以建议锁死3.5.3.1，别手滑升级。

3. 数据库建模：从物种库到捐助订单的字段逻辑

数据库设计是这个项目最见功底的部分。你要让评委一眼看出你“认真设计了数据模型”，而不是随手建了几张表。下面把核心表结构逐一拆开讲，连字段为什么这样设计都说清楚。

3.1 核心表结构与字段说明

用户表，用来存注册用户和管理员。注意密码不能明文，用BCrypt加密后存储。额外记住一个字段deleted，这是逻辑删除标记，配合MyBatis-Plus的@TableLogic注解，删用户只是标记，不会真删数据。

CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, nickname VARCHAR(50), avatar VARCHAR(255), email VARCHAR(100), phone VARCHAR(20), role VARCHAR(20) DEFAULT 'USER', status TINYINT DEFAULT 1, deleted TINYINT DEFAULT 0, create_time DATETIME, update_time DATETIME ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

物种信息表是核心业务表，字段比较多。除了常规的名称、别名、保护等级，一定要有cover_image封面图、population种群数量、habitat栖息地、description详细介绍。保护等级建议用枚举字符串如CR（极危）、EN（濒危）、VU（易危），比纯数字可读性好。

科普文章表包括标题、封面、内容、作者、分类、发布时间。内容字段用LONGTEXT存Markdown原文，渲染时前端解析后展示，这个方案比存富文本HTML更干净——上传HTML容易有脚本注入问题，Markdown则安全得多。

捐助项目表用于挂接具体捐助活动，每个项目关联一个物种，有目标金额、已捐金额、开始时间、结束时间、项目状态。新增一个detail字段存项目介绍，用LONGTEXT类型。

捐助订单表是整张数据表设计里的重头戏：

CREATE TABLE donation_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, user_id BIGINT NOT NULL, project_id BIGINT NOT NULL, amount DECIMAL(10,2) NOT NULL, status VARCHAR(20) DEFAULT 'PENDING', pay_type VARCHAR(20), transaction_id VARCHAR(64), pay_time DATETIME, anonymity TINYINT DEFAULT 0, message VARCHAR(255), create_time DATETIME, update_time DATETIME ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

order_no订单号必须唯一，用来对接支付回调。status状态机从PENDING到PAID到CLOSED，保证每一笔订单的状态都明确。anonymity标记是否匿名捐助，这一小字段功能上能同时满足普通用户和后台管理员的名单展示需求，很实用。

3.2 订单状态设计的防呆措施

订单状态是这类项目最容易被问倒的地方。我见过同学做的捐助系统，只有一个is_paid字段，0和1代表没付和付了。老师问“支付超时怎么办”“用户取消怎么办”“重复回调怎么办”，直接哑口无言。

正确做法是把状态机设计清楚：

• PENDING：已生成订单，等待支付
• PAID：支付成功，完成捐助
• CLOSED：取消或超时关闭

后端每次状态变更，都要校验“当前状态能否流转到目标状态”。比如只有PENDING能变成PAID，如果系统收到同一个订单的两次支付成功回调，第二次必须被识别为重复处理并忽略。

数据库层面再补一个transaction_id字段，存支付平台返回的交易流水号，加上UNIQUE约束，天然防重复。这个设计我建议写进答辩稿里，很能体现工程思维。

3.3 索引与外键的取舍

外键在我的项目里一律不建。这不是偷懒，而是互联网开发的实际习惯——外键会导致锁竞争、影响扩展、关联查询效率低，业务层面的约束用代码解决。但索引一定要建。

需要索引的字段有：用户表username（唯一索引）、订单表order_no（唯一索引）、订单表user_id（普通索引）、订单表project_id（普通索引）、文章表category_id（普通索引）。

MyBatis-Plus生成实体类时，注意用@TableName指定表名，用@TableId(type = IdType.AUTO)指定主键自增，再用@TableLogic标记deleted字段。这三个注解用对了，后面所有单表操作就省事了。

4. 科普模块落地：文章管理、Markdown渲染与图片上传

科普模块是这个系统最容易“一眼假”的部分。如果只是内置几篇文章不做管理功能，答辩时老师一问“内容从哪来”“怎么新增”，你就露馅了。这里把科普模块的完整开发思路梳理一遍，从数据流到前端渲染都覆盖。

4.1 科普内容的存储选型：Markdown还是富文本

如前面所讲，我推荐用Markdown。原因有三：一是安全，Markdown不直接存储可执行代码，前端渲染时即使内容里夹带HTML标签，也会被转义处理；二是编辑体验好，操作人员不需要会HTML；三是对毕设来说，Markdown编辑器和渲染器都有现成组件，工作量小。

后端内容字段存LONGTEXT，发布时提交Markdown原文，前端用Vue项目里的markdown-it库渲染成HTML，再配合highlight.js给代码块做高亮。一条完整链路是：后台编辑 -> 保存Markdown -> 前台拉取内容 -> 前端渲染为HTML。

4.2 后端接口设计与分页检索

科普模块最少要提供这几个接口：

• GET /api/article/page：分页获取文章列表，支持关键词搜索
• GET /api/article/{id}：文章详情，浏览数加一
• POST /api/admin/article：新增文章，需要管理员权限
• PUT /api/admin/article/{id}：修改文章
• DELETE /api/admin/article/{id}：删除文章，逻辑删除
• POST /api/admin/article/{id}/audit：审核文章

列表页要支持按分类筛选和按发布时间倒序。MyBatis-Plus的分页插件配置好后，Service层代码很简洁：

public PageResult<ArticleVO> pageArticles(int page, int size, String keyword, Long categoryId) { LambdaQueryWrapper<Article> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(categoryId != null, Article::getCategoryId, categoryId) .and(StringUtils.hasText(keyword), w -> w.like(Article::getTitle, keyword).or().like(Article::getSummary, keyword)) .eq(Article::getStatus, "PUBLISHED") .orderByDesc(Article::getCreateTime); Page<Article> result = articleMapper.selectPage(new Page<>(page, size), wrapper); // 再用Stream流把实体转成VO，补充分类名称等字段 }

注意这里的eq和and的写法，条件里用了StringUtils.hasText判断，防止空关键词拼出奇怪SQL。

4.3 图片上传与防盗链处理

科普文章和物种信息都少不了图片。很多同学直接把前端传的图片Base64编码塞进数据库，这种做法数据量大、查询慢、非常业余。正确做法是图片上传到服务器本地目录，数据库只存访问路径。

我的做法是在项目根目录建一个upload/文件夹，通过配置类映射为虚拟路径/upload/**，用MultipartFile接收文件，UUID重命名防止重名：

public String uploadImage(MultipartFile file) { String originalFilename = file.getOriginalFilename(); String extension = originalFilename.substring(originalFilename.lastIndexOf(".")); String newFileName = IdUtil.fastSimpleUUID() + extension; File dest = new File(uploadPath + newFileName); // 校验文件大小和后缀 if (file.getSize() > 5 * 1024 * 1024) { throw new BusinessException("图片不能超过5MB"); } List<String> allowedExt = Arrays.asList(".jpg", ".jpeg", ".png", ".gif", ".webp"); if (!allowedExt.contains(extension.toLowerCase())) { throw new BusinessException("不支持的图片格式"); } file.transferTo(dest.getAbsoluteFile()); return "/upload/" + newFileName; }

生产环境图片一般会走对象存储，毕设用本地存储足够，重点是上传之前做大小和格式校验，防止别人往服务器传木马文件。

5. 捐助业务实现：支付沙箱、订单状态机与对账审计

捐助模块是整个系统的核心加分项，也是技术含量最高的部分。很多同学把支付做成“点击按钮直接把订单状态改成已支付”，这是大忌，答辩一演示就被老师看穿。这里必须走模拟支付流程，对接一个支付沙箱环境。

5.1 捐助订单的完整链路

完整的捐助流程是这样：

1. 用户选择捐助项目和金额，后端生成待支付订单
2. 后端调用支付平台的下单接口，拿到支付链接/二维码
3. 用户在沙箱支付页面完成“模拟支付”
4. 支付平台向后端回调接口发送支付结果通知
5. 后端验证回调签名，更新订单状态，记录支付流水号
6. 前端轮询查询订单状态，支付成功后跳转到捐助成功页

这里我用的支付平台是某知名支付平台的沙箱环境（这篇里不说具体名字，避免广告嫌疑），流程和真实支付基本一致，但不需要真实商户资质。申请一个沙箱账号，拿到应用ID和密钥，就能完成本地联调。

核心是后端下单接口，大概是这样的逻辑：

@PostMapping("/api/donation/order") public Result<DonationOrderVO> createOrder(@RequestBody CreateOrderDTO dto) { // 1. 校验项目是否在募捐期 DonationProject project = projectService.getById(dto.getProjectId()); if (project.getStatus() != 1) { throw new BusinessException("该项目当前不在募捐期内"); } // 2. 生成订单号，规则：日期 + 用户ID + 随机数 String orderNo = "D" + DateUtil.format(new Date(), "yyyyMMddHHmmss") + String.format("%04d", dto.getUserId()) + RandomUtil.randomNumbers(4); // 3. 创建订单记录，状态为PENDING DonationOrder order = new DonationOrder(); order.setOrderNo(orderNo); order.setUserId(dto.getUserId()); order.setProjectId(dto.getProjectId()); order.setAmount(dto.getAmount()); order.setAnonymity(dto.getAnonymity()); order.setMessage(dto.getMessage()); order.setStatus("PENDING"); donationOrderService.save(order); // 4. 调用支付平台下单接口，返回支付表单/二维码内容 String payForm = payService.createPayForm(orderNo, dto.getAmount()); // 5. 返回给前端，前端负责跳转或展示二维码 return Result.success(new DonationOrderVO(orderNo, payForm)); }

一个很重要的业务细节：用户传上来的金额不能直接信任，后端要根据项目情况做最小金额校验（比如单笔不少于1元），防止恶意传0.01甚至负数。金额计算用BigDecimal，禁止用double。

5.2 支付回调验签与幂等处理

支付回调是整个模块的命门，也是面试和答辩的高频考点。回调接口必须做两件事：验签和幂等。

验签的逻辑：支付平台把回调参数加上商户密钥做MD5或RSA签名，回调时会带上签名串，后端用同样的算法重新计算签名，一致才说明这个通知确实来自支付平台。

幂等处理的意思是：同一个支付结果，可能回调多次，后端必须保证只处理一次。最简单的幂等策略就是前面说的数据库约束——transaction_id唯一。第二次回调时尝试更新一个已经PAID的订单，直接返回成功，不再重复加钱。

支付回调接口的大致框架：

@PostMapping("/api/pay/notify") public String payNotify(HttpServletRequest request) { // 1. 获取回调参数，验签 Map<String, String> params = parseParams(request); if (!payService.verifySign(params)) { return "验签失败"; } String orderNo = params.get("out_trade_no"); String transactionId = params.get("trade_no"); String tradeStatus = params.get("trade_status"); // 2. 只有在TRADE_SUCCESS时才更新订单 if ("TRADE_SUCCESS".equals(tradeStatus)) { donationOrderService.handlePaySuccess(orderNo, transactionId); } // 3. 必须返回success给支付平台，否则平台会持续重试 return "success"; }

注意最后这步特别重要：回调接口处理完必须明确返回成功标识，支付平台拿到后才能停止重试，如果后端处理失败，平台会隔几分钟再推一次，甚至重推一周。

5.3 对账与审计：打动答辩老师的加分项

这块不是在题目里直接提的，但做出来很出彩。原理很简单：系统定期把“本地订单合计金额”和“支付平台流水合计金额”做比对，不一致则触发告警，管理员可下载对账明细。

实现起来不难：写个定时任务，每天凌晨跑一次，查当天PAID订单的金额总和，再去支付平台查询当天成功的交易总额，对比差异，把结果写到一张对账表里。后台的对账页面展示最近30天的数据，正常时全是“一致”，异常时有“差异金额”高亮显示。

答辩时说到这个功能，老师看到的就不止是“我学会了CRUD”，而是“我理解了第三方支付场景下的金额一致性问题”。这个点在简历上的“项目亮点”里也值得写一笔。

6. 用户与权限体系：Spring Security的RBAC落地细节

用户登录和权限控制是毕设评分的重要观察项。老师登录你的后台，如果随便一个游客接口都能调管理接口，印象分会大打折扣。

6.1 用户表设计与登录接口

用户表前面已经给出，现在说登录逻辑。密码用BCrypt加密存储，注册时前端明文提交，后端调用BCryptPasswordEncoder加密后保存。登录时不比对原密码，而是对登录输入的明文密码做matches校验：

public String login(LoginDTO dto) { LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(User::getUsername, dto.getUsername()); User user = userMapper.selectOne(wrapper); if (user == null || !passwordEncoder.matches(dto.getPassword(), user.getPassword())) { throw new BusinessException("用户名或密码错误"); } if (user.getStatus() != 1) { throw new BusinessException("账号已被禁用"); } // 生成JWT令牌，放入用户ID和角色 return JwtUtil.createToken(user.getId(), user.getRole()); }

登录成功后，前端把JWT存到localStorage，之后每个请求在Axios拦截器里自动带上Authorization头，后端过滤器统一校验。

6.2 基于角色的接口鉴权

Spring Security的配置核心是SecurityFilterChain的Bean定义。需要放行的接口有：注册登录、游客公开的物种列表、文章列表、文章详情、捐助项目列表。需要登录的接口：创建捐助订单、查看我的订单、收藏。需要管理员角色的接口：后台所有增删改和统计接口。

配置大致如下：

http.authorizeHttpRequests(auth -> auth .requestMatchers("/api/auth/**", "/api/species/page", "/api/article/page", "/api/article/detail", "/api/project/list", "/upload/**").permitAll() .requestMatchers("/api/admin/**").hasRole("ADMIN") .anyRequest().authenticated()) .exceptionHandling(e -> e.authenticationEntryPoint(unauthorizedHandler)) .sessionManagement(s -> s.stateless(true));

写到这里提个容易踩的坑：hasRole("ADMIN")和数据库里存的role字段的对应关系。Spring Security的hasRole会自动帮你加ROLE_前缀，所以数据库里角色值必须写成ROLE_ADMIN，或者你在代码里统一处理。

6.3 管理后台的数据隔离

有些同学做完后台权限只挡接口，但后台页面和数据依然能通过前端代码绕过。这里要注意前后端双重校验：后端接口必须有@PreAuthorize或URL拦截，前端的菜单只是隐藏入口。后端是最后一道防线，务必保证所有管理接口都以/api/admin/开头。

还有一个细节：管理员之间的操作也要记录日志。我建了一张audit_log表，记录谁在什么时间做了什么操作，操作对象是谁。后台有个“操作日志”页面可以查。答辩时直接演示“我删了一条物种记录，日志里马上能查到我这个管理员的操作痕迹”，可信度直接上去。

7. 从开发到部署：环境搭建、数据初始化和常见坑位

很多项目栽在最后一步，代码写完了，结果在老师电脑上跑不起来，或者打包完静态文件找不到接口。下面这套流程是我验证过很多次的，按步骤来基本不会出大问题。

7.1 项目初始化与配置

后端部分，最核心的配置文件是application.yml里的数据源和MyBatis-Plus配置：

spring: datasource: url: jdbc:mysql://localhost:3306/endangered_db?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai&useSSL=false username: root password: yourpassword servlet: multipart: max-file-size: 10MB max-request-size: 20MB mybatis-plus: configuration: map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 server: port: 8080

前端部分，Vite开发服务器配置代理转发，解决跨域问题：

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

7.2 初始数据的准备：种子数据脚本的价值

不少人开发时全靠一个init.sql手动录数据，交付时数据库里内容不完整，老师点开物种列表只有两条记录，观感很差。

我的做法是写一个数据初始化跑批，项目启动时检查数据库里物种数量，如果小于某个阈值，就自动插入一批预设的物种档案和科普文章。内容都是真实的濒危物种基础信息（比如大熊猫、华南虎、中华鲟这类公众熟悉的动物），图片用占位图或自己找的无版权封面。好处是每次启动都能有丰富的展示数据，演示效果稳。

7.3 打包部署与Idea都跑不起来的常见问题

部署方案，毕设最简单实用的做法是前后端都放一台服务器：

1. 后端mvn package打成jar包，放到服务器，用nohup java -jar xxx.jar &启动；
2. 前端npm run build把静态文件放到Nginx的html目录，配一个反向代理，把/api转发到8080。

Nginx关键配置：

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

最后说两个常见坑。

一个是启动时端口被占用。SpringBoot启动报Port 8080 was already in use，多半是之前跑过一次没关闭进程，Windows下用netstat -ano | findstr 8080找到PID，再taskkill /f /pid 那个PID即可。

另一个是上传文件路径问题。本地开发时upload/目录在项目根目录下，部署到服务器后，如果你把jar包单独放在一个目录，上传文件的绝对路径会发生变化。解决方案是配置里使用外部路径，比如Linux下放在/home/app/upload，Windows开发时放D:/projects/upload，配置文件里用参数区分环境，别把路径写死在代码里。

这类的坑我写代码时几乎每周都会遇到，很多都是不影响编译但影响运行环境的小问题。我的习惯是每次配置改动后，都重新完整启动一次项目，从浏览器走一遍核心流程，再继续开发下一步。毕设项目做到最后，宁可代码量少一点，也要保证演示全流程顺畅。