企业官网建设流程全解析

接手过几个Vue后台项目的人，大概率都碰到过同一个需求：在页面上加一个富文本编辑器，让运营、编辑自己排版发公告、写文章。我最近一次做这个功能时，项目组内部讨论了半天，最后却选了个“老古董”——百度UEditor。不是没有更时髦的编辑器，但实际测评完一圈，它反而是最不折腾的选择。这篇文章我把Vue项目接入百度UEditor的完整过程记录下来，包括选型、封装、上传对接、踩坑排查和二次开发，给同样被这个需求卡住的人提供一份能直接照抄的方案。

1. 为什么现在还有人在Vue项目里用UEditor

很多人一听UEditor就摇头，觉得它又老又丑、官方早就不维护了。这话对，也不对。对的是它的默认皮肤确实停留在十年前，组件本身也不是为现代前端框架设计的。不对的是，在后台管理系统这个场景里，它的“综合完成度”依然很高，而且大多数替代品并不像宣传的那样轻松。

先说它为什么还在被大量使用。UEditor最核心的强项是“你能想到的编辑功能它基本都有”：图片上传、多图上传、Word粘贴过滤、附件上传、视频上传、代码高亮、数学公式、地图插入、表格编辑。这些功能不是靠一个工具栏按钮撑门面，而是真的集成好了、能用的。另一个系统需要的是运营快速写一篇带图的文章，不是用Markdown写文档，也不是用代码块排版。UEditor在这类场景里几乎是开箱即用。

那为什么不选现在流行的编辑器呢？我把几个主流方案挨个试过，心里的小账本大概是这样的：

• Quill：颜值高、架构干净，但官方文档对图片上传、表格这些常见需求支持得很弱，都得自己写插件。给运营用的编辑器，很多功能要自己补，开发成本上去了。
• wangEditor：轻量、上手快，普通文章够用，但遇到复杂表格、多图批量上传、历史遗留内容兼容时比较吃力。而且新版和旧版API差别大，网上搜到的大部分教程是旧版的，容易踩坑。
• TinyMCE：功能全、社区活跃，但自托管版本很多高级功能要收费，云版本还要注册拿API Key。公司环境里还得考虑数据能不能放在第三方服务上，光这一点就劝退了不少团队。

UEditor虽然老，但它不依赖收费服务、不用注册账号、下载压缩包就能离线部署，功能还几乎全部免费。对于一个要快速交付、还要跑好几年的内部管理后台来说，这种“省事”比“时髦”重要得多。当然我也不否认它的缺点：默认UI难看，移动端基本放弃，官方停止维护后遇到疑难问题只能去翻老帖子和自己看源码。但后台系统本来就是PC端为主，移动端不是核心场景，所以这个缺点也能接受。

说到底，选型这事儿没有绝对的对错，只有适合不适合。如果你的项目是纯内部系统、以PC为主、内容编辑需求又比较杂，那UEditor完全值得考虑；如果你在做面向C端的Modern应用、对交互和颜值要求高，那还是老老实实选新一代编辑器。我这次接手的是一个老业务线的新后台，运营手里的存量文章有几万篇，大部分都是UEditor生成的HTML，新系统如果换了编辑器，历史内容渲染会出各种问题，所以“沿用UEditor”几乎就是唯一解。

2. 三种接入方式的取舍：npm包、社区封装、手动封装

确定用UEditor之后，下一个问题是：Vue项目里怎么接入它？网上方案五花八门，但归纳下来其实就三条路，我全试了一遍，讲讲各自的实际情况。

2.1 直接npm安装官方包

听起来最正规，实际最坑。npm上的ueditor包常年停留在老版本，安装完后你拿到的其实是一个“封装了dist”的压缩包，里面的文件结构和官方下载包一模一样，该有的配置问题一个不少。真正的问题是它的配置方式跟现代打包工具相处不来：UEditor依赖一个全局的UEDITOR_HOME_URL变量来定位资源目录，npm装完你还是得把dist里的静态文件手动拷到public目录，否则各种图标、语言包、对话框模板加载不出来。

