3.8 KiB
3.8 KiB
小菜记账 — 质量迭代设计
日期: 2026-06-08
概述
对「小菜记账」进行全面质量迭代，分四个阶段推进：全面扫描 → 缺陷修复 → UI 交互优化 → 系统功能迭代。
总体方案：分阶段逐层推进
S1 全面扫描 → S2 缺陷修复 → S3 UI 优化 → S4 功能迭代
每阶段有独立验收标准，后续阶段基于前一阶段的稳定基线。
S1: 全面扫描
扫描维度
对每个文件从三个维度同时检查：
🔧 缺陷维度
- 类型安全: API 参数类型错误、null/undefined 处理不当、
any滥用 - 边界条件: 空数据、空字符串、0 值、数组越界
- 竞态条件: 快速切换页面时未取消的请求
- 小程序适配: 胶囊按钮避让缺失、scroll-view 高度计算错误
- 内存泄漏: 未清理的 timer、watcher、事件监听
- 响应格式: 后端路由是否统一返回
{ code, data/message } - 错误码规范: 是否符合 0=成功, 40001=参数错误, 40300=权限, 40400=不存在, 50000=服务器错误
🎨 UI 维度
- 加载态: 是否有 loading/skeleton，避免白屏
- 空状态: 是否有友好的空状态提示（图标+文案）
- 错误态: 网络错误/超时是否有用户提示
- 触摸反馈: 按钮/列表项是否有点击态（
:active样式） - 动画过渡: 是否尊重
prefers-reduced-motion - 设计一致性: 颜色、圆角、阴影是否使用 SCSS 变量，而非硬编码
- 触摸目标: 是否 ≥ 44×44px（小程序最小触摸区域）
- emoji 检查: 是否混用 emoji 代替 Icon 组件（设计规范禁止 emoji）
🚀 功能维度
- 数据完整性: 分页是否正确、筛选是否生效
- 校验完整性: 前端+后端是否都有输入校验
- 错误处理: catch 块是否有用户提示（而非静默失败）
- 数据流: API → store → 组件数据流是否清晰，避免 prop drilling
扫描分组
| 扫描组 | 覆盖范围 | 文件数（约） |
|---|---|---|
| 组 1: 核心页面 | 首页、记账、账单、统计 + 对应 store + API | ~10 |
| 组 2: 用户 & 设置 | 个人、编辑资料、预算、分类管理、群组、通知、反馈、隐私 | ~12 |
| 组 3: 管理后台 | 仪表盘、用户管理、公告、反馈、配置、日志、埋点 | ~10 |
| 组 4: 后端路由 | 15 个路由 + 中间件 + 工具函数 | ~20 |
| 组 5: 公共组件 & 基础设施 | Icon、Numpad、TransactionItem、Skeleton、request、tracker 等 | ~10 |
产出物
每个扫描组输出结构化发现清单，每条发现包含：
- 优先级: P0(立即)/P1(高)/P2(中)/P3(低)
- 文件: 精确到行号
- 问题描述: 清晰说明缺陷/问题
- 影响: 用户可见影响
所有发现汇总到统一清单，供审核和排期。
优先级定义
| 级别 | 含义 | 示例 |
|---|---|---|
| P0 | 数据丢失/安全/崩溃 | 金额计算错误、SQL 注入、白屏 |
| P1 | 功能不可用/严重体验问题 | 按钮无响应、数据不刷新、接口报错 |
| P2 | 体验不佳/边界情况 | 空状态缺失、加载闪烁、动画卡顿 |
| P3 | 建议改进 | 代码整洁、变量命名、注释补充 |
S2: 缺陷修复（扫描后细化）
- 按 P0 → P1 → P2 顺序修复
- 每个修复前先写测试用例复现
- 修复后验证已有测试通过
S3: UI 交互优化（扫描后细化）
- 统一加载/空/错误状态组件
- 统一触摸反馈模式
- 动画一致性检查
- 无障碍改进
S4: 系统功能迭代（扫描后细化）
- 基于扫描发现的功能缺口
- 新功能需写 spec → plan → implement
不涉及的范围
- 不修改
dist/目录 - 不修改 lock 文件
- 不做无关重构
- 不做数据库结构大改（如需迁移需单独评审）