排版插件开发手记2:我把一个收费插件拆开,定下了3条规矩,看清它怎么做之后,我给自己划了3条不能越的线

一 · 起因：一个收费的功能，和一个不服气的工程师

第 1 篇讲了结果：374 KB，11 个版本，每一个都被真机打回来。

这篇讲开头——我为什么要把一个收费插件拆开。

我写公众号，习惯先在 Markdown 里写完，再往编辑器里搬。搬的过程一直是痛的：标题层级、行距、引用块、代码块高亮、图片圆角，在 Markdown 里是一套，粘进公众号是另一套。

试过三种办法。手动调，一篇三千字要四十分钟；用第三方排版工具，中间多一道，模板是它的不是我的；装插件——市面上某排版插件能把 HTML 直接导进公众号，效果也不错，但这项功能收费。

我不是不愿意付费。我是不甘心：把一份带排版的 HTML 送进编辑器，这件事的技术难度，真的值一个订阅价吗？

答案是「拆开看」。

二 · 拆包：先看清它到底怎么做的

crx 是 zip 套了一层头。这里有个坑：偏移 8 到 12 那四个字节是 header 长度，不是签名长度。我第一次按签名长度跳，跳进了压缩数据中间，解出来一堆乱码。

那个 crx 约 13 MB。解开之后是约 2300 个文件、约 41 MB。最大的几段脚本分别是主编辑逻辑约 8 MB、侧栏面板约 2 MB、内容注入约 2 MB。全部是 esbuild / webpack 的产物，没有一个 .map。

（注：以上体量为本系列统一使用的虚构示例值，不对应任何真实产品。）

读它的排版实现，读出一个让我意外的结论：它根本不做样式内联。

它信任用户给的 inline style。用户从别处复制来的 HTML，如果每个元素都带着 style=""，它就原样送进编辑器；如果样式写在 <style> 块里，它不做合并，直接当脏标签删掉。

这解释了一件事：为什么很多人用这类插件，从某些网页复制的内容排版很好，从另一些复制就一塌糊涂。差别不在插件，在源文件有没有 inline style。

还有一处：它的 matches 里写着 *://*/*。意思是打开任何网页，都会加载那个约 8 MB 的主包。这是「采集任意文章」的代价，也是它常被吐槽「卡」的原因。

我要的东西不一样。给我一份带 <style> 的完整 HTML，我自己算层叠。

这也回答了开头的疑问：它收费的那项功能，核心价值不在「送进去」（那有现成接口），而在「送进去之前帮你把样式理清楚」——而这件事，它其实没做。

三 · 定下的三条规矩

拆完，我做了一件比拆更重要的事：把「什么能做、什么不能做」写成了三条规矩。后面七篇，都是这三条的注脚。

第一条说清楚边界。我能从浏览器开发者工具里看到它怎么调编辑器的写入接口——那是公开可见的行为，可以学、可以照着对齐。但源码是别人的，一行不碰。复刻的是「能力」，不是「代码」。

第二条是立场。文章是用户的内容，不该为了一个排版功能再上传一次。本地能算的，就在本地算完。

第三条后来成了整个项目真正的难点，也是最重要的。前两条是功能，第三条是可用性。而大多数工具死在第三条上：它们能跑，但你不知道它跑成了什么。第 1 篇里那个「七行计数日志」，就是这条规矩长出来的果子。

现在回头看，第三条才是这个项目真正的分水岭。前两条让我做出来，第三条让我做得「可信」。

四 · 规矩怎么落地成后面的文章

三条规矩不是口号，它们直接决定了后面每一篇写什么。

规矩一要求「自己算层叠」——那就必须先解决「怎么把一份文档读进来」。Markdown、Word、HTML 三种源，先归一，这是第 3 篇。

读进来了，还要算对。为什么「算样式」会算成浏览器默认值、可继承属性为什么不能省，这是第 4 篇。

算对了，还要送得进去。隔离世界、四级链路，这是第 5 篇。

送进去了，还要说清哪一步不对。七行日志、三态判据，这是第 6 篇。

最后，让这一切能稳定交付。白名单打包、密钥不入包、逐字节可复现，这是第 7 篇。以及诚实地说清没验过的边界，这是第 8 篇。

这一篇的规矩，是后面七篇的基石。

最后

拆一个收费插件，听起来有点「野」。但我拆完之后做的第一件事，是给自己划了三条线——哪些能学，哪些不能碰，以及最重要的：出了问题必须能说清。

下一篇，从第一条规矩的能力部分说起：三种文档，我是怎么用一条流水线吃掉的。