简介在线排版工具源代码是一套基于网络应用的实用程序可实现文章快速格式化、字数统计、空行增删等功能服务于需要轻量文本处理的内容创作者也为学习字符串函数与正则表达式的开发者提供参考。压缩包共17个文件以脚本、样式表、超文本页面及字体资源为主并附带使用帮助文本整体仅184KB便于本地部署或二次开发。其中脚本负责前端交互与动态效果样式表定义界面外观字体图标则丰富按钮视觉清晰展示了在线工具的典型文件分工。目前已有1294人学习使用适合作为Web开发初学者的实践范例。通过阅读源码可了解如何利用内置函数与正则表达式实现字数统计和空行处理同时掌握前端组件与脚本的整合方式。在此基础上开发者能够针对具体业务定制排版规则或利用现有界面快速搭建同类工具提升开发效率。在线排版工具源代码从编辑器到发布链路的完整实现思路做技术这么多年我发现自己和身边不少同事都卡在同一个问题上写好的内容在不同平台上的排版效果五花八门公众号、知乎、博客各有各的渲染规则。碰上还要插入代码块、表格、数学公式的内容每次调格式少说半小时。后来我做了一个在线排版工具把排版这件事从复制粘贴后逐段修变成了一次写好到处能用顺手把整套源代码做了梳理。这篇就围绕这个项目的源代码实现把架构、核心模块、实测中踩过的坑和可以优化的方向都摊开来讲。先说清楚这个工具解决什么问题用户在网页里编辑内容完成排版然后一键导出为适合公众号、知乎、Markdown、PDF等场景的格式。它的核心价值不是再做一款笔记软件而是充当排版中间层帮内容创作者省掉重复劳动。项目代码基于前端为主、Node.js轻量服务为辅的架构适合已经入门前端又想做一个完整项目的开发者参考也比较适合团队内部需要统一输出格式的场景。技术栈方面我选的是React 18 TypeScript Vite 5做界面编辑器基于ProseMirror二次开发导出链路用Puppeteer生成PDF样式方案则是一套自研的排版资产包后面会详细展开。1. 在线排版工具真正要解决的核心矛盾在动笔写源码之前我先花了两个晚上梳理需求边界。这个阶段容易被忽视却是整个项目的地基。网上很多开源的排版工具上来就做一堆功能最后多半变成不像编辑器不像排版器的缝合怪。我把核心需求收敛成三件事HTML语义结构标准化、样式解析与内联化、多平台发布适配。1.1 HTML语义结构标准化在线排版工具和本地文档编辑器的本质差别在于输出端是Web环境。本地Word文档有固定的文件格式字体、段落、分页都写在文件里Web输出则完全依赖HTML标签和CSS规则不同平台只会读取它们认可的那部分。所以我给项目定义的第一条设计原则是编辑器内部永不自造标签。比如用户想表示重要提醒插入的必须是blockquote或aside不能是加了背景色的div想表示代码块必须是precode结构不能用一串带br的段落模拟。这套语义约束是后期所有导出功能能成立的前提。1.2 样式解析与内联化排版工具最脏最累的活是CSS处理。用户写文章时用的是类名体系比如p classhighlight发布到公众号时外链样式表往往直接被丢掉文章瞬间变成裸奔状态。因此我要在导出前把样式计算成最终结果然后以内联style的形式写进HTML标签。这个环节我用了一个很有意思的方案真实DOM渲染 计算样式采集。先把用户内容渲染到不可见的iframe里等样式全部生效后用window.getComputedStyle逐个元素读取font-size、line-height、color、margin等属性再序列化回标签的style属性。这个方法比手工解析CSS文件稳健得多因为浏览器已经帮你处理完了所有级联和继承逻辑。1.3 多平台发布适配这一步是工具价值的最终体现。同一个HTML内联文档针对不同平台做微调。公众号要求图片上传到它的CDN知乎的代码块默认样式比较丑Markdown则不能保留多余的行内样式。我在源代码里设计了一个Exporter接口每个平台实现自己的处理策略核心是transform和serialize两个方法。interface PlatformExporter { id: string; name: string; transform(doc: Document, options: ExportOptions): PromiseDocument; serialize(doc: Document): Promisestring; }这个抽象在后续加新平台时帮了大忙。后来我增加了一个VuePress站点页面导出目标只写了一个新类接入成本大概半天。2. 技术选型和源码架构为什么是React ProseMirror这套组合技术选型阶段我对比过不少方案包括完全自己写contenteditable、基于Slate、基于BlockNote的路线最后选择了ProseMirror。这里把理由说透方便你站在同样的决策节点时少走弯路。2.1 编辑内核ProseMirror的不可替代性ProseMirror是编辑器世界里的老牌发动机它最核心的贡献是把文档状态做成了不可变数据模型。你在界面上每敲一个字背后都对应一次事务提交从state到new state中间经过了精确的文档变更记录。这意味着两步操作之间永远可以计算diff、可以撤销、可以协作这对排版工具来说非常关键——排版超长的文章时用户要反复调整区块顺序有了精准的文档模型拖拽排序、区块折叠这些功能才有实现的可能。对比Slate而言ProseMirror对浏览器原生contenteditable的封装更底层、更稳定。Slate自己的数据模型偏JSON自描述把很多细节暴露给了应用层团队小的话很容易写出能跑但不稳定的编辑器。ProseMirror虽然学习曲线陡峭但把锚点、选区、装饰这些硬骨头都处理好了长期维护成本更低。2.2 前端框架与构建链路React 18主要负责编辑器外围工具面板、菜单栏、模板选择器、导出设置弹窗。编辑器核心没有和React强绑定ProseMirror的EditorView挂载在React的useRef容器里通过事件向外同步状态。这样有个好处——编辑器内部高频变更不会触发React全局重渲染性能上能得到保障。Vite 5则是目前体验最好的构建工具。我最初用过Webpack但热更新在重构编辑器插件时经常要整页刷新效率偏低。Vite的依赖预构建加上原生ESM让开发循环非常丝滑。构建产物方面我用vite-plugin-pwa做了PWA离线缓存用户第二次打开工具基本秒开。2.3 模块划分与目录结构源码目录我设计成下面这样职责边界特别清楚src/ core/ # 文档模型、ProseMirror插件、schema定义 export/ # 各平台导出器、样式采集、图片处理 templates/ # 排版模板每个模板是一个JSON配置 CSS变量集 ui/ # 工具面板、菜单、快捷键设置、弹窗组件 utils/ # 纯函数工具颜色转换、HTML净化、字数统计 workers/ # Web Worker用于大文档的样式序列化core目录是整个源码的心脏export目录是收益的兑现地ui目录尽量做薄不包含任何业务逻辑。这样分法在后期维护中帮了大忙查找问题基本不用猜位置。3. 排版引擎的源码实现从编辑区到导出链路的完整方案这里讲整个工具最核心的代码逻辑。我在写core模块时重点做了三件事定义了一套严谨的Schema、实现了一个主题系统、封装了安全的导出管线。3.1 Schema定义与节点约束Schema是ProseMirror的数据结构宪法。我在core/schema.ts里定义了如下顶层节点类型doc根节点只允许包含以下块级节点paragraph标准段落headinglevel属性限定为1到4超过4级在移动端视觉意义上基本消失了blockquote引用块code_block代码块单独存language与filename字段image图片节点记录src、alt、titledivider分隔线callout带type属性的提示框分为info/warning/error/success四种行内节点则包括text、strong、em、code、link、del。这里有一个设计细节我故意让callout成为一种节点类型而不是渲染成带特殊类名的blockquote。原因在于排版工具后面接的是不同平台很多平台对blockquote有自己的默认样式如果我用它来承载提示框导出时会撞得很难看。数据模型层面的区分比渲染层的努力更彻底。3.2 主题系统与CSS变量的巧妙应用排版工具的用户不可能所有人审美一致我把皮肤做成了CSS变量驱动的主题系统。每个主题是一个JSON文件定义十几个变量{ name: 学术风, variables: { primary: #1E3A5F, text: #2D3748, bg: #FFFFFF, border: #CBD5E0, codeBg: #F7FAFC, blockquoteBar: #3182CE, headingFont: Georgia, Songti SC, serif, bodyFont: -apple-system, PingFang SC, sans-serif, baseFontSize: 16px, lineHeight: 1.8 } }编辑器在预览区域只维护一个带CSS变量的容器变量值随主题切换实时更新。这个方案相比每个主题写一套完整CSS来说改动量是指数级收缩的。而且因为底层是一样的排版引擎主题之间切换不会引发布局抖动。3.3 导出管线内联化、净化、平台转换三步走导出是排版工具区别于普通编辑器的最重要功能。我在export/pipeline.ts里实现了三个阶段通过一个pipe函数串联。第一步是内联化。这一步把预览区域的实际计算样式写到每个元素上。注意这里要跳过style为空或等于默认值的属性不然导出的HTML会膨胀得非常快——我自己实测过一篇一万字的文章不加筛选的内联化产出体积是原始HTML的5倍。第二步是净化。这一步移除所有class和id属性它们对目标平台没有意义移除空标签把不规范嵌套的标签修正。我直接用了一个轻量级的HTML解析器来做AST遍历比正则表达式安全得多。正则处理HTML就像用砍刀做外科手术总有切错组织的时候。第三步是平台转换。每个平台处理器可以修改Document对象。比如公众号导出需要处理图片上传我会遍历所有img节点把src替换成新的支持外链的图片地址知乎导出则会把code_block的language属性映射成它自己的语言类名。async function exportDocument(editorState: EditorState, platformId: string) { const dom renderToDOM(editorState); await inlineStyles(dom); sanitize(dom); const platform platformRegistry.get(platformId); await platform.transform(dom); const html platform.serialize(dom); return html; }4. 实测问题剪贴板样式污染与代码块渲染只把自己写过的bug和踩坑经验放在这一节这部分才是源码之外真正值钱的东西。4.1 剪贴板污染粘贴来的内容毁掉整篇排版第一次内测时我从Word里粘了一段文字进去整个文章的标题层级全部被打乱了。排查了一个多小时发现ProseMirror默认的clipboardTextParser会把带stylefont-weight: bold的纯文本片段解析成加权重的文本标记。问题是Word给每个段落都加了mso-前缀的私有样式这些样式被ProseMirror保存成style属性然后内联化阶段直接合法地把它们当成用户意图写进了导出结果。最终我写了自定义的clipboardTextParser把所有粘贴进来的HTML先过一次净化只保留白名单内的标签和属性。const FORBIDDEN_TAGS new Set([font, o:p, strike, meta, link]); // 粘贴HTML时的预处理过滤掉Word等软件的私有标签和样式 function cleanPastedHTML(html: string): string { const doc new DOMParser().parseFromString(html, text/html); doc.querySelectorAll(*).forEach((el) { el.removeAttribute(style); el.removeAttribute(class); el.removeAttribute(id); }); FORBIDDEN_TAGS.forEach((tag) { doc.querySelectorAll(tag).forEach((el) el.remove()); }); return doc.body.innerHTML; }这里还要提醒一句DOMParser解析出来的HTML再插入ProseMirror时要对p中的纯br以及空白标签做压缩处理不然会出现大量不可见空行。4.2 代码块渲染iframe内的安全隔离在线排版工具需要直接预览html代码块效果但用户写的代码里可能包含script或img onerror在编辑器页面内直接执行还是有风险的会造成页面崩溃甚至XSS攻击。虽然ProseMirror解析时默认会转义脚本内容但浏览器对某些标签的事件属性不会自动清除。我的做法是预览区域和编辑区域分开编辑区域不渲染真正的运行DOM只显示转义后的纯文本代码真正的预览放到一个sandbox属性为allow-same-origin的iframe里并且通过srcdoc属性动态注入内容。这样可以做到完全的脚本隔离。还有一个细节iframe里的代码块字体必需用等宽字体栈font-family: JetBrains Mono, Fira Code, Consolas, monospace不然缩进对齐全乱。4.3 导出PDF时的中文断行与字体缺失这一坑在实测后期才暴露。Puppeteer调用Chromium生成PDF时中文字体在Linux服务器上经常缺失最终输出的PDF中文全是豆腐块方块。解决方案是一方面在服务器上安装fonts-noto-cjk另一方面在page.pdf()的preferCSSPageSize、printBackground等参数之外额外注入一段CSS把中文断行规则固定下来p, li, blockquote { word-break: break-word; overflow-wrap: anywhere; }为什么不直接全局设word-break: break-all因为那会把中文按字符拆开断行视觉上惨不忍睹。overflow-wrap: anywhere则允许长URL和长代码在任意点断开同时尽量保持词语完整性。5. 部署与性能优化的几个关键操作工具开发完成后性能和部署我又打磨了两个晚上这里挑几个关键点说。在线排版工具虽然是前端为主的项目但服务端和静态资源层面有很多可优化空间。5.1 静态资源按需加载压缩编辑器初始化体积ProseMirror核心包加上各种插件体积不小如果全部打进主bundle首屏会白等很久。我用了Vite的manualChunks把编辑器相关代码单独拆包并配合React.lazy做路由级懒加载。工具首页渲染时只加载入口文件和极简的引导UI等用户真正点击新建文档才拉取编辑器全量代码。实际优化效果很明显首屏JS体积从1.2MB降低到260KB左右gzip之后首页加载时间从2.8秒降低到1秒内。5.2 大文档导出时用Web Worker分担线程压力在浏览器里对一篇两万字的长文做样式内联化时主线程会被大量DOM操作阻塞页面直接卡成幻灯片。这个问题我用Web Worker解决在Worker里创建一个OffscreenCanvas和一套极简DOM模拟层但实测发现getComputedStyle在Worker里根本不可用这条路堵死了。最后的归并方案是把样式内联化代码在主线程跑但是分成小块异步执行每处理50个节点就让出时间片配合requestIdleCallback调度。加上async/await让出整个导出过程虽然慢一些但页面始终是可交互状态。这里我把真实的心得说出来追求极致性能前先想想用户是否真的感知得到比起后台2秒完成但页面白屏不如用3秒完成但用户可以继续编辑。5.3 部署到子路径时容易出现静态资源404这个项目部署到服务器子目录比如/tools/editor/时一开始图片和JS全部404。原因是我代码里写死了/assets/xxx.js这类绝对路径。改成相对路径./assets/也不完全可靠因为前端路由如果用了BrowserRouter二级路径下相对路径会解析错。最终方案是Vite配置里设置base: ./但把React Router切换成HashRouter。这样页面URL是/tools/editor/#/doc/123不管怎么刷新静态资源都能正确加载。虽然URL里多了个#不美观但部署鲁棒性比好看重要得多。5.4 自动保存服务的防抖与冲突处理在线排版工具一定要有自动保存不然用户改了半小时不小心关闭标签页直接劝退。我用了一个极简的自研保存方案编辑器的每次事务变更经过500ms防抖后把文档JSON发送给后端/api/drafts接口。同时为了处理多标签页打开的冲突文档元信息里保存了updatedAt时间戳保存端对比时间戳如果发现服务器版本比本地新就返回冲突标志前端弹层让用户选择以我的版本为准或下载服务器版本备份。这个方案没上OT和CRDT但对单人在线编辑场景足够了源码量也少了很多。6. 可扩展方向与后续准备做的新功能目前这个项目的版本已经跑通了写—排—导的完整链路但离一个真正强大的排版工具还有不少路要走。基于阅读社区反馈和用户使用习惯接下来要做的方向大概有这几个。6.1 协作编辑的轻量级实现虽然协作编辑很难但排版工具的协作需求不像在线文档那么重。大多数情况是我先写这段你下一步再改极少出现两个人同时拖拽同一个段落。所以我的计划是先做章节级锁就是文档分成若干块按H2触发分割一个用户正在编辑某块时其他用户看到的这一块是只读状态。这个实现成本远低于OT但已经能覆盖团队协作排版的主要场景。整套机制的实现预计要增加一个WebSocket服务端以及编辑器核心层的操作广播模块。6.2 智能模板引擎现在的模板还是静态JSON配置谈不上智能。我计划让模板能绑定动态数据例如生成周报模板时自动读取仓库的提交记录通过预定义的映射规则把提交信息填入周报段落。更进一步通过解析文章标题和上下文给关键句上色、给术语自动加链接做成一个小型规则引擎。这部分其实不涉及复杂的NLP用关键词加权和正则模式匹配就能适用大部分内容场景。6.3 AI辅助排版的探索很多用户已经习惯用AI生成内容那么排版工具完全可以做成AI生成内容的着陆页。具体设想是读取AI助手输出的Markdown原文自动根据主题风格套模板调整标题层级、重构段落长度分布、在高密度术语附近插入小标题。这些规则适合前端而不是后端完成可以实时看到效果再导出。我预感这个方向会把排版工具的使用习惯带入下一个阶段但目前还在做原型验证。7. 源码之外给同样想自研排版工具的你几句实在话项目做下来我最大的感受是排版工具的技术难点不在编辑器本身而在格式转换的语义保持。很多人会花大量时间在光标、选区、菜单这些细节上这些当然重要但真正能形成护城河的是你能不能把一套文档结构无损地从一个平台搬到另一个平台。初版设计时别急着做多平台先做好一个平台比如公众号跑通后再抽象扩展。第一个平台的导出逻辑可能会写得有点脏这是正常的第二个平台进来时你会知道哪些逻辑该抽出来共用哪些只能平台内处理。这种从具体到抽象的过程比一步到位设计更符合人类认知规律。另外千万不要把排版工具的重心放在花哨效果上。用户需要的是稳定、一致、可预期的输出不是你最新琢磨出来的渐变阴影。等我连上面那些扩展功能也做完会把整份源码再整理一遍到时候再和各位分享。本文还有配套的精品资源点击获取