企业官网建设流程全解析

刚做完一个动物园动物饲养管理系统，前后端分离架构，SpringBoot 3.x + Vue 3全家桶。这个项目是给某中型动物园做的，既要管动物档案，又要盯饲养流程，还要处理饲料库存和健康记录，一开始接手的时候觉得不就是个CRUD吗，真做起来才发现坑不少。这篇就把整个设计和实现过程完整拆一遍，从需求分析到数据库设计，从权限控制到健康预警，再到实际部署时踩过的几个坑，全写出来。

1. 项目整体设计与技术选型思路

1.1 项目背景与核心需求解析

先说说这个项目的实际背景。该动物园目前有哺乳类、鸟类、爬行类等共计两百多只动物，分布在十多个展区。过去的管理方式基本靠纸质台账 + Excel表格，饲养员每天手写饲喂记录，兽医做健康检查也是纸质登记，月底汇总的时候非常痛苦，而且历史数据基本没法追溯。举个例子，某只动物出现食欲不振，想查它过去一周的进食情况，要翻好几个本子，效率极低。

管理方希望做一个系统，核心需求归纳下来有这么几条：

• 动物档案电子化：每只动物有唯一编号，记录品种、性别、出生日期、来源、展区位置等基础信息。
• 饲养任务日常化：饲养员每天按任务清单执行饲喂、清洁、观察等工作，并填写记录。
• 健康管理闭环：兽医定期体检、记录疾病与治疗情况，系统能对异常指标做提醒。
• 饲料库存联动：饲料入库、出库、库存预警，和饲喂记录形成数据关联。
• 数据可视化：管理层要能看到饲养任务完成率、饲料消耗趋势、动物健康状况统计。

需求梳理清楚之后，技术选型就比较明确了：SpringBoot做后端接口服务，Vue做前端管理界面，MySQL存业务数据。这套组合的优点是生态成熟、招人容易、部署简单，对动物园这种预算有限、运维力量也不强的单位来说是非常稳妥的选型。

1.2 为什么选SpringBoot + Vue 3而不是其他方案

选型这件事，我在项目里通常是按“团队熟悉度 + 生态成熟度 + 后续维护成本”三个维度来评估的，而不是哪个技术新就选哪个。

后端选SpringBoot 3.x，原因是：

• Spring Data JPA + MyBatis双支持，这套组合在中小型管理系统中非常成熟，遇到复杂查询可以走MyBatis的XML，简单CRUD直接用JPA就能搞定。
• Spring Security做登录认证和权限控制，JWT无状态令牌适合前后端分离场景。
• 生态里现成的工具类特别多，分页、参数校验、全局异常处理、定时任务都有标准解法，开发效率很高。

前端选Vue 3 + Element Plus，原因是：

• Vue 3的组合式API写业务逻辑比Vue 2的选项式更清爽，逻辑复用度高。
• Element Plus的表格、表单、弹窗、树形控件基本覆盖了管理后台90%的场景。
• Pinia做状态管理，比Vuex更轻量，TypeScript支持也更好。

有的团队喜欢用若依这类脚手架直接改，但我觉得系统定制化程度高、业务逻辑复杂的时候，从零搭建反而更容易掌控，不必为了省初期工作量去适应别人定的框架约束，后期改起来更痛苦。

1.3 系统整体架构与功能模块划分

系统采用经典的前后端分离架构，前端通过HTTP接口调用后端服务，后端分层为Controller、Service、Mapper三层。整体功能模块如下：

这个模块划分的出发点很简单：每个业务域都有明确的责任人，权限边界清晰，操作流程形成闭环。举个例子，饲养员填写的饲喂记录会自动扣减饲料库存，库管员不用等月底盘点就能看到实时消耗，这就是模块联动的价值。

2. 数据库设计与核心表结构拆解

2.1 动物档案表的字段设计

动物档案是整个系统的数据根基，表设计上既要有基础信息，也要考虑状态流转和历史追溯。

CREATE TABLE animal_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键', animal_code VARCHAR(32) NOT NULL UNIQUE COMMENT '动物编号', animal_name VARCHAR(64) NOT NULL COMMENT '动物名称', species VARCHAR(64) COMMENT '物种', category VARCHAR(32) COMMENT '类别：哺乳/鸟/爬行等', gender TINYINT COMMENT '性别：0-未知 1-雄 2-雌', birth_date DATE COMMENT '出生日期', acquisition_type VARCHAR(16) COMMENT '来源：繁殖/购入/救助/交换', acquisition_date DATE COMMENT '入园日期', enclosure_id BIGINT COMMENT '展区ID', health_status VARCHAR(16) COMMENT '健康状态：健康/观察/治疗/隔离', life_status VARCHAR(16) COMMENT '生命状态：存活/死亡/转出', is_sterilized TINYINT DEFAULT 0 COMMENT '是否绝育', remark VARCHAR(255) COMMENT '备注', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );

