一、当前项目状态判断

已基本完成的部分

• 用户 / 家庭 / 邀请 的主模型思路已确定
• Item 模块骨架已完成
• Inventory 模块骨架已完成
• Declutter 模块骨架已完成
• 通用分层结构已完成
• 基础异常处理 / 通用返回结构已具备

当前最关键的问题

不是“缺新模块”，而是：

1. 权限没真正接起来
2. 认证用户获取没统一
3. 数据库与代码未完全对齐
4. 主流程还没联调跑通
5. 若用于答辩/演示，还缺一套稳定演示路径

二、收尾优先级总览

建议你按这个顺序做：

P0：必须先做

这些不做，项目很难真正跑通。

1. 家庭成员权限校验接入
2. 当前登录用户获取方式统一
3. 数据库表结构与实体字段对齐
4. Category / Family / Item 归属校验补齐
5. 主流程联调跑通

P1：建议补齐

这些做完，系统会明显更完整。

1. 通知模块真正接入
2. 库存低于阈值提醒
3. 邀请接受/拒绝后通知
4. 断舍离提醒或候选推荐
5. 分页、筛选、排序优化

P2：工程质量优化

这些更偏“交付质量 / 答辩质量”。

1. Swagger / OpenAPI 文档
2. 全局错误码规范
3. 单元测试 / 接口测试
4. Flyway / Liquibase 数据迁移
5. 日志、安全配置、部署说明

三、P0 必做清单

1. 接入家庭成员权限校验

目标

让所有核心业务都基于“当前用户属于哪个家庭”运行。

要做的事

• 建立或确认 family_members 表
• 实现：
  • getCurrentUserFamilyId(currentUserId)
  • isMember(currentUserId, familyId)
• 在以下模块统一使用：
  • Item
  • Inventory
  • Declutter
  • Category
  • Notification

验收标准

• 用户访问不属于自己家庭的数据时，被拒绝
• 同家庭成员可共享访问家庭资源

2. 统一当前登录用户获取方式

目标

替换掉所有临时的：

@RequestAttribute("currentUserId")

如果你项目已经有 JWT / Spring Security，就统一成真实方案。

你要确认

• 当前用户 ID 从哪里来？
• 是过滤器写入 request？
• 还是 SecurityContext？
• 还是自定义 UserContext？

验收标准

• 所有接口都能稳定拿到当前登录用户 ID
• 无需手动伪造 request attribute

3. 数据库表结构与实体对齐

目标

保证代码字段、数据库字段、SQL 建表语句一致。

重点检查表

• users
• families
• family_members
• items
• inventory_logs
• declutter_records
• notifications
• categories
• invitations

重点检查内容

• 字段名是否一致
• 类型是否一致
• 是否有 NOT NULL
• 是否需要默认值
• 是否有索引
• 是否缺少时间字段 created_at / updated_at

验收标准

• 项目启动不报 JPA 映射错误
• 主要接口能正常增删改查
• 不出现字段缺失或类型不匹配

4. 补齐归属校验

目标

避免跨家庭数据串用。

至少要补的校验

• item.categoryId 是否属于当前家庭
• declutter.itemId 是否属于当前家庭
• inventory.itemId 是否属于当前家庭
• notification.familyId 是否属于当前用户
• invitation.familyId 是否归当前发起者所有

验收标准

• 无法用 A 家庭的 category 去更新 B 家庭的 item
• 无法读取其他家庭的数据

5. 跑通主流程联调

目标

不是看代码，而是真正能从头到尾调通一套业务。

建议联调主流程

1. 用户注册 / 登录
2. 创建家庭
3. 邀请家庭成员
4. 创建分类
5. 创建物品
6. 物品入库
7. 物品出库
8. 查询库存日志
9. 查询过期 / 临期 / 闲置物品
10. 发起断舍离
11. 更新断舍离状态
12. 删除物品（验证有 pending declutter 时不能删）

验收标准

• 用 Postman 或 Apifox 能完整跑通一遍
• 主要接口结果符合预期
• 中途不会因为权限或字段问题中断

四、P1 建议补齐清单

6. 通知模块真正接入

目标

把现在的通知从“预留”变成“可见功能”。

建议最少实现的通知类型

• 家庭邀请通知
• 邀请被接受通知
• 低库存通知
• 物品临期通知
• 断舍离提醒通知

至少需要的接口

• 查询通知列表
• 标记已读
• 全部已读

验收标准

• 关键业务触发后能生成通知记录
• 前端能看到并操作通知状态

7. 低库存提醒补齐

目标

让库存模块更完整。

触发点

• 出库后
• 调整库存后

判断逻辑

afterStock < minStock

验收标准

• 出库后低于阈值时，会写通知
• 同一物品短时间内避免重复轰炸通知（可选优化）

8. 邀请流程闭环

目标

把邀请功能做成完整状态流。

建议具备

• 发起邀请
• 接受邀请
• 拒绝邀请
• 邀请状态变更
• 通知发起方/接收方

验收标准

• 受邀人接受后，能真实加入家庭成员表
• 发起方可以看到处理结果

9. 断舍离候选推荐优化

目标

把“断舍离”从手动记录升级为“有候选来源”。

候选来源

• 已过期物品
• 即将过期物品
• 长期未使用物品
• 库存过多物品

验收标准

• 前端可通过一个接口看到候选列表
• 能一键发起断舍离记录

10. 分页 / 筛选 / 排序补齐

目标

让接口更适合前端使用和答辩展示。

优先补的地方

• Item 列表分页
• Notification 分页
• Declutter 多条件筛选
• InventoryLog 分页 + 时间排序

