refactor: 修改了泛型的排版

Author: 246859

src/essential/senior/90.generic.md

@@ -11,18 +11,19 @@ Go 是没有泛型这一说法的，但自从诞生以来，社区关于 Go 呼
 
 ## 设计
 
-Go 语言在设计泛型时，考虑过了以下的方案
+Go 语言当初在设计泛型时，考虑过了以下的方案
 
-- [stenciling](https://github.com/golang/proposal/blob/master/design/generics-implementation-stenciling.md)：单态化，比较典型的像
-  C++，Rust 这种，为每一个用到的类型都生成一份模板代码，这种的性能是最好的，完全没有任何运行时开销，性能等于直接调用，缺点就是大幅度拖慢编译速度（相较于
+- [stenciling](https://github.com/golang/proposal/blob/master/design/generics-implementation-stenciling.md)
+  ：单态化，比较典型的像C++，Rust 这种，为每一个用到的类型都生成一份模板代码，这种的性能是最好的，完全没有任何运行时开销，性能等于直接调用，缺点就是大幅度拖慢编译速度（相较于
   Go 自己而言），同时由于为每一个类型生成了代码，也会导致编译的二进制文件体积膨胀。
 - [dictionaries](https://github.com/golang/proposal/blob/master/design/generics-implementation-dictionaries.md)
-  ：它只会生成一套代码，同时在编译时生成一个类型字典，它存储了所有会用到的类型信息，在调用函数时，则会根据字典去查询类型信息。这种方式不会拖慢编译速度，也不会造成体积膨胀，但是会造成巨大的运行时开销，泛型的性能很差。
+  ：它只会生成一套代码，同时在编译时生成一个类型字典存储在只读数据段，它存储了所有会用到的类型信息，在调用函数时，则会根据字典去查询类型信息。这种方式不会拖慢编译速度，也不会造成体积膨胀，但是会造成巨大的运行时开销，泛型的性能很差。
 
-上面两个方法代表着两种极端，Go语言最终选择的实现方案是[Gcshape](https://github.com/golang/proposal/blob/master/design/generics-implementation-dictionaries-go1.18.md)
-，它是一个折中的选择，对于同种内存形状（形状怎么看由内存分配器决定）的类型会使用单态化，为其生成同一份代码，比如`type Int int`
-与`int`其实是同一个类型，但是对于指针而言，所有的指针类型都是同一个内存形状，比如`*int`，`*Person`
-都是一个内存形状，它们是无法共用一套代码的，为此，Go同时也会使用字典在运行时获取类型信息，所以Go的泛型也存在运行时开销。
+上面两个方法代表着两种极端，Go
+语言最终选择的实现方案是 [Gcshape stenciling](https://github.com/golang/proposal/blob/master/design/generics-implementation-dictionaries-go1.18.md)
+，它是一个折中的选择，对于同种内存形状（形状怎么看由内存分配器决定）的类型会使用单态化，为其生成同一份代码，比如
+`type Int int`与 `int` 其实是同一个类型，所以共用一套代码，但是对于指针而言，所有的指针类型都是同一个内存形状，比如 `*int`，
+`*Person`都是一个内存形状，它们是无法共用一套代码的，为此，Go 同时也会使用字典在运行时获取类型信息，所以 Go 的泛型也存在运行时开销。
 
 ## 示例