一、微信编辑器为什么「吃样式」
公众号后台的编辑器不是富文本的天堂，而是一个白名单过滤器。它在你保存草稿的那一刻，会把不符合规则的东西全部剥掉：
<style> 标签：整块删除，你在里面写的规则一条都不剩。class 属性：删除。因为样式表已经不在了，class 指向的是空气。id、<script>、<iframe>、外部字体：一律删除，属于安全与性能的硬性限制。- 写在标签上的
style="..."：保留。这是唯一活下来的通道。
理解了这条，就理解了公众号排版的全部难点：你不是在设计网页，你是在为每一个元素手写内联样式。手工做这件事极其枯燥，这也是为什么值得用工具把主题一次性压平。
二、内联 style 是唯一解
一个能活着进公众号的段落长这样：
<p style="font-size:16px;line-height:1.85;margin:0 0 16px;color:#3f3f3f;">
正文内容
</p>
而一个会死掉的段落长这样：
<p class="article-body">正文内容</p>
两者的区别不在视觉效果，而在样式写在哪。因此判断一个排版工具能不能用，只需要看一件事：导出结果里每个标签是否都自带 style，以及是否残留 class。本站的公众号排版工具导出的是 0 个 class、每个元素都带内联样式，就是按这条标准做的。
三、字号、行距与段距的安全值
公众号正文宽度是百分比自适应的：手机约 375px，电脑端会摊到 677px。同一份排版在两端观感差别很大，安全区间如下：
| 元素 | 建议值 | 为什么 |
|---|
| 正文字号 | 15–16px | 小于 14px 在手机端费力，大于 17px 在电脑端显得幼稚 |
| 行高 | 1.8–2.0 | 电脑端一行可达 45 字，行高不够就会串行 |
| 段后距 | 14–20px | 小于 10px 段落粘连，大于 20px 显得松散 |
| 一级标题 | 20–22px | 超过 22px 在小屏会折成两三行，压垮节奏 |
| 二级标题 | 17–19px | 与正文至少差 2px，否则层级读不出来 |
| 字色 | 不用纯黑 | #3f3f3f 一类深灰在大面积正文里更耐读 |
新手最常见的错误是同时把字号调大、行距调小，结果手机端一行只剩 15 字却挤在一起。行长和行高必须一起考虑。
四、图片与封面的硬性规范
图片是公众号唯一「必须经过服务器」的元素，规则也最硬：
- 不能本地粘贴：粘贴本地图片不会自动上传，公众号只认素材库里的公网地址。先传素材库，再插入。
- 分享封面 1200×630（1.91:1），体积控制在 300KB 以内；信息流头图另有裁剪比例，关键文字放中央安全区。
- GIF 有体积上限，长图会被压缩到糊；需要长图时优先用多张分段图代替。
- 上传前先压：用图片压缩把体积压到位，再用裁剪与缩放统一宽度，能显著减少后台上传失败与加载缓慢。
五、引用块、提示框与表格
引用块（>）在公众号里是最容易做出层次感的元素。常见用法是把它当提示框：把 【!TIP】、【!WARNING】、【!DANGER】 写在引用行首，排版工具会换成不同配色的提示框，读者一眼能分辨「建议 / 注意 / 危险」。
三条经验：
- 提示框不要嵌套，也不要连着放三个以上，否则整篇都在喊话，等于没有重点。
- 引用块里的文字建议不超过 3 行，长了改用正文加粗。
- 表格列数控制在 4 列以内；Markdown 原生表格依赖
border-collapse 等属性，粘过去容易散架，必须转成带内联边框样式的表格。
六、表格和代码块为什么不再飘出屏幕
「手机上表格超出正文区」是公众号排版里最难自查的一类问题：你在电脑编辑器里看得整整齐齐，发到手机就飘出去。它有两层原因，得分开治。
- 平台那一层：微信编辑器把它收到的表格节点收进自己的表格模型，按粘贴那一刻的渲染宽度把列宽写成固定像素。真实已发布文章里能看到
width:577px 这种被烤进去的列宽——577px 落在 375px 的屏幕上必然溢出约 200px，而且与内容长短无关，纯中文、没有任何长串的表格一样飘。
- CSS 那一层：表格默认「自动布局」，
width:100% 只是一个希望值；单元格里只要有一个不换行的长串（网址、英文单词、代码），表格就会被顶到比容器更宽。pre 默认不换行，同理会被手机水平截断。
平台那一层在自己这边写什么样式都救不了，唯一的出路是别给它表格节点。做法是：编辑区照常用真表格（工具栏、撤销、联动定位都不受影响），只在复制或下载的那一刻把表格改写成 display:table 的结构——微信只重写表格标签，普通节点的内联样式原样保留。三条实现约束都是踩出来的：先把内联样式烤好再改写（顺序反了就补不上）、display 先摘后写（否则同一条声明出现两遍）、空单元格塞占位符（微信会清掉空节点，一行少一格整列就错位）。含合并单元格或嵌套的表格不做改写，原样交给微信。
CSS 那一层要做成不变量，不能做成主题选项：表格固定布局加最大宽度 100%、单元格允许断词、代码块允许换行，并且必须在主题样式合并全部完成之后补齐——写进任何一层都会被另一层挤掉，实测有 4 套主题覆盖单元格样式、4 套覆盖代码块。老草稿和手工粘进预览区的内容带着生成当时的样式，主题合并管不到，所以导出前再按标签补一次。
实测口径（2026-10-16）：20 套主题 × 320 / 375 / 414px 三档共 60 项测量，溢出 0px；把这几条不变量抽空后，同一测量立刻报出 333px，证明测试不是恒真；导出产物里真表格标签 0 个，微信官方结构检测器返回 isValid: true。
一个要提前知道的取舍：多列表格现在是等宽列，不再按内容比例分配宽度。手机上「不换行」和「按比例分列」没法同时成立——一旦宽度声明被平台丢掉，按比例那一套会重新撑破。
七、Markdown 转公众号：完整流程
- 用 Markdown 写内容：只关心结构——标题层级、列表、引用、表格、代码块，不要在源文里写任何样式。
- 选一套主题：字号、行距、配色、标题装饰一次定下来。同一账号固定一套，别每篇换风格。
- 图片先传素材库，在正文里用公网地址引用。
- 一键复制：导出时把主题压成内联样式，直接粘进公众号编辑器。
- 发到手机预览一遍再群发：编辑器预览不等于手机端效果。
八、长稿怎么两头对照
Markdown 转公众号最耗时的往往不是排版，而是改到中后段就找不到对应的源码：预览十几屏，源码也十几屏，两边行高还不一样。
- 按比例同步滚动解决不了：两边内容高度差得远，源码滚到 40% 处预览可能还在第二段，看着在动，其实对不上。
- 可靠做法是按块锚定：让每个渲染块记住自己来自源码第几行，点哪一段就定位到哪一段，两个方向都成立。
- 不要在打字时联动：预览每输入一个字符就重排一次，跟着滚会抖。只在点击时定位，才既准又安静。
- 定位标记不能进导出：它只是页面上的临时属性，粘给公众号前必须清干净，否则给平台留下改写的不确定性。
本站的 公众号排版工具 把这套做成了一个默认关闭的「联动定位」开关，放在 Markdown 输入栏的标题行——不打开就完全不影响原来的用法。
九、跑版排查清单
按命中率从高到低检查：
- 样式是不是写在 class 或
<style> 里 → 改成内联。
- 行高是否低于 1.7 → 电脑端会串行。
- 标题是否超过 22px → 小屏折行。
- 图片是否用了本地路径 → 显示空白。
- 表格是否超过 4 列 → 手机端挤散。
- 是否用了外部字体 → 公众号不支持，会回退默认字体。
公众号排版工具
Markdown 编辑即时预览 · 20 套主题 · 样式自动内联 · 纯浏览器本地处理
立即使用 →
1. Why the WeChat editor eats your styles
The WeChat MP editor is not a rich-text playground — it is an allow-list filter. The moment you save, it strips everything that fails its rules:
<style> blocks: deleted entirely. Not one rule survives.class attributes: deleted — and with the stylesheet gone, a class points at nothing.id, <script>, <iframe>, web fonts: all removed for security and performance reasons.style="..." on the tag itself: kept. This is the only channel that survives.
Once you get that, you understand the whole difficulty of WeChat typesetting: you are not designing a web page, you are hand-writing inline styles for every element. That is exactly why a tool worth using should flatten a theme for you in one click.
2. Inline style is the only answer
A paragraph that survives looks like this:
<p style="font-size:16px;line-height:1.85;margin:0 0 16px;color:#3f3f3f;">
body text
</p>
A paragraph that dies looks like this:
<p class="article-body">body text</p>
The difference is not visual — it is where the style lives. So to judge any formatting tool, check one thing only: does every tag in the export carry its own style, and is class gone? The WeChat formatter on this site exports zero classes and inline styles on every element, which is the standard it was built to.
3. Safe type sizes, line heights and spacing
WeChat body width is fluid: about 375px on a phone, up to 677px on desktop. The same layout reads very differently on each. Safe ranges:
| Element | Safe value | Why |
|---|
| Body size | 15–16px | Under 14px strains on phones; over 17px looks childish on desktop |
| Line height | 1.8–2.0 | Desktop lines reach 45 characters — anything tighter causes line drift |
| Paragraph gap | 14–20px | Below 10px paragraphs merge; above 20px the text feels loose |
| H1 | 20–22px | Over 22px wraps to two or three lines on small screens |
| H2 | 17–19px | Keep at least 2px above body size or the hierarchy disappears |
| Text colour | Not pure black | Dark grey such as #3f3f3f is easier on long runs |
The most common beginner mistake is raising the font size while shrinking the line height — a phone then shows 15 cramped characters per line. Line length and line height have to be decided together.
4. Hard rules for images and covers
Images are the one element that must go through a server, so the rules are strict:
- No pasting from disk: local images are not uploaded automatically, and WeChat only accepts addresses already in its media library. Upload first, then insert.
- Share cover 1200×630 (1.91:1), under 300KB. The feed thumbnail uses a different crop, so keep key text inside a central safe area.
- GIFs have a size ceiling and long screenshots get crushed; split them into several images instead.
- Optimise before uploading: compress with the image compressor and normalise width with the cropper to cut upload failures and slow loads.
5. Blockquotes, callouts and tables
The blockquote (>) is the easiest way to add hierarchy in WeChat. A common pattern is to treat it as a callout: write 【!TIP】, 【!WARNING】 or 【!DANGER】 at the start of the line and the tool swaps in matching colours, so readers instantly see advice versus warning versus danger.
- Do not nest callouts or stack more than three — if everything shouts, nothing is important.
- Keep callouts to three lines; longer thoughts belong in bold body text.
- Keep tables to four columns or fewer. Native Markdown tables rely on
border-collapse and fall apart on paste; convert them into tables with inline border styles.
6. Why tables and code blocks stopped sliding off the screen
"The table runs past the edge on my phone" is the hardest class of WeChat layout bug to catch yourself: it looks perfect in the desktop editor and spills off the small screen. There are two separate causes.
- The platform side: WeChat folds any table it receives into its own table model and re-bakes each column width into fixed pixels measured at the moment you paste. Published articles carry widths like
width:577px — on a 375px phone that is guaranteed to overflow, and it has nothing to do with how long your content is: a table of pure Chinese characters spills just the same.
- The CSS side: tables default to automatic layout, where
width:100% is only a wish. A single unbreakable run inside a cell — a URL, a long English word, code — pushes the table wider than its container. pre does not wrap by default and gets clipped horizontally for the same reason.
The platform side cannot be answered with CSS, so the only way out is not to hand it a table. The editor keeps using real tables (the toolbar, undo and link-panes all behave as before), and only at copy or download time the table is rewritten into display:table structures — WeChat rewrites table tags and leaves ordinary nodes alone, so the inline styles survive intact. Three implementation constraints, each learned the hard way: bake the inline styles first and rewrite second (the other order cannot fill them in), strip display before writing the new one (or the same declaration appears twice), and put a placeholder in empty cells (WeChat deletes empty nodes and one missing cell shifts the whole column). Tables with merged or nested cells are handed to WeChat untouched.
The CSS side is implemented as an invariant, not a theme option: fixed table layout with a 100% maximum width, breakable cells and wrapping code blocks, applied after the theme layers have been merged — put them in any layer and another layer pushes them out, and four of the twenty themes override cell styles while four override code blocks. Old drafts and content pasted straight into the preview carry the styles they were made with, so the same declarations are topped up per tag at export time.
What was measured (2026-10-16): 20 themes × 320 / 375 / 414px = 60 checks, 0px of overflow; drain those invariants and the same run immediately reports 333px, which proves the test can fail; the exported fragment contains 0 real table tags and the official WeChat structure checker returns isValid: true.
One trade-off to know in advance: multi-column tables now use equal column widths instead of widths proportional to content. On a phone you can have "never breaks the edge" or "proportional columns", not both — the proportional scheme overflows again the moment the platform drops the width declarations.
7. Markdown to WeChat: the full workflow
- Write in Markdown: structure only — headings, lists, quotes, tables, code. No styling in the source.
- Pick one theme: size, line height, palette and heading decoration in a single decision. Keep it consistent per account.
- Upload images to the media library first, then reference them by public URL.
- Copy in one click: the theme is flattened into inline styles on export.
- Preview on your phone before publishing: the editor preview is not the phone result.
8. Cross-referencing a long draft
What costs time in a Markdown-to-WeChat workflow is rarely the styling — it is losing the source line for the paragraph you are editing. The preview runs to a dozen screens, the source does too, and the two do not share a line height.
- Proportional scroll sync does not solve it: the two sides differ too much in height, so 40% down the source can still be the second paragraph in the preview. It moves, but it does not match.
- Anchoring by block does: remember which source line each rendered block came from, then clicking a paragraph lands on its line — in either direction.
- Do not sync while typing: the preview re-lays out on every keystroke, and following it produces jitter. Locating on click only is both accurate and calm.
- The locator must not ship: it is a transient page attribute. Strip it before pasting into WeChat, or you hand the platform another attribute to rewrite.
Our WeChat Article Formatter ships this as a Link panes switch in the Markdown title bar, off by default — leave it off and nothing about the current workflow changes.
9. Troubleshooting checklist
- Styles living in a class or
<style> block → move them inline.
- Line height under 1.7 → lines drift on desktop.
- Headings over 22px → they wrap on small screens.
- Local image paths → blank images.
- Tables over four columns → crushed on phones.
- Web fonts → unsupported, WeChat falls back to its default face.
WeChat Article Formatter
Live Markdown preview · 20 themes · styles inlined automatically · runs fully in your browser
Open the tool →