字段设计上有几个容易被忽略的点：

• animal_code必须唯一，这是每只动物的“身份证号”，后续所有业务记录都通过这个编号关联，比直接用自增ID更规范，也方便线下对应。
• health_status和life_status分开存，是有讲究的。健康状态是可逆的，动物生病治好了能恢复；生命状态是不可逆的，死亡或转出后这条档案就“锁定”了。两个状态混在一个字段里，业务逻辑会非常混乱。
• acquisition_type我建议用字典表管理而不是直接写死枚举，因为动物园之间经常会有动物交换，后续可能新增“借展”这类的来源。

2.2 饲养记录与饲料消耗的关联设计

饲养这块是整个系统业务量最大的部分，设计时最关键的点是“饲喂记录”和“饲料出库”的联动关系。

CREATE TABLE feeding_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, animal_code VARCHAR(32) NOT NULL, feed_id BIGINT NOT NULL, feed_name VARCHAR(64), feed_weight DECIMAL(10,2) COMMENT '饲喂重量(kg)', feed_time DATETIME NOT NULL, feeder_id BIGINT COMMENT '饲养员ID', feeder_name VARCHAR(32), remark VARCHAR(255), create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

这里我设计的是“前端先查饲料信息，选中后提交”的方式，后端接收到feed_id和feed_weight后，在同一事务里做两件事：插入feeding_record，同时扣减饲料库存表对应记录。如果扣减后库存低于预警阈值，自动生成一条补货提醒。

事务控制是这个功能的关键。如果先插记录再扣库存，中间任何一步失败都会造成数据不一致。SpringBoot里直接用@Transactional注解就能搞定量子化操作，两件事要么都成功，要么都回滚。

这里有个实际的业务细节：不同动物的饲喂单位不一样，大象按“千克”算，小型鸟类可能按“克”算。字段类型我都用的是DECIMAL(10,2)，单位统一在饲料字典表里维护，展示的时候根据单位字段自动换算显示，避免数据库里出现“0.05”这种不好理解的数据。

2.3 健康档案与预警机制的表结构支撑

健康模块我做了三张表：体检记录表、疾病治疗表、健康指标阈值表。

体检记录表的核心字段是体检日期、体重、体温、心跳、精神状态评价、兽医姓名和备注。每个字段对应一个健康指标的评分区间，比如动物体温低于或高于正常范围，系统自动标记为“异常”。

为了让预警不写死在代码里，我建了一张阈值配置表：

CREATE TABLE health_threshold ( id BIGINT PRIMARY KEY AUTO_INCREMENT, species VARCHAR(64) COMMENT '适用物种', metric_code VARCHAR(32) COMMENT '指标编码：temperature/heart_rate/weight', min_value DECIMAL(8,2), max_value DECIMAL(8,2), level TINYINT COMMENT '1-注意 2-危险' );

这样做的好处是，兽医可以在系统里直接调整某个物种的体温正常范围，不用改代码重新部署。比如夏天环境温度高，某些爬行动物的活跃体温范围有变化，直接在页面上改配置就行，这种灵活性是写死枚举给不了的。

3. 核心功能实现与实操过程记录

3.1 用户认证与RBAC权限控制的落地

权限控制这块，用的是经典的RBAC模型：用户-角色-菜单三级。用户表只管账号密码和基本信息，角色表定义权限集合，用户和角色做多对多关联。

// JWT工具类核心方法 public String generateToken(Long userId, String username, List<String> roles) { return Jwts.builder() .setSubject(username) .claim("userId", userId) .claim("roles", roles) .setExpiration(new Date(System.currentTimeMillis() + EXPIRATION_TIME)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }

Spring Security的配置上，我重写了SecurityFilterChain，放行了登录接口和静态资源，其余接口全部要求携带有效Token。不同角色的访问控制，是通过自定义注解@PreAuthorize("hasRole('ADMIN')")加到Controller方法上实现的。

实际开发中有个容易踩坑的地方：JWT的密钥和过期时间如果写在代码里，后续修改必须重新编译部署。我这里是放在了application.yml里，通过@ConfigurationProperties注入，这样运维同学改配置重启就行，不用动代码。过期时间设成了12小时，白天上班基本不用重新登录，安全性和便利性比较平衡。

