写一个 Markdown 编辑器，难的从来不是把 **文本** 渲染成粗体。
真正麻烦的是：运营同学不想看标记符号，开发者又不愿意放弃干净的 Markdown；图片要能直接粘贴，表格不能全靠手敲，内容还要在 Vue、React，甚至没有构建工具的旧页面里复用。等这些要求凑到一起，一个看似简单的输入框，很快就会变成依赖、插件和兼容性问题的集合。
这也是我做 ME.js 的出发点：它不是要替代所有 Markdown 工具，而是解决一个更具体的问题------怎样用尽量低的接入成本，在 Web 产品里放进一个真正可用的所见即所得 Markdown 编辑器。
在线体验：juicy696.github.io/markdown-ed...
Markdown 编辑器里的几个老问题
Markdown 对开发者友好，对普通编辑者不一定友好
熟悉 Markdown 的人输入标题、列表和代码块很快，但在内容运营、客服知识库、产品公告等场景里，使用者未必愿意记语法。他们期待的是接近 Word 的操作：选中文字点一下加粗，插入图片后能调整大小，建表格时填行列数，而不是先确认竖线、短横线和空格有没有写对。
这就形成了第一个矛盾：编辑体验需要可视化，数据格式却最好仍然是 Markdown。
能力不难找，恰到好处的接入成本很难找
成熟编辑器通常能力丰富，但嵌入业务系统时，还要考虑包体、依赖、主题、构建链和框架适配。一个只需要写公告的后台，并不一定需要完整的知识库系统；一个需要兼容老页面的项目，也未必愿意为了编辑器重做工程配置。
编辑器"功能多"不等于"适合嵌入"。很多时候，团队真正需要的是：放进页面就能工作，数据能拿出来，图片上传能接自己的后端，按钮还能按业务裁剪。
预览模式和源码模式经常像两套系统
分栏预览适合检查结果，但写作时视线要在源码与预览之间来回跳。纯 WYSIWYG 又容易让人担心：保存下来的到底是什么？再次打开会不会丢格式？如果工具栏只在可视化模式可用，用户一进入源码模式，插入链接、表格和媒体就又要手写语法，模式切换反而成了操作断点。
图片、表格和媒体才是业务里的"硬骨头"
真实的内容后台不会只处理标题和段落。用户会从聊天工具里粘贴截图，会插入产品演示视频，会调整图片宽度，也会从别处复制一段混合格式内容。这些细节不够"炫"，却决定了一款编辑器能不能真正进入生产流程。
现在常见的 Markdown 编辑器，都在解决什么问题？
为了避免把不同类型的产品硬放在一起比较，我更愿意按使用场景来看。
| 类型 / 代表工具 | 更擅长的方向 | 典型使用方式 |
|---|---|---|
| Typora | 沉浸式本地写作、即时渲染、丰富导出 | 个人文章、长文档、本地文件写作 |
| Obsidian | 本地知识库、开放文件格式、插件与主题生态 | 双链笔记、个人知识管理 |
| VS Code | 工程内文档、目录结构、链接与路径补全、扩展能力 | README、项目文档、Docs as Code |
| StackEdit | 浏览器写作、同步、协作与扩展 Markdown | 在线写作、云端同步、博客发布 |
| MarkText 等开源桌面工具 | 所见即所得与本地 Markdown 文件 | 个人写作、开源替代方案 |
| ME.js | 将可视化 Markdown 编辑能力嵌入现有 Web 产品 | CMS、管理后台、文档页面、表单系统 |
Typora 的长处是把源码符号隐藏起来，让本地写作更连贯；Obsidian 的重点是本地数据与知识网络；VS Code 适合已经生活在工程目录里的开发者；StackEdit 则把浏览器写作、同步和协作做成了完整应用。
ME.js 选择的是另一条路线：不再做一个需要用户迁移过去的独立工作台，而是做一个能被开发者带回自己产品里的编辑器。
所以它关注的是：接进现有页面需要多少工程改造、普通用户能否像使用富文本一样写作、可视化与源码模式能否互通、图片上传能否走业务自己的后端，以及最终数据能不能继续迁移和二次处理。
ME.js：界面是富文本，底层仍是 Markdown
ME.js 的核心链路可以概括为：
text
Markdown source
↕
MdParser
↕
WYSIWYG DOM
↕
MdSerializer用户看到的是已经渲染的标题、粗体、列表、引用和表格；业务侧保存的仍然可以是 Markdown。需要检查或精修时，用户可以切到源码模式，修改后再回到预览，内容会按最新源码重新解析。
这不是简单地在左边放输入框、右边放预览，而是在两种编辑习惯之间维持同一份内容。
下面是编辑器当前的实际界面：
最新版重点补齐了"源码模式也能编辑"
根据项目当前的 CHANGELOG.md，最新版重点处理了一个很实际的问题：进入 Code Mode 以后，原来的编辑能力不应该突然消失。
Code Mode 不再只是查看源码
在源码模式中选中文字，工具栏可以直接完成：
- 粗体、斜体、删除线、行内代码包裹；
- 标题、引用、无序/有序/任务列表前缀插入；
- 代码块与分隔线插入；
- 链接、图片、音频、视频等内容写入源码；
- 表格以 Markdown pipe syntax 插入；
- 文字颜色以
<span style="color:...">写入。
从源码模式切回预览时，编辑器会重新解析最新内容。对经常在可视化编辑和精确控制之间切换的人来说，这比"只读源码弹窗"实用得多。
颜色选择器开始记住使用习惯
新版颜色面板会保存最近使用的颜色，最多 20 个，去重并按最近使用排序，记录持久化在 localStorage 中，而且 Vanilla、Vue、React 三个版本可以共享。
这是一个很小的功能，但在公告、状态标记、重点提示等场景里，团队往往反复使用同一组品牌色。减少重复取色，编辑过程会顺手很多。
React 版本修复了几类真实交互问题
新版还修复了 React 版本中对话框输入时焦点被反复抢走、插入表格后光标位置丢失、插入内容导致页面滚回顶部，以及色块样式缺失等问题。
这类修复看起来不像"大版本卖点"，却很能说明编辑器开发的现实：功能入口存在只是第一步，焦点、选区、滚动位置和插入点是否稳定，才决定用户能不能连续写下去。
它有哪些适合落地的功能？
三种接入方式，不要求统一技术栈
ME.js 提供三个独立版本：
- Vanilla JS：约 57 KB，零依赖；
- Vue 3：约 41 KB，只依赖 Vue 3；
- React 18：约 39 KB，只依赖 React 18。
不需要 JSX，也不强制构建步骤。对历史系统、静态工具页和轻量管理后台来说，这比先搭一套工程再接编辑器更直接。
最简单的原生页面接入如下：
html
<div id="app">
# Hello
这是一段 **Markdown** 内容。
</div>
<script src="me-editor.js"></script>
<script>
ME.init({
mount: '#app',
title: '内容编辑',
uploadUrl: '/upload',
maxLength: 5000
});
</script>所见即所得，但不把内容锁死在私有格式里
编辑器支持标题、粗体、斜体、删除线、行内代码、文字颜色、引用、列表、任务列表、代码块、表格、链接、图片、音频、视频和分隔线。
业务可以通过 API 获取 Markdown、HTML、原始 DOM HTML，也能导出 Markdown、HTML 或混合格式。内容不仅能留在编辑器里，还能继续进入静态站点、内容平台、接口或存储系统。
截图直接粘贴，上传策略由业务决定
设置 uploadUrl 后，剪贴板图片可以上传到自己的服务端，接口返回 { "url": "..." } 后插入正文；没有配置接口或上传不可用时，也可以回退到 base64。项目还附带了只使用 Python 标准库的最小上传接收示例，便于本地联调。
图片大小不是插入后就"听天由命"
图片插入后可点击调整为原始大小、100%、75%、50% 或 25%，并通过 HTML round-trip 保留尺寸信息。Markdown 对图片宽度没有统一的标准语法，ME.js 允许在需要时使用 Markdown 与 HTML 的混合表达，兼顾可移植性和展示效果。
表格和媒体采用对话框插入
用户可以指定表格的行数和列数，不需要手敲竖线；图片支持标题与 URL，音频和视频也有独立入口。对于知识库和产品文档，这些是比"支持几十种快捷键"更常用的能力。
工具栏可以按业务做减法
查看源码、复制、音频、视频、状态栏等按钮都可以通过初始化参数开关。还可以设置字符上限，超出后计数变红提醒。编辑器不是越满越好，同一套编辑器应该能够服务不同入口。
三个实际开发场景
案例一：给运营后台增加公告编辑器
一个旧的管理后台可能没有 Vue 或 React，需求却包括：标题与列表可视化、截图粘贴、字符限制，以及最终保存 Markdown。
用 Vanilla 版本可以直接挂载到已有 DOM，不必改造构建链。把 uploadUrl 指向现有对象存储上传接口，设置 maxLength，再关闭暂时用不到的音视频按钮即可。
这个场景里，ME.js 的优势不是比桌面编辑器功能更多，而是它能留在原系统里，并服从原系统的数据与上传规则。
案例二：Vue 与 React 并存的内部文档系统
不少公司在技术栈迁移期同时维护 Vue 旧模块和 React 新模块。如果两个模块分别引入不同的编辑器，Markdown 解析结果、工具栏能力和数据格式很容易逐渐分叉。
ME.js 的三个版本共享相同的解析与序列化层，可以分别使用 v-model 和 value/onChange 接入，但内容链路保持一致。迁移的是页面技术栈，不必同时迁移文档格式。
案例三：技术作者在可视化写作与源码精修之间切换
一篇技术文章通常包含代码块、表格、截图和少量 HTML。作者可以先在所见即所得模式里快速完成主体，再切到 Code Mode 调整 Markdown 细节；此时仍能用工具栏插入表格、链接或媒体。
回到预览后，编辑器重新解析最新源码。整个过程不需要在两个编辑器之间复制内容，也避免了"源码改了但预览还停留在旧状态"的割裂感。
ME.js 的优势和边界都很明确
ME.js 不是 Obsidian 的知识图谱替代品，也不打算复刻 VS Code 的扩展市场，更不会覆盖 Typora 的全部桌面文件管理与导出能力。
它的优势集中在四点：
- 更轻的嵌入方式：单文件、零依赖或仅依赖宿主框架；
- 更低的使用门槛：普通用户按富文本方式编辑，开发者仍拿到 Markdown；
- 模式切换不断档：源码模式也能使用格式化和插入能力；
- 更尊重业务边界：图片走自己的后端，工具栏按场景裁剪，内容可多格式导出。
它目前也有清楚的边界：如果你需要多人实时协作、知识图谱、完整文件管理、复杂数学公式或庞大的插件生态，成熟的专用产品会更合适。
但如果需求是"给现有 Web 产品加一个够用、轻量、数据可控的 Markdown 编辑器"，ME.js 会是一条更短的路径。
写在最后
Markdown 编辑器这个领域并不缺产品，缺的是对场景的取舍。
有人把它做成沉浸式写作软件，有人做成知识库，有人把它放进 IDE。ME.js 想做的事情更克制：让开发者不用背上一整套复杂系统，也能把可视化 Markdown 编辑能力放进自己的产品。
当前版本已经覆盖常见格式、表格与媒体、图片粘贴与调整、源码编辑、多格式导出，以及 Web、Vue 3、React 18 三种接入方式。最新版又把 Code Mode 从"查看"推进到了"可操作"，并修复了一批影响连续编辑体验的 React 交互问题。
如果你正在开发 CMS、知识库、文档页或管理后台，可以直接打开在线 Demo，试着粘一张图、插一个表格，再切到源码模式看看最终保存的内容。一个编辑器是否适合项目，通常几分钟就能判断出来。