正如标题所言，在我四年的编程经历中就没刷过一道算法题，这可能与我所编写的应用有关，算法对我而言提升不是特别大。加上我几乎都是**在需求中学习，而非系统性的学习**。所以像算法这种基础知识我自然就不是很熟悉。

## 那我为何会接触算法呢？

我在今年暑假期间有一个面试，当时面试官想考察下我的算法能力，而我直接明摆了说我不行（指算法上的不行），但面试官还是想继续考察，于是就出了道斐波那契数列作为考题。

但我毕竟也接触了 4 年的代码，虽说不刷算法，但起码也看过许多文章和代码，斐波那契数列使用递归实现的代码也有印象，于是很快我就写出了下面的代码作为我的答案。

```typescript
function fib(n) {
  if (n <= 1) return n

  return fib(n - 1) + fib(n - 2)
}
```

面试官问我还有没有更好的答案，我便摇了摇头表示这 5 行不到的代码难道不是最优解？

> 事实上这份代码看起来很简洁，实际却是耗时最慢的解法

毫无疑问，在算法这关我肯定是挂了的，不过好在项目经验及后续的项目实践考核较为顺利，不然结局就是回去等通知了。最后面试接近尾声时，面试官友情提醒我加强基础知识（算法），强调各种应用框架不断更新迭代，但计算机的底层基础知识是不变的。于是在面试官的建议下，便有了本文。



好吧，我承认我是为了面试才去学算法的。

### 对上述代码进行优化

在介绍我是从何处学习算法以及从中学到了什么，不妨先来看看上题的最优答案是什么。

对于有接触过算法的同学而言，不难看出时间复杂度为 O(n²)，而指数阶属于爆炸式增长，当 n 非常大时执行效果缓慢，且可能会出现函数调用堆栈溢出。

如果仔细观察一下，会发现这其中进行了非常多的重复计算，我们不妨将设置一个 res 变量来输出一下结果

```tsx
function fib(n) {
  if (n <= 1) {
    return n
  }

  const res = fib(n - 1) + fib(n - 2)
  console.log(res)
  return res
}
```

当 n=7 时，所输出的结果如下

