第一部分是文字，第二部分是卡片链接，第三部分是文字的情况下如果拖动卡片调整大小会导致错位。
Hello
第一次遇到，有意思。只有这个卡片会吗，其他的卡片有类似的情况吗。
Kind Regards,
Support Team
我的设备是iPad，每个卡片都是这样，只要卡片评论区出现了文字-卡片链接-文字这种结构就会出现错位
我的文字是开了markdown输入的
刚刚再看了一下卡片链接必须是图像摘录（矩形或者套索），一旦有两段文字夹着卡片链接，中间卡片链接显示的图像尺寸就会出问题
Hello
感谢你的反馈，我们已经注意到了相关问题，会进行进一步的处理。如果后续还有什么问题，可以继续提出或者私信我。
Kind Regards,
Support Team
1 个赞
为啥这些显而易见的问题内部开发者都不知道呢？
这是个很常用的功能啊？感觉开发者都没有很认真地测试MR4
找到解决方案了。在粘贴卡片的URL时以纯文本形式粘贴就不会出现问题。一旦使用 markdown 格式粘贴URL就会出现问题。或者直接使用那个拖拽进行链接的功能也可以（猜测是因为这样是纯文本形式粘贴URL）。但是还是希望能够尽量修复，因为平时都是打开markdown打字的，来回切换很麻烦。我问了一下 ai 是什么原因，希望能够有帮助：
针对 MarginNote 4 中 Markdown 内嵌卡片链接渲染问题的分析
核心问题在于，当 MarginNote 4 的用户在 Markdown 格式的笔记中，将一个**“卡片链接”（MarginNote 的一种特殊对象）**以行间形式（例如：“文本A - [卡片链接] - 文本B”）嵌入时，在调整包含该笔记的父卡片大小时，该卡片链接的预览图像会与周围的文本A和文本B发生重叠和错位。
关键的对比信息是：使用标准的 Markdown 语法插入普通图片 (例如  或 ) 时，即使图片与文本在同一行，调整父卡片大小时，这类标准图片通常能正确地随文本流重排，并不会出现上述的重叠或错位问题。
基于此对比，可以进行如下分析：
-
Markdown 引擎对标准图像的处理是正常的： MarginNote 4 的 Markdown 渲染引擎在处理其原生支持的标准图像元素（如通过
![]()插入的图片）时，其布局、重排（reflow）和尺寸调整逻辑是基本健全的。这表明问题并非出在 Markdown 引擎的基础图像渲染能力上。 -
问题聚焦于“卡片链接”这一特殊对象的集成方式：
- “卡片链接”的特殊性： 与标准静态图片不同，“卡片链接”是 MarginNote 应用程序特有的一个功能性对象。它可能包含动态生成的预览、交互行为（如点击跳转）等，其渲染和行为由 MarginNote 的自定义代码控制。
- 自定义渲染与 Markdown 文本流的协调缺陷： 当这个自定义的“卡片链接”对象被指示要作为 Markdown 文本流的一部分（即行内元素）进行渲染时，挑战在于其自身的尺寸、定位逻辑需要与 Markdown 引擎对周围文本的布局逻辑精确同步。
- 渲染冲突点： 在父卡片尺寸发生变化时，Markdown 引擎会重新计算文本流的布局。与此同时，“卡片链接”的预览图像可能也需要调整其尺寸或位置。这里的 Bug 很可能发生在：
- “卡片链接”预览对象未能正确获取其在变化后的 Markdown 文本流中的应有空间和位置。
- 或者，“卡片链接”预览对象在更新自身尺寸后，未能有效地通知 Markdown 引擎，以便 Markdown 引擎能正确地重排其周围的文本。
- 简而言之，是 MarginNote 自定义的“卡片链接”渲染逻辑与其 Markdown 文本渲染环境在动态布局更新时的“沟通”或“协调”上出现了问题。
-
为何标准 Markdown 图片没问题： 标准 Markdown 图片的渲染路径通常更为直接和成熟。Markdown 解析器将其识别为图像后，会按照既定的规则（如HTML中的
<img>标签类似的行为）进行处理，其尺寸和与文本的相对关系在重排时有明确的规范。而“卡片链接”作为一个外部注入的、具有复杂行为的对象，其与 Markdown 文本流的融合显然更为复杂。
结论：
此渲染 Bug 并非 MarginNote 4 Markdown 功能的普遍缺陷，也不是其处理标准图像内容的问题。它更精确地指向一个特定的集成问题：即 MarginNote 自身特有的**“卡片链接”对象**，在被用作内联元素嵌入到 Markdown 格式的文本中时，其动态布局调整（尤其是在响应父容器尺寸变化时）与周围 Markdown 文本的重排机制之间存在冲突或协调缺陷。