企业官网建设流程全解析

搞这个项目之前，我本来接的是另一个选题，结果用户甩过来一个标题：“JSP基于生理参数采集的社区监护系统”。说实话，第一眼我是不太想碰的——JSP这技术在2025年看来确实有点“老古董”的味道，但你真把需求拆开看，会发现这套东西在高校课程设计、毕业设计、甚至是一些中小型社区医疗信息化项目里，至今还有大量的存量需求和实战价值。它不是什么炫酷的前后端分离架构，却能让人把Java Web最核心的那套东西——Servlet生命周期、Session状态管理、JDBC数据库交互、MVC分层思想——从头到尾撸一遍。

这篇文章我不打算给你堆概念，就围绕这个社区监护系统，讲讲从需求拆解、数据库设计、核心模块实现，到环境搭建、调试部署、踩坑排查的完整过程。尤其是标题里挂着的“程序+源码+数据库+调试部署+开发环境”这几个词，每一个我都展开说说里面的门道。如果你想拿这个项目练手、做课设、或者想把它改造成能跑进真实场景的监护系统，这篇内容能让你少走不少弯路。

1. 项目背后的需求与选题逻辑

1.1 社区监护到底是什么场景

先说清楚这个系统要解决什么问题。社区监护，顾名思义是把医疗监护的场景从医院病房延伸到社区和家庭。重点服务对象是慢性病患者、独居老人、术后康复人群，这类人群不需要24小时躺在医院，但他们的生理指标——心率、血氧、血压、体温——需要被持续、规律地记录和观察。

如果靠人工登记，社区医护人员的负担会非常大，而且数据零散、难以形成趋势分析。所以这类系统的核心价值有两个：一是把生理参数的采集和记录自动化，二是让社区医护人员能在后台高效地查看、筛选、预警异常数据。

这个项目采用的方案是B/S架构，也就是浏览器/服务器模式，JSP负责动态页面展示，Servlet处理业务逻辑，后端连接MySQL数据库做持久化存储。虽然技术在当下看来不算新，但它把整个数据流的闭环跑通了：前端采集页面 → 请求转发到Servlet → JDBC读写数据库 → JSP渲染回显结果。这个闭环理解了，Java Web的地基就打牢了。

1.2 为什么这种老技术栈还有学习价值

我见过不少新手一上来就学Spring Boot、微服务、Docker，结果连HTTP请求怎么被处理、Session怎么维持、数据库连接怎么管理都说不清楚。JSP这套技术栈笨是笨了点，但它“透明”——没有那么多自动配置和注解魔法，每一步你都看得见摸得着。

以这个社区监护系统为例，它涉及的技术点非常典型：基础的增删改查、分页查询、按条件筛选、数据可视化展示（比如用ECharts画心率趋势图）、管理员和普通医护人员的权限区分，再加上生理参数异常时的预警提醒。这些功能无论是用JSP还是Spring Boot，业务逻辑是一样的，但用JSP实现一遍，你能真正理解底层是怎么回事。

我在实际操作中最大的体会是：把JSP这套东西跑通之后，再去接触那些封装的框架，你会有一种“原来是这么封装出来的”通透感。所以这个选题对于正在做课程设计、或者刚入行想打基础的人来说，是一个性价比很高的练手项目。

2. 系统整体架构与设计思路拆解

2.1 技术选型：老老实实的JSP + Servlet + MySQL

这个项目的技术栈非常明确：

• 前端展示层：JSP页面配合JSTL标签库和EL表达式，负责数据渲染。同时引入Bootstrap做基础样式，ECharts做图表可视化。
• 业务控制层：Servlet接收前端请求，调用业务逻辑层的方法，完成参数校验、业务处理、跳转控制。
• 数据访问层：JDBC操作MySQL数据库，封装了基础的增删改查工具类（BaseDao），避免每个模块重复写连接代码。
• 数据库：MySQL 5.7或8.0版本，核心表包括用户表、老人/患者信息表、生理参数记录表、异常报警记录表。
• 开发环境：JDK 1.8，Tomcat 8.5或9.0，IDEA 2022或Eclipse，Maven管理依赖（当然也可以用传统的Web项目方式直接把jar包丢进WEB-INF/lib）。