3.2 动物档案管理的核心接口实现

动物档案管理模块的难点不在CRUD本身，而在“唯一编号自动生成”和“状态变更的联动处理”。

编号生成我用的是统一前缀 + 日期 + 流水号的方案：

public String generateAnimalCode(String category) { String prefix = categoryMapper.getCodePrefix(category); String datePart = LocalDate.now().format(DateTimeFormatter.ofPattern("yyyyMMdd")); int seq = animalMapper.getDailySequence(prefix, datePart); return prefix + datePart + String.format("%03d", seq + 1); }

比如一只新入园的非洲象，类别编码为ELE，生成编号就是ELE20250608001。这种编号规则的好处是，光看编号就能知道动物类别和入园时间，既方便线下登记查找，也方便系统内部索引。

状态变更的联动处理是另一个关键点。动物从“正常”变为“隔离”，系统要自动完成几件事：更新动物表状态、给隔离展区负责人生成一个待办任务、在健康模块插入一条观察记录。这套逻辑必须放在同一个事务里，否则就会出现“状态变了但饲养员不知道”的情况。

前端页面上，动物档案列表用了Element Plus的el-table组件，分页、搜索、状态筛选都做出来了。编辑表单里展区和类别的下拉选项是从后端接口加载的，不写死，这样管理员在系统里新增了展区，前端下拉选项刷新就能同步出来。

3.3 饲养任务派发与饲喂记录填写流程

饲养任务派发的思路是：管理员按展区配置日常任务模板，系统每天凌晨自动生成当天的任务清单，分配到对应的饲养员账号下。

任务模板表的核心字段是展区ID、任务类型、计划开始时间、计划结束时间、任务内容、指定饲养员ID。生成任务的定时任务我用的是Spring的@Scheduled注解：

@Scheduled(cron = "0 30 5 * * ?") public void generateDailyTasks() { List<TaskTemplate> templates = taskTemplateMapper.findAll(); for (TaskTemplate template : templates) { DailyTask task = new DailyTask(); task.setName(template.getName()); task.setEnclosureId(template.getEnclosureId()); task.setAssigneeId(template.getAssigneeId()); task.setPlanStartTime(template.getPlanStartTime()); task.setPlanEndTime(template.getPlanEndTime()); task.setStatus(TaskStatus.PENDING); dailyTaskMapper.insert(task); } }

定时任务生成之后，饲养员登录系统，首页就是“我的今日任务”，可以看到“未开始”“进行中”“已完成”“已逾期”四种状态。点击“开始”按钮后任务状态变为进行中，填写完饲喂记录并提交后状态自动变为已完成。

这个过程对饲养员的操作设计做了减法，尽量一键操作，减少填写负担。因为实际使用这套系统的人不是专业程序员，很多饲养员年纪偏大，在电脑上操作不熟练，界面必须直观，按钮必须大，交互步骤必须少。我在系统里把表格默认的行高调大了，字体也调大了，就是为了让这些终端用户操作时不费劲。

3.4 饲料出入库与库存预警实现

饲料管理模块相对独立，逻辑上更接近进销存系统。入库单、出库单、实时库存、预警记录四张表构成了核心闭环。

入库操作相对简单，填写供应商、饲料名称、数量、单价、入库日期，提交后库存增加。出库操作有两种口径：一种是从饲喂记录自动扣减的“消耗出库”，另一种是饲养员手动填写的“领用出库”，比如定期给展区补充一些零食饲料。

库存预警的实现比较轻量，我在库存表的每个饲料品种上配置了最低库存阈值。每次出库操作完成后，检查当前库存是否低于阈值，如果低于就插入一条预警记录，同时在管理员的待办中心生成一条处理提示。

public void deductStock(Long feedId, BigDecimal weight) { FeedStock stock = feedStockMapper.selectByFeedId(feedId); stock.setCurrentStock(stock.getCurrentStock().subtract(weight)); feedStockMapper.updateById(stock); if (stock.getCurrentStock().compareTo(stock.getMinStock()) < 0) { stockWarningMapper.insert(new StockWarning(feedId, stock.getCurrentStock())); } }

这里有个细节：比较用的是compareTo而不是直接<，因为BigDecimal的compareTo和equals行为不同。直接比较0.1和0.10，equals返回false但compareTo返回0，用compareTo比较数值大小才是正确的。这是我当年在一个财务系统里踩过的坑，印象特别深。

