企业官网建设流程全解析

上个月接到一个开发需求：做一个“国之动力”主题的科普网站，用 Java + SpringBoot3 + Vue.js3 + MySQL 这套技术栈。听上去是典型的内容型站点，没有电商那种交易链路，也没有社交产品那样复杂的关系网络。但真正开工之后才发现，这类“看起来不难”的科普网站，藏了很多容易被忽略的工程问题。

先说结论：我对这种内容型科普项目的判断是，技术选型不是最难的，难在把数据结构设计清楚、把前后端联调的节奏理顺，再老老实实补齐部署、日志、备份这类“看不见的工程能力”。SpringBoot3 + Vue3 + MySQL 的组合，更像是给这个目标提供了一套成熟底座，而不是让项目自动变好。

如果你刚用 SpringBoot 和 Vue 做实际项目，或者正在计划做一个科普展示、知识宣传类的网站，这篇内容会按照我“接需求、建模、后端、前端、上线、长期维护”的真实顺序展开，并把容易踩坑的地方单独拎出来讲。

1. 先搞清楚：内容型科普站真正要解决的是什么

1.1 “科普网站”不等于“官网首页”

很多人在接到这种项目时会下意识把它当成一个“展示页面”来做：一堆静态页面，配几个跳转链接，后台只要能改文字就行。但真正面向运营使用的科普网站，起码要回答下面这几个问题：

• 内容是谁来维护？是技术人员直接操作数据库，还是有编辑人员通过后台录入？
• 内容是不是长期更新？科普网站如果上线之后一个月不更新，用户访问一次就不会再来。
• 需不需要按主题分类检索？比如“大国重器”“基础科学”“科技人物”这类栏目。
• 内容形态是纯文本，还是图文混排、视频嵌入、PDF 附件？

这个判断会直接影响数据库建模和权限设计，而不是“先做一个前端页面再说”。

1.2 为什么是 Java + SpringBoot3 + Vue3 + MySQL

这个技术组合的好处，主要不在“新”或“酷”，而在于工程生态成熟、团队可维护性高。

• SpringBoot3适合快速构建稳定后端服务，内置 Web、校验、缓存、定时任务等常用能力。
• Vue.js3作为前端框架，组合式 API 和组件化开发，很适合一个团队长期迭代后台管理界面和前台浏览页。
• MySQL仍然是内容型 Web 项目最稳妥的关系型数据库。和 SpringBoot 配套的驱动、连接池、ORM 方案都很成熟。

更重要的是，这个组合对“内容管理”场景非常合适。只要不是超高并发的 UGC 内容平台，它就是一套“标准答案”。如果团队后续要加评论、投票、答题互动，扩展空间也足够。

1.3 技术栈背后的动作是“内容管理闭环”

科普网站表面上是一堆内容页面，本质上是一条内容生产链路：

内容录入 → 内容审核/状态管理 → 前台展示 → 用户浏览/检索 → 数据统计返回运营

所以我画后端模块时不会只拆“首页轮播”“列表页”这些页面功能，而是会抽象成：

• 内容模块：文章、栏目、标签
• 用户与权限模块：管理员、内容编辑
• 资源模块：图片、附件
• 前台模块：列表、详情、检索
• 统计模块：浏览量、栏目热度

这个抽象顺序，才是真正决定后续能不能长期运营的关键。

2. 环境准备与最小工程骨架：先跑通，再谈业务

2.1 你最好先检查这四个基础环境

在新建项目之前，我建议先确认本机环境，很多时候一上来就报错不是代码问题，而是环境版本不对。

如果版本存在冲突，比如本机还是 JDK8，那 SpringBoot3 项目会直接出现编译问题，这属于最常见的起步坑。

2.2 后端工程：从空项目开始

后端创建方式很简单，在 Spring Initializr 里选 Java 17 或 21、SpringBoot 3.x，依赖里添加：

