碎记

• 14. Word 的文字行高是如何计算的

  发布于：2026/06/08

  在 OOXML 里有一个段落属性标签 Spacing，该标签上有 lineRule、line 这两个常用的属性，它俩会直接影响文字的行高。

  lineRule 可以是 exact（精确值）、atLeast（最小值）、auto（自动），前两个比较好理解，auto 的规则不是很明确。

  当 lineRule 为 auto 时，line 中的数值除以 240 表示多倍行距的倍率，比如值为 240 对应的就是单倍行距，值为 360 对应的就是 1.5 倍行距。

  核心问题在于，这个多倍的基数是什么？或者说单倍行距到底是多高呢？

  在 OOXML 规范中，关于这一点并不是很明确，行高的计算有很多复杂的逻辑，WPS 实现的效果也难以做到和 Office Word 完全一致。

  简单来讲，它应该是根据当前 run 文字的字体、字重、字号等属性测量出来的文字行高，对于 CJK 文字，可能会额外乘以一个 extendScale，通常为 1.3。除此之外，还有大量优化细节的逻辑，等后续我对此有更深理解之后再单独展开讲讲。

  这里讲一种特殊场景，此场景下的行高规则稍微简单一些，那就是对齐文档网格。

  文档网格整体概念比较简单，包含了行网格和字符网格，段落可以设置对齐行网格属性，run 也可以设置对齐文字网格属性。

  当一个文档节中设置了行网格，并且段落也开启了对齐网格（默认开启）时，实际文字的行高应该是「文字轮廓行高向上对齐整数个网格线」与「多倍行距（多倍网格线）」中的较大值。

  多倍行距这个属性，在对齐网格的场景下，基准将变成单个网格线行高。这一点并不是 OOXML 规范内的要求，而是我通过测试一些 Office Word 实际渲染效果后猜测出来的规则。

  实际测试了金山文档、石墨文档、腾讯文档，自由组合对齐网格、段落间距、段前段后、字号等属性，均符合这条规则。

  不过也发现，各家的 Word 编辑器行内文字在垂直方向上的基线对齐方式存在一些差异，后面有时间再进一步了解吧。

• 13. 关于中文排版中的 autoSpace

  发布于：2026/05/27

  多年前接触到中文文案排版指北这个项目，它包含了一些约定的中文排版规则。按照这套逻辑，文字排版效果会更舒服，很多网站、公众号文章都遵守这些规则，甚至绝大多数的大模型都遵守这个约定，输出的内容总是包含这些空格。

  其中有两条规则分别是「中英文之间需要增加空格」和「中文与数字之间需要增加空格」。

  最近刚好做了一些和中文排版相关的需求，对这方面有了更多的了解。

  这两条规则，实际对应了 Office Open XML 中的两种段落属性，分别是 autoSpaceDE 和 autoSpaceDN，D 指的是 Document，E 指的是 EastAsia 东亚文字，N 指的是 Number。

  按照 OOXML 的规范要求，这个属性默认是开启的，所以其实并不需要人类手动添加空格，这应该是各端的排版引擎去做的事情。

  除此之外，还有四种关系密切的段落属性：kinsoku（按中文习惯控制首尾字符）、wordWrap（允许西文在单词中间换行）、overflowPunct（允许标点溢出边界）、topLinePunct（允许行首标点压缩），它们相互影响，组合起来会有各种各样的效果。

  我早已养成了随手打空格的习惯，当然微信输入法也内置了自动加空格的逻辑，这是因为依然有大量的端软件没有做这种自动空格的适配。

  比如 text-autospace 这个 CSS 属性也是刚刚出现不久，远远没有达到可以生产使用的状态。

