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
S
Description
No description provided
3.2 MiB
Languages
Go 40.2%
HTML 25.1%
JavaScript 21.1%
TypeScript 12.9%
CSS 0.4%
Other 0.2%