![Untitled](https://img.kuizuo.cn/202309162220346.png)

这还只是在 n=7 的情况下，便有这么多输出结果。而在算法中要避免的就是重复计算，这能够高效的节省执行时间，因此不妨定义一个缓存变量，在递归时将缓存变量也传递进去，如果缓存变量中存在则说明已计算过，直接返回计算结果即可。

```typescript
function fib(n, mem = []) {
  if (n <= 1) {
    return n
  }

  if (mem[n]) {
    return mem[n]
  }

  const res = fib(n - 1, mem) + fib(n - 2, mem)
  console.log(res)
  mem[n] = res
  return res
}
```

此时所输出的结果可以很明显的发现没有过多的重复计算，执行时间也有显著降低。

![Untitled](https://img.kuizuo.cn/202309162220348.png)

这便是**记忆化搜索**，时间复杂度被优化至 O(n)。

可这还是免不了递归调用出现堆栈溢出的情况（如 n=10000 时）。

![Untitled](https://img.kuizuo.cn/202309162220349.png)

从上面的解法来看，都是从”**从顶至底**”，比方说 n=7，会先求得 n=6 的结果, 而 n=6 又要求得 n=5 的结果，依次类推直至得到底层 n=1 的结果。

事实上我们可以换一种思路，先求得 n=1，n=2 的结果，然后依次类推上去，最终得到 n=6，n=7 的结果，也就是“**从底至顶”**，而这就是**动态规划**的方法。

从代码上来分析，因此我们可以初始化一个 dp 数组，用于存放数据状态。

```tsx
function fib(n) {
  const dp = [0, 1]

  for (let i = 2; i <= n; i++) {
    dp[i] = dp[i - 1] + dp[i - 2]
  }

  return dp[n]
}
```

最终 dp 数组的最后一个成员便是原问题的解。此时输出 dp 数组结果。

![Untitled](https://img.kuizuo.cn/202309162220350.png)

且由于不存在递归调用，因此你当 n=10000 时也不在会出现堆栈溢出的情况（只不过最终的结果必定超出了 JS 数值可表示范围，所以只会输出 Infinity）

对于上述代码而言，在空间复杂度上能够从 O(n) 优化到 O(1)，至于实现可以参考 [空间优化](https://www.hello-algo.com/chapter_dynamic_programming/intro_to_dynamic_programming#1414)，这里便不再赘述。

我想至少从这里你就能看出算法的魅力所在，**这里我强烈推荐 [hello-algo](https://www.hello-algo.com/) 这本数据结构与算法入门书**，我的算法之旅的起点便是从这本书开始，同时激发起我对算法的兴趣。

## 两数之和

于是在看完了这本算法书后，我便打开了大名鼎鼎的刷题网站 [LeetCode](https://leetcode.cn)，同时打开了究极经典题目的[两数之和](https://leetcode.cn/problems/two-sum)。

> 有人相爱，有人夜里开车看海，有人 leetcode 第一题都做不出来。

题干：

> 给定一个整数数组 `nums`  和一个整数目标值 `target`，请你在该数组中找出和为目标值 `target` 的那 **两个** 整数，并返回它们的数组下标。
>
> 你可以假设每种输入只会对应一个答案。但是，数组中同一个元素在答案里不能重复出现。
>
> 你可以按任意顺序返回答案。

以下代码将会采用 JavaScript 代码作为演示。

### 暴力枚举

我初次接触该题也只会暴力解法，遇事不决，暴力解决。也很验证了那句话：不论多久过去，我首先还是想到两个 for。

```tsx
var twoSum = function (nums, target) {
  const n = nums.length

  for (let i = 0; i < n; i++) {
    for (let j = 0; j < n; j++) {
      if (nums[i] + nums[j] === target && i !== j) {
        return [i, j]
      }
    }
  }
}
```

当然针对上述 for 循环优化部分，比如说让 `j = i + 1` ，这样就可以有效避免重复数字的循环以及 `i ≠ j` 的判断。由于用到了两次循环，很显然时间复杂度为 O(n²)，并不高效。

### 哈希表

我们不妨将每个数字通过 hash 表缓存起来，将值 `nums[i]` 作为 key，将 `i` 作为 value。由于题目的条件则是 `x + y = target`，也就是 `target - x = y`，这样判断的条件就可以由 `nums[i]+ nums[j] === target` 变为 `map.has(target - nums[i])` 。如果 map 表中有 y 索引，那么显然 `target - nums[i] = y`，取出 y 的索引以及当前 i 索引就能够得到答案。代码如下

```tsx
var twoSum = function (nums, target) {
  const map = new Map()

  for (let i = 0; i < nums.length; i++) {
    if (map.has(target - nums[i])) {
      return [map.get(target - nums[i]), i]
    }
    map.set(nums[i], i)
  }
}
```

而这样由于只有一次循环，时间复杂度为 O(N)。

### 双指针算法(特殊情况)

假如理想情况下，题目所给定的 nums 是**有序的情况**，那么就可以考虑使用双指针解法。先说原理，假设给定的 nums 为 `[2,3,5,6,8]`，而目标的解为 9。在上面的做法中都是从索引 0 开始枚举，也就是 2,3,5…依次类推，如果没找到与 2 相加的元素则从 3 开始 3,5,6…依次类推。

此时我们不妨从**最小的数**和**最大的数**开始，在这个例子中也就是 2 和 8，很显然 `2 + 8 > 9`，说明什么？说明 8 和中间所有数都大于 9 即 3+8 ，5+8 肯定都大于 9，所以 8 的下标必然不是最终结果，那么我们就可以把 8 排除，从 `[2,3,5,6]` 中找出结果，同样的从最小和最大的数开始，`2 + 6 < 9` ，这又说明什么？说明 2 和中间这些数相加肯定都下雨 9 即 2+3，2+5 肯定都小于 9，因此 2 也应该排除，然后从 `[3,5,6]` 中找出结果。就这样依次类推，直到找到最终两个数 `3 + 6 = 9`，返回 3 与 6 的下标即可。

由于此解法相当于有两个坐标(指针)不断地向中间移动，因此这种解法也叫**双指针算法**。当然，要使用该方式的前提是输入的**数组有序**，否则无法使用。

用代码的方式来实现：

1. 定义两个坐标(指针)分别指向数组成员最左边与最右边，命名为 left 与 right。
2. 使用 while 循环，循环条件为 left < right。
3. 判断 `nums[left] + nums[right]` 与 `target` 的大小关系，如果相等则说明找到目标(答案)，如果大于则 右指针减 1 `right—-`，小于则左指针加 1 `left++`。

```tsx
function twoSum(nums, target) {
  let left = 0
  let right = nums.length - 1

  while (left < right) {
    const sum = nums[left] + nums[right]
    if (sum === target) {
      return [left, right]
    }

    if (sum > target) {
      right--
    } else if (sum < target) {
      left++
    }
  }
}
```

---

针对上述两道算法题浅浅的做个分享，毕竟我还只是一名初入算法的小白。对我而言，我的算法刷题之旅还有很长的一段时间。且看样子这条路可能不会太平坦。

## 算法对我有用吗？

在我刷算法之前，我在网上看到鼓吹算法无用论的人，也能看到学算法却不知如何应用的人。

这也不禁让我思考 🤔，算法对我所开发的应用是否真的有用呢？

在我的开发过程中，往往面临着各种功能需求，而通常情况下我会以尽可能快的速度去实现该功能，至于说这个功能耗时 1ms，还是 100 ms，并不在乎。因为对我来说，这种微小的速度变化并不会被感知到，或者说绝大多数情况下，处理的数据规模都处在 n = 1 的情况下，此时我们还会在意 n² 大还是 2ⁿ 大吗？

但如果说到了用户感知到卡顿的情况下，那么此时才会关注性能优化，否则，过度的优化可能会成为一种徒劳的努力。

或许正是因为我都没有用到算法解决实际问题的经历，所以很难说服自己算法对我的工作有多大帮助。但不可否认的是，算法对我当前而言是一种思维上的拓宽。让我意识到一道（实际）问题的解法通常不只有一种，如何规划设计出一个高效的解决方案才是值得我们思考的地方。

## 结语

借 MIT 教授 Erik Demaine 的一句话

> If you want to become a good programmer, you can spend 10 years programming, or spend 2 years programming and learning algorithms.

如果你想成为一名优秀的程序员，你可以花 10 年时间编程，或者花 2 年时间编程和学习算法。

这或许就是学习算法的真正意义。

## 参考文章

[初探动态规划](https://www.hello-algo.com/chapter_dynamic_programming/intro_to_dynamic_programming)

[学习算法重要吗?](https://www.zhihu.com/question/335097718)

一位未曾涉足算法的初学者收获

我曾经写过一个项目 [ddddocr_server](https://github.com/kuizuo/ddddocr_server)，使用 fastapi 提供 http 接口，以此来调用 [ddddocr](https://github.com/sml2h3/ddddocr) 库。

其他语言想要调用的话，则是通过 http 协议的方式来调用。然而 http 协议的开销不小，而 Websocket 调用又不灵活，此时针对这种应用场景的最佳选择就是 rpc（Remote Procedure Call 远程过程调用），而这次所要用的技术便是 grpc。

早闻 [gRPC](https://grpc.io/) 大名，所以这次将使用 nest 通过 grpc 的方式来调用 python 的 ddddocr 库来识别验证码。



## 效果图

![Untitled](https://img.kuizuo.cn/202307290823586.png)

本文源码 [nest-ocr](https://github.com/kuizuo/nest-ocr)

## 简单熟悉下 grpc

由于我们的调用方是 nest，因此就很有必要熟悉一下 nest 要如何创建

官方提供了一个 [样例](https://github.com/nestjs/nest/tree/master/sample/04-grpc)，本文便在此基础上进行更改。

首先，在 nest 中 grpc 是以微服务的方式启动的，从代码上也就 3 行便可实现。

```typescript title='main.ts' icon='logos:nestjs'
const app = await NestFactory.create(AppModule)

app.connectMicroservice <
  MicroserviceOptions >
  {
    transport: Transport.GRPC,
    options: {
      package: 'hero',
      protoPath: join(__dirname, './hero/hero.proto'),
    },
  }

await app.startAllMicroservices()
```

既然服务有了，那么要如何调用呢？或者说有没有像 http 接口调试工具能够调用 grpc 服务，有很多种 grpc 客户端工具，但这里选择 Postman。

![Untitled](https://img.kuizuo.cn/202307290823587.png)

### 创建 API

不过这里先别急着调用，为了后续调试，建议先到工作区的 APIs 中添加一个 API，然后将样例中的 hero.proto 中导入进来

![Untitled](https://img.kuizuo.cn/202307290823588.png)

导入完毕后将显示如下页面

![Untitled](https://img.kuizuo.cn/202307290823589.png)

### 创建 gRPC 客户端

点击工作区旁边的 New 按钮（不是 + 按钮），选择 gRPC

![Untitled](https://img.kuizuo.cn/202307290823590.png)

在 Enter URL 输入框填写 [localhost:5000](http://localhost:5000) (nest grpc 默认地址)，这里你也可以选择第一个官方的 gRPC 测试服务，用于看看效果。

![Untitled](https://img.kuizuo.cn/202307290823591.png)

填写完毕后，你会发现在右侧 Select a method 中并没有看到所定义的两个方法：FindOne，FindMang，这时候我们需要将 hero.proto 文件导入进来，如果你完成了 创建 API 那一步骤，你在右侧便能看到那两个方法

![Untitled](https://img.kuizuo.cn/202307290823592.png)

此时不妨选择一下 FindOne，然后点击下方 Use Example Message，将 id 填为 1，点击 Invoke，得到的效果图如下。

![Untitled](https://img.kuizuo.cn/202307290823593.png)

到这里我们就已经搞定了如何调用 grpc 服务，接下来就要自己去实现标题的需求。

## Protobuf 消息编码

**在 grpc 中，数据传输部分通过 Protobuf（Protocol Buffers）定义**

因为从上面服务调用来看，貌似与 http 协议调用不相上下。

其实不然，protobuf 不同于 JSON、XML 数据，是以二进制数据流传输，数据在经 protobuf 序列化后的消息体积很小（传输内容少，传输相对就快）。同时在加上 HTTP/2 协议的加持（底层传输协议，可替换为其他协议），使得 gRPC 的传输性能要优于传统 Restful。

protobuf 对于数据传输的优点有很多，如 **支持流式传输，不过这就不是本文所述的内容了。总之你只要知道 grpc 性能高的原因就是因为 protobuf。**

```protobuf title='hero.proto' icon='vscode-icons:file-type-protobuf'
syntax = "proto3";

package hero;

service HeroService {
  rpc FindOne (HeroById) returns (Hero);
  rpc FindMany (stream HeroById) returns (stream Hero);
}

message HeroById {
  int32 id = 1;
}

message Hero {
  int32 id = 1;
  string name = 2;
}
```

不难看出，package 定义包名，service 定义服务，而 message 则是定义数据传输的类型。

客户端与服务端将根据 protobuf 来生成双方交互方式，其中包名决定了双方传输的作用域，service 下的函数就是双方之间的预先定义好要以什么样的数据发送，又以什么样的数据返回。

我个人是觉得没什么特别重点的部分，根据自己的需求然后修改基本数据结构便可。

## 实践

首先，要**明确谁是客户端，谁是服务端。**

从 标题 上来看，不难看出是 js(client) ⇒ python(server)，也就是 nest 调用 ddddocr 这个库，那么 nest 就应该作为客户端，而 python 作为服务端。

先将整个流程先捋一遍，如图下图示意。

![Untitled](https://img.kuizuo.cn/202307290823594.png)

用户想要调用 ddddocr 库，最理想的肯定是让用户直接和 python 打交道，但应用（这里指 Web）通常不会使用 python 进行编写，而其他语言(js)想要跨语言调用，这时 rpc 就再适合不过了。

可能会有人说这么操作多此一举，我只能说根据性能和业务为主。相比将 nest 后端服务迁移到 python 上，和在 nest 与 python 之间多层 grpc，在两者的工作量之下我肯定毫不疑问的选择后者。

### protobuf 定义

```protobuf title='ocr.proto' icon='vscode-icons:file-type-protobuf'
syntax = "proto3";

package ocr;

service OCR {
  rpc Character (CharacterBody) returns (CharacterReply) {}

  // TODO: Add other type, e.g. select, slide, etc.
}

message CharacterBody {
  bytes image = 1;
}

message CharacterReply {
  string result = 1;
  int32 consumedTime = 2;
}
```

这部分没什么特别好说的，就图片数据以字节数组的方式传递。

### nest 部分

由于 nest 作为客户端，事实上示例部分的很多代码都无关了，就比如 main.ts 中用于启动 gRPC 服务的代码，都可以注释掉，因为在这里我们并不打算将 nest 作为服务端。

```typescript title='main.ts' icon='logos:nestjs'
// app.connectMicroservice<MicroserviceOptions>(grpcClientOptions);
// await app.startAllMicroservices();
```

最核心的代码，就是定义 client, 如下

```typescript
@Client({
  transport: Transport.GRPC,
  options: {
    package: ['ocr'],
    protoPath: join(__dirname, './ocr.proto'),
    url: 'localhost:50051', // 这里所定义的是 grpc 服务端地址
  },
})
client: ClientGrpc
```

> 这一部分也可以通过构造函数的方式注入，因人而异。 `constructor(@Inject('OCR_PACKAGE') private readonly client: ClientGrpc) {}`

有了这个 client 就能够获取 ocrService 了，完整 ocr.controller.ts 代码如下

```typescript title='ocr.controller.ts' icon='logos:nestjs'
import { Body, Controller, OnModuleInit, Post } from '@nestjs/common'
import { Client, ClientGrpc } from '@nestjs/microservices'
import { Observable } from 'rxjs'
import { Character } from './interfaces/character.interface'
import { Reply } from './interfaces/reply.interface'
import { grpcClientOptions } from 'src/grpc-client.options'
import { CharacterDto } from './dtos/character.dto'

interface OCRService {
  Character(image: Character): Observable<Reply>

  // TODO: Add other type, e.g. select, slide, etc.
}

@Controller('ocr')
export class OcrController implements OnModuleInit {
  private ocrService: OCRService

  @Client(grpcClientOptions)
  client: ClientGrpc

  onModuleInit() {
    this.ocrService = this.client.getService('OCR')
  }

  @Post('character')
  character(@Body() dto: CharacterDto): Observable<Reply> {
    // 这里多一步 Base64 将文本解码成图片的操作
    // 主要是根据接口易用性而定，最佳的做法肯定是类似上传文件，直接得到图片二进制数据，省去数据操作步骤
    const buffer = Buffer.from(dto.image, 'base64')

    return this.ocrService.Character({ image: buffer })
  }

  // TODO: Add other type, e.g. select, slide, etc.
}
```

而在之前 http 的方式实现的话，这里 `this.ocrService.Character({ image: dto.image });` 所对应的就是例如 `fetch(’http://localhost:3002/ocr/character’)` ，这里 3002 端口对应的是 python 的 http 服务。

### python 部分

服务端部分其实还稍微有些复杂，可能是因为我太久没写 python 的缘故。

在之前是通过 python 来启动一个 http 服务来供其他语言调用，现在有了 gRPC 就完全没必要启动 http 服务。

可以在 [这里](https://grpc.io/docs/languages/python/quickstart/#download-the-example) 下载官方的 python 示例。

先安装 grpc_tools

```bash
python3 -m pip install grpcio-tools
```

接着执行下方指令

```bash
python3 -m grpc_tools.protoc -I . --python_out=. --grpc_python_out=. ocr.proto
```

它将会在下方根据 `ocr.proto` 生成 `ocr_pb2.py` 与 `ocr_pb2_grpc.py` 两个文件，事实上这两个文件都无需改动，你只需要每次修改 .proto 文件后再重新执行上方代码将新的内容复写到文件上便可。

不过要搞清流程，还要是在意这些文件便可。其中在 `ocr_pb2_grpc.py` 文件中，你会找到 OCRServicer 类的接口定义。

```python title='ocr_pb2_grpc.py' icon='logos:python'
class OCRServicer(object):
    """Missing associated documentation comment in .proto file."""

    def Character(self, request, context):
        """Missing associated documentation comment in .proto file."""
        context.set_code(grpc.StatusCode.UNIMPLEMENTED)
        context.set_details('Method not implemented!')
        raise NotImplementedError('Method not implemented!')
```

很显然这是一个接口类，因此我们需要实现它。

而 ocr_pb2.py 内容就不必细看，但后续也需要用到，主要通过 `ocr_pb2.CharacterReply` 将数据封装返回给客户端。

最终完整的 [server.py](http://server.py) 内容如下

```python title='server.py' icon='logos:python'
from concurrent import futures
import time

import grpc
import ocr_pb2
import ocr_pb2_grpc

import ddddocr

ocr = ddddocr.DdddOcr(beta=True)

class OCRServicer(ocr_pb2_grpc.OCRServicer):

    # 这里实现 英数验证码 识别
    def Character(self, request, context):

        t = time.perf_counter()

        result = ocr.classification(request.image)
        consumed_time = int((time.perf_counter() - t)*1000)

        print({'result': result, 'consumedTime': consumed_time})

        # 根据 ocr.proto 的 message CharacterReply 生成的类
        response = ocr_pb2.CharacterReply(
            result=result, consumedTime=consumed_time)
        return response

def serve():
    port = '50051'
    server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
    ocr_pb2_grpc.add_OCRServicer_to_server(OCRServicer(), server)
    server.add_insecure_port('[::]:' + port)
    server.start()
    print("Server started, listening on " + port)
    server.wait_for_termination()

if __name__ == '__main__':
    serve()
```

此时整个代码的核心流程就已经搞通了，你可以到 [nest-ocr](https://github.com/kuizuo/nest-ocr) 查看源码，先看看用 postman grpc 方式调用，这里 image 为 字节数组（图片的二进制数据）

![Untitled](https://img.kuizuo.cn/202307290823596.png)

用户以 http 方式访问的效果。

![Untitled](https://img.kuizuo.cn/202307290823595.png)

## 结语

时间因素，因此本文最终代码都仅实现 **英数字符识别**，ddddocr 还支持点选、滑块，如有时间再补充相关代码。

从 http 方式转到 gRPC 无非就是围绕 protobuf 展开，预先定义好 protobuf，然后在此基础上去编写 grpc 客户端(调用方)与服务端(提供方) 的代码。虽然引入了一丝复杂性，但可以有效提高性能。

有时候，为了优化性能，又不想增加硬件开销，我们不得不在代码层面做出一些改进，更换高性能框架便是其中之一。然而事实上，提高性能最快捷的方式就是升级硬件。并发数不足，增加服务器数量是最直接有效的办法。

为了偏薄的性能提升，开发者总能想出诸多的解决方案。

Nest grpc 实践之调用 python ddddocr 库

## 基本使用

通常情况下，在 nest.js 的 swagger 页面文档中的响应数据文档默认如下

![](https://img.kuizuo.cn/202307180105813.png)

此时要为这个控制器添加响应数据文档的话，只需要先声明 数据的类型，然后通过@ApiResponse 装饰器添加到该控制器上即可，举例说明

```typescript title="todo.entity.ts" icon='logos:nestjs'
@Entity('todo')
export class TodoEntity {
  @Column()
  @ApiProperty({ description: 'todo' })
  value: string

  @ApiProperty({ description: 'todo' })
  @Column({ default: false })
  status: boolean
}
```

```typescript title="todo.controller.ts" icon='logos:nestjs'
  @Get()
  @ApiOperation({ summary: '获取Todo详情' })
  @ApiResponse({ type: [TodoEntity] })
  async list(): Promise<TodoEntity[]> {
    return this.todoService.list();
  }


  @Get(':id')
  @ApiOperation({ summary: '获取Todo详情' })
  @ApiResponse({ type: TodoEntity })
  async info(@IdParam() id: number): Promise<TodoEntity> {
    return this.todoService.detail(id);
  }
```

此时对应的文档数据如下显示

![image-20230718012234692](https://img.kuizuo.cn/202307180122728.png)

如果你想要自定义返回的数据，而不是用 entity 对象的话，可以按照如下定义

```typescript title="todo.model.ts" icon='logos:nestjs'
export class Todo {
  @ApiProperty({ description: 'todo' })
  value: string

  @ApiProperty({ description: 'todo' })
  status: boolean
}
```

然后将 `@ApiResponse({ type: TodoEntity })` 中的 `TodoEntity` 替换 `Todo` 即可。

## 自定义返回数据

然而通常情况下，都会对返回数据进行一层包装，如

```json
{
  "data": [
    {
      "name": "string"
    }
  ],
  "code": 200,
  "message": "success"
}
```

其中 data 数据就是原始数据。要实现这种数据结构字段，首先定义一个自定义类用于包装，如

```typescript title="res.model.ts"
export class ResOp<T = any> {
  @ApiProperty({ type: 'object' })
  data?: T

  @ApiProperty({ type: 'number', default: 200 })
  code: number

  @ApiProperty({ type: 'string', default: 'success' })
  message: string

  constructor(code: number, data: T, message = 'success') {
    this.code = code
    this.data = data
    this.message = message
  }
}
```

接着在定义一个拦截器，将 data 数据用 ResOp 包装，如下拦截器代码如下

```typescript title="transform.interceptor.ts" icon='logos:nestjs'
export class TransformInterceptor implements NestInterceptor {
  constructor(private readonly reflector: Reflector) {}

  intercept(context: ExecutionContext, next: CallHandler<any>): Observable<any> {
    return next.handle().pipe(
      map(data => {
        const response = context.switchToHttp().getResponse<FastifyReply>()
        response.header('Content-Type', 'application/json; charset=utf-8')
        return new ResOp(HttpStatus.OK, data ?? null)
      }),
    )
  }
}
```

此时返回的数据都会转换为 `{ "data": { }, "code": 200, "message": "success" }` 的形式，这部分不为就本文重点，就不赘述了。

回到 Swagger 文档中，只需将 `@ApiResponse({ type: TodoEntity })` 改写成 `@ApiResponse({ type: ResOp<TodoEntity> })`，就可以实现下图需求。

![image-20230718012618710](https://img.kuizuo.cn/202307180126751.png)

## 自定义 Api 装饰器

然而对于庞大的业务而言，使用 `@ApiResponse({ type: ResOp<TodoEntity> })`的写法，肯定不如 `@ApiResponse({ type: TodoEntity })`来的高效，有没有什么办法能够用后者的写法，却能达到前者的效果，答案是肯定有的。

这里需要先自定义一个装饰器，命名为 `ApiResult`，完整代码如下

```typescript title="api-result.decorator.ts" icon='logos:nestjs'
import { Type, applyDecorators, HttpStatus } from '@nestjs/common'
import { ApiExtraModels, ApiResponse, getSchemaPath } from '@nestjs/swagger'

import { ResOp } from '@/common/model/response.model'

const baseTypeNames = ['String', 'Number', 'Boolean']

/**
 * @description: 生成返回结果装饰器
 */
export const ApiResult = <TModel extends Type<any>>({
  type,
  isPage,
  status,
}: {
  type?: TModel | TModel[]
  isPage?: boolean
  status?: HttpStatus
}) => {
  let prop = null

  if (Array.isArray(type)) {
    if (isPage) {
      prop = {
        type: 'object',
        properties: {
          items: {
            type: 'array',
            items: { $ref: getSchemaPath(type[0]) },
          },
          meta: {
            type: 'object',
            properties: {
              itemCount: { type: 'number', default: 0 },
              totalItems: { type: 'number', default: 0 },
              itemsPerPage: { type: 'number', default: 0 },
              totalPages: { type: 'number', default: 0 },
              currentPage: { type: 'number', default: 0 },
            },
          },
        },
      }
    } else {
      prop = {
        type: 'array',
        items: { $ref: getSchemaPath(type[0]) },
      }
    }
  } else if (type) {
    if (type && baseTypeNames.includes(type.name)) {
      prop = { type: type.name.toLocaleLowerCase() }
    } else {
      prop = { $ref: getSchemaPath(type) }
    }
  } else {
    prop = { type: 'null', default: null }
  }

  const model = Array.isArray(type) ? type[0] : type

  return applyDecorators(
    ApiExtraModels(model),
    ApiResponse({
      status,
      schema: {
        allOf: [
          { $ref: getSchemaPath(ResOp) },
          {
            properties: {
              data: prop,
            },
          },
        ],
      },
    }),
  )
}
```

其核心代码就是在 `@ApiResponse` 上进行扩展，这一部分代码在官方文档: [advanced-generic-apiresponse](https://docs.nestjs.com/openapi/operations#advanced-generic-apiresponse) 中提供相关示例，这里我简单说明下：

`{ $ref: getSchemaPath(ResOp) }` 表示原始数据，要被“塞”到那个类下，而第二个参数 `properties: { data: prop }` 则表示 `ResOp` 的 `data` 属性要如何替换，替换的部分则由 `prop` 变量决定，只需要根据实际需求构造相应的字段结构。

由于有些类没有被任何控制器直接引用， SwaggerModule `SwaggerModule` 还无法生成相应的模型定义，所以需要 `@ApiExtraModels(model)` 将其额外导入。

此时只需要将 `@ApiResponse({ type: TodoEntity })` 改写为 `@ApiResult({ type: TodoEntity })`，就可达到最终目的。

不过我还对其进行扩展，使其能够返回分页数据格式，具体根据实际数据而定，演示效果如下图：

![image-20230718023729609](https://img.kuizuo.cn/202307180237658.png)

## 导入第三方接口管理工具

通过上述的操作后，此时记下项目的 swagger-ui 地址，例如 [http://127.0.0.1:5001/api-docs](http://127.0.0.1:5001/api-docs), 此时再后面添加`-json`，即 [http://127.0.0.1:5001/api-docs-json ](http://127.0.0.1:5001/api-docs-json) 所得到的数据便可导入到第三方的接口管理工具，就能够很好的第三方的接口协同，接口测试等功能。

![image-20230718022612215](https://img.kuizuo.cn/202307180226265.png)

![image-20230718022446188](https://img.kuizuo.cn/202307180224284.png)

nest.js 添加 swagger 响应数据文档

叙一名转专业+休学的大学生经历

首先我不是 iphone 用户，甚至是果黑（苹果的小黑子，合理来说是苹果手机的小黑子），所以我一向从内心就很摈弃苹果的产品。因此我从来没体验过 MacOS 系统，用了近 4 年 window，不过由于我的那台 window 本 （21 年小新 pro14） 给我的体验非常差，虽然说续航勉勉强强足够支撑我一个下午的开发，但 intel 的 i5 cpu 我就没打算将其作为主力机开发（根本做不了），更多是使用向日葵远程桌面软件来远程连接到我的台式电脑，远程操控来进行开发。然而由于屏幕分辨率不同以及网络延迟，这样的体验长期下去必然会崩溃。因此**更换自己的移动办公设备已经成了我当下的刚需。**

见识到诸多程序员大神都将 mac 作为主力开发机器，同时又被安利过很多次 MacBook，但我一直对 macOS 保持观察的态度，自己从未亲自体验过，最多也就看别人用用，在 window 上这些同样也能实现，何必要多此一举再去了解一个新的系统，新的操作逻辑。但直到我真正接触并体验过 macOS 后，我便爱不释手。

在写这篇文章时，我已经用了近一周的 macbook，因此想分享个人的购买流程、选购建议、使用感悟，或许对于某些想要尝试 MacOS 但又保有迟疑态度的用户有所帮助，也算是给曾经的我对苹果的偏见的转变。

> 拖更了近两个月的博文了，摆了一整子，说来也确实有些许惭愧。不过目前生产力工具已就绪，也要开始步入正轨。



## 购买流程

我是在线下 apple 授权店买的，五一假期的前一天晚上逛商场的时候正好经过，于是进去与店员交谈了一整子，又思考了一晚上，最终决定第二天直接现货 购买了丐版（标准版）的 macbook m2 pro 14 寸 16g + 512g。

至于选择 14 寸还是 16 寸，就因人（钱）而异，去线下给我最大的感受就是 16 寸是真的大，且厚重（14 寸也挺重的有 1.6kg），通常我在室内我就会拓展外接显示器加上偶尔有床上办公的需求所以在看到第一眼后便毫不犹豫的选择 14 寸作为我的目标尺寸。

至于说选择 m2 pro 还是 m2 max，这条[链接](https://www.apple.com.cn/macbook-pro-14-and-16/)与下图能告诉你答案。

![Untitled](https://img.kuizuo.cn/202305050428893.png)

其次就是选配方面，在之前我是打算购买 32g + 1t 的。但在如今一堆 electron 应用（一个就要吃至少 100m 的内存），加上我本身的会有多开几个 vscode 以及多个浏览器标签， 16g 内存在 window 下对于开发从事者而言已经不够使用了，在 mac 上 从我的事实也证明 16g 内存 在两个正在运行中的 node 与 的 10 来个浏览器标签，加上一些常用软件（微信、QQ、飞书、）是有些不够用了，以下对应的活动监视图（window 中的任务管理器）

![Untitled](https://img.kuizuo.cn/202305050429190.png)

虽说有 swap，表面上的 16g 物理内存实际上运行内存可能会更多，但最主要还是看内存压力。不过即使是这样，系统也没有出现过任何的卡顿，这要是换 windows，恐怕已经蓝屏了。等哪天内存压力变红时或者出现卡顿现象，再来汇报相关进程。（新买的机子，不舍得压力测试折腾她）

而 m2 pro 的 512g 相比 1t 读写速度减少一半（看下图你便懂了，单通道的速度和两个 512g 组双通道相比），事实上在之前的丐版都存在这种问题，可以说苹果是巴不得你加购硬盘容量，不然硬盘速度缩半。

![Untitled](https://img.kuizuo.cn/202305050428895.png)

而 1t 及以上容量自然是无该问题，何况不加配的 mac 能叫 mac 吗。我其实是很想加配的，但无奈无现货，并且官网定制这个配置（m2 pro 32g + 1t）的还需要等待 2 个星期，据店员说“这只是预计，实际可能会更久“，不过这里不排除店员这么说诱导我在购买丐版现货。

![Untitled](https://img.kuizuo.cn/202305050428896.jpeg)

不过最终能让我购买的很大原因是在五一期间我实在不想用那破 window 本，因此第二天再次联系店员决定直接付款拿丐版现货。因为考虑两年后大概率也会更换电子设备（距离我上次更换电子设备也过去两年），所以综合考虑当前的配置在这两年应该是足以使用（这句话也许说的有点早）。

实体店与线上购买没有本质的区别，**价格上都是一致的**，也是有教育优惠的。只是人家会帮你激活设备，在你的眼皮子底下看看有无问题，确认无误后，交钱走人便可。此外可能还会赠送一些额外的一些配件，如键盘膜，屏幕膜，清洁套装，拓展坞（没有手提包），不过这些对我来说都非刚需，只要 MacBook Pro 没问题即可。

不过这里想要提一下，人家是挺极力推荐我购买 apple care 的（顺带有个配件券），据我了解，貌似是有一个 apple care 的指标，需要达到多少这样。不过我个人不喜欢买保险，因此便没有购买。

## 刚到手的 Mac 该如何处理

### 不要贴膜

**不要贴膜，不要贴膜，不要贴膜!**

我本是不想贴膜，喜欢裸机的感觉，但由于附送一个屏幕膜，我便勉为其难的贴一下，然而当我贴完后我随即将辛辛苦苦贴好的膜又给撕了下来了，并不是因为我贴的不好，而是**贴膜简直就是负提升**，前后对比是肉眼可见明显，这里我用相机拍不出肉眼那种效果，如果说喝枸杞是养生，那看 macbook 屏幕说是养眼可一点不为过。毕竟维修一个 Macbook 屏幕就需要 5000 左右，让我萌生一丝购买 apple care 的想法。

其次就是网上都有流传 macbook 的 B 面(屏幕)与 C 面(键盘)之间的间隔特别薄，贴屏幕膜或键盘膜可能都会让这层素质极高的屏幕受到一些损害。还有贴屏幕膜后，在下一次更换屏幕膜的时候，可能会导致屏幕涂层脱落，而贴键盘膜的话，时间久了会导致合盖的时候键盘膜印在屏幕上。总之，基本都是建议裸机。

### 熟悉 mac 操作以及相关软件

这里我推荐自己我自己看过的几个 mac 相关指南，能够帮助小白速度上手 mac。

[Mac 云课堂的个人空间\_哔哩哔哩\_bilibili](https://space.bilibili.com/41062266)

[【看完秒懂】Mac 苹果电脑超详细上手入门指南！建议做笔记！up 良心制作，用一集视频包你熟练上手 Mac\_哔哩哔哩\_bilibili](https://www.bilibili.com/video/BV1PF411E7LG/)

下面这个会比较针对与程序开发

[2022 我用 MacBook Pro 整一年 【感想 与 踩坑指南】 - 掘金 (juejin.cn)](https://juejin.cn/post/7181274704659873850)

由于我使用时间较短，因此软件方面我不好做出评价与推荐，这里我只附上一张我已安装应用截图

![Untitled](https://img.kuizuo.cn/202305050428897.png)

### 熟悉触控板与应用全屏，提升效率

如果要说使用的这段期间对笔记本电脑的体验变化无意有两点，一是颠覆我对笔记本触控板难用的想法，二是应用全屏（配合台前调度）却能够有如此高效的体验。

这一部分我认为不必过多吹捧，亲自到线下实体店感受才最为真实，相信我，你会爱上触摸板了。

### 养成保养电池的习惯

以下内容为使用 8 个月后的补充。

由于内存的不足加上重度开发，现今我的电池容量已达到 93% 了，说实话是有点小心痛的😭。

![](https://img.kuizuo.cn/2024/0114155525-202401141555937.png)

这与我一些不好的使用习惯还是有关的，我通常会打开好几个标签页，好几个 应用而不关闭，这就导致内存时常处于高负载状态下，不断的从硬盘中拿内存，这样不仅伤硬盘同时也伤电池。此外我通常会用 Type-c 一线连接外接显示器（既可以充电又可以显示），加上我没有拔电以及关机的习惯(可能要过好几周才会重关一次)，这就导致 8 个月的时间内电池最大容量缩减。

现在来看或许当初买个 apple care 还能免费换个电池似乎还划得来。

## 选 windows 还是 macOS ？

现在可以毫不犹豫的说，我会选择 macOS，下一台笔电也会选择 macOS 系统。但并不是说什么场景，macOS 都是最优选，就比如说游戏需求，我想没人会买台 mac 来作为自己的游戏机。mac 上几乎玩不到什么 3A 大作，甚至在 m2 芯片上，你可能都无法下载 wegame 来玩上一把英雄联盟。

![Untitled](https://img.kuizuo.cn/202305050428898.png)

如果你有桌面游戏的需求，建议拉黑 mac。此外还有一些 window 的专业软件，你在 mac 上可能找不到与之对应或平替的软件，尤其是在大学课程中，老师几乎不可能给学生发个 dmg 文件，如果你在大学期间买 mac，又要兼顾学校的课程软件需求，又不得不安装 window 虚拟机，与其如此折腾不如一开始就选用相对便宜的 win 本，还能减少一些经济压力。不过我觉得大学老师上课所说的一些软件都没必要安装，反而占用一些不必要的空间，（vc++、eclipse 等等），如果你们老师提到了 Vscode 那当我没说。

但出色的系统、高素质的屏幕，注定能让 MacBook 能够成为某部分群体的生产力工具，挣钱的机器。选用 macbook 的用户想必都希望在它任职期间产生数十倍的价值，当然排除我这个买来尝鲜的。

## 开发上的体验提升

目前手头的三台电脑设备对应的 CPU（性能从高到低）M2 Pro > AMD 5900x > i5-11300H

![Untitled](https://img.kuizuo.cn/202305050428899.png)

![Untitled](https://img.kuizuo.cn/202305050428900.png)

这里我没找到比较好的前端 benchmark 项目，但就从我个人直观的体验与在这三台机器启动同一个前端项目启动打包来看，在冷启动上，m2 pro 耗费 1.7s, 5900x 耗费 2.8s，i5-11300H 我都不想拉项目，去年的暑假靠这台 win 本进行开发，别提体验有多差，每次都需要干巴巴的干等项目完全启动就需要等个 2、3 分钟（不夸张），有时候可能因为某些特殊原因需要重启服务，好的，又浪费个 2、3 分钟。影响你效率的可能不只是环境，还有你的机器。

冷启动都能有近 1s 的优势，就别提热加载和打包速度上，这里直接给出我打包一个 Nuxt 项目的打包时间输出耗时，m2 pro 耗时 27s、5900x 耗时 116s（数据真实有效），快的让我有点感觉我是不是少写了某部分代码，还是说多注释了些代码。

性能优势可能不是最大的优势，但编程环境上 Mac 绝对比 Window 来的好，一个 [Homebrew](https://brew.sh/) 就已经能解决百分之 90 的编程语言环境，而这换到 Window 上则有诸多的安装方式。至少你不必像 Window 那样还需要打开设置面板配置环境变量。而 MacOS 与 Linux 又非常相似，都可以在命令行中运行 Unix、bash/zsh、以及其他 shell 命令. 所以至少从 `代码` 开发方面, Mac 绝对比 Window 来的好，这也是多数开发人员选择 Mac 的原因。

## 结语

相对遗憾的是购买的还是相对匆忙，就是没有加配 32g，虽说目前来说 16g 勉强能够应付绝大部分场景，但免不了后续爆内存，又无能为力的情况。但想到自己仿佛挖到了一个新世界的宝藏，这种担忧就显得不足为惧。

在写完这篇稿子时，回头用起 win 时，都习惯性的按下 `Alt + C` 键位，殊不知 `Ctrl + C` 才是 win 的复制。适应也许只需要几天的时间，但回去也许可能大半辈子都不再回去。

从被别人安利到用 mac，再到自己安利别人用 mac，这种对 macOS 系统相见恨晚的感受，也许只有使用过 macOS 的人才能理解。**很多东西只有自己用过才知道，只有尝试过，才知道适不适合自己。不尝试并不会丢失什么，但尝试过后往往能够收获意想不到的东西。**

如果你还没有尝试过 macOS 系统，那么你或许真的错过了很多。