• Spring Web
• Validation
• MySQL Driver
• 持久层框架（常见选 MyBatis-Plus 或 Spring Data JPA）

如果使用 Maven 管理的 SpringBoot 项目，核心依赖示例大概是下面这种结构：

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> </dependencies>

在实际开发中，我更推荐先创建一个“空跑后端”：启动后能访问http://localhost:8080/api/ping返回一个固定字符串，确认网络链路通，再开始写业务代码。这样可以避免把数据库连接问题、依赖冲突问题混合在一起排查。

2.3 前端工程：用 Vite 创建 Vue3 项目

创建 Vue3 前端的常见命令是：

npm create vite@latest guozhidongli-web -- --template vue cd guozhidongli-web npm install npm run dev

这个空项目跑起来后，Vue 页面会默认监听 5173 端口。先确认浏览器能访问http://localhost:5173，再接入 axios 请求后端。

2.4 为什么“先跑通空项目”这一步不能省

我在带新人做项目时，第一步永远不是写登录注册，而是把一个前端页面和一个后端接口连通。

原因很简单：科普网站的核心能力是“内容从数据库里来，再通过接口展示到页面上”。如果连最基本的跨域请求都还没解决，你一上来就写几十个接口，后面联调会非常痛苦。先跑通最小链路，等于给整个项目提前做了一次“航路校验”。

3. 数据库建模：科普站最贵的坑都埋在这里

3.1 不要一上来就设计十张表

内容型站点的后台通常涉及两种角色：普通浏览用户和管理员。“用户表”不是不需要，但要控制复杂度。

一个常见的起步模型是这几张表：

• category：栏目分类表
• article：文章内容表
• tag和article_tag：标签表
• admin_user：后台管理员表
• resource：上传的图片或附件记录表

用关系型数据库建模时，最少要围绕“栏目—文章—管理员”这三者展开。文章表是核心，所有关联最终都会落到文章上。

3.2 文章表的核心字段设计

建表时可以抽象成下面这个结构：

