直接用v-for渲染上百个是卡顿根源,应改用雪碧图+background-position定位、computed分页、key唯一ID,并禁用App端base64表情图。

uni-app 表情图片怎么渲染不卡顿
直接用 v-for 渲染上百个 是最常见卡顿根源——每个 都触发独立 HTTP 请求、解码、布局重排,H5 端尤其明显。
实操建议:
- 所有表情图合并为一张雪碧图(sprite),用
background-image+background-position定位,CSS 控制宽高 - 表情数据存 JSON,但别放
data里直接遍历;改用computed分页(如每页 20 个),配合key唯一 ID 避免重绘抖动 - App 端禁用 base64 表情图——打包体积暴涨且无法按需加载;H5 可用,但必须压缩到单图 ≤2KB
textarea 光标处插入表情图片的兼容写法
原生 textarea 不支持富文本插入,所谓“光标处插图”本质是字符串拼接 + 后端/前端解析回显。关键在输入框值的控制逻辑。
实操建议:
- 不要监听
@input实时解析——会打断用户输入节奏;改用@blur或发送前统一处理 - 匹配规则用正则
/\[([^\[\]]+)\]/g,避免嵌套误判(如[[微笑]]) - 替换时保留原始字符串结构:发送时传
"今天开心[微笑]!",后端存纯文本;回显时前端用replaceEmoji()方法转成 - 小程序真机必须加
catchtouchstart到表情容器,否则点击无响应
表情面板怎么贴着输入框下方不被键盘盖住
用 position: fixed 是最大误区——iOS 键盘弹起时视口高度变化,fixed 元素会错位甚至消失;Android WebView 渲染差异还会导致 z-index 失效。
实操建议:
- 父容器设
position: relative,表情面板用position: absolute+bottom: 0 - 必须监听
uni.onKeyboardHeightChange动态改bottom值(注意:H5 不支持该 API,需降级为监听window.resize或预估键盘高度) - 微信小程序要加
safe-area-inset-bottom样式适配,否则面板可能卡在安全区外 - App 端务必先调用
uni.hideKeyboard()再显示面板,否则系统键盘抢焦导致点击失灵
为什么点不到表情图标或点了没反应
不是代码写错了,而是平台事件机制冲突:input/textarea 在 App 端强制捕获焦点,会拦截底层 touch 事件;小程序里冒泡没阻断也会被输入框吞掉。
实操建议:
- 小程序表情图标外层容器加
catchtouchstart(不能只加@tap) - Vue3 项目用
@touchstart.stop,Vue2 用@touchstart.stop.prevent - 避免在
textarea的@focus回调里立刻 show 面板——有约 100ms 延迟,建议用setTimeout(() => { showPanel() }, 100) - App 端首次唤出面板前,确保
textarea已失去焦点(blur()或uni.hideKeyboard())
真正难的不是渲染一张图,而是让同一套逻辑在 iOS/Android/小程序/H5 上都稳住 bottom 值、不丢 touch、不卡帧——这些细节没压到平台 API 差异里,就一定会在某台中低端安卓机上突然失效。











