求助 | 标注块内嵌代码块出现源码模式和阅读模式显示不一致,是语法问题还是软件问题呢

我在写笔记的时候发现标注块内嵌代码块的时候会出现源码模式和阅读模式下显示不一致的情况,想请教是语法问题还是软件的问题呢?


遇到的问题

(新用户只能传一张图片)
左图为源码状态,中间图为实时预览状态,右图为阅读状态。

如左图源码模式所示,在源码模式下查看,从275行开始开头的 > 就被软件标识为纯黑色而不是和上面一样的灰色。从中间图实时预览模式来看会更加明显,从275行开始就不会显示为标注块了。问题就在于在阅读模式下查看是一切正常的,就有点犯强迫症,想请教是我的语法问题还是软件的识别问题呢?

源码如下

> [!note]- 泛型类(Generic Class)
> 泛型类(Generic Class)是面向对象编程中的一种机制,它允许你创建可以处理不同类型的类,而不需要重复编写多个版本的相同逻辑代码。通过使用泛型,你可以在类的定义中引入类型参数,以实现对不同类型数据的通用处理。
>
> ### 为什么使用泛型类?
> 
> 1. **代码复用**:泛型类允许你编写一次代码,可以处理不同类型的数据,而不需要为每种类型重写相同的逻辑。
> 2. **类型安全**:泛型可以在编译时捕获类型错误,减少运行时错误发生的可能性。通过声明类型参数,编译器可以确保你不会错误地使用不同类型的数据。
> 3. **提高代码可读性**:泛型类的定义明确了数据结构或算法期望处理的类型,使代码更加清晰可维护。
> 
> ### 泛型类的定义
> 
> 泛型类通过在类名后面引入类型参数进行声明,通常类型参数用大写字母 `T`、`E`、`K`、`V` 等来表示。泛型类定义的基本语法如下:
> 
> ```java
> class Box<T> {
>     private T content;
> 
>     public Box(T content) {
>         this.content = content;
>     }
> 
>     public T getContent() {
>         return content;
>     }
> 
>     public void setContent(T content) {
>         this.content = content;
>     }
> }
> ```
> 
> 在上面的例子中,`Box<T>` 是一个泛型类,其中 `T` 是类型参数,它表示类可以处理任何类型。你可以在实例化该类时为 `T` 指定一个具体的类型:
> 
> ```java
> Box<String> stringBox = new Box<>("Hello");
> System.out.println(stringBox.getContent()); // 输出 "Hello"
> 
> Box<Integer> integerBox = new Box<>(123);
> System.out.println(integerBox.getContent()); // 输出 123
> ```
> 
> ### 主要特点
> 
> 1. **类型参数的多样性**:一个泛型类可以有多个类型参数,比如 `Map<K, V>`,其中 `K` 是键的类型,`V` 是值的类型。
> 2. **通配符类型**:泛型支持通配符(`?`),用于表示不确定的类型。通配符可以限制类型的上界和下界,例如:
> 	- `< ? extends Number>`  表示可以接受 `Number` 类型及其子类。
>     - `< ? super Integer>` 表示可以接受 `Integer` 类型及其父类。
> 3. **类型擦除**:在 Java 中,泛型的类型信息在编译之后会被擦除,JVM 在运行时并不会保留类型参数的具体信息。这意味着泛型的类型检查是在编译时进行的,确保了类型安全性,但在运行时不会产生性能开销。

我还发现一个问题,加入这段标注块之后,在这段标注块后面的图片链接在实时预览模式下都不会显示图片了,只会显示文字……但是在这个标注块之前的图片链接在实时预览模式下都是是可以显示的 :smiling_face_with_tear::smiling_face_with_tear::smiling_face_with_tear:

我的理解是ob为了保证兼容性,在很多地方都遵守传统markdown,这直接导致了复杂格式(嵌套、callout、列表等)无法渲染,除非牺牲大量性能采用复杂的渲染方法,但这就和富文本编辑器无异了,因此官方一直没做,留给个人开发者决策

块链接无法做精细应该也是类似的情况

看起来好像是这个道理的,有点难过,想找一个完美的解决方案

请问目前来说Callout语法和代码块之间的冲突有完美的解决方案嘛,我试了下在尖括号对中不填内容或者填充其他的变量名的情况,不填充内容、填充数字或符号开头的内容都是正常的,只要字母开头的变量名就会有问题

还是不建议在obsidian中使用Callout语法呢