这还没完。npm包版本和官方源码是脱节的，你想看它的源码调试，得找到node_modules里那一坨压缩过的JS，可读性极差。而且这类包基本不更新，修bug全靠自己。我试用下来的感受是：单纯为了“正规安装”多走一套流程，实际收益为零。

2.2 使用社区封装组件

社区里最常用的封装是vue-ueditor-wrap，它有Vue2版本，也有人维护Vue3版本。用起来确实省事，一个组件嵌套进去就能用，很多常见配置都做了默认处理，如果你只是要“能用”，它是最快的路径。

但它也有自己的限制。一是版本兼容看运气，Vue3版本早期的bug不少，不同项目的webpack、vite版本都可能让它在构建阶段报错；二是封装组件毕竟隔了一层，UEditor本身的报错会被吞掉一部分，排查问题时不好定位；三是社区维护者精力有限，很多浅层配置支持了，深层定制还是要回到底层API。我项目里要做主题色适配和自定义工具栏，发现光靠这个组件不太够。

2.3 手动封装：把UEditor当成独立第三方库加载

这条路是我最后采用的方案。思路很简单：把UEditor官方包的dist目录原样放到项目public目录下，在组件里动态注入script标签加载脚本，然后自己写一个Vue组件包住它的生命周期。好处是足够可控，不跟构建工具纠缠，也不依赖任何人的封装，Vue2、Vue3、React甚至原生JS都能用同一套方案。弊端是要自己处理加载状态、实例管理和销毁，代码量确实比直接用封装组件多一点。

三种方式的取舍我列一张表：

我最终选择手动封装，还有一个很重要的原因：项目里不止一个页面要用编辑器，有的地方还要同一页面放两个编辑器实例。手动封装把“加载脚本—初始化—销毁—内容同步”都收敛在一个组件里，多实例时只要各自生成独立的容器id就行，不会互相干扰。后面做切换编辑器方案时，也只需要改组件内部实现，页面调用方不变。

3. 自封装UEditor组件的核心实现：从脚本加载到v-model同步

下面这部分是整篇文章的重头戏。我尽量把代码写得可以直接复制，并且把每个关键点都解释清楚，免得你抄完代码却不知道出事时怎么排查。

3.1 资源准备与目录结构

第一步是拿到UEditor的官方dist目录。注意从官网下载时选“完整版”，不要选“精简版”，否则缺少语言包和第三方插件，很多功能不能开。解压后把整个dist文件夹扔到项目的public目录下，重命名为ueditor。最后目录大概是这样的：

public/ ueditor/ ueditor.config.js ueditor.all.js ueditor.all.min.js lang/ themes/ third-party/ ...

这个目录下的ueditor.config.js是默认配置入口，打开它你会看到UEDITOR_HOME_URL这个变量，它负责告诉编辑器去哪里找图标、语言包和插件。默认值可能是空字符串或者相对路径，在Vue项目里最好直接改成绝对路径：

// public/ueditor/ueditor.config.js window.UEDITOR_HOME_URL = "/ueditor/";

这段配置要放在初始化之前执行。为了保证它先于代码运行，可以在index.html里用普通script标签引入：

<!-- public/index.html --> <script src="/ueditor/ueditor.config.js"></script>

也可以在组件里用动态script加载，但顺序必须保证config先加载、all后加载，否则UE对象都拿不到。我为了方便统一管理，把config也放在动态加载流程里，后面会给出对应代码。

3.2 动态加载脚本的管理模块

UEditor的JS总量不小，而且一个页面只需要加载一次，所以最好做一个模块专门管理加载状态，避免重复注入script标签导致“UE未定义”或者重复初始化报错。

