本文由 FlintHub 开发文档归档发布。原始文档日期见标题前缀，来源：WWW/docs/编辑器改造方案分析.md。
编辑器改造方案分析
目标：在不动现有编辑器的前提下，评估"换 EasyMDE / 用 nb_editor / 移植优点"三条路线，选出最适合当前状态的做法。
前提：不愿意废除自己辛苦实现的 SoSite WYSIWYG v3.0 编辑器。
一、现状盘点（先看清手里有什么）
现有编辑器位于 assets/js/editor.js（83KB）+ assets/css/editor.css（9KB），是 SoSite WYSIWYG v3.0，contenteditable 双模编辑器。功能实际很完整：
| 能力 | 现状 |
|---|---|
| 双模编辑 | ✅ 可视化 + Markdown 双 tab，Mode 记忆进 localStorage |
| 存储格式 | ✅ HTML（提交取 editor.innerHTML），存量无迁移成本 |
| 工具栏 | ✅ 加粗/斜体/下划线/删除线/标题²³/列表/链接/图片/表情/字体色/对齐/分割线/撤销重做/清除格式/全屏 |
| 字数统计 | ✅ 底部 editor-footer-bar 字数统计 |
| 粘贴上传 | ✅ paste 监听 + uploadPastedImage() |
| 图片上传 | ✅ 对接 /api/upload?ajax=1，带 CSRF |
| 草稿 | ✅ 由 draft_saver 插件提供（读 ACTIVE_EDITORS[].editor.innerHTML） |
| 实时预览 | ✅ 已有 —— 双模切换时 Markdown→可视化即用 markdownToHtml() 所见即所得渲染（见 editor.js 切换逻辑），可视化 tab 即是最佳预览 |
| 快捷键 | ❌ 唯一真缺口（仅 Ctrl+B/I 浏览器默认） |
| 所见即所得 | ✅ 可视化 tab 本身就近 WYSIWYG |
结论：现有编辑器已具备 EasyMDE / nb_editor 的全部重要优点，实时预览也已内置（可视化 tab 即渲染预览）。真正缺的只有 1 项：快捷键。
二、三个候选方案
方案 A：改造为 Markdown 存储 + EasyMDE
- 改动：EasyMDE 换前端；
Content::formatPostContent从 HTML 净化换成 MD→HTML 渲染（可参考 nb_editor 的渲染引擎）；存量 HTML 内容迁移/懒转换；draft_saver 草稿读写重写；上传接口对接imageUploadFunction。 - 优点：数据范式统一；前端成熟、维护外包给 EasyMDE。
- 代价（高）：动数据格式；存量内容迁移有不可逆风险；渲染行为变化（代码块/表格/引用样式退化）；草稿重写；回归面大。
方案 B：保留 HTML 存储，仅用 EasyMDE 换 UI
- 改动：EaysMDE 当字面编辑外壳，回写仍 HTML。
- 优点：不动数据。
- 代价（中-高）：EasyMDE 是纯 MD 编辑器，编辑 HTML 源码体验差；"MD 编辑 + HTML 存储"互相打架，属半吊子方案，不推荐。
方案 D：保留现有编辑器，移植 EasyMDE 的优点 【推荐】
- 改动：不换编辑器。只往现有
editor.js补两块。 - 优点：不动数据、不动存量、不废自己代码、不重写草稿；改动范围集中在 UI 层，可增量发版、随时回退。
- 代价（低-中）：要自己维护；新功能需手动移植。
注：方案 B/C（小范围试水）本质是 A/D 的过渡策略，不作为独立终态。推荐把"试水"并入 D 的实施节奏。
三、方案对比总表
| 维度 | A：改 MD 存储 | B：换 UI 留 HTML | D：移植优点 |
|---|---|---|---|
| 数据格式 | 改 | 不变 | 不变 |
| 存量内容 | 需迁移（风险） | 不变 | 不变 |
| 自有编辑器 | 废除 | 降级为字面壳 | 保留 |
| 草稿插件 | 重写 | 降级 | 保留 |
| 维护归属 | EasyMDE 维护 | EasyMDE 维护 | 自己维护 |
| 实时预览 | 有 | 有 | 已有（可视化 tab） |
| 快捷键 | 有 | 有 | 补上即有 |
| 回归面/风险 | 高 | 中-高 | 低 |
| 工作量 | 高 | 中 | 低 |
| 与你的偏好契合 | ✗ | ✗ | ✓ |
四、推荐：方案 D
为什么是 D
- 你不想废自己的编辑器 —— D 恰恰保留它，只是给它补齐短板。
- 风险最低 —— 不动数据、不动存储、不动存量、不重写草稿。每次只加一个小能力，出错可单独回退。
- 现有编辑器已覆盖几乎所有优点 —— 实时预览已内置（可视化 tab 即所见即所得渲染），真正的差距只有快捷键一项，移植成本最低。
- D 不是"换"而是"增益" —— EasyMDE 的工具/快捷键/贴图/预览，本质是参考再实现，与本项目"改透调用点"的协作风格一致。
D 的实施顺序（按影响面从低到高，每步可独立验证）
- 快捷键：在
editor.js增加keydown分发，Ctrl+B / Ctrl+I / Ctrl+U / Ctrl+Enter(提交) 等映射到现有 COMMANDS。（唯一核心缺口） - 完善工具栏分组：把现有多而杂的按钮按 EasyMDE 分组/间距微调，视觉更清爽（纯 UI 优化，可做可不做）。
- （可选）移动端工具栏换行优化。
- （可选）若确实想要"编辑同时常驻预览栏"的并排体验，可基于现有
markdownToHtml()加一个前端预览栏（零后端改动）；但已有可视化 tab，属锦上添花。
每步的回归验证清单
- [ ] 可视化 tab 编辑/提交不丢内容
- [ ] Markdown tab ↔ 可视化互转一致
- [ ] 快捷键生效且不影响输入法/浏览器冲突
- [ ] 可视化 tab 渲染(即预览)与最终页面渲染一致、XSS 已净化
- [ ] 图片上传 / 粘贴上传仍走
/api/upload、带 CSRF - [ ] draft_saver 草稿保存/恢复正常
- [ ] 移动端工具栏不换行错乱（或可滚动）
- [ ] 零内联
<script>（必需 CSRF/I18n 除外）
五、为什么不选 A / B
- A（改 MD 存储）：成本高、有存量迁移风险；除非你已铁心长期统一全站为 Markdown，否则现在不划算。可作为远期路线保留（现有前端
markdownToHtml()渲染管线已就绪）。 - B（换 UI 留 HTML）：MD 编辑器直接编辑 HTML 源码，编码体验差，是"既要又要"的折中陷阱，不建议。
六、一句话
选 D：保留自己写的编辑器，只补上唯一缺口——快捷键。实时预览早已内置（可视化 tab 即所见即所得渲染）。风险最低，符合你不想废掉已有成果的诉求，改动可控、可增量回退。
远期若想逐步卸掉自维护负担，可在 D 稳定后，向方案 A 平滑演进（前端渲染管线已具备，届时主要补齐服务端渲染与存量迁移）。
