【喵呜档案】流浪猫救助也能「上云」？这款多端协作小工具，把档案 + 打卡 + 账本一次搞定

不是又一个宠物社区，而是给真·一线救助队用的协作面板；下面我会按「能看懂、能装 X、能判断要不要用」来聊，功能干货和技术名词穿插，图多字少，读着不累。

目录： 先看界面 · 技术栈一瞥 · 核心能力 · 谁适合用

先别急着卷，直接看一眼产品长啥样

首页承担「入口 + 图鉴/动态」的聚合：底栏 Tab、轮播、快捷入口都是典型小程序信息架构，后面展开的打卡、喵星、个人中心，都围绕这一套导航跑。

---

写在前面：为啥需要单独一套工具？

救助场景里，微信群 + 备忘录 + Excel 是常态——信息一多就乱：今天谁去喂了？这猫换过药没？上月捐款和支出对得上吗？同一只猫要在一堆群里重复讲「它的故事」。

喵呜档案想做的，是把「结构化档案、协作时间线、可审计的账本、分层权限」收进一个产品里：面向高校社团、小区群、小团队，不替代你线下撸猫，只把杂事和信任成本降下来。

---

技术栈一瞥

工程上，前端走 uni-app（Vue 3 + TypeScript） 一把梭：微信小程序、H5、App 共用一套 UI 与业务逻辑，请求统一走 HTTPS + REST；后端是 Java 17 + Spring Boot 3 的聚合服务，数据落在 PostgreSQL，权限上采用 RBAC 思路 的多角色模型（主理、铲屎官、喵星人、云守护、游客等），支付与资金相关能力由支付网关统一接入——具体路由与配置属于部署范畴，这里不展开。

对读者来说，你只需知道：三端一个账户、一个 API 面、数据同源，比「每端各写一坨」要省心得多。

终端：微信小程序 / H5 / App  ←→  REST API  ←→  Spring Boot 业务  ←→  PostgreSQL
                                    ↑
                            支付网关 · 文件存储 等按模块接入

---

核心能力

1. 图鉴 + 档案：不只是一本「猫咪相册」

图鉴里按「喵星 / 区域 / 全国」等维度浏览，点进单猫是结构化档案：照片、健康、位置、故事……本质是 CRUD 友好的领域模型 + 可见性策略（公开 / 仅队内），既方便领养宣传，也避免敏感信息裸奔。

2. 协作打卡：把「时间线」写进产品，而不是写进群公告

多人在同一片区接力时，最怕「我以为你去喂了」。打卡侧支持选猫、选操作（喂养、换水、喂药、TNR 相关等），带图提交、按日聚合，在服务端形成可追溯记录——和「在群里发一句」相比，可检索、可统计、可复盘是本质差别。

小提示：同类操作在同日有条数上限（防刷、防误触），产品里会有明确提示；细节以线上一致为准。

3. 阳光账本：凭证 + 筛选 + 公示

善款最怕「说不清」。账本侧强调 收支可附凭证、按条件筛选、可生成长图/公示用视图，让「钱从哪来、花到哪去」在团队与捐赠方之间对齐事实，减少扯皮。业务上零平台抽成、捐款直达主理人是信任设计的一部分（规则以产品说明为准）。

4. 云守护 + 主理人订阅：供给侧、需求侧两条收入逻辑

• 云守护：低门槛远程参与，与指定 喵星 绑定，适合「想帮但不在现场」的人。
• 主理人订阅：为创建/管理喵星的一方提供时长制权益（如体验/标准/尊享档），和云守护是两条线——一个管「队长的工具箱」，一个管「远方的人的参与感」。

5. 我的：角色、个人中心、设置一锅端

**「我的」**里聚合订阅状态、云守护、设置、关于等，对应前面说的 多角色、多端统一账号（如 微信登录 等），一人一套权限视图，谁该看啥、能改啥，在界面上就分流了。

---

谁适合用

你的场景	可能带来的收益
高校动保、年年换届	档案与记录留在喵星里，减轻「人走表丢」
小区多志愿者喂同一片	打卡时间线减少重复/遗漏
常被问「钱呢」	阳光账本 + 凭证 + 公示视图，对齐预期
想拉远程支持者	云守护给一条轻量、正式的参与路径

---

小结： 用 uni-app + Spring Boot + PostgreSQL 做底座，用 RBAC 式多角色 管住权限，用 时间线式打卡 和 可凭证账本 管住协作与信任——喵呜档案要解决的，是救助协作里最烦人的信息问题，不是替代人与猫之间的温度。

如果这篇对你有用，欢迎 Star / 收藏；想交流「公益 + 工程」落地，也欢迎在 Issue 里理性讨论（请勿粘贴密钥、内网地址）。

版权所有 © 2026 喵呜档案团队。