做宠物领养救助平台这套东西，说实话最初我是被朋友拉着入坑的。当时他所在的民间救助站还在用纸质表格登记流浪猫狗信息，领养人要看宠物照片还得翻朋友圈相册，效率低到离谱。后来我花了大半个学期用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 vite@latest pet-frontend -- --template vue cd pet-frontend npm install npm run dev这里有一个很关键的步骤别漏了——创建完项目后立刻安装路由和状态管理及UI组件库：
npm install vue-router@4 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做JWT，bcryptjs给密码加密，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 'petapp'@'localhost' IDENTIFIED BY 'YourStrongPassword'; GRANT ALL PRIVILEGES ON pet_adoption.* TO 'petapp'@'localhost'; FLUSH PRIVILEGES;生产环境强烈不建议用root账号直连数据库，权限最小化原则能降低很多安全风险。还有数据库的数据文件和安全备份策略要提前规划，我当时写了一个crontab定时任务，每天凌晨2点用mysqldump备份数据库到指定目录，并保留最近7天的备份文件。对于救助站来说，宠物档案和领养协议是珍贵的核心资产，丢数据比丢服务器还严重。
7. 常见问题排查与优化技巧
7.1 MongoDB还是MySQL？数据存储的取舍汇总表
开发期间有不少朋友问我这类平台到底该选什么数据库，我把典型的场景对比整理成了一个表，方便你选型时直接参考：
| 对比维度 | MySQL | MongoDB |
|---|---|---|
| 数据关系 | 强关联数据（用户、申请、审核）支持好 | 灵活文档嵌套，适合半结构化数据 |
| 事务支持 | 原生支持ACID事务 | 多文档事务较繁琐 |
| 后期运维 | 备份恢复生态成熟 | 需额外学习聚合管道等概念 |
| 典型场景 | 本平台业务，强流程与强审核链路 | 日志、动态表单、评论回复等 |
| 性能取舍 | 关联查询性能稳定可控 | 高并发读取表现好 |
选型没有绝对的对错，核心看系统业务是否强依赖多表关系和事务一致性。我们这个平台从申请到审核到回访的链路到处都是事务场景，MySQL无疑是更稳妥的选择。
7.2 npm与Node高频报错速查表
开发期的报错处理，我整理了最常遇到的几个问题及解决办法：
| 报错现象 | 原因 | 解决方案 |
|---|---|---|
| npm : 无法加载文件 npm.ps1，禁止运行脚本 | PowerShell执行策略限制 | 管理员身份执行Set-ExecutionPolicy RemoteSigned |
| Error: Cannot find module 'xxx' | 依赖未安装或安装不完整 | npm install xxx，或删除node_modules后重装 |
| code ELIFECYCLE，npm run serve崩溃 | 端口被占用或代码语法错误 | 检查占用端口，使用npx kill-port 5173 |
| ERR_PNPM_NO_SCRIPT 或 Scripts cannot be executed | 非npm包管理器问题 | 统一使用npm，项目根目录删除pnpm-lock.yaml |
| Vue Router报错 No match for route | 路由路径写错或history模式与后端不搭配 | 检查routes定义，生产环境nginx配置try_files |
7.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运维，所以我们在部署时加了自动化备份脚本和监控告警，数据库异常时能第一时间通知到管理员微信。系统上线半年，经历了两次服务器迁移和一次磁盘故障，数据都毫发无损，这也是我对这套架构最满意的地方。