3.5 数据统计与可视化大屏的实践

统计分析模块，我做了两类东西：一类是后台管理页面的ECharts图表，另一类是园区大屏展示页。

后台统计包括：

• 近30天饲养任务完成率趋势折线图
• 各展区动物分布饼图
• 饲料消耗TOP10柱状图
• 健康异常动物滚动列表

这些图表的数据来源是后端接口实时查询聚合出来的，不额外建统计表。因为动物园的数据量级很小，就算每天每条记录都查一遍，数据库压力也完全可以承受。我写的SQL基本都是COUNT、SUM配合GROUP BY，加上时间范围条件走索引，毫秒级就能返回。

大屏展示页用了Vue轮询的方式每30秒刷新一次数据，展示当前在线任务量、待办预警数、园区总动物数等核心指标。大屏整体配色是深蓝底 + 绿色数据，比较符合动物园绿色生态的主题。

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

4.1 跨域配置引发的前端联调阻塞

前后端分离开发，本地联调第一个遇到的就是跨域问题。前端跑在5173端口，后端跑在8080端口，浏览器直接拦截跨域请求。

我的处理是在SpringBoot里写了一个统一的CORS配置类：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("*") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

这里有个关键点容易踩坑：前端如果开启了withCredentials（携带Cookie），后端就不能用allowedOrigins("*")，必须使用allowedOriginPatterns("*")，否则浏览器会直接拒绝响应。我当时卡了半小时，最后打开浏览器控制台才发现的。

不过要提醒的是，这只是开发环境方便联调的方案。生产环境我建议还是用Nginx做反向代理，前端请求/api前缀的统一转发到后端服务，从根本上规避跨域问题，性能和安全性都更好。

4.2 JWT登录态失效导致的操作无响应

系统上线后遇到过一个问题：用户登录后长时间停留在某个页面没操作，超过Token有效期后再点按钮，接口返回401，但前端没有统一处理这个状态，页面看起来就是“点了没反应”。

解决方法是加了一个axios的响应拦截器，统一处理401状态码：