验收标准

• 列表接口不再一次性返回全部数据
• 可按状态、时间、关键字筛选

五、P2 工程质量清单

11. 接口文档

目标

方便联调、答辩、演示。

你可以做

• 接 Swagger / Knife4j
• 或整理 Postman / Apifox 集合

验收标准

• 每个核心接口都能快速查看参数和响应

12. 统一错误码

目标

让异常不只是字符串，而是有明确规范。

建议

定义：

• 4001 参数错误
• 4002 权限不足
• 4003 资源不存在
• 4004 状态不允许
• 5000 系统错误

验收标准

• 前端能根据错误码做处理
• 答辩时看起来更专业

13. 测试补齐

建议至少补

• ItemService 测试
• InventoryService 测试
• DeclutterService 测试

至少覆盖场景

• 出库不能负数
• item 有 pending declutter 时不能删
• declutter 不能重复发起 pending
• 非家庭成员不能访问数据

验收标准

• 核心业务规则有测试保护

14. 数据迁移脚本

目标

避免环境切换时数据库混乱。

建议

• Flyway
• 或最少整理统一 SQL 初始化文件

验收标准

• 新环境可一键初始化数据库

15. 部署与运行说明

最少要整理

• JDK 版本
• Maven 版本
• 数据库版本
• 启动步骤
• 默认配置
• 测试账号
• 演示数据导入方式

验收标准

• 别人拿到项目能基本跑起来

六、模块级收尾检查表

A. 用户 / 认证模块

检查项

• 登录接口可用
• 能拿到当前用户 ID
• token 解析稳定
• 未登录访问被拦截
• 登录态在所有业务接口生效

B. 家庭模块

检查项

• 创建家庭可用
• 查询当前家庭信息可用
• 家庭成员列表可用
• 家庭成员关系表正确维护
• 一个用户当前属于哪个家庭逻辑明确

C. 邀请模块

检查项

• 发起邀请可用
• 接受邀请可用
• 拒绝邀请可用
• 邀请状态变化正确
• 接受邀请后写入家庭成员表

D. 分类模块

检查项

• 创建分类可用
• 列表可用
• 更新可用
• 删除前有引用校验
• 分类归属家庭校验完成

E. Item 模块

检查项

• 创建物品可用
• 列表/详情可用
• 更新可用
• 普通更新不能直接改 stock
• 删除前检查 pending declutter
• 过期/临期/闲置查询可用
• categoryId 归属校验完成

F. Inventory 模块

检查项

• 入库可用
• 出库可用
• 调整库存可用
• 库存不能为负
• 每次变更都写日志
• 出库更新 lastUsedAt
• 低库存提醒触发点补齐

G. Declutter 模块

检查项

• 发起断舍离可用
• 列表可用
• 详情可用
• 更新状态可用
• 取消可用
• 同一 item 不允许多个 pending
• 状态流转限制正确
• 与 item 状态联动是否明确

H. Notification 模块

检查项

• 通知列表可用
• 标记已读可用
• 全部已读可用
• 关键业务能触发通知
• 通知归属用户/家庭正确

七、建议你实际推进的执行顺序

这里给你一个很实操的顺序，照着做最省力。

第 1 天：权限和登录接线

• 实现 getCurrentUserFamilyId
• 统一 currentUserId 获取方式
• 跑通用户登录后的基础接口

第 2 天：数据库对齐

• 对齐 items
• 对齐 inventory_logs
• 对齐 declutter_records
• 对齐 family_members
• 跑应用启动检查

第 3 天：主流程联调

• 创建家庭
• 创建分类
• 创建 item
• 入库 / 出库 / 调整库存
• 发起断舍离
• 删除 item 校验

第 4 天：通知和边界修补

• 接低库存通知
• 接邀请通知
• 补 category 校验
• 补异常码 / 错误信息

第 5 天：文档和演示准备

• 整理 API 文档
• 准备测试数据
• 准备演示账号
• 画架构图
• 写答辩流程

八、演示/答辩最推荐展示的主流程

如果你要展示系统，不要乱展示，建议只展示一条“最能体现价值”的链路。

推荐展示链路

1. 用户登录
2. 查看家庭空间
3. 新增物品
4. 物品入库
5. 物品出库
6. 查看库存日志
7. 查看临期/闲置物品
8. 发起断舍离
9. 更新断舍离状态
10. 触发或查看通知

这条链路能把你的系统亮点都讲出来：

• 家庭共享
• 库存管理
• 断舍离决策
• 通知提醒
• 操作留痕

九、如果你时间很紧，最小可交付版本只做这些

如果你现在时间不够，就只保底做这几项：

最小必交版

• 登录拿到当前用户
• 家庭成员归属校验
• Item 增删改查
• Inventory 入库/出库/日志
• Declutter 发起/完成/取消
• 删除 item 前校验 pending declutter
• 至少一种通知（低库存或邀请）
• SQL 初始化脚本
• 一套可跑的演示数据

只要这些稳定，已经足够作为一个完整课程项目 / 毕设阶段成果展示。

十、你现在最应该立即做的三件事

如果只给你最短行动建议，就是这三件：

1.

先把家庭权限实现掉
因为这是所有模块真正可运行的前提。

2.

用 Postman/Apifox 跑通一整条主流程
不要只看代码，必须实际调接口。

3.

整理一份数据库初始化 SQL + 演示账号数据
这样你的项目才真正具备展示能力。

十一、最终一句话总结

你现在项目的正确策略不是“继续扩功能”，而是：

停止发散，开始收口；停止加模块，开始跑闭环。