• 12. 缓存可能会导致图片访问跨域

  发布于：2026/05/14

  这是一个小众知识点。

  我被它坑过一次，排查很久才找到原因，最近第二次遇到，于是很快联想到之前的问题。

  描述一下这个 case：

  服务端：现在有一个图片资源服务器，首先它允许缓存，然后它的跨域访问逻辑是这样的：假如前端请求时添加 crossorigin 属性，那将会返回允许跨域访问的返回头。假如未添加，则不返回允许跨域访问的返回头。

  前端：第一次通过普通 img 标签加载这个图片资源，不添加 crossorigin 属性，可正常渲染。第二次是需要将它绘制在 canvas 上并截图导出，此处需要添加 crossorigin 避免画布污染问题。

  那么这个第二次一定失败，并报跨域访问错误。

  原因是第一次的普通 img 渲染会产生一个不带有允许跨域访问返回头的图片资源，第二次访问同一个图片链接，即使你加了 crossorigin 属性，仍然会命中第一次那个缓存资源，返回头也是缓存的一部分。

  解决办法有哪些呢？

  1、资源服务器直接设置 no-cache，永远不走缓存。最省事儿，但是不太好。

  2、前端在第一次的普通 img 渲染时，就加上 crossorigin 属性，这样即使有缓存 也是一个允许跨域访问的缓存。这样可解决，但是也不完美。万一图片是通过 background image 加载的，那么此方案就行不通，因为根本不可能设置 crossorigin。

  3、通过时间戳绕开缓存，比如第二次绘制时，在图片资源链接后面加一个&t=1之类的，通过改变 url 来绕开缓存。这种做法比第一种好一些，但是前提是这个图片资源服务器没有对链接强校验的逻辑。

  三种方案都有缺点，都不完美，暂时没有更合适的解法。

• 11. 关于我换了 4k 显示器导致上线了一个 bug

  发布于：2025/12/30

  之前一直使用公司发的 1080P 瞎眼屏，实在是受不了，自费买了红米的 a27u Type-C 版。完美，它简直就是 MacBook 的绝配。

  在查看显示器分辨率时，我发现自动设置的是「1920x1080（默认）」，当手动调整至「3840x2160」之后，所有 UI 都变得非常小，文字反而小到没法看了。

  这是因为设备的 devicePixelRatio，以下简称 dpr。

  Mac 的屏幕自称「视网膜显示器」，在网页缩放比例为 100% 的情况下，它的 dpr 值是 2，表示它在单个方向上使用 2 个物理像素点渲染 1 个网页 css 像素。

  而其他普通显示器的 dpr 通常为 1。

  使用「1920x1080（默认）」，并不能显示出更多的内容，但是肉眼看会非常清晰。

  说回正题。

  正因为我使用了这台与 MacBook 屏幕表现一致（指 dpr 值都为 2）的显示器，所以在开发一个新的需求时，没有发现 dpr 发生变化时 Canvas 变模糊的问题。

  当把一个网页从低倍率（dpr为 1）显示器拖动到高倍率（dpr 为 2）的显示器上时，假如上面的 Canvas 绘制逻辑未做适配，没有重绘，则会发现上面的文字、图片都会变模糊。

  基于 Canvas 的富文本编辑器通常会设计一套自己的缩放系统，它不仅要考虑自身的缩放功能、设备的 dpr 变化，还要考虑网页浏览器的缩放功能。这里后续我会单独写篇文章介绍如何设计。

  关于这个 bug，我通过媒体查询实现了对 dpr 变化的监听逻辑，dpr 变化时，对整个 Canvas 的缩放比例进行一次校正和重绘。所有文字绘制时，字体大小的计算应该包含一个当前 dpr 的比例系数。

• 10. 关于如何在 canvas 上选中一个元素

  发布于：2025/08/05

  大三的时候上过一门面向对象的课程，期末要做个小项目，要尽可能使用面向对象的思想，不限制编程语言。

  当时的我正在为即将到来的秋招做准备，便借此机会做了一个简单的 Canvas 绘图工具，可以添加一些基础形状（矩形、菱形、圆形、椭圆、三角形等）、文本框、画笔工具，工具栏 UI 照着 Figma 做的。

  当时需要实现点击选中元素功能，我是通过遍历所有元素，计算点击位置是否在元素的区域内来实现的。如果有多个元素重叠，就比较头疼，需要再额外处理一下层级。

  时隔 4 年，我又一次接触这类 Canvas 应用，看到了其他人对这个问题的一种非常完美的解决思路：

  原始 Canvas 称为 c1，新增一个与其完全一致的 c2，每个元素在触发 draw 方法时，不仅在 c1 上进行绘制，还要在 c2 上绘制自己的包络区域，用一种随机的 rgb 值作为颜色值。并存储这样的（元素, color）键值对。

  当触发点击时，先获取点击坐标在 c2 上的色值，再通过色值直接拿到对应的元素。这种做法也可以很好地处理多个元素重叠的层级问题。

  非常妙。

  这种做法叫做「像素标记法」。

