企业官网建设流程全解析

拿到一份省级高职组 Web 应用软件开发竞赛的样题，我做的第一件事不是打开 IDE，而是把纸摊开，用铅笔把需求分成三堆：必须做完的、能加分的、纯属干扰的。带了几年备赛，我见过太多队伍第一天就把时间耗在登录页的美化上，结果核心业务的接口到交卷前两小时才开始写。这类样题的价值不在题目本身，而在于它把“一个能上手干活的初级开发”需要具备的能力压缩进几个小时：读懂业务、设计表、写接口、调页面、跑起来、写文档。这篇东西写给三类人——第一次参赛的高职组同学、需要带队的指导老师，以及想从课堂项目过渡到工程实践的自学者。下面我按赛题的拆解顺序，把每一块该怎么做、为什么这么做、哪里容易翻车，尽量讲透。

1. 这类赛题到底在考什么

1.1 从样题结构反推评分逻辑

Web 应用软件开发赛项的样题，通常不会给你一份完整需求文档，而是给几页“业务说明 + 功能清单 + 少量界面草图”。这种给法的意图很明确：考的是信息补全能力。评分表一般按模块切分，常见比例大致是需求理解与数据库设计、后端接口实现、前端页面与交互、系统部署与文档四块，权重往中间两块倾斜。

我带过的队伍里，凡是开局先花二十分钟把功能清单逐条翻译成“用例—接口—页面”三列清单的，后面几乎不会乱；反过来，直接照着草图敲页面的，做到第三个模块就开始返工。原因不复杂：草图只描述“长什么样”，不描述“数据从哪来、存到哪去、谁能改”。你把这三件事想清楚，页面只是最后一步的呈现。

判分还有一个隐性规则：功能可运行优先于功能完整。一个能跑通登录、列表、新增、修改的简化系统，分数一定高于功能写了一半但启动就报错的“完整系统”。赛场上时间有限，能跑起来是底线。

1.2 为什么题目偏爱“业务闭环”而不是炫技

近几年这类赛题的另一个共性，是业务场景都很“土”：设备报修、宿舍管理、图书借阅、课程预约、工单流转。没有高并发，没有复杂算法，没有花哨的动画。很多同学第一反应是“这么简单有什么好考的”，恰恰是想反了。

业务闭环考的是完整链路：用户在页面提交一条数据，前端校验、后端接参、参数校验、写库、返回统一响应、前端提示成功、列表刷新。这条链路上任何一环断了，功能就是零分。而炫技型功能（比如复杂图表、实时推送）往往只值一两个加分点，投入产出比极低。我在训练时反复跟队员强调一句话：先把一条数据从页面送到数据库再取回来，这条路走通一百遍，比写十个漂亮页面有用。

1.3 技术栈选型：赛场上什么组合最稳

选型的唯一标准是“你闭着眼睛能写出来”。赛场上没有搜索引擎可用（多数赛项不允许联网查资料，只允许查本地文档），任何需要现场学的技术都是风险。下面这张表是我给队伍做选型参考时常用的对照，左列是常见组合，右列是我对它的实际评价。

选 A 或 C 的队伍最多。我的建议是：如果队里有人能默写 Spring Boot 的三层结构，就选 A；如果两个人都是前端出身，选 C 并用模板引擎或纯静态页 + fetch，别硬上框架。选型之后不要中途换，赛场上换栈等于重开一局。

注意：选型阶段一定要确认赛项提供的环境。JDK 版本、Node 版本、数据库版本、是否预装 Maven 依赖仓库，这些信息通常写在样题附件的环境说明里，很多人不看，结果开场半小时在配环境。

2. 需求拆解与数据库设计

2.1 读题三遍法：把自然语言变成用例清单

第一遍通读，只标注“角色”和“动作”，比如“管理员可以审核申请”“学生可以提交申请”“教师可以查看统计”。第二遍精读，把每个动作补成“输入—处理—输出”，比如“提交申请：输入设备编号、事由、时间；处理为校验设备是否可用、写入申请记录、状态置为待审核；输出为申请编号”。第三遍反向检查，看有没有遗漏的隐藏需求，通常藏在“其他要求”里，比如“所有列表需支持分页”“删除需二次确认”“时间格式统一为 yyyy-MM-dd HH:mm:ss”。

这三遍下来，你会得到一张十几行的用例表。这张表就是你后面所有工作的检查清单，写完一个划掉一个。我一般要求队员把这张表贴在显示器边上，比记在脑子里靠谱得多。

2.2 实体识别与表结构设计