service.interceptors.response.use( response => { return response.data; }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token'); router.push('/login'); ElMessage.error('登录已过期，请重新登录'); } return Promise.reject(error); } );

这样处理之后，用户再次操作时会被自动踢到登录页并收到提示，体验就顺了。

另外还有一个连带问题，用户操作很频繁时，每请求一次就要重新校验一次Token，虽然性能影响不大，但为了更好的体验我在前端做了请求拦截器，给每个请求自动附带Authorization: Bearer xxx的Header，后端只需要在Security过滤器里校验一次。这个组合用下来整体比较稳。

4.3 事务失效问题：饲料扣减和记录插入不同步

有一次测试时发现，饲喂记录已经插进去了，但饲料库存没扣减。排查下来是事务注解写在了同一个类内部调用的方法上，Spring事务切面默认只对外部调用生效，内部自调用不走代理，@Transactional直接失效了。

这个问题的本质是Spring AOP的代理机制。解决思路有两种：一是把扣减库存的逻辑拆到另一个Service类中，通过注入调用走代理；二是用AopContext.currentProxy()显式获取当前代理对象来调用。我采用的是前者，把库存操作单独封装到了StockService里，逻辑也更清晰，后面测试通过后就没再出过问题。

另外提一句，@Transactional默认只在抛出RuntimeException时回滚，如果方法里catch了异常没重新抛出，事务也会失效。事务里尽量不做try-catch包裹，让异常自然抛出，由全局异常处理器统一收口。

4.4 大数据量导出时的内存溢出风险

系统上线一段时间后，管理员提出了导出全年饲养记录的需求。当时第一个版本的实现是直接用select * from feeding_record查出所有数据，再循环处理，几万条数据直接导致内存飙升，个别年份数据量大的时候甚至OutOfMemory。

后来改成了Streaming查询的方式，利用MyBatis的游标读取：

public void exportFeedingRecords(String year, OutputStream outputStream) { try (SqlSession sqlSession = sqlSessionFactory.openSession()) { FeedingRecordMapper mapper = sqlSession.getMapper(FeedingRecordMapper.class); Cursor<FeedingRecord> cursor = mapper.scanByYear(year); for (FeedingRecord record : cursor) { exportRow(record, outputStream); } } }

游标方式不是一次性加载全部数据，而是逐行从数据库读取，内存占用只有原来的零头。十万条记录的导出，从必现OOM变成稳定完成，这个改动算是性价比很高的优化。

4.5 前端菜单权限刷新后丢失

登录后管理系统的基本流程是：前端拿到用户信息和角色，根据角色动态生成菜单。但我最开始是把菜单数据存在Vuex里，一刷新页面Vuex状态清空，菜单就丢了，页面变成一片空白。

后来改成了刷新时重新调用/api/user/info接口，根据返回的角色动态重建菜单。这个方案说穿了就是“刷新后重新拉一次用户信息”，但能把问题彻底解决。另外要注意的是，路由守卫里要处理异步获取用户信息的阻塞，避免菜单还没生成路由就跳转的情况。

5. 系统部署与运维要点总结

5.1 Linux服务器下单服务部署实践

部署方案上，我最终选择的是单机部署：一台Linux服务器，Nginx放前端静态文件并做反向代理，后端Jar包通过systemd守护进程运行。

前端打包用的是npm run build，产物放在/opt/zoo/frontend/目录，Nginx配置大致如下：

server { listen 80; server_name zoo.example.com; location / { root /opt/zoo/frontend; 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; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

这里try_files配置必须要有，否则Vue的history模式路由在刷新非首页路径时会报404。这个是前端路由模式的经典问题，部署过Vue项目的人应该都不陌生。

后端Jar包我用了systemd来管理，配了Restart=always，进程挂掉会自动拉起，再配合一个简单的健康检查脚本，每天凌晨检查一次接口可用性，有问题就发告警提醒。

5.2 MySQL备份与数据安全策略

数据是系统的命脉，备份策略必须提前定好。我配置了每天凌晨3点自动执行mysqldump全量备份，保留最近7天的备份文件：

#!/bin/bash BACKUP_DIR=/opt/backup/mysql DATE=$(date +%Y%m%d_%H%M%S) mysqldump -uzoo_user -pPassword zoo_db | gzip > $BACKUP_DIR/zoo_db_$DATE.sql.gz find $BACKUP_DIR -name "*.sql.gz" -mtime +7 -delete

备份文件我建议至少每月做一次异地拷贝，或者同步到云存储，防止服务器磁盘故障导致数据全丢。这个项目上线后的第二周就遇到过一次磁盘告警，当时要不是提前配了备份清理和异地同步，后果还真挺麻烦的。

另外，管理员账号开启了二步验证，因为系统里包含了动物健康数据，虽然不算特别敏感，但兽医的治疗记录和饲料供应商信息还是应该受到保护，能多一层验证就多一层安心。

6. 项目复盘与二次开发扩展方向

6.1 做得好的地方和遗留的问题

复盘整个项目，我认为做得比较好的点有三个：

• 需求梳理阶段花了足够的时间，和园长、兽医、饲养员都做了面对面沟通，所以模块划分和角色权限边界都比较清晰，后期开发没有出现大范围推倒重来的情况。
• 数据库设计时充分考虑了状态变更的联动性，健康状态、生命状态、库存字段都预留了扩展空间。
• 前端交互做了充分的简化，考虑到终端用户是饲养员和兽医，操作路径很短，基本都能在两三步内完成核心操作。

遗留的问题也有：移动端适配没有做得很完善，饲养员在园区里边走边用手机填记录的时候，部分页面在小屏下显示不够友好。目前是让饲养员在电脑或平板上完成的，但长期来看，响应式适配或者做一个轻量移动端是后续值得投入的方向。

6.2 二次开发的技术演进建议

如果后续要继续扩展，我建议优先考虑下面几个方向：

• 对接摄像头和RFID设备，实现动物自动识别和定位。这样饲养员扫一下动物耳标就能弹出档案，不用手动搜索编号，效率提升会比较明显。
• 引入物联网传感器做环境监测。展区的温度、湿度、空气质量实时采集，超出舒适区间自动报警，数据还能关联到动物健康档案里，对饲养管理很有价值。
• 引入简单的机器学习做异常检测。比如根据动物历史进食量预测正常范围，某天进食量明显偏离时自动标记，辅助兽医做健康判断。这个方向不一定多高大上，但确实能解决实际痛点。

最后再分享一个小技巧：如果你也要做这类“看起来就是个管理系统”的项目，前期沟通需求的时候记得多追问一句“你们现在最痛的是什么”，用户往往会说出一个非常具体的场景，这个场景就是系统里最值得打磨的核心功能。我这套系统的任务派发和库存联动，就是通过这句话挖出来的，成效也确实最明显。

这个项目开发周期大概两个月，中间改了不少需求，但整体架构没有伤筋动骨。希望这篇能帮到正在做类似系统的朋友，少走几个弯路。