微信小程序editor，从入门到精通的全攻略

好，咱们直接聊微信小程序里的editor组件。这东西，说白了就是官方给开发者准备的一个富文本编辑器，能让你在小程序里塞进一个像Word一样能打字、能排版、能插图的输入框。我刚开始接触它的时候，觉得挺鸡肋：不就是个文本框吗？但真用起来才发现，这玩意儿坑不少，潜力也不小。今天我就把这几年踩过的坑、悟出来的门道，掰开了揉碎了跟你聊聊。

先说入门。editor组件在微信小程序里其实是个很“低调”的存在——它不是默认组件，你得在wxml里显式地写标签。基础用法特简单：绑定一个bindready事件，在ready回调里调用editorCtx的init方法，就能初始化编辑器。但很多人一上手就翻车，为啥？因为editor依赖一个固定的id，而且必须等页面渲染完才能操作。我见过有人直接在onLoad里调init，结果editorCtx是null。正确姿势是：在ready事件里拿到editorCtx，然后存到data里备用。官方文档写得很清楚，但实操时容易忽略：editor的富文本内容是通过HTML格式传递的，不是小程序自己的wxml。这意味着你从后端拿到的富文本，得先转成HTML格式才能塞进去，反过来也是一样。这个转换逻辑，得自己写或者用第三方库，比如rich-text组件的toHtml方法。

进阶阶段，你得学会控制editor的行为。比如设置placeholder、限制最大字数、监听输入变化。这些看似简单，但细节决定体验。我踩过一个坑：用户输入时，editor会自动把空格转成 实体，导致字数统计不准。后来我通过监听bindinput事件，手动过滤掉这些实体，才解决。另外，editor默认支持加粗、斜体、下划线这些基础样式，但你要想支持字体大小、颜色、对齐方式，就得手动调用editorCtx的format方法。比如设置字号：editorCtx.format('fontSize', '1.5em')。注意，单位是em或px，不是pt。而且format方法只能逐项设置，不能批量操作。如果你要做个工具栏，就得把每个按钮的点击事件都映射到对应的format调用上，代码量不小。

真正让editor变得“好用”的，是它的图片和视频插入能力。官方提供了insertImage和insertVideo方法，但坑也在这儿：用户从相册选图之后，图片路径是本地临时路径，直接插入editor会显示不出来。你得先把图片上传到CDN，拿到线上地址，再插入。而且editor不支持图片的宽高自适应，默认会按原图尺寸显示，导致大图撑破容器。我的做法是：上传时让后端返回压缩后的缩略图地址，插入时手动设置width: '100%'。还有一个细节：editor的图片默认带一个可拖拽的调整手柄，但UI很丑，而且在小屏手机上容易误触。如果不需要这个功能，可以在insertImage时传参disablePreformatted: true，或者干脆用CSS隐藏掉。

说到性能，editor是个“重”组件。初始化时，它会加载一个完整的富文本渲染引擎，内存占用不小。如果你的页面里同时有多个editor，比如一个表单里有两个输入框，那手机很容易卡顿。我的建议是：最多用一个editor，其他文本输入用input或textarea代替。如果非要用多个，可以尝试把不用的editor用wx:if隐藏掉，但要注意隐藏后editorCtx会被销毁，显示时需要重新初始化。还有一个性能优化点：editor的bindinput事件触发频率很高，每输入一个字符都会触发。如果你在事件处理函数里做复杂计算，比如实时字数统计、敏感词过滤，很容易导致页面卡顿。解决办法是加一个防抖函数，比如300ms的延迟，只在用户停止输入后才执行逻辑。

再聊聊兼容性。editor组件在iOS和Android上的表现差异很大。iOS上，editor的键盘弹出和收起动画比较流畅，但光标定位偶尔会飘，尤其是插入图片后，点击图片旁边的文字，光标可能会跳到图片后面。Android上，问题更多：有些机型（比如小米、华为的低端机）在editor里输入中文时，会出现输入法遮挡editor的情况，导致用户看不到自己打了什么字。我的解决方案是：在bindfocus事件里，用wx.createSelectorQuery获取editor的当前滚动位置，然后手动让页面滚到合适区域。还有一个坑：editor在Android上对emoji的支持很差，很多emoji会显示成方框。如果业务需要输入表情，最好用editor的insertText方法手动插入Unicode码，或者干脆禁用emoji。

到了“精通”阶段，你得学会用editor做复杂交互。比如，用户选中一段文字后，弹出自定义工具栏，让用户设置高亮、插入链接、甚至添加评论。这些需求官方没有直接API，需要你手动监听selectionchange事件。这个事件会返回当前选中文字的起始和结束位置，但注意：它返回的是editor内部的DOM节点偏移量，不是文本字符索引。你得自己写算法，把偏移量映射到文本内容上。我写过一套工具函数：拿到selectionchange事件返回的range对象后，遍历editor的innerHTML结构，找到对应的文本节点，再算出字符位置。这个过程很绕，但一旦实现，就能做很多高级功能，比如给某句话加下划线、改颜色，甚至实现类似Notion的块级编辑。

说一个很多人忽略的点：editor的持久化。用户编辑的内容，你肯定要存到后端。但editor输出的HTML结构是标准的，里面会夹杂很多editor特有的class和data-属性，比如data-editor-entity。这些属性前端解析没问题，但如果直接存到数据库，下次从后端取回来再渲染时，可能会因为版本更新导致样式错乱。我的做法是：保存前，用正则表达式把这些属性删掉，只保留纯HTML结构。读取时，再根据业务需求动态注入样式类。还有一个安全风险：editor支持插入链接和图片，如果用户恶意插入XSS攻击代码，比如带onclick的标签，那你的小程序就挂了。所以一定要做HTML白名单过滤，比如只允许

、、、这些安全标签，其他一律过滤掉。