做宠物领养救助平台这套东西说实话最初我是被朋友拉着入坑的。当时他所在的民间救助站还在用纸质表格登记流浪猫狗信息领养人要看宠物照片还得翻朋友圈相册效率低到离谱。后来我花了大半个学期用Node.js和Vue给他们撸了一套前后端分离的领养救助平台从需求梳理到部署上线都走了一遍。这篇文章就把我从0到1的完整思路、技术选型、数据库设计、核心功能实现和配置文件全部分享出来包含我踩过的坑和验证过的方案。1. 项目全貌与核心需求拆解1.1 宠物领养救助的真实痛点先说说这个项目要解决什么问题。国内做宠物领养救助的机构多数是民间组织普遍面临三个要命的情况一是信息不透明救助站收容了什么宠物、健康状况如何、能否领养外界根本看不到二是审核流程全靠人工微信沟通领养人资历审查、家访记录、回访反馈这些全部散落在聊天记录里时间一长根本没法追溯三是救助资源分配不均有的猫狗在救助站待了半年无人问津有的刚进来就被十几个人同时相中完全没有统一的流转机制。所以这个宠物领养救助平台的核心定位不是普通的信息展示站而是要给救助机构提供一个完整的管理工具链。从宠物入站登记、健康档案维护到领养申请提交、资质审核、领养协议签署再到领养后的回访反馈整条链路都要在系统里跑通。单纯把宠物信息挂到网上让用户浏览那不叫平台那叫静态网页。1.2 功能模块与角色设计我最初跟朋友聊需求的时候先拉了三个角色出来普通访客想领养的人、救助站管理员日常维护宠物信息和处理申请的人、系统超级管理员管账号和权限的人。后面实际开发时发现救助站内部还需要细分就又加了救助人角色——就是在一线救助流浪动物、把宠物送到救助站的那批志愿者。每个角色的功能边界我在第一版设计稿里就定了未登录访客浏览宠物列表、查看宠物详情、搜索筛选、查看救助动态注册用户领养人在线提交领养申请、查看申请进度、上传回访照片、收藏关注的宠物救助人注册后申请身份提交流浪宠物救助信息、上传现场照片、跟踪救助状态救助站管理员宠物档案管理录入/编辑/下架、领养申请审核、领养协议生成、站内公告发布、回访任务分配系统管理员用户管理、角色权限分配、数据统计分析、系统日志查看1.3 为什么是Node.js加Vue这套组合选型这件事我纠结过一阵子。后端当时考虑了Java Spring Boot和Node.js前端考虑过Vue和React。最后定Node.js加Vue理由很实际这个小团队没人专职运维Java那一套重环境而Node.js生态对于这种中小型Web应用来说开发效率是真的高。Express框架几十行代码就能把RESTful API搭起来配合MongoDB或者MySQL都能玩得转Node的异步非阻塞I/O模型在处理宠物图片上传、文件流读取这类I/O密集场景下也不会拉胯。前端选Vue的原因更直接——组件化开发和响应式数据绑定让宠物卡片列表、审核表单这类交互密集型页面的开发速度快很多。Vue Router做前端路由、Vuex/Pinia做全局状态比如用户登录态、宠物筛选条件这些周边生态都是现成的不用自己造轮子。再加上Vue的中文文档质量高、社区活跃出问题排查方案比较好找对于一个需要长期维护给救助机构使用的系统来说后续有人能接手的可能性也更大。2. 技术选型背后的决策逻辑2.1 后端架构Express MySQL JWT后端我用了Express 4 MySQL 8.0的组合并没有上MongoDB。虽然Node社区里有很多人倾向用MongoDB存非结构化数据但宠物领养救助平台的业务逻辑里有大量强关联数据用户和申请、申请和宠物、宠物和救助记录、回访记录和领养人这些用关系型数据库做主存储在事务一致性上更稳妥。比如一个领养申请提交后同时要更新宠物状态为“审核中”这种跨表操作在MySQL里用事务包裹就是常规操作换成MongoDB还得手动处理原子性问题。API鉴权我用的JWT原因是救助站管理员和普通用户的权限差异很大——普通用户只能提交申请、更新自己的资料管理员能操作宠物库全部数据。JWT的无状态特性正好匹配这类前后端分离的场景登录成功后前端拿token存到localStorage每次请求带上Authorization头后端中间件统一解析校验。具体的token载荷我放了userId和role两个字段过期时间设置为24小时需要在JWT中校验过期时间避免token泄露后无限期使用。2.2 前端工程化Vue 3 Vite Element Plus前端框架选了Vue 3的组合式API配套Vite做构建工具。Vite的开发服务器启动速度和热更新体验比Webpack时代的Vue CLI好很多npm run dev基本秒开这对调试宠物管理这种需要反复改样式和交互的页面来说效率提升是实打实的。UI组件库用的Element Plus表格、表单、弹窗、分页这些都是现成的做后台管理界面的时候省了至少一周的工作量。前端项目结构我按功能模块划分每个模块一个目录内部再分views页面组件、components业务组件、api接口封装、router路由配置。宠物模块、领养模块、用户模块、救助模块、统计模块这五个业务目录是独立的新增功能不动其他模块的代码。2.3 前后端分离与API约定整个系统采用前后端分离架构前端跑在Vite开发服务器上通过HTTP请求访问后端API通信格式统一用JSON。RESTful风格的接口是我在项目启动时就定好的约定例如获取宠物列表是GET /api/pets创建领养申请是POST /api/adoptions审核通过是PUT /api/adoptions/:id/approve。前端所有接口请求我用axios封装了一个request模块统一处理baseURL、token注入、错误码提示避免每个页面各自为政地写fetch。跨域问题在开发阶段通过Vite的server.proxy配置解决将前端服务器上的/api路径代理到后端地址。生产部署阶段则通过nginx反向代理将前后端统一到同一域下彻底规避跨域限制。3. 数据库设计与核心模型3.1 用户表与角色体系数据库设计是整个项目的根基这块我反复调整了三版才定下来。用户表users是全系统的基础字段包含id、用户名、密码bcrypt加密后的hash、手机号、邮箱、角色标识、注册时间、状态。角色标识我是用字符串直接存的user领养人、 rescuer救助人、 admin管理员、 super超管权限判断时直接比较这个字段没有引入复杂的RBAC表结构。对于救助站这种人员规模很小的机构过度设计权限表反而增加维护成本。救助人跟普通用户是一张表只是extra字段里多存了救助证号或机构认证信息。这跟正规保险机构的代理人分级逻辑类似——基础身份表复用扩展属性通过附加字段承载。3.2 宠物信息表与状态流转宠物表pets是业务核心字段设计上我参考了宠物医院病历和民政机构登记表的思路。名称、品种、毛色、年龄、性别这些基本档案字段都齐全另外还有入站日期、来源类型救助站接收、个人救助送养、主人弃养、健康状态、疫苗记录、绝育状态、性格描述、当前状态。这里有个关键字段叫status管理着一只宠物的全生命周期状态流转待入站 - 可领养 - 审核中 - 已领养 - 已离世 | | | ---- 治疗中 --------状态只能按顺时针方向流转比如可领养状态的宠物被提交了领养申请后变成审核中审核通过变成已领养审核拒绝则回退为可领养。这个状态机规则我在后端service层写死了前端即使传了非法状态值也会被校验拦截。宠物图片我单独建了一张pet_images表因为一只宠物通常有多张照片正面照、全身照、救助现场照用一对多关联存储比把JSON数组塞在pet表里更符合第一范式。每张图片存的是上传到服务器后的相对路径配合图片CDN访问实际文件名是uuid格式防止重复名冲突。3.3 领养申请表与审核链路领养申请表adoption_requests的字段包括关联宠物id、申请人id、申请类型个人领养/机构领养、家庭住址、住房类型自有/租赁、家庭成员情况、宠物饲养经验、领养理由、状态、审核人id、审核意见、创建时间、更新时间。状态字段是这个表的灵魂我定义了四级审核流程待初审 - 初审通过待家访 - 家访通过待签协议 - 已完成。之所以把审核拆得这么细是跟救助站负责人聊过后发现他们遇到最多的纠纷就是领养流程不规范——有人提交申请后救助站还没核实家庭情况宠物就被接走了后面发现虐宠事件找不回来。拆成四级流程后每步都有明确的操作人和时间记录责任可追溯。前端领养申请页面的表单校验也是按这套规则写的。3.4 救助信息表与回访记录救助信息表rescue_records记录的是平台另一类核心业务数据即救助人上报的流浪动物救助事件。字段涵盖救助人id、救助时间、发现地点经纬度和文本描述双存储、动物种类、现场情况描述、紧急程度、处理状态待接收/已接收入站/已安置。地理位置的经纬度字段是为了后续在管理端地图上做救助热力图和站点分布图预留的。领养回访表follow_up_records则关联领养申请id和宠物id字段有回访日期、回访方式线上视频/线下家访/电话、宠物当前状态健康/生病/走失/死亡、回访人id、回访描述、附件图片。救助站规定领养后三个月内至少完成两次回访这个规则我做成后台定时任务到期自动生成回访工单提醒管理员。4. 核心功能模块的实战开发4.1 API接口设计与RESTful规范整个后端API我按资源维度划分每个资源对应一个router模块。项目运行时所有路由挂在/api前缀下方便nginx统一转发。最核心的几个接口设计如下GET /api/pets 宠物列表支持关键词搜索、品种筛选、状态筛选、分页 GET /api/pets/:id 宠物详情含图片列表、领养要求、救助记录 POST /api/pets 新增宠物档案管理员/救助人权限 PUT /api/pets/:id 更新宠物信息管理员权限 PUT /api/pets/:id/status 更新宠物状态管理员权限 POST /api/adoptions 提交领养申请登录用户 GET /api/adoptions/mine 查看我的申请列表登录用户 PUT /api/adoptions/:id/approve 审核通过管理员 PUT /api/adoptions/:id/reject 审核拒绝管理员 POST /api/rescues 提交救助上报登录用户 GET /api/rescues 救助列表按时间倒序状态筛选 GET /api/notifications 获取我的消息通知 POST /api/upload 图片上传鉴权后返回访问路径每个接口的参数校验我都用了express-validator比在业务代码里手写if else判空优雅得多。校验规则写在单独的文件里比如petValidation.js里定义name必填且长度2到30个字符、age字段是整数且范围0到30、status必须在枚举数组里。这样写法的一个好处是前端和后端可以共用一套校验思路前端表单验证规则我参照后端同样实现。4.2 宠物档案模块的实现细节宠物档案录入是整个平台数据质量的源头这块我做了很多体验优化。前端录入表单支持拖拽上传多张图片list数据提交到后端后会先被multer中间件处理保存到本地磁盘的uploads/pets/目录下然后后端把每个文件路径插入pet_images表。为了防止上传超大图片拖垮服务器性能multer的limits配置里我限定了文件大小不超过5MB超限的直接返回413错误。宠物创建成功后系统会自动生成一条待办通知推送给所有管理员账号内容大致是“新宠物档案[名称]等待审核上架”。这里有一个细节值得说新录入的宠物状态默认不是可领养而是待审核。因为救助站录入员可能同时录入几十只宠物先统一审核确认健康信息无误后再批量上架到前台展示避免有些宠物还在治疗期就被用户看到产生无效领养意向。前端宠物详情页我用了Vue Router的动态路由配合keep-alive缓存切换不同宠物时页面不会整页刷新浏览体验比较流畅。图片画廊用的是Element Plus的el-carousel轮播组件支持左右切换和缩略图预览。4.3 领养审核流程的完整实现领养审核流程是整个平台里业务逻辑最复杂的部分我在后端用一个adoptionService.js集中处理前端配合一个多步骤表单页面。核心的业务逻辑有三个一是状态机流转约束二是消息通知触发三是宠物状态联动更新。用户提交领养申请时后端在事务里做两件事插入adoption_requests记录同时把对应宠物状态从可领养改成审核中。这里一定要用事务否则会出现申请记录了但宠物状态没变的数据不一致问题。如果同一只宠物在审核中又被别人提交申请我通过一个前置状态检查拦截掉返回提示“该宠物已被其他用户申请请选择其他宝贝”。管理员在后台审核时每一级操作都会触发通知推送初审通过通知用户准备家访材料家访通过通知用户到站签署领养协议全部完成后系统发送领养成功祝福语并附带回访计划说明。这些通知的模板都预置在数据库表里管理员也可以自定义编辑。4.4 救助上报与图片处理救助上报模块面向的是在街上发现流浪动物的爱心群众。考虑到用户可能是在户外移动网络下使用前端表单设计得极度克制只有地点、种类、情况描述、紧急程度、照片这五个必填字段整体可以在一分钟内填完。保存时后端通过逆地理编码把经纬度转换成行政区域名称比如“朝阳区望京街道”方便管理员按区域检索和筛选。图片处理上踩过一个坑最初是直接把用户上传的图片原图存到服务器再前端显示结果手机拍的照片动辄3到5MB页面加载慢到怀疑人生。后来我用sharp库做了统一压缩上传时自动生成两个尺寸800px宽度的展示图和200px宽度的缩略图存储路径分两个目录。缩略图用于列表页加速渲染详情页加载展示图。实际效果是列表页首屏加载速度提升了差不多4倍这个优化对救助站内部使用低配电脑的场景特别关键。4.5 权限控制与JWT鉴权实现权限控制我用了一个express中间件叫authMiddleware.js核心逻辑是从请求头取token解密拿到payload把userId和role挂到req对象上再根据路由配置的权限要求判断是否放行。 adminRequired、rescuerRequired、userRequired这三个权限中间件是组合使用的比如领养申请接口要求userRequired宠物新增接口要求adminOrRescuerRequired用户管理接口要求superAdminRequired。有个细节很容易漏部分接口既需要登录又允许匿名访问比如宠物列表接口未登录用户可以看登录用户看了后前端会额外显示“收藏”按钮和“申请领养”入口。这种场景我先放行所有请求在controller里判断req.userId是否存在来返回不同的数据载荷。前端则可以拿axios响应里的isLogin字段来切换展示逻辑。5. 环境配置与新手最常踩的坑5.1 Node.js安装与环境变量配置这个项目的第一步当然是把Node.js环境装好。很多从零开始的朋友在这里就被卡住了尤其是Windows上出现那个著名的报错“npm : 无法加载文件 D:\Program Files\nodejs\npm.ps1因为在此系统上禁止运行脚本”。这不是node装坏了而是PowerShell的执行策略默认禁止运行.ps1脚本。解决方案有两个。方案一推荐以管理员身份打开PowerShell执行一条命令Set-ExecutionPolicy RemoteSigned执行后输入Y确认然后重启终端。RemoteSigned的含义是本地创建的脚本可以直接运行从网上下载的脚本必须有可信签名。这个策略兼顾了安全性和日常开发需求。方案二完全避开PowerShell改用cmd命令行来运行npm命令。VSCode里新建终端时右上角下拉选“命令提示符”而不是“PowerShell”npm命令就能正常跑。这个方法不用改任何系统设置适合不想动执行策略的朋友。Node.js安装包我建议直接去官网下载LTS长期支持版本当时我用的是Node 18.x稳定性和兼容性都很好。安装时有个关键选项“Add to PATH”一定要勾上没有勾的话npm命令会提示找不到。如果之前装错了没勾上补救方法是手动编辑环境变量右键“此电脑”→属性→高级系统设置→环境变量→Path里加上Node.js的安装目录例如D:\Program Files\nodejs\。装完后命令行验证三件事node -v # 查看Node版本 npm -v # 查看npm版本 where node # 确认Node路径已加入环境变量三条命令都有正常输出环境就基本没问题了。5.2 前端工程创建与依赖安装实战环境就绪后前端用的Vite脚手架创建项目。为什么我不用Vue CLI原因前面提到了Vite的启动速度和高热更新体验对于后续频繁修改页面组件、联调接口来说能节省大量等待时间。创建命令如下npm create vitelatest pet-frontend -- --template vue cd pet-frontend npm install npm run dev这里有一个很关键的步骤别漏了——创建完项目后立刻安装路由和状态管理及UI组件库npm install vue-router4 pinia element-plus axiosElement Plus的完整引入方式是在main.js里注册import ElementPlus from element-plus再引入样式文件import element-plus/dist/index.css。如果只想用按需导入需要额外装unplugin-auto-import和unplugin-vue-components配合Vite插件配置。对于业务系统来说完整引入更省心打包体积大点也能接受。后端项目结构我是用Express脚手架生成的虽然没有官方CLI但网上有很多项目模板可用。最简单的方式是自己建一个项目目录然后npm init -y npm install express mysql2 cors dotenv jsonwebtoken bcryptjs multer sharp express-validator这些依赖的作用分别是express是Web框架mysql2是MySQL驱动cors解决开发阶段跨域dotenv读.env配置文件jsonwebtoken做JWTbcryptjs给密码加密multer处理文件上传sharp做图片压缩express-validator做参数校验。一次性装全避免后续一个模块一个模块地补。5.3 前端必学基础与常用配置如果你是Vue新手建议先把这几块基础打牢再动手写业务代码。组合式API的script setup写法是现在的主流写起来比Options API简洁不少Vue Router的动态路由和路由守卫必须掌握因为平台的权限跳转、页面缓存依赖路由机制实现Pinia是状态管理的推荐方案相对于Vuex它的TypeScript支持和代码体积控制都更好Element Plus的组件文档要熟读特别是el-form表单验证和el-table表格的常用插槽这两个是后台页面的高频场景。一个Vue开发中容易忽略的配置是devServer代理。前端跑在5173端口后端跑在3000端口前端直接axios调用后端接口必然跨域。在vite.config.js里配置server: { proxy: { /api: { target: http://localhost:3000, changeOrigin: true } } }这样前端代码里请求写 /api/pets 就够了不用写完整的http://localhost:3000/api/pets部署到生产环境时只需改nginx代理目标不用改业务代码。6. 前后端联调与生产部署实践6.1 接口联调与Mock方案前后端并行开发时接口协议不一致是家常便饭。我采用的方案是后端先定义好OpenAPI文档写在一个openapi.yaml文件里前端严格按照文档封装request函数。在后端还没完全就绪前前端用Vite的mock插件在本地模拟接口数据这样两边的开发进度互不阻塞。联调阶段我习惯在浏览器DevTools里观察Network面板重点检查两个地方响应状态码是否符合预期、请求体/响应体的字段名是否跟接口文档一致。常见的问题比如后端返回的是data字段而前端解析的是list字段这类低级错误在联调初期最耗时间。后来我加了个规矩——所有接口返回格式统一为{ code: 0, message: success, data: {} }code为0表示成功非0就是各种业务错误码。前端axios拦截器统一处理code逻辑业务代码里不用到处写try catch干净很多。6.2 生产环境构建与Nginx配置开发完成后前端打包是一行命令npm run build打包产物生成在dist目录里面是纯静态文件。后端则是一整套Node.js服务代码通过pm2进程守护运行。生产环境我用了nginx来做静态文件托管和反向代理关键配置片段如下server { listen 80; server_name adopt.example.com; location / { root /var/www/pet-frontend/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:3000/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /uploads/ { alias /var/www/pet-backend/uploads/; } }try_files加这个配置很关键——Vue是单页应用路由切换用的history模式用户在某个子路由下刷新页面时nginx需要把请求重新指向index.html否则会返回404。uploads目录映射不能少宠物图片的访问路径通过nginx直接指向后台上传目录不走Node进程静态文件访问效率更高。后端部署我用的pm2进程管理命令非常简单pm2 start ecosystem.config.jsecosystem.config.js里配置了应用名称、脚本入口、环境变量和实例数量。pm2的自动重启和日志采集功能对救助站这种没有专职运维的场景来说足够可靠了。有一次后端代码里有个内存泄漏的bug服务器跑了三天内存快满了pm2检测到后自动重启了进程平台服务没有中断这个机制在正式环境里非常有用。6.3 服务器环境部署避坑第一次部署到云服务器时踩了两个坑。第一个是服务器的防火墙和云安全组必须同时放行端口我在腾讯云控制台开了80端口但忘了服务器内部ufw默认只允许22端口导致外部一直访问不了。第二个坑是MySQL的root账号默认只能本地登录后端进程连接数据库报权限错误解决方法是创建一个专门的应用账号并授权CREATE USER petapplocalhost IDENTIFIED BY YourStrongPassword; GRANT ALL PRIVILEGES ON pet_adoption.* TO petapplocalhost; FLUSH PRIVILEGES;生产环境强烈不建议用root账号直连数据库权限最小化原则能降低很多安全风险。还有数据库的数据文件和安全备份策略要提前规划我当时写了一个crontab定时任务每天凌晨2点用mysqldump备份数据库到指定目录并保留最近7天的备份文件。对于救助站来说宠物档案和领养协议是珍贵的核心资产丢数据比丢服务器还严重。7. 常见问题排查与优化技巧7.1 MongoDB还是MySQL数据存储的取舍汇总表开发期间有不少朋友问我这类平台到底该选什么数据库我把典型的场景对比整理成了一个表方便你选型时直接参考对比维度MySQLMongoDB数据关系强关联数据用户、申请、审核支持好灵活文档嵌套适合半结构化数据事务支持原生支持ACID事务多文档事务较繁琐后期运维备份恢复生态成熟需额外学习聚合管道等概念典型场景本平台业务强流程与强审核链路日志、动态表单、评论回复等性能取舍关联查询性能稳定可控高并发读取表现好选型没有绝对的对错核心看系统业务是否强依赖多表关系和事务一致性。我们这个平台从申请到审核到回访的链路到处都是事务场景MySQL无疑是更稳妥的选择。7.2 npm与Node高频报错速查表开发期的报错处理我整理了最常遇到的几个问题及解决办法报错现象原因解决方案npm : 无法加载文件 npm.ps1禁止运行脚本PowerShell执行策略限制管理员身份执行Set-ExecutionPolicy RemoteSignedError: Cannot find module xxx依赖未安装或安装不完整npm install xxx或删除node_modules后重装code ELIFECYCLEnpm run serve崩溃端口被占用或代码语法错误检查占用端口使用npx kill-port 5173ERR_PNPM_NO_SCRIPT 或 Scripts cannot be executed非npm包管理器问题统一使用npm项目根目录删除pnpm-lock.yamlVue Router报错 No match for route路由路径写错或history模式与后端不搭配检查routes定义生产环境nginx配置try_files7.3 前端性能优化记录前端上线后我做了三次性能优化收益最明显的是三件事。第一件是图片懒加载宠物列表里几百张图片如果一次性全部加载缩略图也扛不住流量。我用Vue自定义指令实现了懒加载滚动到视口范围内才加载img的src首屏时间缩短了将近半秒。第二件是路由懒加载Vue Router里把每个页面组件改成动态import首屏只加载当前路由对应的组件代码整体包体小了40%。第三件是浏览器缓存策略打包后的静态资源文件名带hash值nginx配置Cache-Control头设置为一年用户二次访问基本走本地缓存服务器压力小了很多。7.4 数据一致性与安全校验要重锤安全校验不能只靠前端表单。我在后端所有写操作接口里都做了参数校验和权限校验特别是商家和用户的审核环节比如领养申请通过接口必须校验当前登录人角色是不是管理员否则返回403。再比如上传图片时multer不仅限大小还通过fileFilter限制扩展名必须是jpg、jpeg、png、gif防止有人上传webshell文件到服务器。之前看过不少项目因为文件上传过滤不严导致站点被挂马这个血泪教训值得记录。8. 项目扩展方向与后续维护经验8.1 积分与信用体系上线三个月后有救助站反馈想加一个领养信用体系。后来我把用户表扩展了credits字段领养人每完成一次回访加一定的积分积分累积到阈值可以优先领养热门宠物。救助人上报一条有效救助信息加积分换救助物资。这个体系的本质是把线下的公益行为数字化通过积分杠杆鼓励更多人参与进来。技术实现层面就是在几个关键操作点上加积分流水记录表结构上新增一张credit_logs表记录每次增减行为。8.2 微信小程序适配的想法平台在PC端跑通后救助站的伙伴们提出微信里用的最多的是手机浏览器我们就用同一个后端API适配了一个H5版。有了H5版的API后续再做微信小程序只需写好小程序的页面组件复用后端的接口和业务流程不需要重建后端。这是我当初坚持前后端分离的最大收益之一——后端API跟客户端解耦未来无论适配什么新的前端入口成本都不会太高。8.3 与地方救助机构合作的数据共享最后聊一点宏观层面的经验。宠物领养救助从来不是一个技术问题就能全部解决的社会问题但好的工具确实能让参与其中的每个人效率都更高。在技术上平台可以给不同的救助站分配租户标识单个实例里把宠物、申请、回访数据按机构维度隔离未来做跨机构的数据汇总和流转就方便多了。我想强调的是做这类公益向的系统最重要的是做好数据备份和安全保障。救助站的志愿者往往不太关注IT运维所以我们在部署时加了自动化备份脚本和监控告警数据库异常时能第一时间通知到管理员微信。系统上线半年经历了两次服务器迁移和一次磁盘故障数据都毫发无损这也是我对这套架构最满意的地方。