CREATE TABLE article ( id BIGINT PRIMARY KEY AUTO_INCREMENT, category_id BIGINT NOT NULL, title VARCHAR(200) NOT NULL, summary VARCHAR(500), cover_url VARCHAR(500), content LONGTEXT, status TINYINT NOT NULL DEFAULT 0, view_count INT NOT NULL DEFAULT 0, create_by BIGINT, create_time DATETIME, update_time DATETIME ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_unicode_ci;

这里最需要注意的字段是status。内容型网站的文章不是“录入后立刻显示”，而是要经过编辑、预览、上架、下架这样的状态流转。如果省略这个字段，后面只要运营提出“这篇内容先保存不上线”“那篇内容撤下来”，你就得临时改代码。

TINYINT的取值可以约定：

• 0：草稿
• 1：已上架
• 2：已下架

具体用数字几不是重点，重点是必须有一个字段承接状态流转。

另一个关键点是content的类型。科普文章通常图文较长，答案比较稳妥的是LONGTEXT，能容纳足够大的富文本内容。如果内容里需要存储图片路径，不要把整张图片转成 Base64 塞进数据库，除非你后续有非常特殊的存储需求，否则很容易让数据表和接口响应都变得臃肿。

3.3 分类表设计不要做成无限级菜单

科普网站栏目层级一般不会特别深。最常见的是“一级导航分类 + 二级内容分类”。建议把分类表设计成自关联结构：

CREATE TABLE category ( id BIGINT PRIMARY KEY AUTO_INCREMENT, parent_id BIGINT NOT NULL DEFAULT 0, name VARCHAR(50) NOT NULL, sort INT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 1 ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4;

parent_id为 0 表示顶级栏目。这样做的好处是，以后扩展一个子分类不需要改表结构。但如果业务明确只有单层栏目，完全不必一开始做复杂的树结构生成逻辑，先把一级列表跑通就够了。

3.4 字符串和字符集：尽量使用 utf8mb4

MySQL 8.0 默认字符集可能不是utf8mb4，但正文里如果有生僻字、特殊符号或表情符号，就很容易出现乱码。实际建库时建议显式指定：

CREATE DATABASE guozhidongli DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

后端 JDBC 连接串也要带上字符集和时区参数，否则插入中文后很可能出现乱码，而这类问题经常到部署阶段才暴露。

正确姿势是：

spring: datasource: url: jdbc:mysql://localhost:3306/guozhidongli?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai driver-class-name: com.mysql.cj.jdbc.Driver

注意characterEncoding=utf8和utf8mb4是两回事。MySQL 中utf8mb4是完整的字符集，很多连接串写成utf8也能用，但为了和数据库字符集真正匹配，连接层和数据库统一使用utf8mb4更稳妥。

3.5 别急着做“浏览量排名”的复杂计算

科普网站常有“热门文章”这种模块。很多新手的直觉是，每次页面加载都对view_count做一次排序查询。这种做法不是不能用，而是当文章量大之后，每次全表排序会浪费资源。

更轻量的方案是：

• 浏览结束后异步更新计数
• 后台维护一张统计表，定期汇总
• 或者先用 Redis 做计数，再定时写回 MySQL

但如果项目刚起步，文章量只有几百条，最合适的方法其实是“先用一个view_count字段就足够了”。等确实出现性能瓶颈，再引入缓存或独立统计表。很多系统不是被方案难死的，而是被过度设计拖慢的。

4. 后端实现的关键点：接口只是入口，重点是约定

4.1 基础项目结构要按照业务模块分层

后端代码不要按“页面”分，要按“业务模块”分。比如：

controller ArticleController CategoryController AdminAuthController service ArticleService CategoryService FileStorageService mapper ArticleMapper CategoryMapper domain/model Article Category dto ArticleSaveRequest ArticleQueryRequest common Result GlobalExceptionHandler

很多人写后端会纠结包名，其实核心是让新加入的开发者能快速找到“改文章标题要去哪个 Controller”。模块化的价值在长期维护阶段才会体现出来。

4.2 每个接口返回结构要统一

内容型站前端要处理的数据结构很多：文章详情、分类列表、分页结果、上传结果。如果每个接口返回格式都不一样，前端每接一个接口都要写一套判断，很痛苦。

建议从第一个接口开始就约定统一返回体：

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.code = 200; result.message = "ok"; result.data = data; return result; } public static <T> Result<T> error(Integer code, String message) { Result<T> result = new Result<>(); result.code = code; result.message = message; return result; } }

接口示例：

