如何用Electron打造15MB轻量级Markdown编辑器？
1. 项目概述：为什么我们需要一个“轻量级”的Markdown编辑器？
如果你和我一样，日常工作中需要频繁地与Markdown文档打交道，无论是撰写技术文档、整理项目笔记，还是维护个人博客，那么你肯定对市面上那些“功能齐全”的编辑器又爱又恨。爱的是它们功能强大，语法高亮、实时预览、插件生态一应俱全；恨的是它们往往体积庞大，启动缓慢，吃内存如喝水，有时仅仅为了写几行笔记，却感觉像启动了一个IDE。
这就是我动手打造这个轻量级Markdown编辑器的初衷。它的核心目标非常明确：在保持核心编辑体验完整的前提下，将安装包体积压缩到极致（约15MB），同时集成开发者最需要的实时预览、数学公式（KaTeX）和图表（Mermaid）支持。15MB是什么概念？差不多就是一张高清手机照片的大小，或者一个老式MP3文件的大小。这意味着它几乎可以瞬间下载、秒速启动，并且对系统资源的占用微乎其微。
这个项目不是为了替代VS Code、Typora这些成熟的巨无霸，而是为了填补一个特定的需求空白：当你需要快速记录灵感、编写简单的技术说明，或者在一台配置不高的机器上工作时，一个即开即用、不拖泥带水的工具。它特别适合前端开发者、技术写作者、学生以及任何追求效率和简洁工具的人。接下来，我将详细拆解我是如何实现这个目标的，从技术选型到具体实现，再到那些只有亲手做过才会知道的“坑”。
2. 整体架构与技术选型思路
2.1 核心目标拆解：轻量化的代价与收益
在开始编码之前，我花了大量时间思考“轻量化”的边界在哪里。一个编辑器最核心的功能是文本编辑和渲染。为了实现约15MB的最终体积，我必须做出严格的取舍：
必须保留的核心功能：
- 实时预览：这是现代Markdown编辑器的灵魂，左右分屏或混合视图是基本要求。
- KaTeX支持：对于技术文档，数学公式渲染是刚需，KaTeX以其渲染速度和轻量著称，是不二之选。
- Mermaid支持：绘制流程图、时序图、类图等，能极大提升技术文档的表现力。
- 基本的Markdown语法高亮与扩展：支持GFM（GitHub Flavored Markdown）标准，包括表格、任务列表、删除线等。
必须舍弃或精简的功能：
- 插件系统：这是导致编辑器膨胀的元凶之一。维护一个插件生态需要复杂的运行时和API设计，果断放弃。所有功能都内置。
- 深度集成（如Git、终端）：这些功能交给专业的工具（如Git命令行、系统终端）会更高效。编辑器只专注于编辑和预览。
- 复杂的UI主题和自定义：提供有限的几套精心调校的亮色/暗色主题，而不是一个主题商店。
- 拼写检查、语法检查等高级语言服务：这些功能依赖庞大的词库和计算模型，会显著增加体积。
基于以上原则，技术栈的选择就变得清晰起来。
2.2 技术栈的抉择：为什么是Electron + Vite + SolidJS？
市面上实现桌面应用的主流方案有Electron、Tauri、NW.js等。为了实现跨平台（Windows、macOS、Linux）和利用Web技术的强大生态，我选择了Electron。是的，我知道很多人会说Electron“臃肿”，一个Hello World应用可能就超过100MB。但这正是挑战所在——通过极致优化，将一个Electron应用压缩到15MB。
注意：选择Electron并非因为它轻，而是因为它的生态和稳定性最成熟。我们的目标是通过技术手段“驯服”这头大象，让它变得苗条。Tauri虽然更轻量，但其Rust门槛和相对年轻的生态，在快速集成KaTeX、Mermaid这类复杂的Web库时，可能会遇到更多未知问题，不利于快速实现核心功能。
为了对抗Electron的“先天肥胖”，我在前端框架和构建工具上做了精心选择：
- 构建工具：Vite。取代Webpack或Parcel。Vite基于ES Module，启动和热更新速度极快，其构建产物的Tree Shaking（摇树优化）也更为高效，能帮助我们剔除未使用的代码，这是减重的关键一步。
- 前端框架：SolidJS。这是本次选型中的“秘密武器”。相比于React或Vue，SolidJS的核心优势在于其极致的运行时性能和超小的体积。它采用编译时响应式，最终生成的代码更接近原生的JavaScript，没有Virtual DOM的运行时开销，打包体积可以小得多。对于一个编辑器来说，频繁的DOM更新（如输入、预览渲染）是常态，SolidJS的性能优势正好击中痛点。
技术栈总结：Electron作为应用外壳，Vite负责高效构建和打包优化，SolidJS作为UI层提供高性能且轻量的组件驱动。这个组合为后续的“瘦身计划”打下了坚实的基础。
2.3 依赖库的精挑细选
功能库的选择直接关系到最终体积：
- Markdown解析与渲染：Marked + DOMPurify。
Marked：一个速度快、可扩展性强的Markdown解析器。相比markdown-it，它在默认配置下更轻量，且API简洁。DOMPurify：安全必备！Marked将Markdown转换为HTML后，必须经过DOMPurify进行净化，以防止XSS攻击。这是绝对不能省略的安全步骤。
- 数学公式：KaTeX。
- 选择
KaTeX而非MathJax的决定性因素是体积和速度。KaTeX的设计目标就是快速渲染，其CSS和字体文件经过精心优化，虽然功能集是MathJax的子集，但对于绝大多数数学公式场景已经完全足够。
- 选择
- 图表渲染：Mermaid。
- Mermaid是当前技术绘图的事实标准。我们需要集成的是它的核心渲染库。注意，Mermaid本身并不小，所以需要配合Vite的代码分割，只在需要渲染图表时才动态加载其核心代码，避免影响主包的启动速度。
- 代码高亮：highlight.js。
- 这是一个经典选择。我们只需要导入常用的语言包（如JavaScript、Python、CSS、Shell等），而不是全部语言，进一步减少体积。
- 编辑器核心：CodeMirror 6。
- 这是最艰难的决定之一。
Monaco Editor（VS Code所用）功能强大但体积巨大。CodeMirror 6采用了模块化架构，我们可以只导入语言支持、行号、高亮等最基础的扩展，摈弃所有高级功能（如智能提示、代码诊断），从而将其体积控制在可接受的范围内。
- 这是最艰难的决定之一。
3. 核心功能实现与深度优化
3.1 应用骨架与窗口管理
首先，使用Vite模板快速搭建一个Electron应用。关键点在于主进程（main.js）的配置：
// main.js 精简示例 import { app, BrowserWindow, shell } from 'electron'; import path from 'path'; let mainWindow; function createWindow() { mainWindow = new BrowserWindow({ width: 1200, height: 800, webPreferences: { nodeIntegration: false, // 安全考虑，禁用Node集成 contextIsolation: true, // 启用上下文隔离 preload: path.join(__dirname, 'preload.js') // 预加载脚本 }, icon: path.join(__dirname, 'assets/icon.png'), // 一个极简的图标 // 禁用默认菜单，我们实现自己的轻量级菜单 autoHideMenuBar: true, }); // 加载Vite开发服务器地址或打包后的文件 if (process.env.NODE_ENV === 'development') { mainWindow.loadURL('http://localhost:5173'); mainWindow.webContents.openDevTools(); } else { mainWindow.loadFile(path.join(__dirname, '../dist/index.html')); } // 处理外部链接（如Markdown中的网址）在默认浏览器中打开 mainWindow.webContents.setWindowOpenHandler(({ url }) => { shell.openExternal(url); return { action: 'deny' }; }); }preload.js脚本负责在渲染进程中安全地暴露有限的Electron API，例如文件读写操作。
3.2 编辑器与预览的协同
应用的核心UI是一个简单的左右（或上下）分栏布局，使用SolidJS创建响应式组件。
3.2.1 编辑器区域实现我们使用CodeMirror 6，但只安装最核心的包：
npm install @codemirror/state @codemirror/view @codemirror/commands @codemirror/language npm install @codemirror/lang-markdown @codemirror/theme-one-dark @codemirror/theme-light在SolidJS组件中初始化编辑器：
import { createEffect, onCleanup } from 'solid-js'; import { EditorState } from '@codemirror/state'; import { EditorView, keymap } from '@codemirror/view'; import { defaultKeymap } from '@codemirror/commands'; import { markdown } from '@codemirror/lang-markdown'; import { oneDark } from '@codemirror/theme-one-dark'; function CodeEditor({ onContentChange }) { let editorRef; let editorView; createEffect(() => { if (!editorRef) return; const startState = EditorState.create({ doc: '# Hello Markdown\n\nStart writing here...', extensions: [ keymap.of(defaultKeymap), // 仅保留默认快捷键 markdown(), // Markdown语言支持 oneDark, // 使用一个深色主题 EditorView.updateListener.of((update) => { if (update.docChanged) { const content = update.state.doc.toString(); onContentChange(content); // 内容变化时回调 } }), ], }); editorView = new EditorView({ state: startState, parent: editorRef, }); onCleanup(() => { editorView?.destroy(); }); }); return <div ref={editorRef} />; }实操心得：CodeMirror 6的扩展（extensions）机制非常灵活。这里我们只添加了绝对必要的扩展。避免添加
行号、括号匹配等扩展，除非你确实需要。每一个扩展都会增加打包体积。
3.2.2 预览区域实现预览区域是一个<div>容器，其内容由Marked解析后的HTML填充，并交由KaTeX和Mermaid处理。
Markdown解析与安全净化：
import { marked } from 'marked'; import DOMPurify from 'dompurify'; // 配置marked，例如启用GFM表格、任务列表 marked.use({ gfm: true, breaks: true, }); function parseMarkdown(rawText) { const rawHtml = marked.parse(rawText); const cleanHtml = DOMPurify.sanitize(rawHtml); return cleanHtml; }集成KaTeX： 我们不需要在每次输入时都重新渲染整个预览。更好的做法是，在Marked解析时，识别数学公式块（
$$...$$）和行内公式（$...$），并将其转换为KaTeX可渲染的HTML元素。我们可以使用marked-katex-extension这样的库，或者手动配置Marked的渲染器。import katex from 'katex'; import 'katex/dist/katex.min.css'; // 导入KaTeX核心CSS // 在Marked渲染器中覆盖代码块和行内代码的渲染逻辑 const renderer = new marked.Renderer(); const originalCodeRenderer = renderer.code; renderer.code = function(code, language) { // 如果语言是‘math’，则用KaTeX渲染 if (language === 'math') { return katex.renderToString(code, { displayMode: true, throwOnError: false }); } // 否则交给高亮库处理 return `<pre><code class="hljs language-${language}">${highlight.highlight(code, { language }).value}</code></pre>`; }; // 行内公式处理类似，覆盖`codespan`渲染器 marked.use({ renderer });注意事项：KaTeX的CSS和字体文件是体积大头。务必确保在构建时，只打包我们实际用到的字体文件（通常是
woff2格式），并利用Vite的资产处理进行压缩。集成Mermaid： Mermaid的初始化比较耗时，不宜在每次输入时进行。策略是：
- 在预览HTML被插入DOM后，使用
MutationObserver或一个定时器去查找所有<pre class="mermaid">标签。 - 动态导入
mermaid库（利用Vite的动态导入import()实现代码分割）。 - 调用
mermaid.init()来渲染这些图表。
// 一个简化的渲染函数 async function renderMermaidDiagrams(containerEl) { const mermaidElements = containerEl.querySelectorAll('pre.mermaid'); if (mermaidElements.length > 0) { // 动态加载，避免主包体积膨胀 const mermaid = (await import('mermaid')).default; mermaid.initialize({ startOnLoad: false, theme: 'default' }); mermaidElements.forEach(el => { const graphDefinition = el.textContent; try { mermaid.render(`mermaid-svg-${Date.now()}`, graphDefinition, (svgCode) => { el.innerHTML = svgCode; }); } catch (err) { el.innerHTML = `<div class="error">Mermaid Diagram Error: ${err.message}</div>`; } }); } }常见问题：Mermaid图表在暗色主题下可能显示异常。这是因为Mermaid生成的SVG有内置颜色。解决方案是在初始化时根据应用主题动态设置
theme为'dark'或'default'，并确保导入对应的Mermaid CSS主题文件。- 在预览HTML被插入DOM后，使用
3.3 状态管理与文件操作
应用的状态（当前文件内容、文件路径、主题模式）使用SolidJS自带的createSignal和createStore管理就足够了，无需引入Redux或MobX等重型状态库。
文件读写通过Electron主进程暴露的API进行。在preload.js中：
// preload.js const { contextBridge, ipcRenderer } = require('electron'); contextBridge.exposeInMainWorld('electronAPI', { openFile: () => ipcRenderer.invoke('dialog:openFile'), saveFile: (content, filePath) => ipcRenderer.invoke('file:save', content, filePath), // ... 其他API });在渲染进程中调用window.electronAPI.openFile()，通过IPC与主进程通信，由主进程调用dialog.showOpenDialog和fs模块完成实际操作。这种设计确保了渲染进程无法直接访问文件系统，符合安全最佳实践。
4. 极致的打包优化与体积控制
这是将应用从“普通Electron应用”压缩到“15MB轻量应用”最关键、最艰难的一步。
4.1 构建阶段的优化（Vite配置）
vite.config.js是我们的主战场：
import { defineConfig } from 'vite'; import solidPlugin from 'vite-plugin-solid'; import { viteStaticCopy } from 'vite-plugin-static-copy'; import compression from 'vite-plugin-compression'; export default defineConfig({ plugins: [ solidPlugin(), // 压缩构建产物 compression({ algorithm: 'gzip', // 生成 .gz 文件 ext: '.gz', }), compression({ algorithm: 'brotliCompress', // 生成 .br 文件，现代浏览器支持 ext: '.br', }), // 静态资源复制（如KaTeX字体） viteStaticCopy({ targets: [ { src: 'node_modules/katex/dist/fonts/*.woff2', dest: 'assets/fonts' } ] }) ], build: { target: 'es2020', // 使用较新的ES标准以获得更好的压缩 minify: 'terser', // 使用Terser进行代码压缩 terserOptions: { compress: { drop_console: true, // 生产环境移除console.log drop_debugger: true, }, }, rollupOptions: { output: { // 对代码进行分块，将KaTeX、Mermaid等大库拆分成单独的chunk manualChunks(id) { if (id.includes('node_modules')) { if (id.includes('katex')) return 'vendor-katex'; if (id.includes('mermaid')) return 'vendor-mermaid'; if (id.includes('highlight.js')) return 'vendor-highlight'; // 将其他较大的依赖也拆分出来 return 'vendor'; } }, // 使用更小的哈希命名，减少文件名体积 entryFileNames: 'assets/[name]-[hash:8].js', chunkFileNames: 'assets/[name]-[hash:8].js', assetFileNames: 'assets/[name]-[hash:8].[ext]' } }, // 启用CSS代码分割和压缩 cssCodeSplit: true, // 生成详细的bundle分析报告，便于排查体积问题 reportCompressedSize: true, }, });4.2 Electron打包优化（electron-builder配置）
package.json中的build配置至关重要：
{ "build": { "appId": "com.yourname.lightmark", "productName": "LightMark", "directories": { "output": "release" }, "files": [ "dist/**/*", "!node_modules/**/*", // 明确排除node_modules "package.json", "main.js", "preload.js" ], "asar": true, // 使用asar归档，保护代码并略微减小体积 "compression": "maximum", // 最大压缩 "npmRebuild": false, // 如果没用原生模块，设为false "electronDownload": { "mirror": "https://npmmirror.com/mirrors/electron/" // 使用国内镜像加速 }, "win": { "target": ["nsis"], "icon": "build/icon.ico" }, "nsis": { "oneClick": false, "perMachine": false, "allowToChangeInstallationDirectory": true, "deleteAppDataOnUninstall": true, "shortcutName": "LightMark Editor" }, "mac": { "target": "dmg", "icon": "build/icon.icns", "category": "public.app-category.developer-tools" }, "linux": { "target": ["AppImage"], "icon": "build/icon.png", "category": "Development" } } }关键减重操作：
- 清理
node_modules：确保files配置中排除了庞大的node_modules。Electron-builder会自动处理生产依赖。 - 选择最小运行时：检查并移除
package.json中所有非必要的生产依赖（dependencies）。使用npm prune --production或yarn install --production进行清理。 - 资源文件优化：
- 图标：使用专业工具将PNG图标转换为
.ico(Windows)和.icns(macOS)，并确保尺寸齐全但无冗余。 - 字体：KaTeX字体只包含
woff2格式，这是目前压缩率最高的Web字体格式。 - 图片：所有界面图片使用SVG格式，或者经过
svgo、pngquant等工具压缩的PNG。
- 图标：使用专业工具将PNG图标转换为
- 压缩与归档：启用
asar和compression: maximum。
4.3 体积分析工具
使用rollup-plugin-visualizer或webpack-bundle-analyzer（Vite兼容）生成构建产物的可视化报告。这个报告能清晰地告诉你哪个库、哪个模块占据了最大的体积，从而有针对性地进行优化（比如寻找更轻量的替代库，或检查是否有未使用的代码被引入）。
5. 开发中的挑战与解决方案实录
5.1 性能瓶颈：实时预览的防抖与节流
在编辑器快速输入时，频繁触发Markdown解析、HTML净化、KaTeX渲染和Mermaid初始化会导致界面卡顿。解决方案是使用防抖（Debounce）。
import { createSignal, onCleanup } from 'solid-js'; function useDebouncedSignal(initialValue, delay) { const [signal, setSignal] = createSignal(initialValue); let timeoutId; const setDebouncedSignal = (newValue) => { clearTimeout(timeoutId); timeoutId = setTimeout(() => setSignal(newValue), delay); }; onCleanup(() => clearTimeout(timeoutId)); return [signal, setDebouncedSignal]; } // 在编辑器组件中使用 const [editorContent, setEditorContent] = createSignal(''); const [debouncedContent, setDebouncedContent] = useDebouncedSignal('', 300); // 300ms防抖 // 编辑器内容变化时，更新防抖信号 createEffect(() => { setDebouncedContent(editorContent()); }); // 只有防抖后的内容变化，才触发昂贵的预览渲染 createEffect(() => { const content = debouncedContent(); if (content) { updatePreview(content); // 这个函数内部进行Marked解析、KaTeX/Mermaid处理 } });实操心得：防抖延迟时间需要权衡。太短（如100ms）可能仍有性能压力，太长（如1000ms）则预览反馈迟钝。经过测试，对于代码和文字输入，200-350ms是一个较好的平衡点。对于图表（Mermaid）渲染，甚至可以延迟更久，或者提供一个“手动刷新图表”的按钮。
5.2 样式隔离与主题切换
编辑器区域（CodeMirror）和预览区域（生成的HTML）需要共享一套主题（亮色/暗色）。但CodeMirror有自己的主题CSS，而预览区域是我们自定义的HTML。
解决方案：
- 定义一组CSS变量（CSS Custom Properties）来统一定义颜色方案。
:root { --bg-primary: #ffffff; --text-primary: #333333; --code-bg: #f5f5f5; --border-color: #e1e4e8; } [data-theme='dark'] { --bg-primary: #1e1e1e; --text-primary: #d4d4d4; --code-bg: #2d2d2d; --border-color: #444444; } - 预览区域的样式全部基于这些CSS变量。
- 对于CodeMirror，我们需要创建自定义主题扩展，使其颜色映射到我们的CSS变量上。
import { EditorView } from '@codemirror/view'; const customLightTheme = EditorView.theme({ '&': { backgroundColor: 'var(--bg-primary)', color: 'var(--text-primary)' }, '.cm-content': { caretColor: 'var(--text-primary)' }, // ... 更多样式映射 }, { dark: false }); const customDarkTheme = EditorView.theme({ // ... 暗色样式映射 }, { dark: true }); - 切换主题时，同时做三件事：
- 修改根元素的
>// 在主进程的IPC处理函数中 ipcMain.handle('file:save', async (event, content, filePath) => { try { // 检查文件路径是否有效，是否有写入权限 await fs.promises.access(path.dirname(filePath), fs.constants.W_OK); // 写入文件 await fs.promises.writeFile(filePath, content, 'utf-8'); return { success: true }; } catch (error) { console.error('Save file error:', error); // 将错误信息分类，返回给渲染进程友好提示 let userMessage = '保存文件失败。'; if (error.code === 'ENOENT') userMessage = '目录不存在。'; if (error.code === 'EACCES') userMessage = '没有写入权限。'; if (error.code === 'ENOSPC') userMessage = '磁盘空间不足。'; return { success: false, message: userMessage, detail: error.message }; } });在渲染进程中，根据返回的结果显示成功或友好的错误提示，而不是让整个应用崩溃。
5.4 内存泄漏排查
由于集成了多个复杂的库（CodeMirror、Mermaid），并在频繁地创建和销毁DOM元素（预览区域），内存泄漏是需要警惕的。使用Chromium开发者工具的Memory面板，定期进行堆快照对比。
常见泄漏点：
- 事件监听器未移除：在SolidJS的
onCleanup或组件的销毁生命周期中，确保移除所有通过addEventListener手动添加的监听器。 - 定时器未清理：防抖/节流、轮询等使用的
setTimeout/setInterval必须在组件卸载时清理。 - 第三方库实例未销毁：例如，在切换文档时，旧的Mermaid图表SVG元素可能仍被引用。确保在渲染新内容前，清理旧预览容器的所有子元素，并尝试调用
mermaid.init()的清理方法（如果存在）。
6. 最终成果与未来可能的延伸
经过上述一系列的设计、实现和优化，最终打包出的应用安装包成功控制在了14.8MB左右（Windows NSIS安装包）。启动时间在普通机械硬盘上小于2秒，内存占用长期稳定在100MB以下。
这个项目验证了一个想法：通过精准的功能定位、谨慎的技术选型和极致的构建优化，完全可以用Electron打造出体验轻快、功能聚焦的桌面应用。它可能没有VS Code那样无所不能，但在“快速编写格式丰富的Markdown文档”这个特定场景下，它做到了专注和高效。
如果你也想尝试类似的构建，我的建议是：始终以终为始。先明确你最终想要的那个“轻量级”安装包大小，然后反向推导每一个技术决策。每一个依赖的引入，都要问一句“这个功能是必须的吗？有没有更轻量的实现方案？”。在开发过程中，要善用打包分析工具，持续监控体积变化。
这个编辑器本身也有许多可以自然延伸的方向，例如：
- 导出功能：集成
Pandoc的命令行调用，支持导出为PDF、Word等格式（这可能会增加体积，可作为可选插件）。 - 聚焦模式：隐藏所有UI，只保留编辑区域，帮助用户集中注意力。
- 本地图片粘贴与管理：自动将粘贴板中的图片保存到相对路径，并插入Markdown引用。
- 片段（Snippet）管理：保存和插入常用的文本或代码片段。
不过，任何新功能的增加，都必须再次经过“体积天平”的称量，以守住“轻量”这个立身之本。这或许就是打造一个精致工具的乐趣所在——在克制与功能之间，寻找那个完美的平衡点。
- 事件监听器未移除：在SolidJS的
- 修改根元素的