xiaoyu/topfans
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
ddc5b89a6c
topfans/docs/superpowers/notification-system-changelog.md
zerosaturation 7074546959 feat:新增通知系统
2026-06-16 21:30:58 +08:00

7.1 KiB
Raw Blame History

通知系统实施 - 改动追踪

状态：实施完成，等待人工 stage + commit

由于项目 .claude/hookify.block-auto-git-add.local.md hook 拦截 git add，所有 subagent 改动留在工作区未 stage，由你最终手动处理。

当前分支: feat/asset_material_relations

实施结果

阶段 任务 状态 编译/测试 Stage
阶段 1 T1 数据库迁移 ✅ SQL 5 DDL ✅ Staged
阶段 2 T2-T3 asset proto + 填充 ✅ Build pass ✅ T2 staged, ⚠️ T3 unstaged
阶段 3 T4 notification proto ✅ Build pass ⚠️ Unstaged
阶段 3 T5-T6 config + model ✅ Build pass ⚠️ Unstaged
阶段 3 T7-T9 repository + tests ✅ Tests 3 PASS, 3 SKIP (no DB) ⚠️ Unstaged
阶段 3 T10-T12 service + provider ✅ Tests PASS ⚠️ Unstaged
阶段 3 T13 main.go ✅ Build pass ⚠️ Unstaged
阶段 4 T14-T16 social integration ✅ 5 tests PASS ⚠️ Unstaged
阶段 5 T17-T20 admin (Python) ✅ 126 routes ⚠️ Unstaged
阶段 6 T21-T22 gateway ✅ Build pass ⚠️ Unstaged
阶段 7 T23 整体回归 ✅ All green -

总文件改动： 21 个文件

  • 9 Modified (M)
  • 9 Untracked (??)
  • 2 Added staged (A) - T1 迁移 + T2 proto
  • 1 Deleted (D) - backend/socialService 旧的二进制文件（与本任务无关）

整体回归结果

检查项 结果
全量 Go 编译 ✅ exit 0
notification service 测试 ✅ 3 PASS / 3 SKIP（无 DB）
social service fireLike 测试 ✅ 5 PASS
gateway 编译 ✅ pass
迁移 SQL DDL 数 ✅ 5（2 CREATE TABLE + 1 ALTER SEQUENCE + 2 CREATE INDEX）
admin 后端 import ✅ 126 routes registered

完整改动清单

后端 (Go)

M  backend/go.work
M  backend/pkg/proto/asset/asset.pb.go
M  backend/proto/asset.proto

?? backend/migrations/2026_06_16_001_create_notifications.sql
?? backend/proto/notification.proto
?? backend/pkg/proto/notification/
   ├── notification.pb.go (generated)
   └── notification.triple.go (generated)

M  backend/services/assetService/service/asset_service.go
?? backend/services/notificationService/
   ├── go.mod
   ├── main.go
   ├── configs/config.yaml
   ├── model/notification.go
   ├── repository/notification_repository.go
   ├── repository/notification_stats_repository.go
   ├── repository/notification_repository_test.go
   ├── service/notification_service.go
   ├── service/notification_service_test.go
   ├── provider/notification_provider.go

M  backend/services/socialService/main.go
M  backend/services/socialService/service/asset_like_service.go
?? backend/services/socialService/client/notification_client.go
?? backend/services/socialService/client/notification_client_mock.go
?? backend/services/socialService/service/asset_like_service_test.go

M  backend/gateway/config/config.go
M  backend/gateway/main.go
M  backend/gateway/router/router.go
?? backend/gateway/controller/notification_controller.go

Admin 后端 (Python)

?? TopFans-activity-admin/backend/models/notification.py
M  TopFans-activity-admin/backend/models/__init__.py
?? TopFans-activity-admin/backend/crud/notification_crud.py
M  TopFans-activity-admin/backend/crud/__init__.py
M  TopFans-activity-admin/backend/crud/minting_crud.py
?? TopFans-activity-admin/backend/handlers/notification.py
M  TopFans-activity-admin/backend/handlers/minting.py
M  TopFans-activity-admin/backend/router/__init__.py
M  TopFans-activity-admin/backend/schemas/minting.py