这套组合看起来朴素，但胜在稳定，对环境要求低。Tomcat + MySQL就能跑起来，不像Spring Cloud那一套还需要注册中心、配置中心、网关联动。

2.2 功能模块划分与页面流转

整个社区监护系统的功能模块，大致可以拆成这么几块。

用户认证模块：登录、注册、退出。这个模块决定了系统的入口安全性，领导干部和普通人员的权限也要在这里区分。

老人信息管理模块：社区里被监护老人的基本信息，包括姓名、年龄、联系方式、家属电话、病史摘要、主治医生等。这个模块是其他功能的数据基础。

生理参数采集与记录模块：核心模块。采集心率、血氧、血压（收缩压/舒张压）、体温等参数，支持手动录入（比如上门测量的医护人员填写），也预留了对接硬件设备的接口思路（虽然实际开发中大多是用模拟数据测试）。

异常预警模块：设定各项生理参数的正常范围，一旦录入的数据超出范围，系统自动生成预警记录，在首页醒目标识，同时能在列表中按“已处理/未处理”状态筛选。

数据可视化模块：按时间维度展示某位老人的心率、血压变化趋势，帮助医生判断病情走向。这里用ECharts画折线图，数据从数据库按日期聚合查询。

个人信息管理：对应热搜词里的“jsp个人信息展示页面”——登录用户修改自己的密码、完善联系方式等基本资料。

页面流转是这样的：登录成功后进入首页看板，顶部展示今日采集人数、异常预警数量、待处理任务数等统计卡片；左侧是导航菜单，区分管理员和普通医护人员可见的功能项；点击具体菜单后，右侧内容区加载对应模块的JSP页面。

2.3 为什么选这种结构而不是前后端分离

现在很多新项目都在强调前后端分离，后端出接口，前端用Vue或React渲染。但在这个社区监护系统场景下，用JSP + Servlet反而更合理。原因有三点：

第一，项目的核心价值在业务逻辑和数据管理，页面交互复杂度并不高。用JSP的服务器端渲染，一个请求过去页面和数据一并返回，对低配服务器和弱网环境更友好。

第二，对于一个人开发或者两三个人协作的课设级项目，前后端分离意味着要维护两套工程、两套部署流程，成本和复杂度都翻倍。JSP模式直接一个WAR包扔进Tomcat就完事。

第三，社区医疗机构这类场景，往往不需要极致的交互体验，页面能用、数据准、操作简单才是关键。老技术不代表不能用，关键是匹配需求。

当然，如果你以后想把它升级成前后端分离架构，业务逻辑层和数据访问层完全可以复用，只需要把Servlet改写成返回JSON的接口，再加上一套前端页面就行。这一点我当时做系统的时候就考虑过，所以Service层和Dao层的边界切得比较干净，方便后续扩展。

3. 数据库设计：系统的地基怎么打

3.1 核心表结构与字段设计

数据库设计是这类系统最见功力的地方。表设计得好，后面写代码就顺；表设计得不合理，后面各种JOIN和冗余字段能把人搞疯。

我实际设计的核心表有四张，下面分别说明。

用户表（t_user）

• id：主键，自增
• username：登录账号，唯一索引
• password：加密后的密码（这里用的是MD5加盐，虽然不算绝对安全，但对于教学项目够了）
• real_name：真实姓名
• role：角色，区分管理员（1）、医生（2）、护士（3）
• phone：联系电话
• create_time：创建时间

老人信息表（t_elder）

• id：主键
• name：老人姓名
• age：年龄
• gender：性别
• phone：老人或家属联系电话
• address：居住地址，精确到社区和楼栋门牌号
• medical_history：既往病史，用Text类型存储一段文本
• emergency_contact：紧急联系人
• emergency_phone：紧急联系电话
• create_time：建档时间

