在 Markdown 模式下，输入：
A B
C D
选择 B 和 C，但不选择 A 和 D，然后点击“模糊预览”。
结果将如下所示：
A [spoiler]
B
C
[/spoiler] D
结果将不会被模糊处理。
A [spoiler]
BC
[/spoiler] D
现在请在富文本模式下再次尝试。从以下内容开始：
A B
C D
选择 B 和 C 并模糊处理。
段落分隔符将被删除，结果如下所示：
A BC D
如果切换回 Markdown 模式，结果将如下所示：
A [spoiler]BC[/spoiler] D
在这种情况下，考虑到“spoiler”不能同时是行内和块状，您会期望什么结果？
我认为“Spoiler”不能同时是内联和块级元素的想法是 CSS 的一个事实，用户不必了解这一点。
考虑加粗。您今天可以在 Discourse bbcode 中这样写：
A [b]B
C[/b] D
或者您可以用 HTML 这样写：
<!DOCTYPE html>
<html>
<body>
<p>A <strong>B</p>
<p>C</strong> D</p>
</body>
</html>
它的渲染效果正如您所期望的那样：
A B
C D
但 DOM 表示看起来是这样的：
<p>A <strong>B</strong></p>
<strong> </strong>
<p><strong>C</strong> D</p>
HTML 规范要求对多块超链接做类似的事情。如果您在 HTML 中这样写：
<!DOCTYPE html>
<html>
<body>
<p>A <a href="https://example.com.">B</p>
<p>C</a> D</p>
</body>
</html>
HTML 规范要求 DOM 表示看起来是这样的，有 三个 超链接：
<body>
<p>A <a href="https://example.com.">B</a>
</p><a href="https://example.com."> </a>
<p><a href="https://example.com.">C</a> D</p>
</body>
您可以想象以类似的方式渲染多段内联 Spoiler：
<p>A <spoiler>B</spoiler></p>
<p><spoiler>C</spoiler> D</p>
但 Spoiler 与加粗不同，因为 Spoiler 是 交互式 的。当您单击 Spoiler 的 B 部分时，它应该会显示 Spoiler 的 B 和 C 部分；它应该看起来和感觉像“一个 Spoiler”。
我认为处理此问题的方法是在 DOM 表示中支持链接的 Spoiler。也许 <spoiler> 会有一个像 name 这样的属性，当您单击一个 Spoiler 时，它会显示所有具有相同名称的 Spoiler。（这应该通过属性、属性还是其他链接这三个 Spoiler 的系统来完成？我不知道，随便您怎么做。）
所以，假设您有这样的 Markdown：
A B
C
D E
[spoiler]F[/spoiler]
然后您选择 B、C 和 D 并将它们模糊化。
Markdown 看起来会是这样的：
A [spoiler]B
C
D[/spoiler] E
[spoiler]F[/spoiler]
生成的 DOM 会是这样的：
<p>A <inline-spoiler name="x">B</inline-spoiler></p>
<block-spoiler name="x"><p>C</p></block-spoiler>
<p><inline-spoiler name="x">D</inline-spoiler> E</p>
<block-spoiler name="y"><p>F</p></block-spoiler>
在 JS 中，当您单击这三个 Spoiler 中的任何一个时，所有具有相同“name”属性的 Spoiler 都会一起显示出来。
因此，从最终用户的角度来看，它会 感觉 像是可以混合搭配内联和块级 Spoiler。
我已经将此内容从 Bug 移动到 Feature，因为我们目前正在探索的功能不受支持。
@dfabulich 您能否分享一下您希望支持的用例？这将帮助我们了解如何最好地解决问题。您能否告诉我们支持这种内联+块式剧透对您的社区有何帮助，或者它们何时会出现？
我认为将此归类为“功能”是错误的。
我可以想象说“这个错误太难修复了；不值得优先处理它”。
但我认为没有人会为当前的行为辩护是_正确的_。
至于你的问题，实际上不可能为修复错误提供“用例”。功能才有其用例（模糊剧透：用户希望模糊剧透，以便他们可以讨论媒体而不会破坏惊喜），但错误存在于功能内部。修复错误是功能实现其用例的方式。
如果我将此问题视为“错误”，并承认实施我提出的解决方案可能成本高昂，那么我能回答你“用例”问题的最接近的方式是回答另一个问题：
“为什么这个错误很重要？承认当前行为不正确，谁会在乎你无法模糊多段文本中的内联文本？你真的_需要_这样做吗？”
对此，我认为我会说：当前的体验令人困惑，并且破坏了用户对 Discourse 的信任。当你选择一些文本并单击“模糊剧透”但它根本_不_模糊你选择的文本时，这对所有相关人员来说都令人尴尬。
老实说，当用户尝试剧透两段文本的一部分时，显示错误消息，告知用户问题的性质，这比当前行为要好一些。错误消息可以这样说：“在 Discourse 中，你可以剧透一段文本的一部分，或者你可以剧透一个或多个完整的段落，但你不能创建一个包含两段或更多段落部分的剧透。”
但现在想象一下，你必须为粗体文本或斜体文本显示这样的错误？
这就说明了剧透对我来说为什么重要：我运营的论坛（以及我参与的其他 Discourse 论坛）是游戏玩家论坛，在那里讨论媒体，尤其是讨论不破坏谜题解决方案的媒体，是一件非常重要的事情。
我能理解为什么有人会说“剧透模糊不如粗体文本重要。我们将通过创建多个粗体文本部分来修复粗体文本的错误，但对于剧透模糊，我们有更重要的事情要做；让我们暂时不修复剧透错误。我们不太关心剧透。用户会找到解决办法。”
但对我、我的论坛以及我生活的论坛来说，剧透模糊比粗体文本更重要。这就是为什么我一直在关注这些剧透模糊错误！
“用例”是什么？用例是：我们使用剧透来讨论媒体而不破坏惊喜。因此，模糊剧透功能应该正常工作，并且正确工作，以满足这一需求。
就我而言，我认为这里有一个 bug 和一个功能。我们可以在语义上达成一致，但我想解释一下我们是如何看待这个问题的，以便您了解接下来会发生什么，考虑到 spoiler 对您和您的社区有多么重要。
bug 是，当您尝试在 rich text 模式下跨块应用内联 spoiler 时，段落分隔符会被移除（在 rich text 模式下），而在 Markdown 模式下会被添加：
Rich text：
Markdown：
我同意这并不是一种愉快的体验。我们可以修复这个 bug，但其结果将是：
功能请求是支持一个可以内联开始并跨越多个块的单独 spoiler，然后只需单击一次即可显示。这并不是 spoiler 的设计方式。
我之所以询问您的用例，是为了帮助修复 bug 并了解该功能的重要性。我们通常看到 spoiler 要么是内联的，要么是块状的，所以我想知道是否有特定的情况会用到内联+块状 spoiler。这有助于我们更好地了解您如何使用 Discourse，并了解解决此问题将如何帮助您（以及那些在您在此分享的内容中认同自己社区需求的人）。
鉴于这两个选项，我认为我会选择“单个隐藏内容，但选定的内容将被强制放入自己的块中。”
我无法给出基于用例的理由；我认为强制块行为仍然会有错误。
但强制块选项给我的感觉“错误更少”，因为它“只”影响隐藏内容的外观：在隐藏内容的开头和结尾添加额外的换行符。
多个未链接的隐藏内容会影响隐藏内容的运作方式。读者需要点击多达三次才能显示整个隐藏内容：一次是开头的内联隐藏内容，然后是 N 个块隐藏内容，最后是结尾的内联隐藏内容。
使用强制块隐藏内容，它就变成了一个外观上的硬性错误，也许没有人会去修复它。
这个表述对我来说是有意义的：
我们会着手解决这个问题；我目前无法提供预计完成时间，但一旦解决，我会在此更新。