// src/ueditor/load-ueditor.js let configLoaded = false; let allLoaded = false; let loadingPromise = null; function loadScript(src) { return new Promise((resolve, reject) => { const script = document.createElement("script"); script.src = src; script.onload = resolve; script.onerror = () => reject(new Error("加载失败: " + src)); document.body.appendChild(script); }); } export function loadUEditor() { // 已经全部加载完成，直接返回成功 if (configLoaded && allLoaded && window.UE) { return Promise.resolve(); } // 正在加载，复用同一个Promise，防止重复触发 if (loadingPromise) { return loadingPromise; } loadingPromise = loadScript("/ueditor/ueditor.config.js") .then(() => { configLoaded = true; return loadScript("/ueditor/ueditor.all.js"); }) .then(() => { allLoaded = true; return window.UE; }) .catch((err) => { // 加载失败要重置状态，否则后续永远不重试 configLoaded = false; allLoaded = false; loadingPromise = null; throw err; }); return loadingPromise; }

这里有一个细节容易被忽略：加载失败后必须把状态重置。我第一次写的时候没做catch里的重置，结果有一次网络抖动导致一个用户加载失败，之后他再怎么刷新页面，Promise一直处于rejected状态，编辑器永远起不来。这种问题在低网速环境下特别容易出现。

3.3 Vue组件主体

组件的核心逻辑是：script标签充当容器、初始化UEditor实例、把编辑器内容和v-model双向同步、在组件销毁时清理实例。我直接给出完整的Vue2版本的组件代码，Vue3的差异我后面单独说。