生理参数记录表（t_health_record）

• id：主键
• elder_id：关联老人信息表的外键
• heart_rate：心率，单位bpm
• blood_oxygen：血氧饱和度，单位%
• systolic_pressure：收缩压，单位mmHg
• diastolic_pressure：舒张压，单位mmHg
• body_temperature：体温，单位摄氏度
• record_time：测量时间
• recorder_id：记录人ID，关联用户表
• remark：备注信息，比如测量时的状态（运动后、静息等）

异常预警表（t_alarm）

• id：主键
• elder_id：关联老人ID
• record_id：关联生理参数记录ID
• alarm_type：异常类型，比如心率过快、血压偏高、血氧偏低
• alarm_value：触发预警的指标值
• alarm_time：预警时间
• status：处理状态，0表示未处理，1表示已处理
• deal_user：处理人
• deal_time：处理时间
• deal_remark：处理结果备注

3.2 为什么这样设计字段

设计这套表的时候，有几个细节值得关注。

生理参数单独建表而不是作为老人表的一个字段，是考虑到一个老人的测量数据是持续增长的，如果把数据堆在老人表里，表会变得非常臃肿，查询性能也会直线下降。拆成独立表后，每次测量只插入一条记录，按elder_id和时间索引查询，性能有保障。

预警表单独建表，而不是在参数记录表里加一个状态字段，是因为预警需要记录额外的处理信息——谁处理的、什么时候处理的、处理结果是什么——这些信息跟测量记录本身是不同维度的事情，混在一起会让表结构变成“大宽表”，既不好维护也不好在页面上分开展示。

外键关系要用但不要滥用，我实际开发中并没有在数据库物理层面大量设置外键约束，而是在应用层保证了数据的引用完整性。原因在于外键约束会带来写入性能损耗，而且在后期要调整数据的时候非常麻烦。这是一种取舍：教学项目中，逻辑层控制就够了；生产环境中，则需要根据实际情况决定是否启用物理外键。

3.3 数据库初始化脚本的坑

在准备数据库脚本的时候，第一个坑就是字符集。建表时我统一用了utf8mb4字符集，这个版本支持完整的Unicode编码，包括生僻字和emoji表情。如果你只用了utf8，遇到患者名字里有生僻字时会出现乱码或者插入失败。

第二个坑是时区问题。MySQL 8.0默认使用的时区是UTC，而中国这边是东八区，如果你直接使用CST（China Standard Time）会跟数据库的UTC混淆，导致时间字段差8个小时。解决办法是在JDBC连接URL中显式设置serverTimezone=Asia/Shanghai。

第三个坑是数据库脚本的导入顺序。用户表没有外键依赖，可以最先导入；老人信息表依赖用户表吗？不依赖，但逻辑上是独立的基础数据；生理参数记录表依赖老人表和用户表，需要在前面两张表之后导入；预警表依赖前面的所有表，最后导入。如果你在课程设计答辩时现场演示，脚本导入报错是很减分的，所以脚本本身要写成可重复执行的格式，用DROP TABLE IF EXISTS开头，避免反复导入时报错。

4. 开发环境搭建与项目初始化

4.1 JDK、IDEA、Maven的安装配置

标题里对应的是“idea2022 初始化安装后端开发环境”“需要怎么安装java”“配置maven 下载依赖之类”这些热搜词，这里我就展开把流程捋一遍。

JDK安装：建议直接装JDK 1.8，虽然现在Oracle已经停止了对Java 8的免费商用更新，但Tomcat 8.5/9.0，以及市面上海量的老项目都跑在Java 8上面，兼容性最好。安装路径不要带空格和中文，否则后续配置环境变量容易出现各种莫名其妙的坑。装完验证一下，命令行输入java -version和javac -version，两个都有输出才算配好。