@RestController @RequestMapping("/api/article") public class ArticleController { @GetMapping("/list") public Result<PageResult<ArticleVO>> list( @RequestParam(defaultValue = "1") int page, @RequestParam(defaultValue = "10") int size, @RequestParam(required = false) Long categoryId ) { // service 层完成分页查询 return Result.success(articleService.pageQuery(page, size, categoryId)); } }

这样至少保证了前端收到响应时，只需要看code是否为 200，其他结构都是固定模式。

4.3 查询接口一定要做分页，别把所有数据一次返回

最典型的反面案例是：文章列表接口不写LIMIT，一次性把全表查询结果返回给前端。数据量少时看不出问题，等管理员往后台传了两三百条长文章后，接口会越来越慢。

分页参数可以默认：

• page：从 1 开始
• size：默认 10，最大不要超过 100
• 排序：按create_time DESC或is_top DESC, create_time DESC

对于科普站首页的热门列表，可以单独写一个“查询浏览量 Top 10”的小接口，不需要和文章分页接口混在一起。混在一个接口里，会让复杂度上升，后续改动互相受影响。

4.4 后台上传图片要限制文件类型

科普站需要大量配图，所以图片上传是核心功能。但上传接口最容易出的问题不是“不能传”，而是“什么文件都能传”。

安全但不过度的做法是：

• 限制扩展名：jpg、png、webp、gif
• 限制单个文件大小：比如 5MB
• 用 UUID 或日期重新生成文件名
• 不要把文件保存到代码包的 classpath 目录
• 上线后要配置独立的静态资源目录或使用对象存储

这里最容易出现的问题是本地路径。很多人在本机写D:/upload/，上线后服务器上没有这个目录，接口就会报 500。最稳妥的方法是把上传目录放到配置文件中，同时服务启动时自动创建目录。

SpringBoot 的配置文件示例：

app: upload-dir: ./upload

业务代码里统一读取这个配置项。这样换机器部署时只改配置文件，不需要动代码。

4.5 异常处理要做到“前端只看格式，不用猜原因”

后端全局异常处理是很容易被新人忽略的点。如果每个 Controller 都自己 try-catch，代码会非常冗余，而且异常返回格式很难统一。

建议实现一个@RestControllerAdvice全局异常处理器，把业务异常、参数校验异常、未知异常三类分开处理：

• 参数校验异常：返回 400 和具体提示
• 业务异常：返回自定义业务错误码
• 未知异常：返回 500 和“系统繁忙”，但把详细错误记录到服务端日志，不能直接返回给前端

很多安全实践都会强调这一点：不要把数据库堆栈信息直接抛到页面，否则容易暴露表结构、连接串等内部信息。

4.6 安全边界：科普站也不能裸奔

如果是内容型网站，没有复杂的交易体系，很多人会觉得安全不用太在意。但至少要考虑：

• SQL 注入：使用 MyBatis-Plus 或 JPA 的自带参数绑定，尽量不拼接 SQL
• XSS 脚本注入：富文本内容要过滤<script>标签
• 越权访问：后台管理接口必须校验管理员登录状态
• 文件上传：只允许指定格式、指定大小，且不能把上传目录放在 Web 根目录下

运维层面的数据库密码也不要硬编码在代码里，可以通过环境变量注入。就算项目再简单，也不想上线第一周就被人通过弱口令扫进后台吧。

5. Vue3 前端联调：别把页面做完才想起后端

5.1 先做 axios 封装，再写组件

Vue3 项目通常用 axios 请求后端接口。直接在每个组件里axios.get(...)不是不能跑，但每次都要写 baseURL、超时时间、错误提示，重复代码太多。

比较可维护的做法是拆出一个src/utils/request.js：

import axios from 'axios' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.response.use( (response) => { const res = response.data if (res.code !== 200) { console.error(res.message) return Promise.reject(new Error(res.message)) } return res.data }, (error) => { console.error(error) return Promise.reject(error) } ) export default request

这样页面调接口时，拿到的是后端返回的data字段，不需要在每个页面判断code。

5.2 页面结构按“信息公开”类网站来划分

科普网站的典型前端页面包括：

• 首页：展示头图、推荐内容、重点栏目入口
• 列表页：按分类展示文章标题和摘要
• 详情页：展示正文内容，支持浏览量累计
• 搜索页：按关键词检索内容
• 后台管理页：管理分类、维护文章、查看上传记录

这种结构下，路由设计可以用 Vue Router 懒加载，避免首屏一次性加载全部页面代码：

const routes = [ { path: '/', component: () => import('@/views/Home.vue') }, { path: '/article/:id', component: () => import('@/views/ArticleDetail.vue') }, { path: '/admin', component: () => import('@/views/admin/AdminLayout.vue'), children: [ { path: 'article', component: () => import('@/views/admin/ArticleManage.vue') } ] } ]

5.3 开发时的跨域问题：别急着“关闭跨域”

本地开发时，前端在 5173 端口，后端在 8080 端口。浏览器直接请求会出现跨域问题。

有两个常见处理方式：

• SpringBoot 后端配置允许跨域
• 前端 Vite 开发服务器配置代理，把/api转发到后端

实际项目中我强烈建议优先用 Vite 代理，因为这样前端代码里只用写/api，不需要写死http://localhost:8080。

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

这样在生产环境时，只需要让 Nginx 把/api转发到后端，前端代码不需要改。一旦你把localhost:8080写死在代码里，部署到服务器后可能还要再改一遍代码，而且很容易漏改。

5.4 富文本编辑器选择要克制

科普站后台肯定要支持正文编辑。前端富文本编辑器有好几种，常见的有 wangEditor、TinyMCE、Quill 等。具体选哪一个要结合团队熟悉程度，而不是只看功能列表。

但对前端来说，更重要的往往不是编辑器的“炫酷”，而是编辑器产物如何传给后端，再回显到详情页。如果后端是直接把 HTML 保存进LONGTEXT字段，那么详情页就不能用 Vue 默认的文本插值展示，而要使用v-html渲染。使用v-html前要确保内容经过过滤，否则脚本注入会成为一个风险点。

注意：富文本内容如果直接渲染为 HTML，至少要过滤掉<script>、事件属性这类危险片段。很多正规系统的做法是后端入库前做白名单过滤，而不是单纯依赖前端编辑器的输出。

6. 部署上线与排查链路：单次跑通不等于项目完成

6.1 常见的“开发能跑，部署就挂”场景

本地开发时，Java 后端和 Vue 前端同时在电脑上运行，切换路径很方便。但很多项目往往在上线阶段才出现下面这些问题：

• 服务器没有安装 JDK17，只有 JDK8
• 数据库字符集不是 utf8mb4，导致中文乱码
• 后端接口能被本地访问，但服务器上接口超时
• 前端打包后的dist文件不知道应该放到哪个目录
• 数据库密码、上传目录都没有修改，直接沿用了本机配置
• 防火墙没放行 8080 端口，接口访问不通

这些坑在部署前都可以提前处理。一个比较稳妥的部署是：后端打包成jar，通过java -jar启动；前端执行npm run build后把dist目录交给 Nginx 托管。

6.2 用 Nginx 做页面托管和反向代理

生产环境里，域名或 IP 的 80/443 端口通常由 Nginx 监听，前端静态页面由 Nginx 返回，接口请求/api/...则反向代理到 SpringBoot 的 8080。

Nginx 配置示例：

server { listen 80; server_name localhost; root /usr/share/nginx/html; index 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; } location / { try_files $uri $uri/ /index.html; } }

这里需要注意：Vue Router 如果是 history 模式，刷新详情页路径时容易 404，所以一般要加try_files回退到index.html。

6.3 上线排错按四层来查

遇到生产环境问题，最容易犯的错是“只看第一层”。当你发现用户访问首页很慢，应该按下面的链路逐层排查：

1. 浏览器层：F12 查看 Network，看资源加载是否超时、接口状态码是什么
2. Nginx 层：查看 Nginx 错误日志和访问日志，确认请求是否到了 Nginx，有没有 502、504
3. SpringBoot 层：查看应用日志，确认接口有没有被调用，调用后有没有抛异常
4. MySQL 层：确认数据库连接是否正常，慢查询日志中有没有消耗较大的 SQL

如果接口返回 500，先看后端日志文件里完整的堆栈，不要反复刷新页面猜原因。很多部署问题最后都集中在三处：端口、目录权限、数据库连接串。

注意：排查问题时先确认“哪一层出了问题”，再决定“要不要改代码”。很多时候不是程序逻辑错误，而是服务器防火墙没有放行端口、数据库连接密码错误，或者上传目录没有写权限。

6.4 部署后必须补的基础设施

项目一旦上线，“能打开首页”只是起点。后面还要补齐：

• 日志：保存 service.log 和 error.log，方便追溯
• 备份：定期备份 MySQL 数据库和上传目录
• 进程守护：避免 Java 进程意外退出后没人拉起
• 配置文件外部化：数据库密码、上传目录不要打进 jar 包
• HTTPS：如果有正式域名，尽早配置证书，避免内容被篡改

很多人以为把这些放到“以后再说”，但对内容型网站来说，数据库和上传目录就是核心资产。一旦服务器磁盘损坏，前端代码可以重新打包，数据丢了很难恢复。

7. 长期运营视角：从“开发完成”到“真正能用”

7.1 内容维护需要的是“发布工作流”，不是改代码

科普网站在上线后，内容运营频率可能远高于代码更新频率。如果每一次编辑内容都要重启后端，那这个项目就一定走不长。

所以开发阶段就要把“内容发布工作流”做好：

• 分类维护可以由管理员完成
• 文章支持保存草稿、上架、下架
• 上传的图片能统一管理
• 后台操作留下操作日志，防止误改内容

这些功能看起来不起眼，却是决定一个后台系统能不能长期承担业务的关键。只写内容展示接口、不做后台维护，本质上还是一套“高立工程”，不是产品。

7.2 性能优化要按顺序做

科普网站在没有很高并发时，不建议一上来就引入 Redis、消息队列、分库分表。更合理的优化顺序是：

1. 数据库加合适索引
2. 列表接口只返回必要字段，避免SELECT *
3. 静态资源交给 Nginx 或对象存储，不经过 Java 层
4. 热点列表接口加本地缓存或 Redis 缓存
5. 单机扛不住再考虑集群与负载均衡

很多科普网站的流量高峰来自活动推广，平时访问量可能不高。对这种流量模型，“弹性伸缩”远没有“处理突发时能快速加缓存和限流”重要。

7.3 “国之动力科普网站”这类内容更适合沉淀成内容资产

如果把这类网站仅仅看作“给用户看的几个页面”，那后续数据的价值就非常有限。但如果你把它当做一个可以长期扩充的内容平台，你会发现真正有价值的是数据关系：

• 文章与栏目之间的归类和变更记录
• 不同专题之间的内容关联
• 文章浏览数据与用户兴趣之间的关系
• 图片、视频、附件等资源是否被规范管理

比如“国之动力”如果希望后续推出答题活动、专题展览、知识图谱，底层数据依然来自最原始论文档表和分类表。前期建表时留好扩展字段，比到时候重构数据库要省太多成本。

7.4 一个小团队的落地路径建议

如果你是一两个人负责这个项目，我的建议是不要试图“一步到位分微服务”，也不要同时引入十几个中间件。按这个顺序走：

1. 第一个里程碑：SpringBoot 空后端 + Vue3 空前端 + MySQL 建库成功
2. 第二个里程碑：跑通一个文章列表接口和一个 Vue 页面
3. 第三个里程碑：完成分类、文章详情、后台维护
4. 第四个里程碑：部署到服务器，配上 Nginx、日志和数据库备份
5. 第五个里程碑：根据真实运营反馈优化检索、上传和热门内容

如果一开始就想把用户、权限、统计、消息中心全部做完，那项目大概率会拖到失去上线时机。

最后说一点实际经验

我见过很多内容型网站项目，最后陷入泥潭的原因不是某个框架难学，而是没有把“数据模型、接口约定、上线运维”这三件事当成项目核心来做。SpringBoot3 + Vue3 + MySQL 能让你很快跑起来一个页面，但要让网站真正长期运营，建立一套稳定的内容发布流程，理解内容数据的归属和变更方式，处理部署后的端口、日志、上传目录和数据库备份，才是更有价值的部分。

如果你刚接触到类似“国之动力科普网站”这种内容型项目，先从最小闭环开始：一篇文章、一个分类、一个列表页、一个详情页。把这个串起来，再慢慢加权限、热门推荐和后台运营能力。做这种网站，最危险的，从来都不是“技术不够新”，而是以为页面能打开就算做完了。