• 9. 移动端软键盘真的折磨人

  发布于：2025/07/04

  业务场景：点击 quill 中的图片元素，展示图片编辑框（有裁剪、修改尺寸之类的功能），但同时会唤起软键盘，产品诉求不希望唤起。

  原因分析：quill 容器是 contenteditable=true 的元素，图片元素在该元素内部，只要图片触发 touch 动作，事件冒泡到 quill 容器，就会触发 focus 事件，进而唤起软键盘。

  尝试了一些方案，比如 click 事件中 prevent/stop/capture，各种组合都不行。 后来发现在 touchstart 时 prevent + stop 可以避免 quill 发生 focus，但是同时连该区域的页面滑动都阻止了，并不合适。

  硬控我一整天，才找到一个解决方案： 在 touchstart 时将 quill 禁用（contenteditable=false），并在 touchcancel/end 时延迟一段时间（比如 200ms）再激活 quill。

  只读的容器，不可 focus，软键盘想弹都没机会。

  这个方案实际只是凑合，很不优雅。

  调研了其他产品在移动端网页上的体验，只发现了金山文档可以做到点击图片不唤起软键盘。

  它是基于 ProseMirror 的，但是 ProseMirror 自己做不到，金山文档重新设计了光标选区和输入逻辑，并未将整个容器设置为 contenteditable=true，而是创建了一个虚拟输入框（一个 contenteditable=plaintext-only 元素）专门接收输入，位置放在光标处，整个页面除了它，用户随便点，都不会触发 focus，所有 focus 行为都由开发者控制。

  它这种做法，有点像 canvas 编辑器上的输入方案，但是竟然挪到了 dom 的编辑器上用。确实有点东西的。

  我打算在 quill 上试一试。

• 8. 又一次被 Pinia 坑

  发布于：2025/06/20

  新项目代码结构分了两层：内层是 SDK 层，包含部分 Vue 组件，使用了 pinia，不含任何业务逻辑；外层是业务层，包含 UI 和业务逻辑，也使用相同版本的 Vue 和 Pinia。

  测试时发现业务层挂了，SDK 层 store 中数据的响应式有问题，修改了 store 中的数据，组件不刷新。销毁 Vue 组件再重新 mount，就正常了，但是再操作几次就又会坏掉。

  排查了好几天，二分删代码法 debug，终于在注释掉业务层的 use(pinia) 后正常了。

  尝试在业务层和 SDK 层使用相同 Pinia 版本，有问题；使用不同版本，正常。 解决方案是在 SDK 层的构建配置 external 中不设置 Pinia，即 SDK 层打包时把 Pinia 打进去。

  目前也没有搞懂这其中的本质原因，两个层级各自定义的 store 也不重名，但是只要使用同一个 pinia 实例，就会间歇丢失响应式。

  怀疑是 SDK 层在使用 Pinia 时有一些不是很常见、明确的错误用法，需要进一步看看。

  同样的问题，这是第二次遇到。

  上次遇到时，没有太关注，就简单处理了一下，果然第二次再遇到就完全没印象，排查问题浪费了很多时间。

• 7. 吐槽一下 remarkjs

  发布于：2025/04/25

  remarkjs 是一个将 markdown 转换为语法树进而转换为 html 的工具，它遵循 CommonMark 的标准，是最小集，比如很常用的表格格式就不在里面。

  GFM（GitHub Flavored Markdown），是 GitHub 在 Markdown 基础上扩展的一些新格式，它包含了删除线、任务列表、表格、自动链接等等。

  所以出现了一个 remark-gfm 的插件来实现这些格式，它几乎是使用 remarkjs 时的必装插件。

  然而实际使用中，我发现 GFM 中的「自动链接」不是一个好的逻辑，它会把一切疑似链接的纯文本都解析为 link，在链接与中英文标点符号混用时，解析错乱的概率非常大。

  第一时间想到的就是只禁用「自动链接」功能，这时我才发现，remark-gfm 这个插件，并没有提供这种配置项，即要么都启用，要么就别用。

  于是火速赶往它的开源仓库，打算提交代码成为 contributor，翻了 issue 后发现，有人提过这个问题，但维护者的态度是：不做，也不接收 PR，建议想做的自己 fork。理由是希望统一而不要有差异化。

  心凉了，道理我都懂，但是测试真的会给我提 bug。

  尝试自己封装插件，只把自己需要的格式引入，由于 remarkjs 拆分的粒度比较细，从一个包依赖变成了 7 个包依赖，锁死版本。业务项目实在不适合这样搞。

  题外话，remarkjs 早早地就拥抱了 esm only，而且跨大版本升级时，搞出了类似 eslint 那种级别的破坏性变更，属实是让我痛苦了很久。

  我都开始后悔，当初为什么不选择 markdown-it 呢？

  人家是真自由，想怎么配怎么配。