环保网站管理系统开发复盘：SpringBoot+Vue+MyBatis+MySQL企业级实践

最近刚把手头这套环保网站管理系统源码完整整理了一遍，从数据库设计到前后端联调，踩了不少坑也沉淀了不少经验。这套系统用的正是 SpringBoot + Vue + MyBatis + MySQL 这套企业级黄金组合，前端页面以 HTML 为底座，完整覆盖了环保资讯展示、监测数据可视化、后台管理、权限控制等场景。如果你正打算做类似的信息管理系统，或者刚接触前后端分离开发，这篇复盘应该能帮你省掉不少弯路。

1. 环保网站管理系统整体设计与技术选型

1.1 这套系统到底解决什么问题

先别急着看代码，得想清楚环保网站管理系统这类项目存在的意义。很多初学者会觉得无非就是做一个新闻发布网站，放几篇环保文章、贴几个大气质量指数就完事了。实际落地到企业级场景，需求完全不是这么简单。

我做过的这类系统，客户通常是环保科技公司、环境监测站、环保公益组织，甚至是一些需要对外展示 ESG 数据的生产企业。他们的核心诉求分三层：

第一层是信息展示，也就是环保政策法规、行业资讯、企业环保动态这些内容需要有一个规范的发布渠道。第二层是数据呈现，比如空气质量指数、水质监测指标、碳排放趋势、垃圾回收统计等，定期更新并可视化展示。第三层是管理能力，管理员要能维护栏目、审核文章、管理注册用户、配置轮播图，甚至要给不同角色分配不同的操作权限。

这三层诉求叠加在一起，“企业级”三个字就落到了实处：它不是一个静态网页，而是一个有后台、有数据库、有权限体系、可长期运维的动态网站系统。所以在我设计技术方案的时候，前端展示只是表象，真正的核心是后台管理能力和数据流转的安全性。

1.2 为什么选 SpringBoot + Vue + MyBatis + MySQL

这套组合在中小企业级项目里基本是标配，但每个选型背后都有具体理由。

SpringBoot 解决的是后端开发效率的问题。传统的 SSM 项目要写大量的 XML 配置，光是配置文件就能铺满一个文件夹。SpringBoot 的自动装配机制把这些繁琐的部分全部接管了，我只需要在application.yml里写上数据源、端口等关键参数，框架自己会完成其余的初始化。对于环保网站这种业务逻辑不算特别复杂、但涉及模块比较多的系统，SpringBoot 的快速开发和内嵌 Tomcat 特性非常合适，打一个 Jar 包丢到服务器上就能跑，运维成本极低。

Vue 这边，我用的是 Vue 2 + Element UI 的组合。这套组合在国内企业项目里的成熟度非常高，文档全、组件丰富、踩坑案例多，任何想不到的疑难杂症基本都能搜到解决方案。Vue 的核心价值在于它让前端变成了组件化的开发模式，一个环保数据看板、一个新闻列表、一个表单弹窗，都是一个独立的组件。组件之间互不干扰，需求变更时只需要改对应组件，不会牵一发动全身。

MyBatis 是数据持久层的老将了。选择它而不是 JPA，关键在于 SQL 的可控性。环保监测数据经常要写比较复杂的统计 SQL，比如按月份聚合某个监测站点的平均 PM2.5 数值，或者跨表联查文章分类和评论数量。MyBatis 允许我手写 SQL，虽然多写几行代码，但性能和灵活性都是完全可控的。另一个细节是，MyBatis 的动态 SQL 标签非常实用，比如<if>标签可以根据前端传参动态拼接查询条件，一个方法就能搞定原本要写三个 DAO 方法才能完成的模糊搜索。

MySQL 没什么好争议的，开源、稳定、SQL 标准兼容性好，配合 Navicat 或者 MySQL Workbench 做可视化管理非常顺手。对于环保网站系统的数据量级，MySQL 的性能和可靠性完全够用。

