大三的时候上过一门面向对象的课程，期末要做个小项目，要尽可能使用面向对象的思想，不限制编程语言。
当时的我正在为即将到来的秋招做准备，便借此机会做了一个简单的 Canvas 绘图工具，可以添加一些基础形状（矩形、菱形、圆形、椭圆、三角形等）、文本框、画笔工具，工具栏 UI 照着 Figma 做的。
当时需要实现点击选中元素功能，我是通过遍历所有元素，计算点击位置是否在元素的区域内来实现的。如果有多个元素重叠，就比较头疼，需要再额外处理一下层级。
时隔 4 年，我又一次接触这类 Canvas 应用，看到了其他人对这个问题的一种非常完美的解决思路：
原始 Canvas 称为 c1，新增一个与其完全一致的 c2，每个元素在触发 draw 方法时，不仅在 c1 上进行绘制，还要在 c2 上绘制自己的包络区域，用一种随机的 rgb 值作为颜色值。并存储这样的（元素, color）键值对。
当触发点击时，先获取点击坐标在 c2 上的色值，再通过色值直接拿到对应的元素。这种做法也可以很好地处理多个元素重叠的层级问题。
非常妙。
这种做法叫做「像素标记法」。
业务场景：点击 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 上试一试。
新项目代码结构分了两层：内层是 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 时有一些不是很常见、明确的错误用法，需要进一步看看。
同样的问题，这是第二次遇到。
上次遇到时，没有太关注，就简单处理了一下，果然第二次再遇到就完全没印象，排查问题浪费了很多时间。
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 呢？
人家是真自由，想怎么配怎么配。
距离上一条想法才没几天，又有新的问题出现了。
在 markdown 的列表语法中，如果有一个 listItem 仅仅包含一个 html 标签，并且不是那种常见的 inline 格式（比如 span），那么它会被认为是一个块级 html，同时该层级 listItem 内的子节点（即下一层级列表）将全部被当做 html 的一部分。
同样又是查了一圈，这也是 CommonMark 标准里面的，属于是让人很无语。
今天又发现了一个 markdown 渲染上的 bug。
加粗的语法是前后各两个星号，如果结尾的两个星号前有一个中文标点符号，比如。\*\*」，且后面紧跟着其他文字，那么就渲染不出来加粗格式了。
查了一圈的结论是：在 CommonMark 标准中，中文标点符号不是合法的 word character，当它和星号放在一起时，将不能作为加粗格式的闭合标签。
前端很常用的两个工具 remarkjs 和 markdown-it，都遵循这个标准。所以几乎所有大模型对话产品都能复现这个问题，比如豆包和 ChatGPT。
解决办法有两种：
第一种是自行实现 remarkjs/mdit 的插件去做预处理/后处理，或者干脆选择一种不那么遵守标准的工具，如 marked.js。
第二种方法是我从腾讯元宝学到的。你还别说，腾讯元宝作为国内对话产品中的「后辈」，居然对这种魔鬼细节都有处理到，给他们的测试团队点个赞。
它是这么做的：由前端处理，将大模型输出的 markdown 数据中所有的星号星号前后各添加一个零宽空格，既不影响展示，又满足了 CommonMark 的闭合要求，非常完美。
不得不说，markdown 转 html 的坑实在是太多了，尽管本身语法并不多，但依然存在大量的细节，你不踩坑就不知道。
比如一个段落结尾处有两个空格，它表示的意思是换行，在 mdast 中对应了一个 break 节点。
很多时候只能 case by case 去解了。
Quill 编辑器的实例很重要，对内容的各种操作、事件监听都需要直接调用实例上的方法，它是一个层级很深、非常复杂的 js 对象（下面都以 quill 称）。
当在 Vue3 项目中使用 quill 时，可能随手就将它放进了 ref 里，默认会被深层代理。这里就会出大问题。
如果直接通过代理的方式访问 quill 上的任何方法时，浏览器可能会报错（找不到 blot 上的 offset），不仅操作不会生效，而且后续会一直报错，出现键盘操作无响应、注册的事件不触发、显示内容与 delta 数据不一致等等各种问题，几乎就是彻底崩溃了。
猜测原因是 Vue Proxy 数据代理机制会对这种第三方的非响应式的对象产生影响。
解决办法就是不对它进行代理：
// 1、不使用 vue ref
let quill = null
onMounted(() => {
quill = new Quill({})
})
// 2、用 markRaw 标记 quill 实例
const quill = ref(null)
onMounted(() => {
quill.value = markRaw(new Quill({}))
})Vue 文档中有关于 markRaw 的详细介绍，里面专门提到了「有些值不应该是响应式的，例如复杂的第三方类实例或 Vue 组件对象」，可参考：markRaw。
浏览器默认有这样一个行为：当用户双击一段文本时，会选中单词（中文有分词处理），当三击时，会选中整段文本。
这个「选中整段文本」的行为所产生的浏览器选区 Selection 对象上，extendNode、focusNode 是当前块级文本的下一行的节点。
而如果用户通过手动拖拽行为，从段落开头框选到段落结尾，这时产生的选区对象上，上述的两个字段是当前块级文本的末尾节点。
对比这两种操作，用户看到的选区是一样的，实际生成的选区对象却是不同的，从编辑器框架的角度看，前者的 range 似乎比后者多了 1。
这就会造成很多问题，如果在此时进行插入带格式文本的操作，就会有意料之外的效果。
那么如何解决这个问题？
unhang 的格式化处理，在其中重新计算了选区结尾节点，参考 Slate 源码。关于它，也有一些比较有趣的社区讨论。