从用例表里抽名词，重复出现的名词基本就是实体。以常见的“设备预约与报修”类业务为例，抽出来大概是：用户、角色、设备、预约单、报修单、操作日志。别急着建表，先画关系：用户属于角色（一对多或一对一），用户提交预约单（一对多），设备被预约（一对多），报修单关联设备（一对多）。

一个常见错误是把“状态”单独建一张表。除非题目明确要求状态可配置，否则状态用枚举字段（tinyint）就够了，多一张表就多一次关联查询，多一处出错点。另一个错误是过度设计，把每个字段都做成字典表，结果写一个新增接口要插五张表。

2.3 字段、约束与索引的取舍

字段设计遵循三条：能给默认值的不给 NULL、能加唯一约束的加唯一约束、外键视情况而定。赛场上我通常不建议加物理外键，因为初始化数据顺序稍错就会插入失败，用逻辑外键（存 id，不建约束）更省事，代价是数据一致性靠自己保证——这在赛题规模下完全可控。

下面是我常用的建表模板，以预约单为例：

CREATE TABLE `reservation` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `user_id` bigint NOT NULL COMMENT '申请人', `device_id` bigint NOT NULL COMMENT '设备', `start_time` datetime NOT NULL COMMENT '开始时间', `end_time` datetime NOT NULL COMMENT '结束时间', `reason` varchar(255) DEFAULT NULL COMMENT '事由', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0待审 1通过 2驳回 3已取消', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user` (`user_id`), KEY `idx_device_time` (`device_id`, `start_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='预约单';

几个细节值得说。字符集必须 utf8mb4，不然用户输入生僻字或表情符号会插入失败，这类报错在赛场上排查起来很浪费时间。时间字段用 datetime 而不是 timestamp，避免时区转换带来的诡异问题。索引只建两个：按用户查“我的预约”，按设备和时间查“设备是否被占用”，正好对上两条核心查询。

2.4 接口契约先行，避免前后端互相等

分工之后最容易出现的场面是：前端同学问“你接口返回什么格式”，后端说“还没写完”。解决办法是开赛半小时内把接口契约定下来，写在一张纸上或者一个 txt 里，内容包括 URL、方法、请求参数、响应结构。统一响应体我固定用这一套：

{ "code": 200, "msg": "操作成功", "data": {} }

分页响应在 data 里放 records 和 total。契约定死之后，前端可以用假数据先把页面跑起来，后端按契约实现，中间不需要反复沟通。这个习惯看起来多花十分钟，实际能省一小时。

3. 后端接口实现的关键细节

3.1 分层结构与统一响应体

三层结构（Controller - Service - Mapper）不是形式主义，它的好处是改需求时只动一层。Controller 只负责接参、调 Service、返回结果；Service 写业务判断；Mapper 只管 SQL。下面这段是我赛后复盘时最常给队员看的模板：

@RestController @RequestMapping("/api/reservation") public class ReservationController { @Resource private ReservationService reservationService; @PostMapping public Result<?> create(@RequestBody @Valid ReservationDTO dto) { reservationService.create(dto); return Result.ok("提交成功"); } @GetMapping("/page") public Result<PageResult<ReservationVO>> page(ReservationQuery query) { return Result.ok(reservationService.page(query)); } }

注意@Valid的位置，加在请求体参数上才会触发校验；很多人加在类上或者忘了加，导致空值直接进库，后面查询时字段缺失引发空指针。统一响应体用泛型包装，避免每个接口返回结构不一致，前端写拦截器时能统一处理 code 非 200 的情况。

3.2 分页、条件查询与参数校验

分页几乎是必考项，也是很多人丢分的地方。赛题通常要求“列表支持按名称模糊查询、按状态筛选、按时间倒序、分页”。用 MyBatis-Plus 的话，一个 Page 对象加 LambdaQueryWrapper 就能搞定，但要注意两个坑：一是模糊查询要判空，否则拼出like '%%'虽然不报错但会走全表；二是排序字段必须白名单校验，不能让前端随便传字段名拼进 SQL。

参数校验用注解最省事，但分组校验要提前规划。比如新增时 id 为空、修改时 id 必填，很多人图省事写两套 DTO，其实用@Validated分组能省不少代码。校验失败时统一异常处理器要返回友好提示，不能让 400 的默认错误页露给前端。

3.3 登录鉴权与权限控制

基本每个赛题都有登录。最轻量的做法是登录成功后签发 token，前端存起来，每次请求放在请求头，后端用拦截器解析。赛场上不要上 Spring Security 全家桶，配置量大、报错难懂，用拦截器加一个 ThreadLocal 存当前用户足够。