提示：如果你所在团队对数据库锁机制和事务隔离级别不太熟悉，不要迷信微服务和大数据架构。先用好单一 MySQL 数据库，做好索引和事务管理，就已经能支撑绝大多数业务场景了。

2. 数据库设计与后端架构实现

2.1 核心数据表结构设计

数据库是整个系统的基础，表结构设计的好坏直接决定后期开发效率。这套环保网站管理系统，我在设计时围绕着“内容”和“用户”两条主线展开。

内容主线是环保资讯的管理，我拆出了这样几张表：

• category栏目表：存储栏目的名称、父级 ID、排序值、是否启用。注意要用自关联的方式实现无限级分类，这样以后要加“政策法规 -> 地方政策 -> 北京市政策”这种多层栏目也不需要改动表结构。
• article文章表：核心字段包括标题、摘要、封面图、正文内容、所属栏目 ID、作者、浏览量、是否置顶、状态（草稿/已发布/已下架）、发布时间。这里有一个容易被忽略的设计细节：正文内容字段一定要用longtext类型，不要用varchar，因为环保类的深度报告文章动辄几万字，varchar撑不住。
• article_comment评论表：关联文章 ID 和用户 ID，存评论内容和审核状态。

用户主线围绕权限体系展开：

• user用户表：存储用户名、密码（加密后）、昵称、头像、手机号、邮箱、状态。
• role角色表：管理员、编辑、普通用户等角色。
• user_role用户角色关联表：因为一个用户可能有多个角色，需要多对多关联。
• menu菜单表：存储系统侧边栏的菜单项，每个菜单对应一个前端路由。
• role_menu角色菜单关联表：控制不同角色能看到的菜单项，这是前端权限控制的基础。

除此之外，还要有一张monitor_data监测数据表，存储各个监测站点的环境指标历史数据。这张表的设计要特别注意，我建议使用“一行一条指标”的方式，而不是把 PM2.5、PM10、二氧化硫、臭氧都放在一行。虽然宽表查询简单，但一旦监测指标类型增加（比如新增了噪音监测），宽表就要 ALTER TABLE 加列，而长表只需要往指标类型字段里加一条记录。长表配合GROUP BY和PIVOT思路，在报表展示时可以灵活转换成需要的形式。

2.2 SpringBoot 工程结构分层

后端工程结构我采用的是经典的四层架构：Controller 层、Service 层、Mapper 层、Entity 层。

Controller 层只负责接收 HTTP 请求、参数校验、调用 Service 并返回统一格式的响应体。我没有让 Controller 里出现任何业务逻辑，哪怕只是简单的时间格式化，也放到 Service 里处理。这样可以保证 Controller 层代码非常薄，接口清单一目了然。

Service 层承载全部业务逻辑。以文章发布为例，Service 里要做的事包括：校验栏目是否存在、校验用户是否有权限、处理封面图上传（存本地路径还是 OSS）、生成文章摘要（如果没填就从正文自动截取）、插入文章记录、更新栏目的文章数量统计。这些逻辑如果不拆到 Service 层，全都堆在 Controller 里，后期一个接口的代码量就能超过 200 行，维护起来非常痛苦。

Mapper 层是 MyBatis 的接口层，只定义方法签名和 SQL 映射。我在这个系统里没有使用 MyBatis-Plus，原因是项目本身的通用 CRUD 并不算多，手写 SQL 反而更灵活，也更能控制查询的字段列表，避免SELECT *带来的性能问题。

Entity 层是数据库表的映射实体。这里有一个我强烈建议的实践：不要直接在 Entity 上做参数校验，而是单独建 DTO（Data Transfer Object）类接收前端参数。因为前端的入参往往还包含确认密码、验证码等不需要持久化的字段，如果都塞进 Entity，会误导后端的逻辑判断。

2.3 SpringBoot 核心配置细节