IDEA配置：IDEA 2022版本对Java 8的支持很完善，下载安装后先把项目的SDK指定到JDK 1.8路径。然后配置Maven——建议用Maven 3.6.3或者3.8.x版本，太新的版本（3.9+）在某些情况下跟旧版IDEA插件存在兼容问题。配置Maven时需要注意三件事：一是settings.xml里的本地仓库路径要改成非系统盘（比如D盘的maven-repo），因为默认在C盘用户目录下，时间长了会占用大量空间；二是镜像要配阿里云镜像，否则从中央仓库拉依赖能让你等到怀疑人生；三是IDEA里Maven的Runner选项要把JRE也指向JDK 1.8，避免编译时用了错误的JDK。

4.2 传统Web项目还是Maven项目

这个社区监护系统，我推荐用Maven方式构建，虽然JSP项目用传统方式（直接建Web项目，把jar包丢进WEB-INF/lib）也能跑，但Maven的好处在于依赖管理清晰——你需要什么库就在pom.xml里声明坐标，Maven会自动下载并处理传递依赖。

还有一个好处是打包部署方便。在IDEA里执行mvn clean package，直接在项目target目录下生成一个可部署的WAR包，扔进Tomcat的webapps目录就能跑。传统方式你得手动去复制文件，容易漏东西。

当然，用Maven也有一个需要注意的地方：JSP项目用Maven构建之后，页面文件默认放在src/main/webapp目录下，编译后的class文件会输出到target/classes，这和以前的目录结构不一样。很多从MyEclipse转过来的同学会在这里栽跟头——明明源码里能看到JSP页面，但启动Tomcat后访问404。根源就在于webapp目录没有被正确识别为Web资源目录。

4.3 Tomcat配置与项目部署

Tomcat的配置相对简单，解压后就能用。但有几个细节需要处理。

启动端口：默认是8080，如果被其他程序占用，可以修改conf/server.xml里的Connector端口，把8080改成8081或者其他未占用的端口。我遇到过很多次IDEA里自带Tomcat插件和本地安装的Tomcat冲突的问题，表现就是“Port already in use: 8080”，实际上就是两个Tomcat实例在抢占同一个端口。解决办法很简单，把其中一个的端口改掉，或者停掉其中一个服务。

部署方式：在IDEA里配置Tomcat时，有两种部署方式——一种是外部Tomcat方式，配置好Tomcat安装路径后，IDEA把项目热部署到Tomcat的webapps目录；另一种是嵌入式方式，项目启动时直接通过插件方式运行。实际开发中用外部Tomcat的调试模式更贴近真实部署，而且可以直接访问Tomcat的管理后台。

JSP编译临时目录：Tomcat运行JSP页面时会把JSP编译成Java源文件再编译成class文件。这里对应了热词里“jsp编译class文件保存在哪里”这个问题——默认在Tomcat的work/Catalina/localhost/项目名/org/apache/jsp目录下，按页面路径生成对应的java和class文件。如果你改了JSP页面但刷新浏览器不生效，多半是Tomcat没有重新编译，清理一下work目录下对应的临时文件，重启Tomcat就好了。

4.4 IDEA热部署失效的问题

这里单独说一下热部署。很多人在开发JSP项目时遇到一个非常头大的问题：改了JSP页面，刷新浏览器不生效。这个问题的根源在于IDEA和Tomcat之间的热部署机制。

JSP页面本身是支持热部署的，Tomcat检测到JSP文件变动后会自动重新编译。但是如果你是通过IDEA的Smart Reload或Restart Server方式部署，IDEA默认的构建操作可能没有把最新的JSP文件同步到Tomcat的工作目录。解决办法是在IDEA的Deployment设置里，把项目的webapp目录映射到Tomcat的部署目录，并且勾选“Build before run”和“Update resources”相关选项。还有一个笨办法但很有效：直接停掉Tomcat，重新Run一次，保证文件是全新同步的。

另外要注意，如果你修改的是Java源码（Servlet类、工具类），默认情况下Tomcat不会自动重载Java类，需要触发类重载——要么通过IDEA的Update操作触发重新部署，要么改Tomcat配置让容器监听并自动重载。在开发阶段，我通常把IDEA的On Update Action设置为“Update classes and resources”，这样Java代码变了之后会自动编译并重新加载到JVM中。