权限控制在赛题里通常只分两级：管理员和普通用户。实现方式是在拦截器里校验角色，或者在方法上加自定义注解。注意别把权限判断写死在每个接口里，一个需求变更就要改十几处。我在训练时会要求队员把所有需要管理员权限的路径集中在一个配置类里，改起来只改一行。

提示：token 里不要放密码、手机号等敏感信息，也别把过期时间设得太短，赛场上演示中途掉登录是灾难。

3.4 文件上传、导出这些加分项怎么处理

样题的“拓展要求”里经常出现上传图片、导出 Excel。这两项投入产出比很高，但要注意实现方式。上传文件存在项目外的固定目录，数据库只存相对路径，别把文件二进制塞进数据库。导出用 EasyExcel 或者直接手写 CSV，后者更稳，因为不依赖额外依赖包，几十行代码就能写出一个可用的导出。

导出时容易忽略的是中文文件名乱码，响应头里用 URLEncoder 编码一次即可。另一个细节是导出数据量，如果赛题数据只有几十条，不用考虑流式写出，一次性读进内存反而代码更短。

3.5 异常处理与错误码

统一异常处理器是必须写的，否则任何一处空指针都会让前端拿到 500 页面。做法是用@RestControllerAdvice捕获业务异常和系统异常，业务异常返回自定义 code 和提示语，系统异常返回“系统繁忙”并打日志。日志里要打出请求路径和参数，排查时非常有用。我见过队伍因为没有异常处理器，演示时点到一个空数据页面直接白屏，后面几个功能都没来得及演示。

4. 前端页面与交互拿分要点

4.1 骨架先行：路由、布局、菜单

前端第一件事不是画页面，是把路由和布局搭好。侧边菜单 + 顶部栏 + 内容区的经典布局，用组件库的 Container 组件十几行就能搭完。路由按模块分，每个模块一个文件，登录页单独处理（不套布局）。

骨架搭好后，先把所有页面建成空文件并挂上路由，确保点菜单能切换、不报错。这一步只需要二十分钟，但能让你后面每写完一个页面就立刻能验证，而不是最后才发现路由配错。

4.2 列表加表单的通用套路

赛题里八成页面都是“列表 + 搜索 + 新增/编辑弹窗”。把这套写成可复用的模式，后面每个模块直接复制改字段。列表表格的关键点是列宽、空数据提示、分页器位置；表单弹窗的关键点是打开时重置校验状态、关闭时清空表单数据。很多人的弹窗第二次打开还残留第一次的校验红字，就是这个没处理。

const openDialog = (row) => { formRef.value?.resetFields(); form.value = row ? { ...row } : { status: 0 }; visible.value = true; };

resetFields必须在赋值之前调用，顺序反了就没效果。这是我在训练中反复纠正的一个小点，但它的影响很直观：演示时弹窗带着上次的红字，评委一眼就看出细节没打磨。

4.3 联调阶段的代理与跨域

开发阶段前后端分离跑，跨域是绕不开的。最省事的方案是在前端配置代理，把 /api 转发到后端端口，这样前端代码里写的都是相对路径，部署时也不用改。

// vite.config.js export default { server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

注意changeOrigin要开，否则后端拿到的 Host 不对，某些校验会失败。另外代理只在开发服务器生效，打包后必须由 Nginx 转发，这一步在部署章节会讲，很多人开发时好好的，打包后就 404，就是漏了这步。

4.4 交互细节，评委看的就是这些

功能都能跑之后，拉开差距的是细节。我列几个性价比最高的：表单必填项加星号并做前端校验；删除操作二次确认；提交按钮点击后置灰防止重复提交；操作成功有轻提示；表格空数据显示“暂无数据”而不是一片空白；长文本用省略号加悬浮提示。

这些每项只要几分钟，但演示时的观感完全不同。反过来说，有些细节不要碰：不要做复杂动画，不要引入没见过的图表库，不要改组件库默认样式，赛场上时间紧张，样式冲突排查起来非常耗时。

5. 时间管理与部署交付

5.1 时间切片方案

我把六个小时的赛程切成这样几块，实际执行时允许上下浮动半小时：

这张表的重点在最后两段。太多队伍把部署留到最后一刻，结果环境问题吃掉所有缓冲时间。我的做法是第一天训练就强制要求“每完成一个模块就打包部署一次”，让部署变成肌肉记忆。

5.2 打包部署的标准动作

后端打成 jar，前端 build 出静态文件，统一交给 Nginx 托管。下面是我常用的配置片段：

server { listen 80; server_name _; root /opt/app/dist; index index.html; location / { 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; } }

try_files那行是单页应用必须的，否则刷新页面直接 404。proxy_pass结尾的斜杠要注意，带斜杠和不带斜杠的转发路径不一样，这是最常见的 404 来源。数据库连接配置写在外部配置文件里，不要硬编码在代码中，换环境时只改一处。