application.yml是后端配置的中枢。我在这套系统里的核心配置如下：

server: port: 8080 servlet: context-path: /api spring: datasource: url: jdbc:mysql://localhost:3306/env_protection?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.environment.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

有几个配置项值得单独拿出来说一下。

context-path: /api是我给所有后端接口加的统一前缀。这样前端请求地址统一是/api/article/list这种格式，在 Nginx 反向代理的时候可以很方便地把/api开头的请求转发到后端服务，而其他静态资源请求走前端服务器。这个设计在部署阶段能避免大量跨域问题，强烈推荐。

map-underscore-to-camel-case: true这个配置能自动把数据库字段名create_time映射为实体属性createTime。如果不开启，你就得在每一个 XML 映射文件里手动写resultMap做字段映射，那工作量是非常可怕的。

log-impl: org.apache.ibatis.logging.stdout.StdOutImpl是开发阶段的利器。开启后，每一次 SQL 执行都会在控制台打印完整的 SQL 语句和参数列表，排查问题的时候一眼就能看出 SQL 拼错了还是参数传错了。生产环境记得关掉，否则日志文件会迅速膨胀并且打印大量敏感信息。

2.4 MyBatis 映射文件编写要点

在 MyBatis 的 XML 映射文件里，有几个我在实际开发中反复使用的技巧。

第一个是动态 SQL。比如环保监测数据的查询，输入条件包括监测点名称、开始时间、结束时间、指标类型，但用户未必每一项都填。用<if>标签可以优雅地处理这种情况：

