Blizzard
|
25f655a6fc
|
feat: 补齐关注的入口——用户主页 + 关注/粉丝列表
关注之前只做了一半:能从帖子上点「+关注」,也有「关注」信息流,但
关注完就石沉大海——没有用户主页、看不到自己关注了谁、也不知道谁关注
了自己。功能是通的,路是断的。
后端新增:
- GET /api/users/:id/profile 公开资料 + 帖子/关注/粉丝三个计数 + 我是否已关注
- GET /api/users/:id/posts TA 发布的帖子
- GET /api/users/:id/relations?kind=following|followers
- /api/user/summary 补 following / followers,否则「我的」页那两行永远是 0
关系列表里「我是否关注了这批人」用一次 IN 查询查完,不是每行一次。
小程序端新增两个页面:
- pages/user/user 用户主页:头像/昵称/三项计数/关注按钮 + TA 的帖子
- pages/relations 关注列表与粉丝列表(同一页,kind 区分)
入口:
- 社区点头像或昵称 → TA 的主页
- 主页点「关注/粉丝」数字 → 对应列表
- 「我的」页新增「我的关注」「我的粉丝」两行
关注按钮先本地翻转再发请求,失败回滚——等接口返回按钮才变会显得很迟钝。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-07-29 17:13:04 +08:00 |
|
Blizzard
|
9fc61e878e
|
feat: 评论支持回复(两级 + @某人)
不做无限层级——手机屏幕撑不住层层缩进,读到第四层就没法看了。
微信、小红书、B站清一色是两级:一级评论 + 其下的回复列表,回复里
用「回复 @某人」表达指向谁。
数据结构:comments 加 parent_id + reply_to_name。回复的回复会被
压平到同一条一级评论下(parent_id 取爷爷的),同时把被回复人的名字
记进 reply_to_name —— 这样既保住两级,又不丢「在跟谁说话」的信息。
几个容易做错的地方:
- 一次查完这一页所有一级评论的回复,不是每条一次查询(N+1)
- 一级评论默认只带 3 条回复,其余点「展开全部 N 条」再拉,避免热门
评论一次返回几百条
- 删一级评论要连它下面的回复一起删,否则回复变成挂在空处的孤儿;
帖子的 comment_count 也要按实际删除条数减,不是减 1
- total 统计含回复,和帖子上显示的数字对得上
- replies 为空时返回 [],不是 null
实测四条评论(含一条回复的回复):
▸ 甲:一级评论 (2 条回复)
└ 乙:多久了?
└ 甲 回复 乙:三天了
▸ 乙:另一条一级评论 (0 条回复)
删掉第一条一级评论后 total 4→1,comment_count 同步。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-07-29 16:33:50 +08:00 |
|
Blizzard
|
5b2f8e50bc
|
fix: 带 date 查任务时区错位导致重复生成 + 评论弹窗重做 + AI 每日次数上限
## 首页添加的任务不显示(根因比表象严重)
time.Parse("2006-01-02", q) 返回的是 UTC 时间,dayStart 又保留了
t.Location(),于是带 ?date= 查询时:
查询区间 = 07-29 00:00 UTC ~ 次日 = CST 的 08:00 ~ 次日 08:00
已有任务的 task_date 是 07-29 00:00 CST,落在区间外
后果不只是「新任务不显示」——ensureDayTasks 因此认为今天没有任务,
每刷一次首页就重新生成一批。用户手动加的那条(00:00 CST)永远不在
那个错位窗口里,所以管理页看得到、首页看不到。
全项目 7 处 time.Parse 日期解析统一换成 ParseInLocation + time.Local
(任务、日计划、生日、到家日期、提醒到期日都受影响)。
实测:加一条后带 date 查得到 4 条,连查 4 次仍是 4 条不再增长。
## 评论弹窗
- 改成居中弹出。评论以输入为主,贴底弹层会被键盘顶掉大半屏
- 单行 input 换成自动撑高的 textarea,最多 500 字,带字数
- 支持配图,最多 3 张(评论表加 images 字段)
- 空评论原来会直接把弹层关掉,看起来像发成功了,改成明确提示
- 发完就地刷新列表,不再关闭弹层——连着回复更顺
## AI 每日次数上限
AI 调用是真金白银,不设上限等于把钱包交给用户。新增按「用户 + 自然日
+ 功能」计的额度,后台「社区运营」页可配问问 AI / 异常评估 / AI 计划
三档,改完立即生效。
两个刻意的设计:
- 扣额度在请求大模型之前,失败也算用掉一次。否则刷接口空转照样烧钱
- 配置读不到时回落到保守默认值,绝不「读不到就不限制」——那正是配置
出问题时最不该发生的事
超限返回业务码 42900,小程序端明确说明「明天 0 点恢复」,不当成网络
错误让用户反复重试。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-07-29 15:50:38 +08:00 |
|
Blizzard
|
75765b3ee8
|
feat: 健康洞察——把散落的记录变成能看懂的结论
之前用户记几十条数据只换回一条折线,数据没有回到他身上,所以不记也不亏。
新增 GET /api/pets/:id/insights,只看最近 90 天(更早的对「现在怎么样」
没参考价值,还会让关联分析找出一堆巧合),产出最多 6 条按严重度排序的结论:
1. 体重趋势 —— 单次数字没意义,跨度 ≥14 天的连续同向变化才算。
跌 10% 报警建议血检,涨 15% 提醒控制,跌 5% 持续观察
2. 换粮 → 软便的时间关联 —— 找异常排便前 72 小时内的饮食记录。
这是用户最看不出来的一类:两条记录隔两三天、分属不同类型,翻时间轴翻不出来
3. 异常扎堆 —— 两周内 ≥2 次异常。偶发一次和反复出现完全不是一回事
4. 逾期提醒 —— 设了不看等于没设
5. 同龄体重对比 —— 同物种、月龄差 2 个月内其它宠物的中位数。
样本 <8 只直接不显示:拿 3 只算出来的「中位数」比不给还糟
6. 记录习惯 —— 数据不足时negative空手而归,给一句「再记几条就能看出规律」
每条都带 evidence(支撑它的具体数据)和 action(点击直接跳到对应记录入口),
结论不能只是断言。文案沿用 AI 助手同一套护栏:不做诊断,异常一律写清
什么时候必须就医。
前端落在记录页体重趋势卡上方,三档配色区分严重度。
实测(造 4 条体重下滑 + 换粮 + 软便 + 两次异常):
🔴 体重掉了 13%,建议就医检查(39 天内 4.50→3.90kg)
🔴 两周内记了 2 次异常
🟠 这次「软便」之前 2 天有过饮食变化(7月20日换粮 → 7月22日软便)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-07-29 15:03:36 +08:00 |
|
Blizzard
|
9adafb1354
|
feat(auth): access token 缩到 2 小时 + refresh token 机制
后台登录框原来预填了 sundynix/sundynix,等于把凭证写在页面上,去掉。
令牌改为 access(2h) + refresh 两段式:
- 新表 sundynix_refresh_tokens,只存 sha256,明文只在签发时返回一次
- 有效期:小程序 30 天、后台 7 天
- 新接口 /api/auth/refresh|logout、/api/admin/refresh|logout
安全约定:
- 每次续期都轮换刷新令牌,旧的立即作废
- 作废后 60 秒内再到达算并发重试放行,超过则判定泄露、吊销该账号全部会话
- 主动退出与被连坐吊销的令牌不吃宽限期,否则「吊销全部」形同虚设
- 禁用用户时一并吊销刷新令牌,最多 2 小时彻底失去访问
两端请求层都做了单飞续期:并发请求同时 401 只发一次 refresh,
否则刷新令牌会被并发轮换掉互相打架。小程序续期失败回退 wx.login,
登录/续期请求标 noAuthRetry,避免登录失败(同样返回 40100)触发自我套娃。
顺带修掉 vite 代理仍指向 8080 的遗留(端口早已改 9090)。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-07-29 09:38:19 +08:00 |
|
Blizzard
|
7093e6517d
|
perf(fe): 修复 token 过期白屏、请求翻倍与失败伪装成空态
token 过期后小程序静默白屏(影响所有用户)
- JWT 有效期 7 天,过期后 40100 只 clearToken 不重新登录,而
store.ready 的 promise 已缓存不会重跑,加上 23 处静默 catch,
用户看到的是「什么都没有、也没有任何提示」,只能重启小程序
- request 层加 token 失效钩子:自动重新登录并重试一次(只重试一次,
防止登录接口本身故障时死循环);store 注册钩子重置引导缓存
- 补 15s 请求超时、60s 上传超时,超时给明确文案(原先默认 60s 卡住无反馈)
请求翻倍
- 每个 tab 页同时用 store.subscribe 和 onShow→ready().then() 加载,
而 ready() 内部 loadPets 会 notify 触发 subscriber,首次进入请求翻倍
- subscriber 改为只处理「切换宠物 / 数据变更」,首次加载交给 onShow
- 首页 bind:save 与组件实际触发的 saved 事件名不一致,onSheetSave
从未生效;一并修正,并去掉关闭弹层时的全量重载
失败伪装成空态
- 社区请求失败时显示「还没有帖子,来发第一条吧」,把故障说成没数据。
改为区分「加载失败(可点击重试)」「关注 tab 为空」「确实没有帖子」
- 新增 utils/ui.js 统一错误提示(同文案 3 秒内去重,避免并发失败刷屏),
首页与记录页主数据加载失败不再静默
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
2026-07-28 17:56:35 +08:00 |
|
Blizzard
|
2e3345cdfc
|
feat: 记录删除与筛选、用户侧内容删除、AI 聊天历史
修复雪花 ID 精度丢失(真 bug)
- bottom-sheet 的 postId 声明为 Number,而 ID 是 18 位雪花字符串,
超出 JS 安全整数范围:339346584095428608 会被转成 ...600,
评论弹层实际查的是不存在的帖子。改为 String
记录
- 后端 DELETE /records/:id 早已就绪但前端从未调用,记错了删不掉。
时间轴支持长按删除
- 时间轴加类型筛选(体重/便便/饮食/异常/用药/疫苗/消费/照片),
后端 ?type= 本就支持
用户侧内容删除(UGC 合规:用户应能删除自己发布的内容)
- 新增 DELETE /posts/:id 与 DELETE /comments/:id,仅限本人,
越权返回 40300;帖子软删除,评论删除同步递减 comment_count
- 评论列表返回 is_self;社区长按自己的帖子、长按自己的评论可删
AI 聊天历史
- ai_messages 一直在写但没有查询接口,每次打开弹层都是空白。
新增 GET /api/ai/messages,弹层打开时接在开场白后加载
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
2026-07-28 17:42:14 +08:00 |
|
Blizzard
|
3fde90e97b
|
feat: 补齐五块缺失功能(记录丢数据/文章正文/提醒管理/我的页入口/分享/关注)
P0 修数据问题
- 记录弹层有 5 个输入框从未绑定,用户填的便便备注、饮食内容、药品名称、
剂量、消费备注全部丢弃;用药记录因此只存下「用药记录」四个字。已全部绑定并入库
- 异常观察保存时写死「风险中」,AI 实际判定的等级被丢掉。改为使用 riskData
的真实 risk_level,并把成因与建议存进备注
文章正文
- 早期 seed 的 4 篇文章 Content 全空,点开只是打开关联记录弹层,内容运营等于白做
- 补写 4 篇真实正文(疫苗驱虫/软便判断/换粮方案/养宠花销),遵循不诊断、
异常必提就医的护栏;对已存在的空正文做幂等回填
- 新增文章详情页,学习页与首页卡片改为打开正文
提醒管理
- 后端 CRUD 早已具备但小程序只读,用户改不了疫苗驱虫日期。提醒弹层支持增删改
- 修复后端 UpdateReminder 漏掉 type 字段导致改类型不生效
「我的」页 7 个死入口接活
- 提醒设置、健康记录、多宠物管理、会员权益分别落到对应功能
- 数据导出:汇总档案与记录为文本,可复制发给医生
- 意见反馈:新增 feedback 表与提交接口,后台加「意见反馈」管理页
- 关于我们:应用说明与免责声明
分享
- 各页面补 onShareAppMessage/onShareTimeline
- 帖子分享按钮改用微信原生 open-type="share",删除原来点了没反应的空壳弹层
社区关注
- 新增 follows 表与关注/取关接口,「关注」tab 此前等同「推荐」,
现只显示已关注用户的帖子;帖子头部可直接关注,标记 followed / is_self
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
2026-07-25 18:11:08 +08:00 |
|
Blizzard
|
eaa21585de
|
ci: Docker 单镜像部署 + Gitea 自动发布
- pets-be/Dockerfile:多阶段单镜像,node 构建管理后台 → Go 编译内嵌
(go:embed)→ alpine 运行。一个容器同时提供 /api 与 /admin,50MB,
非 root、内置 tzdata 保证按东八区计算每日任务
- deploy/docker-compose.yml:只有一个 app 容器,MySQL/MinIO 用外部现成的,
容器内 9090 映射宿主机 4000
- deploy/.env.example:全部配置项(MySQL/MinIO/微信/AI/管理员)
- .gitea/workflows/deploy.yml:push 或合并到 main 触发,runner 构建镜像 →
save 打包 → scp 到服务器 → docker load + compose up -d → 健康检查
- 修复容器化阻塞问题:config.Load 原本强制要求 config.yaml(而它不进 git),
且 viper 未登记默认值的 key 环境变量绑不上。现补全默认值并把配置文件
改为可选,纯 .env 即可启动
- 服务端口统一改为 9090
验证:镜像构建通过;本地起完整栈 ping/admin/登录/建表 seed/图片上传全通;
对接真实 MySQL 9.4(sundynix_pet)建表 19 张并 seed 成功。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
2026-07-25 16:47:49 +08:00 |
|
Blizzard
|
28b95a6468
|
feat: 每日任务顺延与增删改 + 计划到期续期 + 靠谱养护模板 + 图片URL修复
后端
- 每日任务惰性生成:某天为空则从最近一天顺延复制(done 重置),首天用模板
- 任务增删改 API(POST /pets/:id/tasks、PUT/DELETE /tasks/:id),改动自动顺延
- 30 天计划到期自动归档并按当前阶段生成新一轮
- 内置养护模板重写为兽医常识向:狗每阶段含遛狗/牵引/狂犬,猫含猫砂/梳毛/饮水
- 文件 URL 改为按 object_name + 当前配置动态拼接,换 IP/域名不再有旧地址
小程序
- 首页今日任务加「管理」入口:增删改任务弹层
- 记录时间轴显示照片缩略图(可全屏预览)+ 拍照成功提示
- 社区发布条精简为单个「发布图文」按钮,去掉头像/输入框误触
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
2026-07-06 10:06:13 +08:00 |
|
Blizzard
|
2f5dd6eefc
|
feat: 养护模板/社区运营/体重趋势/计划日历 + 雪花ID重构 + 文件表与图片上传
后端
- 主键改雪花字符串 ID(pkg/idgen + Base.BeforeCreate),全表外键/JWT/中间件随之调整
- 新增 files 表:/api/upload 按 MD5 去重,返回 {id,url,md5},服务端只收图片
- 头像/记录附图/帖子图改 file_id 关联,读取解析为 URL
- 养护模板(物种×阶段)后台可配 + AI 生成草稿;建档按模板生成任务/计划/提醒
- 社区 AI 运营:虚拟账号池 + 每日定时/手动生成,帖子带 AI 标
- 计划路线图节点带真实日期;首页周历与计划日历同源;新增 day-plan 当日安排
- 体重趋势接口带备注;记录列表分页
小程序
- 公共图片上传 utils/upload.js(仅图片);记录拍照/我的头像/社区发图三处接入
- 首页日历点选查当日任务;记录页体重趋势可点看备注 + 时间轴分页折叠
- 计划页日历点选查当日计划;自定义 tabBar 高度调整
后台(React)
- 新增「养护模板」「社区运营」页;用户管理加机器人筛选
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
2026-07-06 08:48:15 +08:00 |
|
Blizzard
|
609f7d06cf
|
init: 毛孩子计划 小程序 + Go 后端 + 内嵌后台
- pets-fe: 微信原生小程序(首页/计划/记录/报告/社区/引导),
服务端驱动、无假数据;弹层改用 scroll-view,打开时隐藏自定义 tabBar
- pets-be: Gin + GORM(MySQL, sundynix_ 前缀) + MinIO,统一响应/分页,
微信 code2session 登录,provider-neutral AI(DeepSeek),go:embed React 后台
- 修复:分段选择类型不匹配(字符串 vs 数字)导致选不中
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
2026-07-03 15:36:55 +08:00 |
|