注意：部署完成后一定要用另一台机器或者手机访问一次，确认不是只有本机能通。防火墙端口、绑定地址 0.0.0.0 这些细节，现场排查要花时间。

5.3 文档写什么，怎么写

文档分值通常不高，但它是评委了解你系统全貌的入口。我建议只写三部分：一是系统说明与账号（管理员、普通用户各一个测试账号，写清楚密码）；二是功能清单与对应菜单路径；三是数据库表说明。别写大段技术架构介绍，评委没时间看。

功能清单用表格，一行一个功能，标注“已完成/部分完成/未完成”。诚实标注比虚报好，评委点两下就知道实际情况，虚报反而扣印象分。测试账号一定要在文档第一页显眼位置，演示开始时评委第一件事就是登录。

6. 常见问题与排查实录

6.1 环境与配置类问题

数据库连不上是开赛最高频的问题。排查顺序固定为：服务是否启动、端口是否被占、账号密码是否正确、库名是否拼错、驱动版本是否匹配。我遇到过一次是 MySQL 8 的驱动类名写成了旧版，报错信息很绕，其实换一行配置就好。

中文乱码一般出在三个位置：数据库字符集、连接串参数、页面编码。连接串里加上characterEncoding=utf8，建库用 utf8mb4，基本能覆盖。时间字段显示成 ISO 格式带 T 和 Z，是序列化配置问题，在配置文件里指定日期格式即可。

6.2 前后端联调类问题

接口 404 排查看四件事：请求方法是否一致、路径前缀是否被代理吃掉、后端是否真的启动在预期端口、Controller 是否被扫描到。白屏排查看控制台第一个报错，通常是一个未定义的变量或者组件引入路径错。跨域报错要看是开发环境还是打包后，开发环境配代理，打包后配 Nginx，两者不能混。

下面这张表是我整理的速查表，训练时贴在墙上：

6.3 几个独家避坑经验

第一，比赛开始前把项目骨架先跑一遍。有些赛项环境预装了依赖仓库但版本不对，提前十分钟发现比中途发现好得多。第二，每完成一个可运行的功能就复制一份代码目录做备份，命名带时间戳。我在训练中见过一次误删文件导致两小时工作没了，赛场上没有回收站。第三，演示前把所有测试数据清空重造一遍，保证列表里有数据、状态分布合理、没有“测试测试”这种记录。第四，演示脚本按“登录—列表—新增—修改—删除—导出”顺序走一遍，每一步点哪里、说什么话提前演练，控制在五分钟内。

还有一条容易被忽略：代码里不要留调试输出和默认密码注释。有些评委会翻代码，满屏的System.out.println和注释掉的旧逻辑，观感很差。花五分钟全局搜一遍删掉，成本极低。

7. 训练安排与能力补齐路线

7.1 四周训练计划

如果距离比赛还有一个月，我一般按这个节奏排：第一周只做基础，从空项目到登录加一个完整模块的增删改查，要求不看教程独立完成；第二周做两个完整业务模块，加入分页、条件查询、文件上传；第三周做限时模拟，用往年样题或自拟题目，严格按六小时计时；第四周只做两件事，复盘错题和练部署，把每次模拟中卡住超过二十分钟的问题整理成清单，逐条消灭。

限时模拟的价值不在于做完，而在于暴露“你在哪一步会卡住”。有人卡在建表，有人卡在跨域，有人卡在打包，卡点不同，补的方向完全不同。模拟结束后一定要写复盘，记录时间分配和卡点原因，下一轮针对性调整。

7.2 从会写到写得好，差在哪

同样能跑通功能，分数差距往往在这几处：接口是否统一响应、是否有参数校验、异常是否被捕获、代码是否有基本分层、页面是否有空数据处理、文档是否清晰。这些都属于“工程习惯”，不是知识点，靠刻意练习形成。我的建议是每写完一个模块，花十分钟自查这六项，坚持两三周就固化了。

另外，别把组件库当黑盒。赛场上最耗时的往往不是业务逻辑，而是某个组件属性记不清。提前把表格、表单、弹窗、上传、分页这几个高频组件的常用属性整理成一页纸，赛前看一遍，比临时翻文档快得多。

我个人在实际带队中的体会是，决定成绩的从来不是谁会的技术多，而是谁在有限时间里把该做的事做完了、做稳了。那些看起来“不够酷”的增删改查、那些反复检查的字符集和路径配置，才是分数真正的来源。赛前一天把环境跑一遍，把演示脚本念一遍，把测试数据造一遍，这三件事做完，心里就踏实了。