uni-app视频点赞需初始化isLiked/likeCount字段，用pendingIds防连点，状态存localStorage防刷新丢失，动画须onReady后创建并按“改状态→启动动画→发请求”顺序执行。
视频点赞、评论、转发不是三个独立功能，而是一套状态联动的交互闭环。直接在 onTap 里发请求 + 改 data，大概率出现图标不翻转、数字不同步、连点重复提交、下拉刷新后状态丢失等问题——根本原因在于 uni-app 的响应式机制和小程序生命周期约束。
uni-app 视频列表里点赞按钮点击无反应？检查 data 初始化是否包含完整字段
常见现象：点了爱心图标，isLiked 在 console 里确实变了，但图标没切换、数字没加减，甚至整个 v-for 列表重渲染导致滚动错位。
- uni-app（基于 Vue 2）只对
data()初始化时就声明的属性做响应式劫持；后端返回的视频数据若没带isLiked或likeCount字段，后续赋值不会触发更新 - 错误写法：
this.videoList[index] = {...video, isLiked: !video.isLiked}—— 替换整个对象会切断响应式引用 - 正确做法：初始化时确保每条视频都有默认值，例如
{ id: '1001', title: 'xxx', isLiked: false, likeCount: 0 } - 更新时用直接赋值：
this.videoList[index].isLiked = !this.videoList[index].isLiked，或兜底用this.$set(this.videoList[index], 'isLiked', newValue)
怎么防止用户手滑连点导致点赞状态错乱？用 pendingIds 做请求节流
没有防抖时，快速双击会触发两次 onTap，本地状态翻转两次，但服务端可能只处理最后一次，最终 UI 和接口状态不一致。
- 在
data中声明pendingIds: []，记录正在请求的视频 ID - 点击时先判断：
if (this.pendingIds.includes(video.id)) return - 发起请求前：
this.pendingIds.push(video.id) - 请求完成后（无论 success/fail）：
const idx = this.pendingIds.indexOf(video.id); if (idx > -1) this.pendingIds.splice(idx, 1) - 服务端返回新
likeCount后再更新本地，别依赖++，避免并发计数偏差
评论和转发按钮点击后如何保持状态跨页面/下拉刷新不丢失？必须持久化本地状态
uni-app 页面卸载（如从详情页返回列表页）或 onPullDownRefresh 重拉数据时，data 会被清空或覆盖，之前点过的赞、发过的评论、转过的链接就“消失”了。
- 点赞状态优先存
uni.setStorageSync('liked_videos', ['1001', '1005'])，渲染前用liked_videos.includes(video.id)判断图标样式 - 转发状态建议用
uni.setStorageSync('shared_videos', { '1001': { platform: 'wechat', timestamp: 1730287680 })，支持多平台区分 - 评论内容本身不能只存在内存里；用户输入后应立即存入
uni.setStorageSync('draft_comments', { '1001': '刚看到这个...' })，避免切后台丢失 -
onPullDownRefresh时，先缓存当前已操作 ID 集合：const localLiked = this.videoList.filter(v => v.isLiked).map(v => v.id)，请求成功后再合并进新数据
为什么小红书式点赞动画一卡一卡？动画容器和创建时机必须严格匹配
CSS 动画在 iOS 微信小程序中对 transform + opacity 同时动画支持不稳定；用 uni.createAnimation 是更稳妥的选择，但容易因 DOM 未就绪或复用错位导致动画不触发。
- 动画容器必须是
- 每个视频项需独立的
animationData字段，如aniData[index]，避免多个动画互相覆盖 - 动画实例必须在 DOM 渲染完成之后创建：推荐在
onReady钩子中懒创建，或首次点击时判断!this.animation再初始化 - 动画结束后要手动重置：
setTimeout(() => this.aniData[index] = {}, 400)，否则下次点击无法再次触发 - 数字增长动画不能靠 CSS 过渡，必须用
requestAnimationFrame控制逐帧变化；封装成工具函数传入起始值、目标值、持续时间即可
最易被忽略的一点：所有操作必须严格遵循「先改本地状态 → 再触发动画 → 最后发网络请求」顺序。把请求放在最前面，一旦延迟或失败，UI 就会滞后甚至卡死。这不是性能问题，而是状态流设计的硬性约束。
