Blizzard
9b30bfaaff
## 为什么不是「从计划开始日起 30 天」 上一版是那样做的，截图一看就不对：计划是月中建的，日历显示 「7月26日 — 8月25日」，既不像本月也不像下月，用户想问「这个月还剩什么」 根本对不上。改成自然月，日历就是一眼能认的月历。 能翻到下月 —— 否则「做下月计划」这件事本身做不了。 ## 校验从「Day 上限」改成「日期」 PlanTask.Day 是相对计划开始日的，月份边界是相对今天的，两者会错开。 原来卡 Day<=30，计划建了几天之后下月末就换算成 Day=40 多， 用户在日历上明明看得到那格、点进去却存不了。 现在的规则：不早于计划开始日（下界放到开始日而不是本月 1 号——模板生成的 历史节点可能在上个月，那些要允许原地改），不晚于下月月底。 ## 应用到每天 一天建一条，不做「一条 + repeat 字段读时展开」：勾选状态是按天的， 展开方案还得再开一张表记「哪天打过勾」，而直接建 N 条天然就有这个能力。 范围止于**这一天所在那个月**的月底，不跨月——「应用到每天」说的是这个月每天， 跨过去就变成用户没要求的事了。只有新增能选，已有的那条改成每天等于凭空 复制 N 份（用户想要的是「以后每天」，不是「把这条撒开」）。 ## 首页那个提醒 GET /pets/:id/plan/month-status 返回本月件数/剩余、下月件数、need_next。 need_next 只在**月末最后 7 天**且下月为空时为真：月初就催「排下个月」太早， 用户会当成噪音。角标做在图标上而不是弹 toast——每次进首页弹一下很烦， 而这件事不紧急、看见就行。 副标题有优先级：「8 月计划还没排」压过「本月都做完了」，因为前者有时效。 四种状态实跑验过，包括让位关系。 ## 顺手 pet-switch 加 show-add 属性。计划页只需要在既有宠物之间切，建档入口在首页 和「我的」就够了，到处摆一个「添加」会让这条 chip 变得很长。 本月/下月的切换用新的 .link-tabs 而不是挂在 .head-links 上：首页的 「管理 / 全部完成」也用 head-links，那是两个并列动作，不该有一个是灰的。 ## 验证（预生产库实跑） 月边界 本月末通过、下月末通过、下下月拒（报出具体日期） 应用到每天 今天→本月末 2 条，没跨月 month-status 下月清空 → need_next 翻 true；补一条 → 翻回 false 四种副标题 下月未排 / 本月还有 N 件 / 本月都做完了 / 还没有安排，含优先级 测试数据全部还原 上一条 cd 打错目录，导致「日期窗口」那次改动没写进文件、只有批量那半截进去了， 所以中间出现过一次 planWindow undefined。这次一并改对。 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 重新登录。