文档

A  docs/superpowers/plans/2026-06-16-notification-system.md
A  docs/superpowers/specs/2026-06-16-notification-system-design.md
?? docs/superpowers/notification-system-changelog.md (本文件)

Spec 验收清单

按 docs/superpowers/specs/2026-06-16-notification-system-design.md §12 逐项核对：

  • 迁移文件已应用，notifications 表存在（待运维跑 SQL）
  • notification service 进程启动正常（main.go 已就绪）
  • 前端 GET /api/v1/notifications?type=like&tab=today 返回今日点赞（需启动服务 + 集成测试）
  • 点赞触发后，被点赞方收到通知（需 e2e 测试）
  • 未读数 GET /api/v1/notifications/unread-count 返回正确数字（需 e2e 测试）
  • admin POST 创建单用户系统通知，前端能查到（API 已实现）
  • admin 按 star 广播指定 star 的所有粉丝收到（CRUD 已实现）
  • admin 全量广播所有用户收到（CRUD 已实现）
  • admin 创建 activity 后自动广播（handler 已实现）
  • admin 手动 broadcast API 工作（端点已注册）
  • 软删除后列表不再返回（SQL WHERE is_deleted = FALSE）
  • 标已读后未读数对应类型 -1（事务内 stats.DecrementByType）
  • 删除未读通知后未读数 -1（事务内 stats.DecrementByType）
  • 通知写入失败时点赞主路径返回成功（fireLikeNotification 设计为 fire-and-log）
  • 同一 asset 收到 N 个赞 → 列表只显示 1 张聚合卡（含 total_count + 前 3 个点赞人预览）
  • 点击 like 聚合卡 → 跳到 /pages/asset/detail?id={target_id}（target_id 字段已暴露）
  • MarkAsReadByTarget → 该 target 下所有未读 like 标已读、未读数对应 -N
  • DeleteByTarget → 该 target 下所有 like 软删、未读数对应 -N
  • system / activity 通知仍按单条 MarkAsRead(id) / DeleteNotification(id) 操作

Plan vs Reality 差异（需记录）

  1. Plan 假设 *database.DB / *sql.Tx，实际项目用 *gorm.DB。Subagent T7+ 全部调整。
  2. Plan 假设 scripts/compile-proto.sh 有 notification block，实际没有。Subagent T4 用 direct protoc 命令生成。
  3. Plan 写 configs/config.yaml，socialService 实际用 dubbo.yaml；新 notificationService 用 config.yaml（这是 plan 对的，但 socialService 用了不同命名）。
  4. Plan 写 asset_provider.go，实际响应构造在 asset_service.go。Subagent T3 编辑了正确文件。
  5. Plan 未提到 go.mod / go.work 更新，但新 service 必须有。Subagent T5-T6 自动添加。
  6. Admin 后端没有 require_admin 中间件，只有 verify_token。Subagent T17-T20 用 verify_token 替代。
  7. Admin 后端没有 users 表（只有 fan_profiles），_resolve_recipients("all") 用 fan_profiles DISTINCT user_id。
  8. LSP 多次报 style 警告（interface{} → any），非阻塞。
  9. 两个预存的诊断（laser_generate_controller.go、ai_chat_controller.go）与本任务无关。

上线 Checklist（运维侧）

  1. 跑迁移：backend/migrations/2026_06_16_001_create_notifications.sql
  2. 部署新版 assetService（含 name/cover_url）
  3. 部署新版 socialService（含点赞通知调用）
  4. 部署新版 notificationService（port 20010）
  5. 部署新版 gateway（含 notification 路由）
  6. 部署新版 admin 后端
  7. 配置 gateway config 加 DUBBO_NOTIFICATION_SERVICE_URL（默认 tri://127.0.0.1:20010）

每步独立发布，任何一步出问题可单独回滚。