<select id="selectMonitorData" resultType="MonitorData"> SELECT * FROM monitor_data <where> <if test="stationName != null and stationName != ''"> AND station_name LIKE CONCAT('%', #{stationName}, '%') </if> <if test="startDate != null"> AND monitor_time &gt;= #{startDate} </if> <if test="endDate != null"> AND monitor_time &lt;= #{endDate} </if> <if test="indicatorType != null and indicatorType != ''"> AND indicator_type = #{indicatorType} </if> </where> ORDER BY monitor_time DESC </select>

注意 XML 里的小于号<必须用转义字符，直接用<会导致 XML 解析报错。这个坑我初期踩过好几次，排查了半天才发现是符号问题。

第二个是分页查询。我在这里没有引入 PageHelper 插件，而是自己算 offset 和 limit。前端传pageNum和pageSize，Service 层计算offset = (pageNum - 1) * pageSize，然后传给 Mapper。同时用<select>返回的总条数单独统计。好处是 SQL 完全可控，分页逻辑一眼就能看懂。

第三个是一对多关联查询。比如一篇环保文章关联多个标签，用嵌套查询的collection标签可以实现。但这里要提醒一点：当数据量大的时候，嵌套查询会产生 N+1 问题，即先查文章列表，再逐条查询每篇文章的标签。实际项目中我会把标签直接冗余存储到文章表的一个字段中，用逗号分隔，虽然违反了第三范式，但查询性能大幅提升，对于标签这种低频变更的数据是值得的。

3. 前端页面与交互实现

3.1 Vue 工程搭建与环境配置

前端工程我选择的是 Vue CLI 创建的标准工程结构。Node.js 版本建议使用 14.x 或 16.x，这是与 Vue 2 生态兼容最稳定的版本。Vue 3 和 Vite 虽然更新，但这套系统基于的是 Element UI 组件库，它与 Vue 2 的配合成熟度远高于 Vue 3，这也是我选择 Vue 2 的根本原因。

环境配置中，最重要的一个文件是根目录下的.env.development和.env.production：

# .env.development NODE_ENV=development VUE_APP_BASE_API=http://localhost:8080/api # .env.production NODE_ENV=production VUE_APP_BASE_API=/api

这个配置的作用是区分开发环境和生产环境的接口地址。开发时前端跑在localhost:8081，后端跑在8080，存在跨域；生产环境通过 Nginx 做反向代理，前端和后端用同一个域名，接口地址只需要写成相对路径/api即可。

封装axios实例的时候，我习惯把 BASE_URL 设置为process.env.VUE_APP_BASE_API，这样代码里不需要到处写死接口地址。同时统一处理请求拦截器和响应拦截器：请求拦截器里从localStorage取出 token 并加到请求头；响应拦截器里判断 HTTP 状态码，如果返回 401 就跳转到登录页，如果返回业务错误码就弹出提示。这样一来，业务代码里只需要关心成功的逻辑，异常处理全部收敛到拦截器里，代码会干净很多。

3.2 核心页面组件拆解——以环保数据看板为例

环保网站的前端页面里，最具备技术含金量的当属数据看板页面，也就是用图表展示各类环境指标。这里我使用的是 ECharts 做数据可视化，配合 Vue 的响应式数据绑定。

拆解一下这个页面的实现思路。页面顶部是筛选区，包含监测站点下拉框、日期范围选择器、指标类型选项卡；中部是四个统计卡片，展示当前日期的空气质量指数、水质达标率、碳排放量、垃圾回收量四组核心数据；下半部分是一个折线图和一个柱状图，分别展示近 30 天的 PM2.5 趋势和各站点的指标对比。

在 Vue 组件中，这个页面的关键逻辑是数据请求和图表渲染的联动：

async function fetchMonitorData() { loading.value = true try { const res = await api.get('/monitor/statistics', { params: { stationId: stationId.value, startDate: dateRange.value[0], endDate: dateRange.value[1], indicator: indicator.value } }) const data = res.data lineChartOption.value = buildLineOption(data.pm25Trend) barChartOption.value = buildBarOption(data.stationCompare) cardData.value = data.cardSummary } finally { loading.value = false } }

有一点容易翻车的地方：ECharts 实例的销毁。如果你在 Vue 组件中直接echarts.init(dom)创建实例，组件销毁时一定要调用instance.dispose()释放资源，否则在页面频繁切换时会出现内存泄漏，浏览器卡顿。我当时封装了一个useECharts的 composable，在onUnmounted钩子里自动执行dispose，省心很多。另外要注意，容器元素在数据加载完成之前可能没有宽度，导致图表渲染空白，通常的做法是把图表初始化放在nextTick回调里，或者在容器上设置一个显式的 height。

3.3 后台管理页面的权限控制实现

后台管理涉及到路由权限。我用的是前端路由守卫 + 后端菜单接口双重控制方案。

具体做法是这样的：用户登录成功后，后端根据用户的角色返回可访问的菜单列表和按钮权限标识。前端把这些信息存储到 Vuex 中，在路由守卫beforeEach钩子里，根据当前用户的权限列表动态添加路由：

router.beforeEach(async (to, from, next) => { const token = getToken() if (!token) { if (to.path === '/login') { next() } else { next('/login') } return } if (!store.state.user.permissions.length) { const permissions = await store.dispatch('user/getPermissions') const accessRoutes = generateRoutes(permissions) router.addRoutes(accessRoutes) next({ ...to, replace: true }) } else { next() } })

这里的generateRoutes函数是核心，它把后端返回的菜单数据转换成 Vue Router 的路由配置。转换过程中注意处理组件路径的映射，后端返回的是system/article这样的路径，前端要把它映射为() => import('@/views/system/article.vue')。

按钮级别的权限控制，我实现了一个自定义指令v-permission，在按钮上写上v-permission="'article:add'"，指令内部判断当前用户是否拥有该权限标识，没有就自动移除该按钮的 DOM 节点。这样后端只需要配合返回按钮权限标识，前端的权限控制就能精确到每一个操作按钮。

这套权限方案最直观的好处是：新增一个角色时，只需要在后台管理界面上勾选它能访问的菜单和按钮，完全不需要改前端代码。对我做这一类多客户定制的环保管理系统来说，这种灵活性至关重要，因为不同的客户对“管理员能否删除文章”“编辑能否上传视频”这些细粒度权限的要求都不一样。

4. 前端 HTML 静态页面与 Vue 工程的无缝结合

4.1 HTML 语义化在环保门户首页中的应用

提到 HTML，很多人觉得 Vue 工程里都是组件模板，用不到传统 HTML 的知识。其实不然，环保网站的对外门户首页（用户端首页）对 HTML 语义化的要求很高，因为这里直接关系到 SEO 效果。

访客在搜索引擎搜索“城市空气质量实时数据”“环保政策解读”这类关键词时，搜索引擎爬虫读取的是 HTML 源码。如果整个页面都是 JavaScript 动态渲染，爬虫抓到的就是空壳页面，SEO 排名会非常吃亏。所以我在设计门户首页时，采取了“首屏静态化 + 动态区域按需加载”的策略。

具体来说，页面的头部导航、横幅轮播、政策解读入口这些对 SEO 友好的模块，用传统的 HTML 标签预先写死在页面中，保证爬虫能抓到内容。而实时空气质量、新闻列表这类需要从后端加载的数据区域，用一个空容器占位，然后通过 Vue 的生命周期钩子mounted中请求接口填充数据。

语义化标签的使用也很有讲究。整个页面的结构我使用的是header、nav、main、section、article、aside、footer等标准标签，替代单纯的div堆叠。这么做不只是为了通过 W3C 验证，更重要的是让爬虫能正确识别页面的主题区域和内容权重。特别是article标签，它会告诉搜索引擎这里是一篇独立完整的文章，有助于提高收录和排名。

在编写 HTML 时，meta标签的完整性也是我在这个项目里比较在意的细节。

<!doctype html> <html lang="zh-cn"> <head> <meta charset="utf-8"> <meta name="description" content="环保网站管理系统，提供实时环境监测数据、环保政策法规、绿色产业资讯，助力生态文明建设"> <meta name="keywords" content="环保,环境监测,空气质量,绿色低碳,环保政策"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>绿色生态 - 环保信息服务平台</title> </head>

lang="zh-cn"这个属性经常被忘记，但它直接影响浏览器对页面语言的判断和语音合成工具的发音选择。description和keywords虽然对 SEO 的权重影响不如早年那么大，但作为页面的身份标识，仍然建议认真填写。viewport标签则是移动端适配的基础，不写这个，手机浏览器会默认按 980px 宽度渲染页面，导致布局严重错乱。

4.2 静态资源管理与构建优化

Vue 工程里 HTML 模板只是入口，真正的资源加载链路是：public/index.html是模板文件，Webpack 构建时会自动把所有 JS 和 CSS 文件注入到这个 HTML 中。我在这个项目里做了一些构建层面的优化实践。

第一项是路由懒加载。环保门户首页虽然是静态化优先，但后台管理的几十个页面如果全部打包到一个 JS 文件里，首屏加载体积可能超过 3MB，在弱网环境下体验极差。通过路由懒加载，每个路由组件独立成块，访问到对应路由时才加载对应 JS 文件：

const ArticleList = () => import('@/views/article/list.vue') const ArticleEdit = () => import('@/views/article/edit.vue') const MonitorDashboard = () => import('@/views/monitor/dashboard.vue')

第二项是图片资源的处理。环保网站最不缺的就是蓝天绿水的高清图，一张未压缩的图片可能有 3-5MB。我在 Webpack 配置中加入了image-webpack-loader做压缩，同时把较小的图片转成 base64 内联到 JS 中，减少 HTTP 请求次数。更大的图片则上传到对象存储，并开启 CDN 加速，前端只用缩略图 URL。

第三项是公共 UI 库的按需导入。Element UI 如果全量引入，体积能到 600KB 以上。我在babel.config.js中配置了babel-plugin-import，实现按需加载，最终打包体积比全量引入减少了近 60%。具体的配置方式，网上资料非常多，这里不再赘述代码，只提醒一个坑——按需加载后，如果你在代码里用了某个组件但忘了在插件配置中声明，构建时是不会报错的，但运行时会提示 Unknown component，排查起来比较隐蔽。我的习惯是新建一个element.js文件集中注册所有用到的组件，一目了然。

4.3 响应式适配的取舍与实现

环保网站的门户首页面向普通公众，用户访问的设备五花八门，从 4K 大屏到手机都可能，所以响应式适配不能马虎。

我的方案是基于 CSS 媒体查询 + Flex 布局 + 相对单位的三层组合策略。首先，页面主体容器宽度不写死固定像素，而是用max-width: 1200px; width: 100%来约束，在小屏设备上自动收缩。其次，使用媒体查询在不同断点（768px、992px、1200px）下调整导航栏的排列方式和卡片栅格布局。最后，字体大小采用rem单位，配合根元素的font-size动态调整。

有一个实践中的经验教训：不要把三个断点视为三条平行线，而是要在设计稿阶段就考虑内容在中间断点下的表现。比如空气质量指数卡片在 PC 端是一行四个，在 768px 以下变成一行两个，但在 992px 时如果直接排四个就会显得拥挤。我的处理方式是设置四个断点，在 992-1200px 之间一行显示两个，1200px 以上才显示四个。这个细节需要在开发时用浏览器开发者工具以不同宽度反复预览调整，不能只写三个断点就完事。实测下来，现如今的用户屏幕尺寸五花八门，多准备一个中间断点能明显减少用户反馈的布局错乱问题。

5. 系统部署与前后端联调实战

5.1 本地开发环境搭建清单

在拿到源码开始运行之前，本地环境需要准备好这些基础软件：JDK 1.8 或 11、Maven 3.6+、Node.js 14.x、MySQL 8.0、Navicat 或 MySQL Workbench。

MySQL 8.0 的安装配置是很多新手第一个卡住的地方，这里单独说明几个容易出问题的点。安装过程中会让你设置 root 密码，安装完成后如果连接报错，最常见的原因是认证插件问题。MySQL 8.0 默认的认证方式是caching_sha2_password，但某些旧版本的客户端工具不支持，需要在命令行中执行一次ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码';才能正常连接。

另一个高频问题是时区配置。如果 JDBC 连接串里没有配置serverTimezone=Asia/Shanghai，连接 MySQL 8.0 时会直接报The server time zone value is unrecognized错误，或者数据时间比本地时间差 8 个小时。除了在连接串中指定，也可以在 MySQL 的my.ini配置文件中设置default-time-zone = '+08:00'。

数据库初始化很简单，我提供了一个env_protection.sql脚本文件，用 Navicat 新建数据库后，运行该脚本就会自动创建全部数据表和预置的初始数据。脚本中包含了管理员账号（admin/admin123，密码是 BCrypt 加密后的）和基础的角色菜单数据，拿来就能直接登录后台。

5.2 前后端跨域与联调方案

开发环境下前后端是两个不同的端口（前端 8081，后端 8080），这必然会产生跨域请求。我的处理方案是在后端单独配置一个 CORS 过滤器，允许特定来源的跨域访问：

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOrigin("http://localhost:8081"); config.addAllowedHeader("*"); config.addAllowedMethod("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

这里有一个细节：如果使用了setAllowCredentials(true)（允许携带 Cookie），那么addAllowedOrigin就不能使用通配符*，必须明确指定来源地址。浏览器在这个问题上是零容忍的，配置不当会直接拦截请求。

生产环境的跨域我则完全交给了 Nginx。前端静态文件由 Nginx 直接托管，后端请求通过反向代理转发：

server { listen 80; server_name your-domain.com; root /usr/share/nginx/html/environment-web; 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; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

try_files $uri $uri/ /index.html这一行是 Vue Router 使用 history 模式时必须配置的，它保证用户在地址栏直接访问/article/detail/1这样的前端路由时，Nginx 能把请求回退到index.html，由 Vue Router 接管并渲染对应页面。你发表的每一步操作，其实都已经在 Vue 的路由表里定义好了对应的地址。

5.3 打包发布实操流程

后端打包，我习惯用 Maven 的命令行工具：

mvn clean package -DskipTests

打包完成后，在target目录下会生成一个 Jar 包，比如environment-server-1.0.0.jar。在服务器上，我使用nohup命令把进程放到后台运行：

nohup java -jar environment-server-1.0.0.jar --spring.profiles.active=prod > application.log 2>&1 &

这里的--spring.profiles.active=prod指定使用生产环境配置，我提前在application-prod.yml里配置好了生产数据库连接和日志记录策略。前端构建则使用：

npm run build

构建产物生成在dist目录中，直接复制到 Nginx 配置的站点根目录即可。

部署时有一个经验值得分享：生产环境的数据库密码不要直接写在application-prod.yml里，可以用环境变量或 Jasypt 加密的方式处理。哪怕服务器内网访问也有被横向渗透的风险，密码明文写在配置文件中总归是不安全的。我在这套系统里使用了 Jasypt 对配置文件中的敏感信息做了加密，启动时通过启动参数传入解密密钥，这样即便有人拿到了配置文件，也看不到真实的数据库密码。

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

6.1 数据库连接相关故障

这类问题在整套系统的故障中占比最高，我整理了几个最常见的情形：

排查数据库连接问题时，我的经验是先用 Navicat 等客户端工具单独测试连接。如果客户端能连上但程序连不上，那基本就是 JDBC 连接串或其他配置的问题；如果客户端也连不上，问题就出在数据库服务本身。这个方法可以快速缩小问题范围。

6.2 SpringBoot 启动失败排查

SpringBoot 启动失败通常会出现一大段红色报错日志，很多初学者一看就慌了。其实最关键的只有一行：APPLICATION FAILED TO START下面紧跟着的Description部分。这里列举两个高频问题。

一个是端口被占用：

Description: Web server failed to start. Port 8080 was already in use.

解决方案很简单：要么关闭占用端口的进程，要么修改server.port改成 8081 或 9090。Windows 下查看哪个进程占了 8080 端口，用命令netstat -ano | findstr 8080找到 PID，再到任务管理器结束对应进程，或者用taskkill /PID 进程号 /F强行结束。

另一个是 MyBatis 映射文件路径错误：

Description: Invalid value type for attribute 'factoryBeanObjectType': java.lang.String

这通常是因为mapper-locations配置的路径与实际文件位置不一致。检查resources/mapper目录下是否有对应的 XML 文件，以及路径中的通配符classpath*:mapper/*.xml写法是否正确。还有一个很隐蔽的问题：XML 文件的目录层级如果和 package 声明的不一致，也会导致扫描不到，所以尽量保持 XML 放在resources/mapper平铺目录中，不要嵌套过深。

6.3 前端常见运行问题

前端的典型问题第一个是npm install装依赖时各种报错。解决这类问题的第一步是确认 Node.js 版本是否与项目要求一致。Vue 2 项目在 Node 17+ 上容易出现Error: error:0308010C:digital envelope routines::unsupported错误，这是 OpenSSL 版本导致的。最快的解决方案是使用 Node 14 或 16 重新安装，或者设置环境变量NODE_OPTIONS=--openssl-legacy-provider。不过最稳妥的做法还是锁定 Node 版本，项目根目录有.nvmrc文件，写清楚要求的 Node 版本。

第二个是接口请求 404。排查思路是：先看浏览器开发者工具中 Network 面板的请求完整 URL，确认是否带上了/api前缀；再确认后端 Controller 的@RequestMapping映射路径；最后检查后端是否启动了对应的上下文路径。前端和后端的路由路径加在一起，必须完全匹配。

第三个是页面白屏。打开控制台如果看到Uncaught SyntaxError: Unexpected token '<'，说明服务器返回了 HTML 而不是 JS 文件，这通常是 Nginx 或静态资源服务器没有正确指向dist目录。如果看到Cannot read property 'xxx' of undefined，多半是接口返回的数据结构与前端期望的不一致，先打印接口返回内容核对字段名是否对得上。

6.4 MyBatis 映射文件高频错误

我在 MyBatis 上踩过的坑太多了，这里挑三个典型的：

第一个是Invalid bound statement (not found)，提示找不到某个 Mapper 方法对应的 SQL 语句。检查方向包括：接口方法名与 XML 中的id是否完全一致；XML 文件的namespace是否与接口全限定名一致；mapper-locations是否扫描到了 XML 文件路径。这三个点排查完，基本都能解决。

第二个是传参数时There is no getter for property named 'xxx' in class 'java.lang.Integer'。这个错误几乎都是因为 Mapper 方法传了多个参数但没有加@Param注解。在 MyBatis 中，单个基本类型参数不需要注解，但如果方法签名是List<Article> selectList(String categoryId, Integer status)，就必须加上@Param("categoryId")和@Param("status")，否则 MyBatis 无法在 XML 中通过参数名直接引用。

第三个是查询结果出现重复数据。这通常不是 SQL 的问题，而是表连接时一对多关系导致的笛卡尔积。比如查文章同时关联标签表，一篇有 3 个标签的文章，连接后会产生 3 行结果。解决办法是在 XML 中使用distinct去重，或者改用子查询的方式。实际开发中我会尽量规避不必要的外连接，把需要聚合的数据放到 Service 层单独查询组装。

7. 这套系统的后续扩展方向

系统目前的基础功能已经完整，但如果你拿到手之后想继续完善，我认为有两个方向最值得投入。

第一个方向是数据可视化大屏。环保行业对数据大屏的需求非常旺盛，无论是政务汇报、企业展厅还是环保产业园的指挥中心，都需要一块直观展示环境数据的屏幕。现有系统已经有了monitor_data表存储的历史数据，你只需要新增一个大屏页面，使用 ECharts 的visualMap组件和地图组件，就可以把数据渲染到百度地图或高德地图上，在地图上以热力点的形式标注各个监测站的实时数据。这个功能在客户演示时非常加分，而且技术难度并不大。

第二个方向是引入工作流审批机制。目前文章发布的操作是“编辑直接发”还是“编辑提交后台管理员审核”，取决于业务需求。如果客户需要多级审核（比如编辑 -> 部门主管 -> 管理员），就需要引入工作流引擎。这套系统的用户、角色、权限体系已经打好了底子，接入流程引擎只是增加一张流程定义表和一张审批记录表，在前端增加一个审批弹窗组件，改动范围可控。

还有个实用的小改进：消息通知。当前系统的架构中并没有通知模块，如果加上操作日志和站内信功能，可以很好地记录每一次管理操作，并且当有新的待审核文章时可以推送给管理员。这块实现起来也不复杂，一张sys_log表加一张message表就够了。

我在实际做同类项目的时候，客户需求总是源源不断，从“帮我加一个下载中心”到“能不能做个移动端适配”，再到“加一个环保知识答题小程序”。正因为这套系统的基础架构合理、模块边界清晰，每一个新需求都能比较平滑地接进来，这也是当初在架构设计上多花心思换来的长期收益。

做一个企业级系统确实需要处理好很多工程细节，从数据库字段类型到 Nginx 配置的路径回退，任何一个环节敷衍了事，都会在生产环境的某个时刻以某种意想不到的方式“回报”你。希望这次的分享能对正在做或者准备做类以系统的朋友有一些实际帮助。