5. 核心功能模块的实现细节

5.1 用户认证与权限控制

用户登录是整个系统的入口，逻辑不复杂但坑很多。我的实现方式是：登录表单提交到LoginServlet，Servlet从请求中获取username和password，先做空值校验，然后调用UserDao的findByUsername方法查询用户，比对密码（MD5加密后的密文），比对通过后把用户信息存进Session，然后重定向到首页；比对失败则返回登录页，带一个错误提示参数。

权限控制的思路比较直接：写一个LoginFilter，在web.xml中配置拦截规则，把除登录页、注册页、静态资源（css/js/images）以外的所有路径都拦截下来。Filter的doFilter方法里先判断Session中是否有用户信息，没有就重定向到登录页；有的话再判断当前请求的路径是否属于该角色允许访问的范围。管理员能访问所有页面，医生和护士无权访问用户管理相关的页面。

这里我踩过一个非常典型的坑：登录成功后页面跳转用forward还是sendRedirect。如果我用了forward，虽然页面跳转到了首页，但是浏览器的地址栏仍然是/LoginServlet，用户刷新页面就会重复提交登录表单，造成重复登录记录。正确的做法是用sendRedirect发送重定向，让浏览器重新发起一个新的请求，这样地址栏变成/index.jsp，刷新也安全了。

5.2 生理参数记录模块实现

这个模块是系统的核心，操作流程是这样的：医护人员选择老人 → 进入测量记录页面 → 填写心率、血氧、收缩压、舒张压、体温等参数 → 点击保存。

保存的时候，客户端先用JavaScript做个简单的数据合法性校验（比如心率在30到260之间，温度在34到43度之间），避免明显不合理的脏数据直接入库。然后把数据提交到HealthRecordServlet，Servlet再把数据拆成两部分处理：一部分是正常插入健康记录表，另一部分是根据指标范围判断是否触发异常预警，如果心率超过100或低于60、血氧低于95%、收缩压高于140或低于90、体温高于37.5度等情况，自动向预警表插入一条记录。

这个自动预警的逻辑非常关键。医疗服务讲究“早发现、早干预”，如果等医生自己去翻每一份测量记录找异常，效率太低了。系统自动预警就相当于一个不知疲倦的哨兵，把异常情况主动推到首页，医护人员一上线就能看到。

5.3 数据展示与ECharts图表渲染

数据可视化是这个系统的亮点部分，也是很多课程设计答辩时老师喜欢问的点。实现原理不复杂：在老人详情页里放一个div容器，页面加载时异步请求一个ChartDataServlet，这个Servlet根据老人ID和天数参数查询近7天或近30天的生理参数记录，按日期聚合平均值，拼成JSON字符串返回前端；前端用jQuery的ajax获取数据后，调用ECharts API绘制折线图。

这里有两个细节需要注意。第一，ECharts的引入方式——老版本用script标签直接引入echarts.min.js，新版本推荐用npm包管理，但在JSP项目里直接用CDN引用是最简单的。不过要考虑到社区内网环境可能没有外网，所以稳妥起见还是把echarts.min.js文件下载到项目的js目录下，做本地引用。

第二，JSON数据的日期格式。ECharts的x轴接受时间字符串，但需要保证格式统一，我用的是SimplDateFormat格式化成了“MM-dd”格式。如果后端返回的是标准日期对象或者时间戳，前端需要做额外转换，否则图表会出现轴标签显示异常的问题。

5.4 列表分页与条件筛选

老人列表和健康记录列表都做了分页功能。实现手段是在Servlet里接收pageNum和pageSize两个参数，用LIMIT offset, count的SQL语句查询当前页数据，同时查询符合条件的总记录数，计算总页数，把PageBean对象（封装了当前页码、总页数、当前页数据列表、每页条数）放进request域，转发到JSP页面渲染。

