写在前面：距离上一篇博客已经过去了一段时间。这段时间里，"计科智伴"项目经历了一次从内到外的蜕变——从最初的页面原型搭建，到UI全面优化，再到引入状态管理、完善核心功能模块。这篇博客主要记录我在开发过程中的思考、遇到的问题以及解决思路。
一、UI优化：从"能用"到"好用"
在完成了基础页面搭建后，项目已经具备了所有核心功能。但实际展示时我发现，虽然功能完整，但在视觉层次和整体一致性上存在明显不足。这促使我思考：一个面向真实用户的产品，仅仅"能用"是不够的，还必须"好用"。
因此，我决定对整个项目进行系统性的UI优化。第一步是建立统一的设计规范，在样式文件中定义了全局的设计变量，包括主色调、功能色、间距系统等。这样做的好处是显而易见的：当需要调整整体风格时，只需要修改一处定义，所有页面都会同步更新。
在优化报告页面时，我遇到了一个典型的CSS布局问题：设置了右侧内边距，但内容仍然紧贴屏幕边缘。排查后发现，问题的根源在于默认的CSS盒模型计算方式——当元素设置了宽度后再添加padding，padding会增加元素的总宽度，导致内容溢出容器。
解决方案是使用box-sizing属性，将盒模型设置为border-box模式。这样padding和border都会包含在元素宽度内。虽然这是一个基础的CSS知识点，但在实际开发中很容易被忽略。修复了报告页面后，我系统性地检查了所有页面，确保每个容器都正确设置了盒模型。
//修复前的代码： ```scss .scroll-container { padding: 30rpx; // 未设置 box-sizing，默认使用 content-box // padding 会在宽度之外额外计算，导致内容溢出 } ```//修复后的代码： ```scss .scroll-container { padding: 30rpx 20rpx; box-sizing: border-box; // 关键！padding 包含在宽度内 } ```二、状态管理
在引入状态管理之前，项目中的数据管理存在明显问题。以用户信息为例，这个数据在首页、个人中心、学习计划等多个页面都需要使用，但每个页面都独立维护自己的数据副本。这就导致了数据冗余、同步困难、维护成本高等问题。
在状态管理方案的选择上，我对比了Vuex和Pinia。考虑到项目使用的是Vue 3框架，并且Pinia是官方推荐的方案，API更加简洁直观，最终选择了Pinia。
在Store模块的设计上，我遵循了单一职责原则，设计了七个核心模块：用户信息模块、学习数据模块、通知模块、练习模块、对话模块、学习计划模块和成就模块。每个Store只关心自己负责的业务领域，职责清晰，便于维护。
以通知模块为例，Store的结构如下：
export const useNotificationStore = defineStore('notification', { state: () => ({ notifications: [], unreadCount: 0, currentFilter: 'all', settings: { enabled: true, systemEnabled: true, taskEnabled: true } }), getters: { filteredNotifications: (state) => { if (state.currentFilter === 'all') { return state.notifications } return state.notifications.filter(item => item.type === state.currentFilter) } }, actions: { markAsRead(notificationId) { const notification = this.notifications.find(item => item.id === notificationId) if (notification && !notification.isRead) { notification.isRead = true this.unreadCount = Math.max(0, this.unreadCount - 1) } } }, persist: { key: 'notification-store', storage: { getItem: (key) => uni.getStorageSync(key), setItem: (key, value) => uni.setStorageSync(key, value) }, paths: ['notifications', 'unreadCount', 'settings'] } })将现有页面迁移到Pinia的过程中，遇到了响应式更新的问题。一开始在页面中直接调用Store的方法修改数据，发现数据变化后页面没有重新渲染。
迁移前的错误写法：
// 错误：直接修改state，不触发响应式更新 methods: { updateData() { this.notificationStore.notifications = [] } }迁移后的正确写法：
// 正确：通过computed返回store实例，通过action修改数据 computed: { notificationStore() { return useNotificationStore() } }, methods: { updateData() { this.notificationStore.clearAllNotifications() } }另一个问题是数据加载时机的选择。uni-app的页面生命周期中，onLoad只在页面首次加载时触发，而onShow在每次页面显示时都会触发。对于用户信息这类只需要初始化一次的数据，放在onLoad中加载即可；而对于未读通知数量这类需要实时刷新的数据，则必须放在onShow中加载。
三、核心功能开发
3.1 学习计划功能
学习计划是项目的核心功能之一。在设计时，我主要考虑了以下几个方面：
首先是学习计划的展示方式，采用了按天展示的结构，将一周的学习任务以列表形式呈现，每个任务都有明确的状态标识。其次是任务状态的流转逻辑，用户可以通过点击任务来切换状态，形成完整的任务执行闭环。第三是打卡签到功能，用户每天完成学习任务后可以进行打卡，系统会记录连续学习的天数，实现时需要考虑防重复打卡的逻辑。最后是进度追踪功能，系统会自动计算学习计划的总体完成百分比，并以进度条的形式展示给用户。
点击开始任务
再次点击任务完成
3.2 个人中心与成就系统
个人中心是用户查看自己学习成果的主要入口。在这个页面中，我整合了来自多个Store模块的数据，包括用户基本信息、学习统计数据、成就信息等。
成就系统的设计思路是"游戏化学习"。通过设置不同的成就目标和等级体系，给用户持续的正向反馈。成就的获取条件涵盖了多个维度：学习连续性、学习量、学习效果等。每个成就解锁时，用户会获得相应的积分和经验值奖励，经验值积累到一定程度后可以提升等级。
3.3 消息通知中心
消息通知中心是这次开发的重点功能之一。通知列表页支持按类型筛选，包括全部通知、系统通知、任务提醒、成就通知和AI通知五个分类。通知的已读管理支持单条标记已读和全部标记已读两种操作方式。
通知设置页是这次新增的功能模块，用户可以精细化管理自己的通知偏好，包括通知总开关、各类通知的独立开关、免打扰时段设置、通知提醒方式等。当用户关闭通知总开关时，其他设置项会自动隐藏，避免无效操作。
在技术层面，这次项目让我在多个方面得到了提升。在Vue框架方面，从只会使用Options API，到能够熟练使用Composition API和Pinia进行状态管理，对Vue的响应式原理有了更深的理解。在uni-app框架方面，掌握了跨平台开发的要点，了解了iOS和Android在状态栏、安全区域、导航栏等方面的差异。在CSS方面，对盒模型、Flexbox布局的理解更加深入，能够独立解决各种布局问题。
这段时间的开发经历，让我真正体会到了从需求分析到功能实现的完整过程。前端开发不仅仅是编写代码，更需要理解用户需求、设计合理的架构、关注用户体验。感谢这次项目实训，让我有机会将课堂上学到的知识应用到实际项目中。在实践中学习，在问题中成长，这是我最宝贵的收获。
