用 reactive 维护商品评价列表的筛选与点赞状态，需将筛选条件（rating、hasimage、keyword）封装为 filterstate 对象统一管理，点赞状态则随评价数据嵌套在 reviews 中；筛选通过 computed 过滤列表，点赞直接修改对应项 isliked 和 likecount，二者隔离避免互相污染，并通过防抖、abortcontroller 和独立 loadingstate 控制竞态。
用 reactive 维护商品评价列表的筛选与点赞状态，关键在于把“哪些数据要响应式”和“哪些行为要触发更新”理清楚。评价列表不是静态展示，它既要支持按评分、时间、是否带图等条件筛选，又要允许用户实时点赞，而这些操作必须互不干扰、各自生效。
筛选状态单独聚合管理
筛选条件通常是一组关联字段（如星级、时间段、关键词），适合用 reactive 封装成一个对象，避免分散声明多个 ref：
- 定义一个
filterState = reactive({ rating: 0, hasImage: false, keyword: '' })，所有筛选参数都在这一个对象里 - 在模板中绑定表单控件时直接用
v-model指向filterState.rating或filterState.keyword，无需额外解构 - 配合
computed生成过滤后的评价列表：const filteredReviews = computed(() => reviews.filter(...))，自动响应filterState的任何变化
点赞状态嵌套在评价数据内部
每个评价的点赞状态（是否已点、当前点赞数）属于业务数据的一部分，应随评价项一起管理，而不是抽离为全局开关：
- 从接口获取的原始评价列表，本身包含
isLiked和likeCount字段，直接用reactive包裹整个列表：const reviews = reactive([]) - 点击点赞按钮时，只修改对应项的
isLiked和likeCount，例如：review.isLiked = !review.isLiked; review.likeCount += review.isLiked ? 1 : -1 - 由于
reviews是响应式代理，且每个评价项也是响应式对象，UI 会立即重渲染该条目，不影响其他评价
避免筛选与点赞互相污染
筛选结果是计算属性，点赞是原数据变更，二者必须隔离——不能让点赞操作导致筛选条件重置，也不能让筛选改变点赞状态：
- 确保
filteredReviews只依赖reviews和filterState，不依赖任何临时 UI 状态（比如“正在加载中”） - 点赞逻辑走真实 API 调用后，再同步更新本地
reviews中对应项，而不是仅更新filteredReviews——否则翻页或切换筛选条件时状态丢失 - 如果需要高亮“刚点过赞”的条目，可用额外字段如
review.tempLiked = true，并在下一次数据刷新时清除，不混入主状态
异步操作需控制竞态
用户快速连点点赞按钮，或筛选条件频繁切换，容易引发请求冲突或状态错乱：
- 点赞函数内加简单防抖或禁用按钮，避免重复提交
- 筛选触发的列表刷新，建议用
watch监听filterState，并在请求前清空或标记旧请求失效（例如用 AbortController） - 不推荐把整个
reviews对象设为 loading 状态，而是用独立的loadingState = reactive({ list: false, like: {} })，按粒度控制骨架屏或按钮状态
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