条件筛选做得比较细致：老人列表支持按姓名和住址模糊查询，健康记录列表支持按老人姓名、测量时间段、指标类型（只看心率异常或只看血压异常）筛选。如果你在开发时遇到“jsp实现数据导出为excel”这类需求，导出功能的思路其实跟列表查询一样——查询数据后不渲染到JSP，而是用POI或easyexcel直接写Excel文件，以流的方式输出到浏览器，触发下载。这个系统里我也顺手做了一个导出功能，把筛选后的健康记录导出成Excel，方便医护人员做线下归档。

5.5 个人中心与密码修改

对应热词里的“jsp个人信息展示页面”，这块功能虽然简单但属于“必备项”。用户登录后点击右上角的头像或姓名，可以进入个人信息页面，展示自己的账号、角色、姓名、联系电话等；修改信息时提交到ProfileServlet，校验当前登录用户的身份，更新对应字段，回显更新后的数据。

修改密码这里有一个安全细节：必须要求用户输入原密码才能设置新密码，防止用户离开座位后被别人恶意修改密码。实现时先在Service层校验原密码是否正确，正确后再更新为新密码的密文。密码存储我一直用MD5加盐的方式，盐值可以是用户名或固定字符串，这样同一密码在不同用户下密文不同，安全性比裸MD5高不少。

6. 调试部署与常见问题排查

6.1 从“本地能跑”到“部署能上”

很多同学的程序在自己电脑上跑得飞起，一到现场演示或者部署到服务器上就崩了。这种问题多半出在环境差异上。我总结了几条实用的部署前检查清单。

第一，数据库账号密码不要写死在代码里。虽然教学项目里直接写在JDBC工具类中很方便，但部署到服务器时必须改成实际环境的值。更优雅的做法是写一个db.properties配置文件，用Properties工具类加载，这样切换环境时只改配置文件，不需要动代码重新编译。

第二，MySQL连接驱动版本要和数据库版本匹配。如果数据库是MySQL 8.0，就使用mysql-connector-java 8.0.x版本的驱动，同时连接URL里要带useSSL=false和serverTimezone参数，否则会报SSL连接错误或者时区异常。

第三，Tomcat的JVM内存参数要调整。课程设计级别的项目默认内存够用，但如果部署到生产环境，并发量上来之后容易OOM，所以建议在Tomcat的catalina.bat或catalina.sh中设置JAVA_OPTS，增加-Xms和-Xmx参数，如-Xms512m -Xmx1024m。

第四，端口和防火墙。服务器上需要放行Tomcat的端口（默认8080，如果通过Nginx转发的话还需要配置Nginx），以及MySQL的3306端口（如果是远程连接的话）。这个坑在真实服务器上非常常见——程序明明起了，但外部访问不了，就是防火墙拦截的问题。

6.2 开发过程中常见的五个问题

我把实际开发中踩过的坑整理成了一份对照表，按照出现频率排序：

第二项的坑尤其经典。比如数据库字段叫heart_rate，Java实体类的属性叫heartRate，从ResultSet里getString时如果直接写rs.getString("heart_rate")，那没问题；如果你写的是rs.getString("heartRate")，就会报列名找不到。这种问题编译期发现不了，只有运行到那一行才报错，排查起来需要仔细核对字段名。

6.3 JSP页面修改不生效的终极解决方案

前面提过JSP编译临时目录的问题，这里再详细展开。Tomcat处理JSP请求的流程是：客户端首次请求某个JSP页面时，Tomcat把JSP文件翻译成Java源文件，再编译成class文件，然后执行；后续再请求同一个页面时，Tomcat会先检查JSP文件是否发生了修改，如果没修改就直接执行之前的class文件，如果修改了则重新翻译编译。

问题在于这个“检查是否修改”的机制在某些情况下会失效——比如IDEA把新的JSP文件复制到了Tomcat部署目录，但文件的时间戳没有变化，Tomcat认为文件没修改就继续用旧的class。或者修改了JSP但容器检测不到，因为Tomcat用于部署的是解压后的目录副本。