<!-- src/ueditor/UEditor.vue --> <template> <div class="ue-container"> <script :id="editorId" type="text/plain" style="height: 300px;"></script> </div> </template> <script> import { loadUEditor } from "./load-ueditor"; let seq = 0; export default { name: "UEditor", model: { prop: "value", event: "input" }, props: { value: { type: String, default: "" }, config: { type: Object, default: () => ({}) }, height: { type: Number, default: 300 } }, data() { // 同一页面多个编辑器实例时，id必须唯一 const editorId = `ue-${Date.now()}-${seq++}`; return { editorId, editor: null, destroyTimer: null }; }, watch: { value(newVal) { // 外部改动内容时回写编辑器，但避免光标跳动 if (this.editor && this.editor.getContent() !== newVal) { this.editor.setContent(newVal || ""); } } }, mounted() { this.initEditor(); }, beforeDestroy() { this.destroyEditor(); }, methods: { async initEditor() { try { await loadUEditor(); } catch (e) { console.error("UEditor加载失败", e); return; } if (!window.UE) { console.error("window.UE不存在"); return; } const config = { initialFrameHeight: this.height, initialFrameWidth: "100%", // 关闭自动长高，避免每次都触发滚动条跳动 autoHeightEnabled: false, // 用自己项目的z-index，防止弹窗被遮挡 zIndex: 3000, ...this.config }; this.editor = window.UE.getEditor(this.editorId, config); const me = this; this.editor.addListener("ready", () => { // 初始化完成后注入外部传入的内容 me.editor.setContent(me.value || ""); me.$emit("ready", me.editor); }); // contentchange是UEditor内部生成的事件，输入、粘贴都会触发 this.editor.addListener("contentchange", () => { const content = me.editor.getContent(); me.$emit("input", content); me.$emit("change", content); }); }, destroyEditor() { // 销毁时要先清理编辑器实例，再移除容器 if (this.editor && this.editor.destroy) { this.editor.destroy(); } this.editor = null; const el = document.getElementById(this.editorId); if (el) { el.remove(); } } } }; </script>

有几个点我必须单独拎出来讲，因为它们是隐性的坑。

容器为什么用script标签而不是textarea。UEditor默认支持两种容器：textarea和script标签。textarea作为容器时，如果项目里存在表单序列化操作，可能会把textarea里的内容当成表单字段提交。而script标签作为容器时不会参与表单提交，更干净。模板里写type="text/plain"是为了让浏览器不把它当真正的脚本执行，只当普通文本容器。这个写法是UEditor官方推荐的。

内容回写watch要加内容相等判断。如果不判断，父组件在拿到编辑器内容后再次赋给value，就会触发setContent，而setContent又会触发contentchange，再次向外emit内容，形成“回声”循环。虽然Vue的更新机制不会导致死循环，但会出现光标跳动的体验问题。加上getContent() !== newVal判断能避免无意义的重复写入。

beforeDestroy里的清理。UEditor内部会创建iframe、绑定全局事件，如果只移除DOM而不调用destroy，编辑器实例会一直存在内存里，再次进入页面时可能出现“编辑器容器已存在”这类诡异问题。同时要注意销毁时机的顺序：先destroy编辑器，再remove script容器。顺序反了可能导致destroy时找不到容器内部节点而报错。

3.4 Vue3适配思路

Vue3和Vue2的组件差异主要在于生命周期和组合式API。核心逻辑是一样的，我简单给出替代生命周期的写法：

<script setup> import { onBeforeUnmount, onMounted, ref, watch } from "vue"; const props = defineProps({ value: String, config: Object, height: Number }); const emit = defineEmits(["update:value", "change", "ready"]); // Vue3里用 v-model 默认是 update:value 事件 const editorId = `ue-${Date.now()}`; const editor = ref(null); onMounted(initEditor); onBeforeUnmount(destroyEditor); function initEditor() { // 同样是 loadUEditor 后 window.UE.getEditor(...) } function destroyEditor() { // 清理逻辑相同 } </script>

这里要说一个v-model的差异：Vue3默认的更新事件是update:value，组件内emit时要对应修改，否则父组件的v-model不会生效。Vue2用的是input事件，所以我在上面的代码里用了model选项指定。这个细节很容易被忽视，接Vue3时尤其要检查一下。

3.5 多实例时的id冲突问题

同一页面放两个UEditor组件时，如果id写死成同一个，只有一个实例能正常初始化，另一个会拿到同一个DOM容器。我代码里用Date.now() + seq++生成唯一id，就是为了解决这个问题。seq是模块级别的自增计数，即使两个组件在同一毫秒内创建，也能保证id不同。

实际项目中我遇到过更隐蔽的场景：同一个组件被v-for循环几遍，id生成时机在data函数里，每次创建组件实例都会执行一次data函数，所以天然是独立的。这个方案比用Math.random()更稳，随机数在极端情况下可能重复，自增序列不会。

4. 图片上传对接后端：协议格式、鉴权与回显

UEditor自带的上传能力需要通过后端接口配合。它的上传机制绕不开，所以我专门把这块拎出来讲清楚，免得后端同学第一次对接时看着文档一脸懵。

4.1 后端要响应的协议格式

UEditor上传图片时，默认会向serverUrl发起请求，请求参数里有action=uploadimage，文件字段名是upfile。后端只需要按这套约定处理即可，不一定要走它自带的Java/PHP源码，任何语言只要能接收multipart文件就行。

返回给前端的JSON必须是严格约定好的格式，否则编辑器会把整段响应当成“上传失败”处理。关键字段如下：

{ "state": "SUCCESS", "url": "/uploads/2026/07/xxx.png", "title": "xxx.png", "original": "xxx.png", "type": ".png", "size": 12345 }

• state固定要等于SUCCESS，其他任何值都会被前端判定为失败
• url是图片访问的相对路径或完整URL
• title和original分别是新文件名和原始文件名，简单点直接填同一个值也行
• type是扩展名，size是文件大小，这两个字段编辑器用来做展示

如果后端返回的state不是SUCCESS，编辑器会直接把state对应的文本当作错误消息弹出。比如返回{"state": "文件大小超出限制"}，前端就能看到对应提示。

4.2 Node.js后端示例

我所在的模拟项目后端用的是Node.js，对接时我用express和multer写了个最小实现：

// routes/ueditor.js const path = require("path"); const fs = require("fs"); const express = require("express"); const multer = require("multer"); const router = express.Router(); const storage = multer.diskStorage({ destination: (req, file, cb) => { const dir = path.join(__dirname, "../uploads"); if (!fs.existsSync(dir)) { fs.mkdirSync(dir, { recursive: true }); } cb(null, dir); }, filename: (req, file, cb) => { const ext = path.extname(file.originalname); const name = `${Date.now()}-${Math.round(Math.random() * 1e9)}${ext}`; cb(null, name); } }); const upload = multer({ storage, limits: { fileSize: 5 * 1024 * 1024 } }); router.post("/upload", upload.single("upfile"), (req, res) => { if (!req.file) { return res.json({ state: "没有收到文件" }); } const data = { state: "SUCCESS", url: `/uploads/${req.file.filename}`, title: req.file.originalname, original: req.file.originalname, type: path.extname(req.file.originalname), size: req.file.size }; res.json(data); }); module.exports = router;

这段代码里有两点值得注意。一个是文件名我用时间戳+随机数而不是用户原始文件名，可以避免中文文件名的编码问题，也能防止重名文件覆盖。另一个是目录不存在时用recursive: true自动创建，否则第一次上传会直接报错。开发时经常漏掉这个，导致本地跑起来一上传就500。

4.3 serverUrl和action的配置关系

UEditor前端配置里，最核心的是这两个：

const config = { serverUrl: "/api/ueditor/upload", // serverUrl前端接到 action 参数，例如: // GET /api/ueditor/upload?action=config // POST /api/ueditor/upload?action=uploadimage };

UEditor会在不同时机请求不同的action。初始化时它想获取后端支持的配置列表，会发一个?action=config的GET请求；点击上传时发?action=uploadimage的POST请求。如果后端接口没有区分action，光接收upfile文件是不够的，编辑器会因为在初始化时拿不到config而弹“后端配置项无法正常加载”。

如果你的后端不想实现config这个动作，前端还有一个讨巧的办法：在config里写死serverUrl不指向后端，并利用catcherUrl或者干脆关闭远程图片抓取。更省事的做法是让后端对action=config直接返回一个空数组，UEditor就能跳过配置步骤。严格来说这不是标准做法，但实践里能解决90%的对接报错。

4.4 鉴权怎么处理

后台系统的上传接口往往需要登录态。UEditor的图片上传是自己发的XHR请求，默认不会带上项目里的token header。解决思路有三个：

1. 后端放行上传接口，利用nginx层IP白名单、内网限制等手段保护。适合内部系统，最简单。
2. 把token拼到serverUrl的query参数上，后端从query里取。做法快但token会出现在日志里，需要结合时效性短token使用。
3. 全局拦截XHR，注入Authorization header。前端代码少、改造小，但要小心影响项目里其他正常的上传请求。

我实测过第3种，一个比较稳的写法是：

// main.js 里统一注入，只在项目里没有统一请求封装时用 const originalOpen = XMLHttpRequest.prototype.open; XMLHttpRequest.prototype.open = function (...args) { const token = localStorage.getItem("token"); if (token) { this.setRequestHeader("Authorization", `Bearer ${token}`); } originalOpen.apply(this, args); };

这里有个坑：setRequestHeader必须在open之后、send之前调用。直接写在open函数体里是没问题的，但如果你放在load回调里再set，请求已经发出去了，header不会生效。我自己第一次就是写错了位置，抓包看了半天才发现header根本没带上。

如果项目里有自己封装的axios或fetch拦截器，优先用拦截器，全局改XHR原型影响面太大，能不用尽量不用。

4.5 上传成功后的图片回显

后端返回的url如果是相对路径，前端访问时会拼当前域名。开发环境本地代理没有问题，但生产环境如果前端域名和后端文件服务域名不同，图片就会裂掉。稳妥的做法是后端返回一个完整可访问的URL，或者前端在拿到editor输出的HTML后统一做一次域名替换。

我是用自定义指令在渲染前处理：

function replaceImgUrl(html, staticHost) { return html.replace(/src="\/(uploads|ueditor)\//g, `src="${staticHost}/$1/`); }

这个处理不能写在编辑器组件内部，因为编辑器组件只管输出HTML，渲染富文本的页面可能不止一个。建议在展示内容的通用组件里统一处理，这样以后文件服务换域名只需要改一个地方。

5. 封装之后遇到的五个高频坑及排查过程

代码写出来是一回事，跑起来不出问题是另一回事。我把实际的踩坑记录整理成列表，每个都是反复排查后找到的根因，希望能帮你少走弯路。

5.1 重复进页面后编辑器容器越来越多

现象：页面第一次进入正常，退出后再进入，界面上出现多个空白文本域，控制台偶尔报错。

排查过程：先怀疑组件beforeDestroy没触发，给方法加了console.log，发现触发了。那就说明destroyEditor执行了，但DOM删除不彻底。按下F12查看elements，发现原本的script容器被UEditor替换成了一套复杂节点，里面还包括一个textarea和iframe。手动remove只移除了外层div，但某些版本的UEditor会在别的DOM节点下残留内容。

解法：在destroyEditor里，除了purge自己创建的script容器，还要找到editor.container并移除。UEditor实例自身有container属性，指向它创建的DOM根节点。我最后改成的逻辑是：

destroyEditor() { if (this.editor) { if (this.editor.destroy) { this.editor.destroy(); } if (this.editor.container && this.editor.container.parentNode) { this.editor.container.parentNode.removeChild(this.editor.container); } this.editor = null; } const el = document.getElementById(this.editorId); if (el) { el.remove(); } }

这样改之后，反复进页面测试十几次都没再出现残留节点。

5.2 多个编辑器实例互相“串台”

现象：系统里有两个Tab，分别放不同的公告编辑器和通知编辑器。在公告编辑器里输入文字，通知编辑器里也出现同样内容。

排查过程：第一反应是组件复用导致data共享，查了没有。接着怀疑是id冲突，打开elements看，两个script容器的id确实是独立的。后来发现是UEditor的全局配置对象在作怪。项目里有人在页面初始化时给window.UEDITOR_CONFIG赋了全局默认值，两个实例初始化时都读到了同一份配置，里面的initialContent被写成共用内容，编辑器初始化时就把这份内容塞进去了。

解法：不要在全局window上挂配置键值。每个实例的配置在getEditor时单独传，并且把initialContent直接置空。如果确有必要动态修改全局配置，必须保证同一个页面同时只存在一个编辑器实例，或者创建完配置后把全局对象置空。

5.3 上传图片弹窗被弹层挡住

现象：点击工具栏图片按钮，弹出的对话框出现在页面底部，或者被后台的modal盖住，完全点不到。

排查过程：UEditor的弹窗是绝对定位的，默认z-index不高。项目里的后台框架自带的高层级弹窗如果开了遮罩，UEditor的对话框就会被压下去。我一开始以为是iframe层级问题，调了半天iframe属性没效果，最后直接在浏览器里对比两个元素的computed style才发现是z-index。

解法：初始化配置里加zIndex: 3000，或者在全局样式里覆盖：

.edui-dialog { z-index: 3100 !important; } .edui-shadow { z-index: 3000 !important; }

注意只调整主对话层的层级还不够，遮罩层也要对应改，否则出现“对话框在最上面、但背景全黑了”的尴尬效果。

5.4 控制台报“后端配置项无法正常加载”

现象：页面加载UEditor时，请求/api/ueditor/upload?action=config，返回404，随后编辑器顶部出现红色错误条提示配置无法加载。

排查过程：一开始我以为是serverUrl配置少了，检查后发现URL没问题。接着去后端口，发现路由只注册了POST/upload，没处理GET请求，更没处理action=config。UEditor文档里写了初始化时会请求config，但很多后端示例代码只截取了上传部分，就把这个动作漏了。

解法：后端加一个专门处理config的动作：

router.get("/upload", (req, res) => { const action = req.query.action; if (action === "config") { return res.json([]); } res.json({ state: "unknown action" }); });

返回空数组符合UEditor的预期，它会使用前端配置继续工作。如果你的项目对编辑器上传的文件类型、大小有严格限制，可以在这个config里返回具体配置项。不过用空数组最省事，也足够满足大多数内部系统需求。

5.5 v-model拿到旧内容或空内容

现象：编辑器里明明写了字，但点击提交按钮后，传给后端的内容是空的，或者少了几段。

排查过程：检查组件的@change事件是否正常触发，发现输入时会触发。但提交按钮有自己的表单提交逻辑，它读取的不是组件实时emit的值，而是自己在DOM里找textarea取val。由于UEditor把textarea隐藏了，或者textarea内容没有同步更新，表单里拿到的就是旧值。

解法：内部系统的提交动作统一走组件的v-model值，不要在页面里自己从DOM找textarea取值。如果实在有老代码要兼容，可以在组件实例对外暴露一个getContent方法，页面提交时调用组件ref获取：

<template> <UEditor ref="editorRef" v-model="content" /> </template> <script> export default { methods: { handleSubmit() { const content = this.$refs.editorRef.getContent(); // 或者用 this.content，两者应该一致 submitData(content); } } }; </script>

给组件加上getContent方法：

methods: { getContent() { return this.editor ? this.editor.getContent() : this.value; }, setContent(html) { if (this.editor) { this.editor.setContent(html || ""); } } }

对外暴露方法的好处是，即使某些极端情况下contentchange事件没触发，提交时也能强制拿到最新内容。

5.6 全屏模式样式错乱

现象：点击全屏按钮后，编辑器虽然铺满屏幕，但工具栏按钮错位，弹窗位置偏了，保存按钮也被遮住。

排查过程：UEditor的全屏方案是把自身DOM的position改成fixed，然后给body加样式。如果父容器有transform属性，fixed定位会失效，编辑器就会以父容器为参照物，出现位置错乱。这个属于CSS包含块问题，和UEditor本身的代码关系不大。

解法：编辑器全屏时，如果父容器有transform，要临时关闭。我给编辑器外层加了一下判断：

// 监听编辑器全屏事件 this.editor.addListener("fullscreenchanged", (isFullscreen) => { const parent = this.$el.parentNode; if (parent) { parent.style.transform = isFullscreen ? "none" : ""; } });

更彻底的方案是限制编辑器所在区域不要使用transform动画，或者干脆在UI上隐藏全屏按钮。内部系统很多时候根本不需要全屏，隐藏按钮比折腾CSS省事得多。

6. 二次开发：工具栏定制与个性化扩展

UEditor真正的价值在于可定制。在Vue项目里接入只是第一步，想让它贴合自己项目的业务场景，就得动工具栏和内置行为。

6.1 按需裁剪工具栏

编辑器的工具栏默认项非常多，运营同事一看密密麻麻就容易不知道怎么用。我一般会在初始化config里明确指定需要的按钮，其他全部去掉。下面是一个运营编辑场景的典型配置：

const config = { toolbars: [[ "source", "undo", "redo", "bold", "italic", "underline", "forecolor", "backcolor", "fontfamily", "fontsize", "insertimage", "insertvideo", "attachment", "removeformat", "link", "unlink", "inserttable", "fullscreen" ]] };

减少工具栏按钮后，界面清爽了，误操作也少了。还有一个隐藏好处：编辑器初始化时会主动加载按钮对应的插件，裁剪掉没用的按钮能减少初始化时间。在慢速网络下这个差异还挺明显。

6.2 新增自定义按钮

内部后台经常会需要“一键插入模板”之类的功能。UEditor的自定义按钮机制不复杂，核心是UE.registerUI：

// 在初始化编辑器之前注册 UE.registerUI("insertTemplate", function (editor, uiName) { // 创建一个按钮实例 const btn = new UE.ui.Button({ name: uiName, title: "插入模板", cssRules: "width:20px;background-position: -740px -40px;", onclick: function () { // 在光标位置插入模板HTML const html = `<div class="template-box"> <h3>公告模板</h3> <p>这里是模板内容...</p> </div>`; editor.execCommand("insertHtml", html); } }); // ready后加到工具栏第一位 editor.addListener("ready", function () { const toolbarBtns = editor.getOpt("toolbars")[0]; toolbarBtns.splice(toolbarBtns.length, 0, uiName); }); return btn; });

这里有两个容易踩的坑。一个是注册时机必须在UE.getEditor之前，否则编辑器已经创建，按钮注册不到对应的工具栏上。另一个是toolbars数组里要手动加入这个按钮名，注册UI并不会自动出现在工具栏，我一度以为registerUI就完事了，结果找半天按钮不显示，后来翻源码才发现还要在toolbars里声明。

6.3 修改编辑器默认样式

默认字体、字号、行高这些，如果每次都让运营手动调，体验很差。可以通过初始化配置里的initialStyle设置编辑器内容区域的默认样式：

const config = { initialStyle: ` p { line-height: 1.75; margin: 0 0 1em 0; } body { font-family: "Microsoft YaHei", sans-serif; font-size: 14px; color: #333; } img { max-width: 100%; height: auto; } ` };

设置之后，编辑器内容区域里的正文排版就会更贴近最终发布到页面的效果。这个方法比让用户在正文里手动敲一堆空格和换行靠谱得多。

需要注意initialStyle只影响编辑器内部的预览样式，发布后的页面要另外写对应CSS。如果想让两边的排版一致，就把这套style也复制到展示组件的全局样式里，否则运营在编辑器里看着好看，发出去又是另一副模样，容易引发“为什么编辑器里和页面上不一样”的投诉。

6.4 远程图片抓取与本地化

运营从别的网页复制内容时，图片通常还是远程地址，一旦外链失效，正文里就出现一堆裂图。UEditor内置了远程图片抓取功能，可以配置开启：

const config = { catcherUrl: "/api/ueditor/catchimage", catcherActionName: "catchimage", catcherFieldName: "source" };

后端对应实现一个接收图片URL列表、下载图片并保存到本地的接口。这个功能开启后，粘贴HTML时能自动把图片拉到自己的服务器。我实际体验下来效果不错，但它依赖后端接口稳定，接口超时就会导致粘贴内容迟迟不显示。建议后端对抓取设置超时，不要为了少数图片卡住整个粘贴操作。

如果你不想用这个功能，也可以在初始配置里关掉远程图片抓取，让粘贴过来的图片保持原始链接。做决定之前先想清楚自己的内容安全策略，如果运营经常从外部复制长篇图文，拉起图片本地化会更稳妥。

7. 一点个人取舍：老编辑器也有舒服的用法

写到这里，分享几句个人长期使用下来的心得。

第一，接入老库不可怕，可怕的是没有把它“包”起来。我在项目里做的这个UEditor组件，对页面开发者来说就是一个普通的Vue组件，他们不需要知道UEditor内部怎么加载、怎么销毁、怎么处理上传协议。将来真有一天要迁移到新编辑器，我也只需要重写这个组件内部，所有引用方都不用改。这个隔离设计带来的长期收益，远远超过一开始多写的几百行代码。

第二，很多上报的“编辑器bug”其实和UEditor无关，而是使用方式的问题。比如在v-if里频繁创建销毁组件、容器id冲突、后端上传接口没按协议返回、父容器transform影响全屏定位。排查时先怀疑这些基本面，再考虑是不是编辑器自身的问题，效率会高很多。我上面列的那六个常见坑，基本都是这个层面。

第三，如果团队里有人建议“换个新编辑器兼容老内容”，一定要先确认历史内容的HTML结构。UEditor产出的HTML用了很多内联样式和特定标签，新编辑器做渲染时会遇到表格、字体、图片样式等兼容问题。迁移成本往往比想象的大。我的建议是：历史内容多且复杂就继续用UEditor，新项目、内容简单再换新编辑器，这是性价比最高的选择。

最后分享一个具体的小技巧：编辑器内容保存前，最好统一做一次HTML清洗，把无用的空行、多余的class、历史遗留的奇怪标签去掉。你可以用一个简单的正则链，或者接一个HTML解析库处理。清洗规则每个业务不一样，但至少要做“去掉空段落”“合并连续空格”“移除onerror等事件属性”这三件事，能明显降低后期页面展示的样式错乱概率。

百度UEditor确实老了，但在这个具体需求下，它依然是那个能快速让我交付、让运营用得顺手的老伙伴。技术选型本来就不该只盯“新不新”，更要看“合不合”。希望这篇文章能帮你在类似场景里少踩几个坑，顺利把编辑器接到自己的Vue项目里。