Blizzard
c4c0c2b7cd
## 你问的「养了半年会不会自动切换」
原来的答案是「都不会，而且比这更糟」：
age「2个月」 建档时算好存进库，养半年后首页还显示 2个月
stage「幼年期」同上，一年后还是幼年期
养护方案 按 stage 挑的，所以永远给幼猫那套
NormalizeStage 只在建档那一次调用（handler/pet.go:51），之后就是两个死字符串。
现在：
age 改成计算字段（gorm:"-"），读取时现算。它没有手改需求，存下来只会过期。
填在 ownedPet 这个收口里，不是逐个函数补——那样漏一个就返回空年龄。
stage 保留存储（有正当的手改需求：领养的猫生日是估的，主人按体型判断更准），
但加了漂移检测 GET /pets/:id/stage-drift。
**系统负责发现，用户负责决定。** 不自动改的三个理由：
1. 用户可能手改过
2. 已经排好的这个月计划不该被推翻（套用是「往里加」不是「替换」）
3. 偷偷换会让用户莫名发现计划变了，找不到原因
## 猫狗不能共用阈值 —— 这是这次最实质的发现
原来一刀切「<12月幼年，>=7岁老年」，对猫勉强，对狗两头都错：
吉娃娃 8 个月已性成熟、可换成犬粮；大丹犬 8 个月还在长骨头，
这时喂成犬粮（钙磷比和热量密度都不同）会加重关节负担。
吉娃娃 7 岁还在成年期（8 岁才进中年，能活 13-16 年）；
大丹犬 7 岁已是老年（平均寿命 7-10 年）。
所以狗的阶段判定要看体型。体型不能靠当前体重（幼犬体重说明不了成年后多大），
只能靠品种 —— breeds 表加 size_class，45 个犬种逐个标了。
实测：同样 10 个月大 → 吉娃娃青年期、柴犬幼年期、金毛幼年期、大丹犬幼年期；
同样 7 岁 → 吉娃娃成年期、大丹犬老年期。
## 阶段 3 段 → 5 段
幼年期 / 青年期 / 成年期 / 中年期 / 老年期。
标签做成物种中立（不分幼猫期/幼犬期）——物种本来是另一个字段，
分开会让 (species,stage) 的组合和方案配置都翻倍。
「刚到家 0-30 天」不进这五段：它和年龄正交（刚接回家的成年猫两套都需要），
代码里本来就是叠加处理的。
猫按 AAFP/AAHA 猫生命阶段指南那套，在成年里细分出中年。
狗五段的阈值按体型走四组，越大的犬种生长期越长、老得越早。
## 划分标准和判定用同一张表
StageRules 那张表既驱动判定，也直接吐给前端当依据展示
（GET /api/life-stages?species=dog&size=giant）。
不是「代码里判定 + 文档里写标准」——后者一定会漂：改了阈值忘了改文档，
用户看到的说明和实际行为对不上，比没有说明更糟。
建档第三步的阶段选择器现在会显示「0-18 月 · 巨型犬生长期最长，18 个月还在长；
这阶段最忌过度补钙」，还会标出「巨型犬（成年 >40kg）——阶段阈值按体型算」。
前端和后台的 STAGES 硬编码列表都删了，改成读后端。
## 10 套方案，内容按各阶段真实重点配
不是把同一份换个名字：
幼年期 疫苗序列 + 驱虫 + 社会化，大型犬还要控制生长速度
青年期 绝育窗口 + 换成年粮
成年期 维持期，把基线数据记下来
中年期 年度血检开始有意义，体重和牙结石重点看
老年期 体检半年一次；猫记饮水量（多饮多尿是慢性肾病最典型的早期表现）、
狗记精神食欲，都设成「重要」
老的 8 套（按 3 段配的）改名停用不删：万一新内容有问题还能翻回去看；
而且已套用出去的计划早就和模板断开了，停用不影响任何用户。
## 验证（预生产库实跑）
体型判定 10 个月 / 7 岁两组对照，四个体型都落在预期阶段
age '13个月' 现算，不入库
漂移检测 手改成幼年期后 drifted=true，连带给出新阶段的依据和重点
划分标准 猫 5 段、狗 4 个体型各 5 段，老年起点 7/8/10/11 岁
全链路 3 个月大丹犬建档 → 幼年期 → 0 任务 + 4 条必要提醒 →
挑「幼犬标准照护」→ 套用下月 104 条节点，
周四那天正确出现每周项（检查爪垫和耳朵）
迁移 45 个犬种体型回填；现有 5 只宠物阶段重算后无变化（原本都对）
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
毛孩子计划 · 后端 (pets-be)
Gin + GORM + MySQL + MinIO 的宠物小程序后端，内嵌 React(Vite + Tailwind + shadcn/ui) 后台管理。
技术栈与约定
- 模块路径
github.com/sundynix/pets-be，标准 Go 布局（cmd/ internal/ pkg/ configs/ deployments/ web/） - 所有数据库表带前缀
sundynix_ - 统一响应
{code, message, data}（pkg/response），列表接口统一分页参数page/page_size（response.PageQuery+PageResult） - MySQL
root/root库pets；MinIOsundynix/sundynix桶pets - 服务端口
:8080；后台在http://localhost:8080/admin（seed 管理员sundynix/sundynix）
快速开始
# 1. 起依赖（MySQL + MinIO）
make env-up # 或 cd deployments && docker compose up -d
# 2. 构建后台前端 + 后端单二进制
make build # 产物 bin/pets-be（已 embed 后台）
./bin/pets-be
# 或开发期直接运行（使用现有 internal/admin/dist）
make run
后台前端开发（热更新）
make admin-dev # vite dev server :5173，已代理 /api → :8080
# 改完执行 make admin-build 让产物落到 internal/admin/dist，再 go build 即 embed
目录
cmd/server入口：载配置→连库→迁移→seed→建桶→路由→启动internal/config配置(viper，支持PETS_环境变量覆盖)internal/modelGORM 模型（sundynix_前缀）internal/database连接/迁移/seedinternal/storageMinIO 封装（自动建桶 + 上传）internal/service业务逻辑；internal/handlerHTTP 处理器；internal/router路由internal/middlewareCORS / 用户鉴权 / 管理员鉴权internal/admingo:embed内嵌后台产物 + SPA fallbackpkg/response统一响应与分页；pkg/jwt令牌；pkg/errcode错误码web/admin后台前端源码
接口
- 小程序
/api/*（用户 JWT）：auth / user / pets / onboarding / records / tasks / plan / reminders / report / bill / community / articles / pro / ai / upload - 后台
/api/admin/*（管理员 JWT）：login / stats / users / pets / posts / comments / articles / memberships
登录鉴权
默认 auth.dev_login: true，POST /api/auth/login {"nickname":"xxx"} 即发用户 JWT。
接真微信：在 configs/config.yaml 填 wechat.app_secret 并把 dev_login 置 false，实现 /api/auth/wechat(code2session)。
access token + refresh token
登录接口返回 token(access) 与 refresh_token 两个令牌：
- access token：JWT，默认 2 小时（
jwt.expire_hours），放Authorization: Bearer，服务端无状态校验。 - refresh token：随机串，落库
sundynix_refresh_tokens（只存 sha256）。小程序 30 天、后台 7 天。 - 续期：
POST /api/auth/refresh/POST /api/admin/refresh，入参{"refresh_token":"..."}，返回新的一对令牌。 - 退出：
POST /api/auth/logout/POST /api/admin/logout作废该刷新令牌。
安全约定：
- 每次续期都轮换刷新令牌，旧的立即作废；作废后 60 秒内再到达算并发重试（放行），超过则判定泄露，吊销该账号全部会话。
- 主动退出、被连坐吊销的令牌不享受宽限期。
- 禁用用户时一并吊销其刷新令牌，最多 2 小时后彻底失去访问。
前端两端都做了单飞续期：并发请求同时 401 只会发一次 refresh（否则刷新令牌会被并发轮换掉）。小程序续期失败会回退到 wx.login 重新登录。