我的经验是：JSP页面修改不生效时，不要心存侥幸，直接清Work目录重启。在IDEA里就执行Build → Rebuild Project，然后把Tomcat停掉，进入Tomcat的work目录手动删除里面的缓存文件，或者直接用Clean操作，然后重新启动。这一套操作下来95%的问题都能解决。剩下5%的情况是JSP文件本身语法有误，但错误提示又没有直接显示出来——这种情况下把页面代码从头到尾检查一遍，重点看标签是否闭合、EL表达式是否写错、JSTL标签库有没有引入正确。

6.4 数据库连接异常的排查思路

数据库连接报错是Java Web开发中最烦人的问题之一。常见的情况有几种。

第一种是“Communications link failure”或者“Connection refused”，这个说明客户端根本连不上MySQL服务器。先ping一下服务器的IP看网络通不通，再telnet IP 3306看端口通不通，如果端口不通检查MySQL服务是否启动，检查是否有skip-networking配置，检查bind-address是否限制了访问。第二种是“Access denied for user”，说明用户名或密码错误，或者该用户没有远程访问权限，需要在MySQL中执行授权命令。第三种是“Unknown database”，说明数据库名写错了，或者没有创建对应的数据库。

还有一个很容易忽视的点：JDBC驱动版本与MySQL版本不匹配。MySQL 8.0需要驱动类名是com.mysql.cj.jdbc.Driver，老版本是com.mysql.jdbc.Driver。如果你用的驱动包版本较低，可能没有cj的这个类，就会报ClassNotFoundException。

6.5 项目上线部署的操作流程

整个项目完成后，部署到Linux服务器上的标准流程大概是这样的：先把项目用Maven打成WAR包，然后上传到服务器的Tomcat的webapps目录下。如果改动不大，直接利用Tomcat的自动解压部署功能，把WAR包放进去后启动Tomcat，它会自动解压并部署应用。如果项目有更新，需要把新的WAR包替换掉旧包，先停Tomcat，删掉旧的解压目录和work缓存，再放新包启动。

MySQL的迁移也很简单：在旧库导出SQL文件，传到服务器后执行source命令导入。注意导入之前要在服务器端创建同名的数据库，并设置好utf8mb4字符集。

如果你希望项目在服务器上长期稳定运行，建议用systemd把Tomcat注册成服务，设置开机自启。这样重启服务器后Tomcat自动启动，不用每次手动去startup.sh启动。

7. 这个项目还能怎么扩展

这个社区监护系统虽然功能已经比较完整，但距离一个真正的商用系统还有很大的提升空间。我当时做完后就在琢磨几个升级方向，在这里分享给大家。

第一个方向是引入消息推送机制。目前的预警是在页面内展示，如果医护人员没有时刻盯着浏览器，就很难第一时间发现异常。可以接入微信公众号模板消息、短信服务或者现在常见的钉钉/企微机器人通知，一旦检测到生理参数异常，立即推送消息给值班医生或家属。

第二个方向是采集设备的真实对接。目前系统的参数录入方式主要是手动录入，但在真实的物联网场景中，可以通过串口、蓝牙或者WiFi与血氧仪、血压计等设备对接，实现数据的自动上传。这条路径会涉及到硬件开发、通信协议解析等内容，技术含量会高很多。

第三个方向是数据分析的算法化。现在只是简单的超限判断，如果引入一些基础的数据挖掘算法，比如及时性强的移动平均线来分析趋势、异常点检测算法来发现潜在风险，系统就能从“被动记录”升级为“主动预测”，这对于慢性病的管理价值会大很多。

不过这些都是后话，对于一个以学习和练手为主要目的的项目来说，先把基础的功能做扎实、跑通整个流程、理解每一行代码背后的逻辑，比盲目追求炫酷的技术栈更有价值。我现在再看这个项目，最大的感受就是：技术虽然简洁朴素，但麻雀虽小五脏俱全，它让我把Java Web的知识体系完完整整地串了一遍，这种收获是看再多的教程视频都替代不了的。