迟到的毕业证书​

由于之前经历了转专业+休学以及一系列旷课行为导致挂科学分不够，最终不得不在临近毕业时为这些“买单”（出来混总是要还的）。在大四下的时候，有几场考试的时间被安排在发毕业证之前，这意味着我会比他人晚拿到毕业证(大约 2 周)。

不过因祸得福的是，由于延毕所导致我的学生认证资格一直延续到现在，预估明年 6 月毕业季时，我的学生认证才会真正到期。

要我说读大学对我有什么用的话，我能回答的或许只有学生认证所带来的各种优惠，而非传统大学教育为我提供了什么有价值的东西。

上大学对我说算是一种束缚，甚至让我一度怀疑我所读的不是一所的“大学”，反而是所“监狱”。

上大学也是我愧对于父母的一件事情，我也一直不愿意与他们诉说我在大学期间做了什么，因为解释给他们晦涩难懂，何况大学期间发生的变故差点让我难以毕业。

每当他人提起我的学校，我总会有点莫名的哽咽，因为大学很垃圾，难以说出口，我一直不愿说我是本校的学生，且有意为之将有关学校的信息隐秘于世，宁可告诉别人我没读过大学，也不愿让其知道大学名字。

或许当年直接选择辍学而非休学能真正抹除自己内心的阴霾。

初次面基​

在结束了毕业论文答辩，于是决定去广州与网友面基。这是我第一次网友线下面基，再次之前我甚至都没有去过北上广深，甚至这是我自己第一次一个人出省玩🥲。

面基的第一天网友就带我体验了 livehouse，还用无人机拍下广州塔的美景。

后面一起去深圳参加了 VueConf 大会，也是我第一次参加这种大型技术活动。之后还计划一同去🇭🇰搞卡，然而和去年一样，由于特殊原因，今年的我依旧办理不了港澳通行证😔

下半年参加 Feday 有幸见到了一些大佬，技术的氛围感，让我感受到了一种前所未有的激动。明年的我一定要面基更多的网友，去更多的地方，体验更多的生活。

结束了短暂的游玩时光，终于要开始苦逼的牛马生活了，吗？

初入职场​

和绝大多数刚毕业的应届生一样，在家人的建议和考虑下，我最终选择去福州和我姐一起生活和工作，这样既能照应彼此，减轻一些生活压力的同时，还能提高生活幸福指数。

事实也确实如此，在我姐的几年生活经验下，我几乎不用考虑衣行吃住，在福州过得是有滋有味。一向宅男的我在我姐的怂恿下尝试了很多不一样生活的方式，并不是只有宅在家里才是活着（虽然在家里活着确实挺舒服的😂）。

在五一的节假日期间，我准备完简历与项目后开始找工作去，这一段的求职与就业的感悟故事我也记录了下来。

记 · 在 AI 公司入职一个月的体验与感悟

然而在工作了三个月后，我逐渐发现公司内部异常混乱。在这段时间里，我被卷入高管之间的内斗，沦为他们博弈的工具人。试用期结束时，不但被卡转正，还遭遇了疯狂的职场PUA和无止境的压榨。

就在我萌生离职念头时，没想到我的前领导竟然比我更快一步离职。而我却做出了一个让我至今懊悔的决定——接手前领导的活，还选择吃下老板画的大饼。在这种超负荷的状态最终只让我坚持了一个月。9月30日这一天，我终于下定决心递交了辞呈，给自己放了一个真正的长假。😇

期间所发生的故事尤为精彩，我也将其整理了下来，也算是给我的职业生涯增添了浓墨重彩的一笔。

至于说现在这个 AI 初创公司发展的如何，或许是在濒临倒闭的边缘，不过我现在只清晰地记得离职那天一刻无比愉悦的心情😆。

游戏艺术​

离职回到老家的我第一时间玩起了《黑神话·悟空》，之前玩的是《黑公司·牛马》。我特意为此购入了XBox手柄，只为离职之后的娱乐尽兴一把。

今年年初在朋友的怂恿下玩《荒野大镖客 2》。也是从这部作品刷新了我对游戏的认知，让我开始对这类游戏产生了浓厚兴趣，让我意识到游戏不仅仅是一个娱乐方式，更像是部电影、艺术，每一帧画面、每一段配乐、每一个剧情都蕴含着制作者的匠心。不仅是对自己兴趣的一次探索，也是一种对高品质游戏制作的致敬。

远程工作​

就当我即将结束我的长假之时，一则私信引起了我的注意。

对方看到我的技术栈与他的项目十分贴合，阅读了我职场故事会（原来写小作文真有用啊），便向我抛出橄榄枝，但当时的我还没那么想要再次进入工作状态，况且这家公司又是 AI 初创公司（我对初创公司已经有 PTSD 了，生怕再经历类似的职场故事🥲），所以当时的我对这份机会此挺无所谓的。

后面进一步的了解，发现是老板自己搞 B2B 的项目，不愿招外包，于是就在 X 上招聘，并找到了我。于是安排了场 2 小时视频通话，聊了聊我过往的项目经历，就这样拿到了该 Remote 的 Offer 😄，同时也多了一位美国朋友。

即便没有这个 Remote 机会，我也会选择尝试寻求其他海外的远程工作机会，因为我已经对坐班工作产生了厌倦感，我想要的更多是自由，而非束缚。

虽说是初创公司，但各种合同手续也都齐全，还是先发工资再干活（用老板的话讲就是：他先发薪资是我欠老板的，我先干活再拿钱是我欠老板的），时间上自由不少(就是要倒时差)， AI 工具服务必须齐全。本来还答应圣诞给我换台 Macbook，不过我还没到换设备的程度（其实是我觉得换设备迁移数据太麻烦了）。

业余时间的视频会议还让我看了真🔫，大🚬，这很🇺🇸特色。不过对我最不适应的还是来自于沟通而非技术。也让我深刻意识到了英语在远程工作，乃至未来职业发展的重要性。

去年这时候我对我未来的职业规划有所思考，其中就提到了远程工作。如今我确实达到了当初对职场的期望。

或许是因为过往的职场经历在简历上不够看，大厂经历或许能给职业生态添金，加上学历的自卑，总让我对大厂一直怀有向往。但当我与一些大厂员工的谈话之后，他们反倒羡慕我的远程工作生活，至少不用 996，不用坐班。或许这就是人们总是向往他人的生活，却不知对方的苦恼。

🐈

突如其来的变故致使我不得不马上搬家，正当决定新住所的时候，脑海里浮现直接回到老家生活并开始 Remote 工作的决定，并且还能迎接了我的新伙伴😽

我一毕业就想养猫，但我姐的鼻子对味道特别敏感，与她同住就更不可能了（这才是我回老家的最大原因），因为搬家的变故，养猫成为了现实。

养猫让我身心舒畅，但也让我分心乏力。关于养猫的记录，我想过段时间经历了更多再做更细致的分享，是一篇劝退指南😿。

给自己的话​

相比以往在大学期间自我摸索技术，今年尝试了很多之前不曾接触的事情。网友面基，参加技术大会，游玩方特，远程工作，养猫等等，相比之前大学期间只会宅在家里专研技术，却不懂的体验生活的我，或许是因为喜欢折腾的性格，也或许是因为大学期间的压抑，让我在现在更加渴望体验生活。

这一年，从独自摸索到与团队协作，从封闭的校园到远程工作，也让我逐渐认识到，技术只是工具，技术的提升可能是人生中最不起眼的东西，更有意义的是这个过程的体验、成长、感悟。

感谢自己愿意尝试未知，希望这份勇于尝试的心态让我始终保持热爱与激情。

往年回顾​

• 2023 · 谈谈职业规划
• 2023 · 叙一名转专业+休学的大学生经历
• 2022 · 逆向到Web开发
• 2021 · 休学一年
• 2020 · 编程之旅-起点

这还没完，当你需要数据验证、错误处理、中间件等等功能，又得花费不小的功夫，所以 Next.js 的 API Route 更多是为你的全栈项目编写一些简易的 API 供外部服务，这也可能是为什么 Next.js 宁可设计 Server Action 也不愿为 API Route 提供传统后端的能力。

但不乏有人会想直接使用 Next.js 来编写这些复杂服务，恰好 Hono.js 便提供相关能力。

这篇文章就带你在 Next.js 项目中要如何接入 Hono，以及开发可能遇到的一些坑点并如何优化。

Next.js 中使用 Hono​

可以按照 官方的 cli 搭建或者照 next.js 模版 https://github.com/vercel/hono-nextjs 搭建，核心代码 app/api/[[...route]]/route.ts 的写法如下所示。

import { Hono } from 'hono'
import { handle } from 'hono/vercel'

const app = new Hono().basePath('/api')

app.get('/hello', (c) => {
  return c.json({
    message: 'Hello Next.js!',
  })
})

export const GET = handle(app)
export const POST = handle(app)
export const PUT = handle(app)
export const DELETE = handle(app)

从 hono/vercel 导入的 handle 函数会将 app 实例下的所有请求方法导出，例如 GET、POST、PUT、DELETE 等。

一开始的 User CRUD 例子，则可以将其归属到一个文件内下，这里我不建议将后端业务代码放在 app/api 下，因为 Next.js 会自动扫描 app 下的文件夹，这可能会导致不必要的热更新，并且也不易于服务相关代码的拆分。而是在根目录下创建名为 server 的目录，并将有关后端服务的工具库(如 db、redis、zod)放置该目录下以便调用。

至此 next.js 的 api 接口都将由 hono.js 来接管，接下来只需要按照 Hono 的开发形态便可。

数据效验​

zod 可以说是 TS 生态下最优的数据验证器，hono 的 @hono/zod-validator 很好用，用起来也十分简单。

import { z } from 'zod'
import { zValidator } from '@hono/zod-validator'
import { Hono } from 'hono'

const paramSchema = z.object({
  id: z.string().cuid(),
})

const jsonSchema = z.object({
  status: z.boolean(),
})

const app = new Hono().put(
  '/users/:id',
  zValidator('param', paramSchema),
  zValidator('json', jsonSchema),
  (c) => {
    const { id } = c.req.valid('param')
    const { status } = c.req.valid('json')

    // 逻辑代码...

    return c.json({})
  },
)

export default app

支持多种验证目标(param,query,json,header 等)，以及 TS 类型完备，这都不用多说。

但此时触发数据验证失败，响应的结果令人不是很满意。下图为访问 /api/todo/xxx 的响应结果（其中 xxx 不为 cuid 格式，因此抛出数据验证异常)

所返回的响应体是完整的 zodError 内容，并且状态码为 400

因为 zod-validator 默认以 json 格式返回整个 result，代码详见 zod-validator/src/index.ts#L68-L70

这就是坑点之一，返回给客户端的错误信息肯定不会是以这种格式。这里我将其更改为全局错误捕获，做法如下

1. 复制 zod-validator 文件并粘贴至 server/api/validator.ts，并将 return 语句更改为 throw 语句。

   if (!result.success) {
-    return c.json(result, 400)
   }

   if (!result.success) {
+    throw result.error
   }

2. 在 server/api/error.ts 中，编写 handleError 函数用于统一处理异常。（后文前端请求也需要统一处理异常）

import { z } from 'zod'
import type { Context } from 'hono'
import { HTTPException } from 'hono/http-exception'

export function handleError(err: Error, c: Context): Response {
  if (err instanceof z.ZodError) {
    const firstError = err.errors[0]

    return c.json(
      { code: 422, message: `\`${firstError.path}\`: ${firstError.message}` },
      422,
    )
  }

  // handle other error, e.g. ApiError

  return c.json(
    {
      code: 500,
      message: '出了点问题, 请稍后再试。',
    },
    { status: 500 },
  )
}

3. 在 server/api/index.ts ，也就是 hono app 对象中绑定错误捕获。

const app = new Hono().basePath('/api')

app.onError(handleError)

4. 更改 zValidator 导入路径。

- import { zValidator } from '@hono/zod-validator'

+ import { zValidator } from '@/server/api/validator'

这样就将错误统一处理，响应体也自定义，且后续自定义业务错误也同样如此。

RPC​

Hono 有个特性我很喜欢也很好用，可以像 TRPC 那样，导出一个 client 供前端直接调用，省去编写前端 api 调用代码以及对应的类型。

这里我不想在过多叙述 RPC(可见我之前所写有关 TRPC 的使用)，直接来说说有哪些注意点。

链式调用​

还是以 User CRUD 的代码为例，不难发现 .get .post .put 都是以链式调用的写法来写的，一旦拆分后，此时接口还是能够调用，但这将会丢失此时路由对应的类型，导致 client 无法使用获取正常类型，使用链式调用的 app 实例化对象则正常。

替换原生 Fetch 库​

hono 自带的 fetch 或者说原生的 fetch 非常难用，为了针对业务错误统一处理，因此需要选用请求库来替换，这里我的选择是 ky，因为他的写法相对原生 fetch 更友好一些，并且不会破坏 hono 原有类型推导。

在 lib/api-client.ts 编写以下代码

import { AppType } from '@/server/api'
import { hc } from 'hono/client'
import ky from 'ky'

const baseUrl =
  process.env.NODE_ENV === 'development'
    ? 'http://localhost:3000'
    : process.env.NEXT_PUBLIC_APP_URL!

export const fetch = ky.extend({
  hooks: {
    afterResponse: [
      async (_, __, response: Response) => {
        if (response.ok) {
          return response
        } else {
          throw await response.json()
        }
      },
    ],
  },
})

export const client = hc<AppType>(baseUrl, {
  fetch: fetch,
})

这里我是根据请求状态码来判断本次请求是否为异常，因此使用 response.ok，而响应体正好有 message 字段可直接用作 Error message 提示，这样就完成了前端请求异常处理。

至于说请求前自动添加协议头、请求后的数据转换，这就属于老生常谈的东西了，这里就不多赘述，根据实际需求编写即可。

请求体与响应体的类型推导​

配合 react-query 可以更好的获取类型安全。此写法与 tRPC 十分相似，相应代码 → Inferring Types

// hooks/users/use-user-create.ts

import { client } from '@/lib/api-client'
import { InferRequestType, InferResponseType } from 'hono/client'
import { useMutation } from '@tanstack/react-query'
import { toast } from 'sonner'
const $post = client.api.users.$post

type BodyType = InferRequestType<typeof $post>['json']

type ResponseType = InferResponseType<typeof $post>['data']

export const useUserCreate = () => {
  return useMutation<ResponseType, Error, BodyType>({
    mutationKey: ['create-user'],
    mutationFn: async (json) => {
      const { data } = await (await $post({ json })).json()

      return data
    },
    onSuccess: (data) => {
      toast.success('User created successfully')
    },
    onError: (error) => {
      toast.error(error.message)
    },
  })
}

在 app/users/page.tsx 中的使用

'use client'

import { useUserCreate } from '@/features/users/use-user-create'

export default function UsersPage() {
  const { mutate, isPending } = useUserCreate()

  const handleSubmit = (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault()
    const formData = new FormData(e.currentTarget)
    const name = formData.get('name') as string
    const email = formData.get('email') as string
    mutate({ name, email })
  }

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <label htmlFor='name'>Name:</label>
        <input type='text' id='name' name='name' />
      </div>
      <div>
        <label htmlFor='email'>Email:</label>
        <input type='email' id='email' name='email' />
      </div>
      <button type='submit' disabled={isPending}>
        Create User
      </button>
    </form>
  )
}

OpenAPI 文档​

这部分我已经弃坑了，没找到一个很好的方式为 Hono 写 OpenAPI 文档。不过对于 TS 全栈开发者，似乎也没必要编写 API 文档（接口自给自足），更何况还有 RPC 这样的黑科技，不担心接口的请求参数与响应接口。

如果你真要写，那我说说几个我遇到的坑，也是我弃坑的原因。

首先就是写法上，你需要将所有的 Hono 替换成 OpenAPIHono (来自 @hono/zod-openapi， 其中 zod 实例 z 也是)。以下是官方的示例代码，我将其整合到一个文件内

import { createRoute, OpenAPIHono, z } from '@hono/zod-openapi'
import { swaggerUI } from '@hono/swagger-ui'

const app = new OpenAPIHono()

const ParamsSchema = z.object({
  id: z
    .string()
    .min(3)
    .openapi({
      param: {
        name: 'id',
        in: 'path',
      },
      example: '123',
    }),
})

const UserSchema = z
  .object({
    id: z.string().openapi({ example: '123' }),
    name: z.string().openapi({ example: 'John Doe' }),
  })
  .openapi('User')

const route = createRoute({
  method: 'get',
  path: '/api/users/{id}',
  request: {
    params: ParamsSchema,
  },
  responses: {
    200: {
      content: {
        'application/json': {
          schema: UserSchema,
        },
      },
      description: 'Retrieve the user',
    },
  },
})

app.openapi(route, async (c) => {
  const { id } = c.req.valid('param')

  // 逻辑代码...
  const user = {
    id,
    name: 'Ultra-man',
  }

  return c.json(user)
})

从上述代码的可读性来看，第一眼你很难看到清晰的看出这个接口到底是什么请求方法、请求路径，并且在写法上需要使用 .openapi 方法，传入一个由 createRoute 所创建的 router 对象。并且写法上不是在原有基础上扩展，已有的代码想要通过代码优先的方式来编写 OpenAPI 文档将要花费不小的工程，这也是我为何不推荐的原因。

定义完接口(路由)之后，只需要通过 app.doc 方法与 swaggerUI 函数，访问 /api/doc 查看 OpenAPI 的 JSON 数据，以及访问 /api/ui 查看 Swagger 界面。

import { swaggerUI } from '@hono/swagger-ui'

app.doc('/api/doc', {
  openapi: '3.0.0',
  info: {
    version: '1.0.0',
    title: 'Demo API',
  },
})

app.get('/api/ui', swaggerUI({ url: '/api/doc' }))

从目前来看，OpenAPI 文档的生成仍面临挑战。我们期待 Hono 未来能推出一个功能，可以根据 app 下的路由自动生成接口文档（相关Issue已存在）。

仓库地址​

附上本文中示例 demo 仓库链接（这个项目就不搞线上访问了）

https://github.com/kuizuo/nextjs-with-hono

后记​

其实我还想写写 Auth、DB 这些服务集成的(这些都在我实际工作中实践并应用了)，或许是太久未写 Blog 导致手生了不少，这篇文章也是断断续续写了好几天。后续我将会出一版完整的我个人的 Nextjs 与 Hono 的最佳实践模版。

也说说我为什么会选用 Hono.js 作为后端服务, 其实就是 Next.js 的 API Route 实在是太难用了，加之轻量化，你完全可以将整个 Nextjs + Hono 服务部署在 Vercel 上，并且还能用上 Edge Functions 的特性。(就是有点小贵)

但不过从我的 Nest.js 开发经验来看（也可能是习惯了 Spring Boot 那套三层架构开发形态），总觉得 Hono 差了点意思，说不出来的体验，可能这就是所谓的全栈框架的开发感受吧。

已经在一家 AI 公司入职了一个月，对坐班有些厌恶的我，没想到有一天也会开始通勤打卡。而经历了这一个月的工作，我对坐班的态度有所转变，开始理解这种工作方式对我的意义。是时候分享入职这期间的工作内容与感受。

背景​

直入正题，先说职位背景。该职位的技术要求大致如下，仅做参考。

## 任职要求 
1. 本科及以上学历，计算机科学、软件工程等相关专业, 硕士优先； 
2. 扎实的 HTML、CSS、JavaScript 基础(vanilla) 功底 ； 
3. 熟练使用 React、React Native 和 Next.js 进行前端开发 
4. 了解前端性能优化技术，如代码压缩、懒加载等 
5. 熟悉前端工程化工具 
6. 具备良好的问题解决能力和团队协作精神 
7. 熟练阅读英文技术文档 
8. 有优异前端项目开发经验者优先 

## 加分项： 
- 贡献开源社区 
- 有 AI 相关项目经验。 
- 有前端性能优化和 SEO 优化经验。 
- 有良好的产品思维和设计(UI/UX)意识。 
- 有同理心思维。
- 具有一定的审美感。

很贴合国外主流的技术栈（至于为何，看后文便知），比较巧的是，我的 Web 全栈学习路线就是偏国外的技术栈。因此在技术栈上，这家公司是我喜欢的，恰巧又是 AI 开发，能让我尝试到一些前沿技术，也正好是想我折腾的。

求职经历​

我是 Boss 直聘上找的（这里没给 boss 直聘打广告，我甚至还是第一次使用 boss 直聘），我有想过找人内推，但由于家庭因素被限定在福州这座城市，而内推的所在的城市往往都是那些一线城市，加上我的八股文和算法很不过关（我也很不情愿刷），到时候面试那关估计也不乐观。

因此就在 Boss 上碰碰运气，也顺带体验一下新人都是怎么找工作的。

从五一的时候开始准备简历和项目，在5号开始投简历，投递简历一关我是直接怼着工作经验1-3年的来投，而不是投应届或实习岗。因为我确实有一些工作经验，只不过不是正常的坐班打卡的形式，这在之前的博客中有说到。

在这期间共投了20多家，基本都是已读不回，就更别说投递简历了。后来我才了解到，原来 HR 回复消息是要花钱的，发布一个岗位也是。

唯一回复的还是我现在入职的这家，而且我还投了两份过去，一份是给 HR 的（没回），一份是给技术 leader 的（leader 回了）。

面试被鸽​

可能是由于当时这个岗位急招的原因，在 boss 直聘上也没多说什么，leader 就约明早 11 点来公司现场初步面试聊天一下。这期间还发生了一个小变故，我到公司了，可联系不上面试官，打了微信电话也无果。待了10来分钟后我就走了，等了约一个小时都没信息，那我大概率是被鸽了，还不提前和我通知一声，然后在boss上留下了这句评价🥲。

初入职场，初次面试就这种情况，说真的我当时都有点心灰意冷了，我猜想是不是因为有其他合适的人选，于是就不招我了，就连信息也不给我打一个招呼，相当于把我拉黑似得。随后我就到附近的麦当劳花了 10 元的套餐安慰了一下自己，麦！

开始面试​

直到到下午一点多的时候，面试官回复我说当时他们在开会，期间不让携带电子设备。早上就当一面过了，问我下午有没有时间，直接二面技术面(code test)过了就直接拿offer。

这时我才知道，原来早上也仅仅只是我的猜想，但我还是有点不想去了，心情有点不太愉悦，但想了想也懒得计较了，过去就当聊天罢了。到了下午面试问的就偏前端基础、八股文那些问题，其实我回答的巨烂，确实也没好好刷题，也不喜欢刷题，就面试了。自己写代码是由业务环境下驱动的，并从中寻求最佳实践。但好在我的技术面是比较广的，很多前沿的前端相关的工具库或多或少都使用过，也能侃侃而谈，加上个人 blog 和 github 这两个大加分项。就进入到了一个代码考核测试，不限框架，不限规则，使用公司的电脑打开 codesandbox 写一个todo list，前提是不使用任何 AI 工具。

这不正好到了我的强项，之前学某个框架的时候，不知道写什么demo，就写 todo list 来练手😂。恰好这次我就使用 next.js app router + Tailwindcss 的模版并且使用 form 标签的 action 和 use server 来实现新增功能。 能体现出我有在使用 next.js，而且用上了一些新特性，就拿到 offer 了。

听完之后是不是莫名的感觉这个 offer 拿的好像有点莫名其妙的感觉😂，不管怎么样结果是好的就行了。

不过拿到 offer 后，我并没有选择马上入职，经历了一次被鸽的经历，对该公司的印象带有一些怀疑。其次就是这是一家初创 AI 公司，规模不大，从应届生找工作的角度，第一份正式的工作的起点很关键，如果能直接进大厂，后续跳槽到其他公司大概率也不成问题。

但在当地我投递了 20 多家已读不回的情况下，加上这份已有的 offer 不等人（急招），加上我家里人给我推荐的工作内容我并不是很满意，于是思考了两天，最终还是选择入职了这家公司。

薪资​

比较令我差异的是我与企业签订的直接劳动合同，可能是因为我直接投递 1-3 年的工作经验，但我此时的身份还是应届生，按理来说我应该是签订实习合同后，转正再签劳动合同，难道说我已经提前转正了？。不过也好，这样和学校的三方协议都可以不用签了，直接给劳动合同便可。

试用期 3 个月，薪资打 8 折。薪资在我当地还算 ok，但对于我而言并不理想。可能是会的比较多(全栈？全干！)，加上曾经赚过比这还高上许多的薪资，从内心的角度多少是有些不平衡。不过目前还是试用期，薪资这方面后续也能再谈。

接下来尤为重要的上班体验才是让我觉得没后悔入职这家公司。

上班体验​

介绍一下公司部门的办公工具

办公管理：企业微信

团队协作：Slack

任务看板：Trello

代码仓库：Github

代码托管：Vercel

视频会议：Zoom

你会发现除了企业微信，其他的应用都是国外的。怎么看都不是一家国内的企业吧，这是因为我部门的 Leader 是海外留学的，这也就不难理解工具是国外应用，技术栈选型是 React 生态了。

入职的第一周部门开了个小会，就是简单介绍了一下部门的任务职责，每个成员自我介绍。重点是提供一个优质的学习环境，像是技术书籍，电子设备，UI 模版或是技术会议的门票等费用，只要对部门有利，能提升自己，都可以找他报销。

我已经找 Leader 报销了个 magic ui pro，大约 420 块，直接找财务刷卡，付款的感觉是真爽，我是真爱了🥰。

几天后，公司来了一个阿里做 B 端低代码开发的同事，也是负责前端开发，这不，我可以间接和这个老哥那学习大厂相关经验，我还正愁着没大厂相关的经验😄。

我询问他来这家公司的原因，他说被裁了，在家接外包一年了，不稳定就准备找工作，恰好这家公司急招，于是就来了。

团建​

在我入职的第一周周末 Leader 为整个部门安排团建，由于这个部门成立不到 2 周，来的都是新成员，让我们自己组个局，去外面吃个饭。

也是在团建的时候了解到同事的履历一个个都不简单，有 985 的，有海外留学的，有在阿里、网易待过的，还有我这不堪回首的经历 🤡。

后面原定在 61 安排整个公司的团建，但由于天气和周末时间去的人少的因素而取消了，这我就不多说了。

端午之后的第一个工作日的中午，补过端午节部门聚餐的，这我也不多说了。就是怎么感觉这频率有点不太对，然后实际项目产出也还停留在 Spring 1 的阶段，让我有些不自在。

福利​

部门每个月都会定一个最佳员工奖，我很荣幸获得部门本月的最佳员工，也感谢部门成员的认可，奖励是 300 元奖金或一日自由假。

甚至还有一张奖状，就是这奖状怎么有点像给小学生似的。（事后我才了解到这奖状还是用打印机打印的😂）

目前我已经能感受到最大的福利就是那个 magicui 动效库的模版，当然了，这个是要给公司的官网用上的，我也是蹭公司的福，给自己的站点用上了这个动效库。

此外像节日福利，如这次端午节，就是聚餐和发粽子，这也就没什么好说的。

通勤​

公司距离我租房的地方只有 2 公里，每日的通勤总时间大约 40 分钟，早上大约 8 点起床，我通常坐公交车到公司附近的早餐店吃个早饭，吃完差不多 8 点 40分~50 分。中午外卖就不说了。下午下班从公交车和走路做个选择，吃完饭回到家。

黑客松​

黑客松(hackathon)，也称编程马拉松比赛。我是第一次听说过这个词，Leader 给定两个选题一个是打造某市地铁智能出行，另一个是给某商场的提供贴心的购物体验，发挥自己近一个月所学的知识，去创造一个供用户使用的 AI 程序，月底交付，奖金 3000 元/小组，抽签分组。我们当时部门有个人提了一嘴，要不我们两小组自己商量一下，把奖金平分得了😂。

不过对于这个行为，我个人认为目的是为了激励员工之间协同合作，但同时也免不了技术上的内耗，毕竟这个比赛不是我们的主要工作内容。

工作内容​

我想肯定有很多人对 AI 开发的刻板印象是要会大模型开发，会懂得微调，会懂得人工智能算法。这个想法也没错，但从开发 AI 应用的角度，其实蛮需要前端的，尤其是会全栈框架的前端。

这里我不得不惊叹 next.js 的生态，很多 AI 相关的例子可以直接从 Vercel 的 AI Template 下学习，预览是否有你需要的功能，Clone 到本地，然后运行项目，对某些部分进行更改。搭建 AI 应用也是异常的快。

仿 AI SDK 网站效果​

Leader 下发的一个任务，入职的前两周主要让我熟悉一些怎么使用 next.js 配合 vercel 的 ai sdk 来开发 AI 应用，如怎么调用 openai 的模型，实现一个 ai chatbot。给定了一个任务就是仿造 AI SDK，由于该项目没有开源，自然就只能另辟蹊径。

首先就是仿造页面了，这个作为前端开发，实现起来也算容易，更何况这个这个页面的样式使用 Tailwindcss 编写，直接通过审查元素仿造就行了。

其次在功能实现上，ai sdk 文档都提供了非常完善的解决方案，照着文档将代码稍微改写一下便可，具体的细节就不演示了。

官网首页​

两周后开始正式项目开发了，首当其冲的就是官网页。

这里当时 Leader 问我有没有用过 Gatsbyjs，要用这个框架搭建一个官网。我表明我没用过，但我提了一嘴如果要搭建偏内容向的网站，可以考虑 Astro，我愿意折腾一番（我也一直想学 Astro 的）。不过最终在开发时间和成本的商讨下还是选择使用 next.js 来搭建，leader 还顺带给我推荐了一个动效库 magicui，叫我看看里面的案例，看看能不能给官网加点动效。 之后就有了上文提到报销 magicui 的事。

Rag bot​

篇幅实在有限，有关 RAG 的不做过多解释，它可以让你的 AI 应用更具有权威性，让数据的来源可靠，而非胡乱生成数据。

RAG 的基本流程就是：

1. 用户输入提问
2. 检索：根据用户提问对 向量数据库 进行相似性检测，查找与回答用户问题最相关的内容
3. 增强：根据检索的结果，生成 prompt。 一般都会涉及 “仅依赖下述信息源来回答问题” 这种限制 llm 参考信息源的语句，来减少幻想，让回答更加聚焦
4. 生成：将增强后的 prompt 传递给 llm，返回数据给用户

在这个应用开发中，借鉴了 ragbot-starter 这个开源项目，同时向量数据库选用 datastax 公司的Astra DB。

恰好在开发这个应用的期间，我也正好在学习 Langchain.js，所以在数据处理这部分有点得心应手，目前应用还只停留在处理本地文件或用户上传的文件，只需要配置各种 File Loader 便可。

使用 RN 实现 chatbot​

先看 Gif 效果。

第一次用 Screen Studio，显示的不是很好，还请见谅，主要就是实现一个流式文本效果。

这里简单说下怎么实现的，就用 react-native-reusables 的模版(React native 的 Shadcn/ui) + react-native-gen-ui 实现的，不过后者的功能比较单一，后续估计要改代码了。代码就不贴了，我怕涉嫌代码泄露（其实已经泄露差不多了）。

收获​

要我说最大的收获不是遇到一个氛围不错的公司，遇到一个好 leader，也不是接触 AI 开发从中学到了什么，更不是增进了我的技术栈。而是让我养成良好的习惯，开始正常一日三餐，开始作息规律，开始将工作与生活分离，身体状态也渐渐好了起来。

下图为 5 月的生物作息，基本都保持 0 点前入睡。（不过在我写这篇文章的时候已经两点了🥱）

过去几年内我的作息与饮食都非常糟糕，能明显的感觉到状态有所下滑，编写代码的效率和能力也明显不如以前，有些力不从心。今年都快过去一半了，而我仅仅完成了2篇博文的写作，文章的输出效率明显不行😮‍💨。

在半年前我对自己当时的现状做了个分析，幻想着坐班或许能改变我当下的现状。如今经历了这一个月的坐班生活，可能是因为坐班而改变，也可能是公司的氛围，不管是那种，让我跳出我原有舒适区，重新拾起对新颖事物的兴趣，重新点燃学习某个技术的热情，重新找回了自我。

结尾​

在我还没找工作之前，从我几个同届毕业的同学和网友的反馈得知今年的就业环境异常险峻。不仅如此，我还在网络上看到了大量工作者对自身工作的抱怨与不满，这些现象让我在工作前让我对未来的就业前景感到了一些不安。

当我亲身入局感受一番，也不禁开始低声叹气。开始思考是什么原因导致了如今大环境不好的现象，人为的制造就业焦虑，还是当下现实本就如此。当我跳出思考，回到现实难道环境好就一定挣钱多，环境差就一定挣钱少吗？社会似乎并不是这么简单的等式。

我逐渐意识到，无论大环境如何，每个人的努力和选择仍是至关重要。在面对不确定性和挑战时，保持学习和进步的态度，以及寻找自己的核心竞争力，才是应对困境的关键。

真正的职业安全感并不完全来自于外部环境，而是来自于我们自身不断提升的能力和适应变化的灵活性。

代码仓库： https://github.com/kuizuo/youni

为什么是 RN 而不是 Flutter？​

很简单，就是技术栈问题。从开发角度而言，尤其还是对于前端开发人员，会 JS 且搞过 React ，那 RN 上手就十分友好，最起码有关 React 社区的逻辑库或状态库是可以使用的。

虽说 Flutter 的性能是会比 RN 好上不少，但抛开需求不谈，与其比性能不如比开发速度。很显然开发 RN 的效率比 开发 Flutter 高上不少。况且真在意性能的话，那多半就不会考虑跨平台技术了，而是直接考虑原生开发了。

再从需求考量，我所编写的应用更偏向于内容展示的 app，而不是编写一个手机电池监控或者内存监控的app，如果是后者，那这时选择任何跨平台开发都没有意义，像这些系统级别的API在跨平台开发基本不太可能实现的。

对于这两个跨平台技术的选择，应该考虑自身需求、开发成本、技术选型，没有最好的只有最适合的。如果有的选择，谁不会选择原生开发是吧。

但凭我自己接触 RN 以来，国内的 RN 资源甚少，反倒是 Flutter 资源很多，并且从这些相关资料来看，确实 Flutter 优于 RN，但还是那句话，这里就不再过多赘述了。

是否有必要学 react-native？​

先说一个结论：RN ≠ 原生，别指望会个 react 就能写出靠谱的原生应用。

就从我的开发经历来说，坑是真的多，但好在RN拥有庞大的线上社区，可以找到的几乎所有问题的答案。但国内的社区好像并不是很好，很多问题我都是在国外论坛中解决的。

如果你学习它是为了扩展其他平台的开发能力，那么还是可以学习一番的，会有另一番的收获。但如果学 RN 只是为了避免不用学 android 和 iOS 等原生技术就能写 app，那便不建议学习。抱着这心态的话前期开发可能不明显，但到了后面会踩很多坑，而且两眼一黑，因为你不懂 native 开发。

我的个人评价是 RN 只能作为 H5 手机页面运行在原生移动设备的一种展示形态。虽然本质不是，但其所展示的效果如同。RN 不仅仅只是 Web，但也止步于 Web。

顺带吐槽一番，React-Native 项目发布4年多了，还没有 1.0 版本么(¬_¬)

如果你想再继续了解 RN，那么就请往下看。

Expo​

Expo 是基于 React Native 并整合大量常用的 native module(Expo SDK)，像原生的功能如相册，相机，蓝牙等功能，在 expo 都是直接集成的，相当于封装原生的api，暴露给js调用。因此你不用去了解原生开发的许多知识和坑点，上手即用便可。本地配置好应用所需的环境，就直接直接运行 RN 项目，开发十分方便。

此外 Expo 还提供了 Expo Go App，只需要在你的移动端设备中安装它，启动开发服务器并生成 QR 码。在浏览器打开 snack.expo.dev ，点击 MyDevice，扫码并在 Expo app 中查看。

会自动将该程序实时运行在你的移动端设备，意味着你更改代码也将会同步到Expo go 中。极大程度上提升 RN 的开发体验，尤其是在真机测试阶段。

Expo 官方还贴心的提供了云服务 Expo Application Services (EAS)，意为这你可以你可以将你的 RN 项目在托管在云服务上，来执行构建与发布等流程。

总之如今开发 RN 请毫不犹豫的使用上 Expo。

开发中遇到的一些坑点​

实际开发中所遇到的坑点远不止下述所说，这里只列举几个相对有代表，坑比较深的点。甚至有很多坑都不是前端方面的知识了。

在 pnpm 下无法启动 Android​

错误提示：Error: Unable to resolve module ./nxode_modules/expo/AppEntry

解决方案：在项目根目录创建 .npmrc ，内容如下

shamefully-hoist=true
node-linker=hoisted

删除 node_modules 与 .expo 文件夹，重新安装依赖即可。

相关链接：https://github.com/expo/expo/issues/9591#issuecomment-1485871356

样式问题​

在样式方面与传统的 Web 开发存在一定的区别。在 RN 中有两个主要组件，View 与 Text，可以理解为 Web 的 div 与 span。基本所有的 View 都是 flex 布局，想要让 View 组件占满通常不会使用 width: ’100%’ 或 height: ‘100%’，而是使用 flex: 1，例如一般都会带上这么一个样式。

<View style={{ felx: 1 }}>

如果样式问题就只是这样就好了，同一套样式在不同平台上所展示的效果都可能不大一样，尤其使用原生 Web 的样式，哪怕你用 style 编写，在 Web 网页也能成功显示效果，但是在 IOS 与 Android 中绝大多数情况下是不显示的。这会在后面介绍 Tailwindcss 相关库的时候会额外在提到一点。

文本必须要用 Text 包裹​

如果不怎么做的话，会报错，如果只是这样倒还没什么。重点是错误提示并没有堆栈信息！就如下图所示

这点对于开发体验而言并不友好。

模拟器无法请求本地 api​

由于一开始是在 Web 端进行调试开发的，所以没留意到这个问题，直到切换到安卓模拟器之后发现模拟器无法请求本地后端服务，在IOS 端暂无这问题。因此需要做如下配置：

1、首先将模拟器内网切换到本地。

假设后端 api 地址为 [http://localhost:6001](http://localhost:6001)，正常情况下，开发环境下的调试主机可以通过如下方式获取

import Constants from 'expo-constants'

const debuggerHost = Constants.expoConfig?.hostUri
// 192.168.123.233:8081

接着所要做的就是将 192.168.123.233:8081 替换成我们的目标端口 192.168.123.233:6001

这里以 axios 为例， 先为环境变量添加 EXPO_PUBLIC_API_URL=http://localhost:6001，具体替换的代码如下所示

export const client = axios.create({
  baseURL: getApiUrl(),
  timeout: 5000,
})

export function getApiUrl() {
  const apiUrl = process.env.EXPO_PUBLIC_API_URL
  return replaceLocalhost(apiUrl)
}

export function getLocalhost() {
  if (localhost !== undefined) return localhost

  const debuggerHost = Constants.expoConfig?.hostUri
  // 192.168.123.233:8081
  localhost = debuggerHost?.split(':')[0] ?? 'localhost'
  return localhost
}

export function replaceLocalhost(address: string) {
  const PROTOCOL = 'http:'
  const localhostRegex = new RegExp(`${PROTOCOL}\/\/localhost:`, 'g')
  return address.replace(localhostRegex, () => `${PROTOCOL}//${getLocalhost()}:`)
}

2、端口转发

此外还需要执行以下命令转发端口。

adb reverse tcp:6001 tcp:6001

此时安卓模拟器便可正常请求本地后端服务的资源，IOS 端并未有该问题。

组件库的选择​

如今在 UI 的选择上，我是毫不犹豫选择 Tailwindcss，在 RN 使用 Tailwindcss 有两个库可以作为选择 nativewind 和 twrnc。

nativewind​

nativewind 采用 Web 的 className 属性，其用法如同 Web 开发使用 Tailwindcss 的写法，这里便不过多展示了。

twrnc​

twrnc 的写法则有些不同，需要通过 tw 包装，然后填写到 style 中，就如下图所示

import { View, Text } from 'react-native'
import tw from 'twrnc'

const MyComponent = () => (
  <View style={tw`p-4 android:pt-2 bg-white dark:bg-black`}>
    <Text style={tw`text-md text-black dark:text-white`}>Hello World</Text>
  </View>
)

事实上有很多 Web 端支持的类，在移动端并不能生效，通常来说只适合用 Tailwindcss 来编写基本的宽高，内外边距等样式。

这两个库的区别​

从 Web 开发使用的角度，nativewind 会更好用一些， npm 实际使用量也确实比 twrnc 来的多，但要在一些情况下，比如给第三方组件更改 props 的样式情况下就会没有 twrnc 那么直观了，例如一些第三方组件有 xxxStyle 属性，例如 contentContainerStyle，这时 twrnc 就方便很多。

<FlatList style={tw`flex-1`} contentContainerStyle={tw`p-4`} />

而 nativewind 则繁琐许多，下图例子。

// This component has two 'style' props
function ThirdPartyComponent({ style, contentContainerStyle, ...props }) {
  return <FlatList style={style} contentContainerStyle={contentContainerStyle} {...props} />
}

// Call this once at the entry point of your app
remapProps(ThirdPartyComponent, {
  className: 'style',
  contentContainerClassName: 'contentContainerStyle',
})

// Now you can use the component with NativeWind
<ThirdPartyComponent className="p-5" contentContainerClassName="p-2" />

再者，twrnc 可以使用动态变量，例如在 RN 中经常需要处理安全区域，如下写法在 twrnc 就支持，但 nativewind 则不生效。

const { top } = useSafeAreaInsets();

<View style={tw`pt-[${top}]`}> // twrnc 支持

<View className={`pt-[${top}]`}> // nativewind 不支持

tamagui(不推荐)​

我便提一下 tamagui 这个组件库。tamagui 看似很炫酷，但是实际配置的过程异常的繁琐，用起来也没有特别舒服，可以看以下示例代码。

<XStack flex={1} justifyContent="center" alignItems="center" gap="$2">
  <Button size="$3" theme="active">
    Active
  </Button>
  <Button size="$3" variant="outlined">
    Outlined
  </Button>
</XStack>

其效果就是一个容器内包含两个按钮，样式编写上则通过 prop 属性来实现，用过 unocss 的 Attributify Mode 应该会有些许熟悉，但还不那么一样。

并且他的主题系统使用极其的怪，采用 $number 的形式来定义尺寸(官方称 token)，重点是宽高和边距采用相同的 token 效果还不一样，贴个图。

但他的颜色更是一言难尽了，从 color0 到 color11 的效果就如下图

可能是因为我用惯了 Tailwindcss 那套颜色系统，所以很不能理解这套颜色系统，并且在我实际编写组件的过程也是异常的奇怪。

但最让我想吐槽的是官方还为此提供了一个主题系统配置的生成器网站，但只有 tamagui 的赞助者才能够使用，如果想要自己定义一个主题，就需要配置特别多的文件，总之就是很难用就对了。

顺带在贴一张 Provider 嵌套

这里我就不得不提到我为啥一开始选用 tamagui 了(现已迁移到 gluestack-ui)，说实话我是有点后悔的，在一开始选定 UI 库的时候，我是选择 NativeWind 的，但后面无意刷到了 T4-stack (算是被他坑了)，而它所用的便是 tamagui，并且一套代码跑 expo 与 next.js。于是便采用相同的项目结构以及 UI 库了。但事实上在我编写的过程中，想要一套代码就能实现跨三端(web,android,ios) 效果并不佳了，这在下一章便会说到。

gluestack-ui​

首先它与 tamagui 相似，也采用 token 的方式来定义尺寸样式，但该库所对标的 token 设计就是Tailwindcss。此外该 UI 提供 NativeWind 的定制方案，意味着你的项目中可以集成了 NativeWind 用 Tailwindcss 的方式编写组件(类似 shadcn/ui)，并且还在 X 上表示 gluestack-ui + NativeWind 组合就是 React Native 的 shadcn/ui。

因此我个人是比较看好的，不过目前该库目前还处于 Alpha 阶段，可以持续观望中。这个也是我目前最值得推荐的组件库。

React Native 和 Next.js 应用程序共享代码​

如果你想要在 React Native 和 Next.js 应用程序共享代码(UI，逻辑)，你可以考虑使用 solito。该库的写法上会更偏向于 next 的写法，举个例子。

比如说 Image 组件在 RN 写法如下

import { Image } from 'react-native'

<Image
  style={styles.xxx}
  source={{
    uri: 'https://beatgig.com/image.png',
  }}
/>

next.js 的写法

import Image from 'next/image'

<Image src="https://beatgig.com/image.png" width={100} height={100} />

solito 的写法

import { SolitoImage } from 'solito/image'

<SolitoImage src="https://beatgig.com/image.png" height={100} width={100} />

这样 SolitoImage 会判断当前的仓库是 next.js 项目还是 RN 项目对不同的平台进行渲染，以做到同一个组件跨平台的开发，像 Link、useRouter 都是类似用法。

不过当你想要共享代码时，此时就必须得上 monorepo 了，通常目录结构如下图所示，你也可以到这个仓库中查看。

├── apps
│   ├── expo
│   └── next
├── packages
│   └── app
│       ├── features
│       ├── index.ts
│       ├── layouts
│       ├── package.json
│       ├── provider
│       └── screens
├── turbo.json
└── package.json

packages/app 存放主要的公共业务代码，在 next 和 expo 中则直接通过 @xxx/app 子包来导入，具体可看代码，这里就不做过多介绍了。

处理平台差异​

不同平台之间必然会存在一定的开发差异，expo 也提供了相应的解决方案，可以通过给文件添加不同的后缀扩展(.web .android .ios) 以在对应平台执行对应文件，官方文档 Platform specific extensions

一些库分享​

这里只会介绍这个库的用途，至于为什么选择这个而不是其他的，不想做过多的篇幅来解释。如果你用过比这更好的库，也可相互交流。

@gorhom/bottom-sheet​

底部窗口，效果如图

@shopify/flash-list​

一个高性能的列表，可替代 RN 的 FlatList，其中它还支持如下图布局。

react-native-toast-message

toast 消息组件，轻量简单易用。

react-native-gesture-handler

如果你觉得所编写的 RN 应用没有触摸反馈效果，那么可能需要尝试使用 这个库。例如，你可以使用 RectButton 来包装子元素来实现点击按钮波纹反馈效果。如下图所示

此外像拖动组件、滑动删除、放大缩小图片等常见的手势操作，总之这个库都可以实现。

react-native-reanimated

RN 动画库，没啥好说的。

以上组件库可以说基本必装，能为 RN 应用使用体验提升一个档次。

一些案例/组件分析​

分享一些我在编写 RN 中的一些案例。该说不说，RN 的生态是真的可以，很多原生的解决办法几乎都有。

React Navigation​

在这个库你可以实现几乎所有的原生布局，如底部 tabs，左侧抽屉等，expo 是在此基础上进行包装的。

底部 Tabs​

Expo 自带案例，实现效果也简单，这里不在赘述了。

左侧抽屉​

https://reactnavigation.org/assets/navigators/drawer/drawer.mp4

expo 官方所提供的左侧抽屉是带导航的，也就是说你无法同时使用底部选项和左侧抽屉两个布局效果。因此想要同时使用这两种布局，就要使用 Drawer Layout，这里分享我个人的实现过程。

首先，编写 DrawerContainer 组件，代码如下

import { Drawer } from 'react-native-drawer-layout'
import { useDrawerOpen } from '@/atoms/drawer'
import CustomDrawerContent from './CustomDrawerContent'

export function DrawerContainer({ children }: { children: React.ReactNode }) {
  const [open, setOpen] = useDrawerOpen()

  return (
    <Drawer
      open={open}
      onOpen={() => setOpen(true)}
      onClose={() => setOpen(false)}
      swipeEnabled={false}
      renderDrawerContent={() => <CustomDrawerContent></CustomDrawerContent>}
    >
      {children}
    </Drawer>
  )
}

如果想要定制化左侧菜单就必须使用 CustomDrawerContent，这里贴相关代码

import { DrawerContentScrollView, DrawerItem } from '@react-navigation/drawer'

export default function CustomDrawerContent() {
  return (
    <DrawerContentScrollView
      scrollEnabled={false}
      contentContainerStyle={{
        flexGrow: 1,
      }}
    >
      {/* <DrawerItemList {...props} /> */}

      <View className="flex-1 mx-2">

        <DrawerItem
          label="子项 1"
          onPress={() => { }}
        />
        <DrawerItem
          label="子项 2"
          onPress={() => { }}
        />
        {/* ... */}
      </VStack>
    </DrawerContentScrollView>
  )
}

最后在 app/_layout.tsx 中用 DrawerContainer 包装一下 Stack，如下代码。

import { Stack } from 'expo-router'
import { Provider } from '@/provider'
import { DrawerContainer } from '@/components/DrawerContainer'

export default function RootLayout() {
  return (
    <Provider>
      <DrawerContainer>
        <Stack
          screenOptions={{
            headerShown: false,
          }}
        ></Stack>
      </DrawerContainer>
    </Provider>
  )
}

此时就可以用 useDrawerOpen（这里状态库选用 jotai）来控制左侧菜单的展开了。

TabView​

同样的，这个效果在 React Navigation 也是有提供的。但在 expo 中有 react-native-pager-view作为平替，并且更兼容原生，但是 react-native-pager-view 是不支持 Web 端的，因此如何选择就看具体需求了。

固定 Header + tab view​

先看一张图，很多 app 都有这种类似的效果。

这种效果可以使用监听 ScrollY 配合 react-native-reanimated 动画来实现，如果你不想自己实现也可以看看 @codeherence/react-native-header，上图便来自此库。

此外我还留意到 TabbedHeaderPager 这个库（很坑，别用），别看官方 gif 图效果很炫酷，然而实际效果并不达预期，并且十分难用，比如想要更改 tab 样式得像下方这样传递 props 编写。

<TabbedHeaderPager
  tabTextStyle={{
    color: theme.color?.get(),
    padding: 0,
  }}
  tabTextActiveStyle={{
    backgroundColor: 'transparent',
  }}
  tabTextContainerStyle={{
    padding: 0,
  }}
  tabTextContainerActiveStyle={{
    backgroundColor: 'transparent',
  }}
  tabWrapperStyle={{
    paddingVertical: 0,
  }}
  tabUnderlineColor={primaryColor}
  tabsContainerStyle={{
    backgroundColor: bgColor,
    flex: 1,
    maxWidth: Platform.select({
      web: 200,
    }),
    margin: Platform.select({
      web: 'auto',
    }),
  }}
  tabsContainerHorizontalPadding={Platform.select({
    default: 120,
    web: 0,
  })}
  contentContainerStyle={{
    flex: 1,
  }}
/>

RN 原生开发的感悟​

在这段的 RN 开发经历，我还有很多 API 还未尝试，有很多开发上的细节没编写到。篇幅有限，未来如果还有机会编写 RN 项目，再做一些分享(我觉得应该不会有了)。

我曾与安卓开发打过两次交道:

一段是在学习安卓逆向的时候，免不了学习一些基础的原生安卓开发的知识。

另一段是在接触自动化开发的时候，看到了 Auto.js 这个库， 可以使用 JavaScript 和 Node.js 实现小型的安卓应用（不支持 IOS），更多是使用这个库来编写一些脚本类相关的应用。现在回看该库的文档，不由得开始莫名的感叹。

Auto.js Pro 移除了自动化测试、图片处理、消息通知等模块，如果你需要实现的是自动化、工作流工具，则不适合 Auto.js Pro。

在如今内卷的环境下，技术框架变化飞快，文档示例不断完善，服务商们也提供快速搭建应用的模版，又赶上了 AI 热潮，学习一件新东西对于初学者过于容易。随之而来的是开发人员变多，市场需求不足难以满足如此庞大的开发人员，貌似技术对开发人员本身也不是那么的重要？

对于技术人员要如何破局，或许是每位程序员的最值得思考的问题。

本文面向的对象是饱受 TypeORM 折磨的资深用户(说的便是我自己)。只对这两个 ORM 框架从开发体验上进行对比，你也可以到 这里 查看 Prisma 官方对这两个 ORM 框架的对比。

整体对比​

更新频率 & 下载量​

TypeORM 距离上次更新已经过去半年之久了（下图截取自 24 年 1 月 1 日，没想到年初竟然还复活了）

从下载量以及 star 数来看，如今 Prisma 已经超过 TypeORM，这很大一部分的功劳归功于像 Next.js、Nuxt.js 这样的全栈框架。

上图来源 https://npmtrends.com/prisma-vs-typeorm

而在 Nest.js 的 Discord 社区 讨论之中，Prisma 也成为诸多 Nest.js 开发者首选的 ORM 框架，因为它有着更好的开发体验。

在大势所趋之下相信你内心已经有一份属于自己的答案。

文档 & 生态​

从文档的细致程度上 Prisma 比 TypeORM 要清晰详尽。在 Get started 花个数十分钟了解 Prisma 基本使用，到 playground.prisma.io 中在线尝试，到 learn 查看官方所提供的免费教程。

此外 Prisma 不仅支持 js/ts 生态，还支持其他语言。丰富的生态下，加之 Prisma 开发团队的背后是由商业公司维护，无需担心需求得不到解决。

开发体验对比​

在从开发体验上对比之前，我想先说说 TypeORM 都有哪些坑(不足)。

findOne(undefined) 所查询到的却是第一条记录​

首先 TypeORM 有个天坑，你可以在 这个 Issue 中查看详情或查看 这篇文章 是如何破解使用 TypeORM 的 Node.js 应用。

当你使用 userRepository.findOne({ where: { id: null } }) 时，从开发者的预期来看所返回的结果应该为 null 才对，但结果却是大跌眼镜，结果所返回的是 user 表中的第一个数据记录！

你可能会说，这不是 bug 吗？为何官方还不修。事实上确实是 bug，而事实上官方到目前也还没修复该 bug。再结合上文提到的更新频率，哦，那没事了。

目前解决方法则是用 createQueryBuilder().where({ id }).getOne() 平替上一条语句或者确保查询参数不为 undefined。从这也可以看的出，TypeORM 在现今或许并不是一个很好的选择。

synchronize: true 导致数据丢失​

synchronize 表示数据库的结构是否和代码保持同步，官方提及到请不要在生产环境中使用，但在开发阶段这也并不是一个很好的做法。举个例子，有这么一个实体

@Entity()
export class User {
  @PrimaryGeneratedColumn()
  id: number

  @Column()
  name: string
}

当开启了 synchronize: true，并且将 name 更改为 title 时，一旦运行 nest 服务后就会发现原有 name 下的数据全都丢失了！如图所示

因为 TypeORM 针对上述操作的 sql 语句是这样的

ALTER TABLE `user` CHANGE `name` `title` varchar(255) NOT NULL
ALTER TABLE `user` DROP COLUMN `title`
ALTER TABLE `user` ADD `title` varchar(255) NOT NULL

也就是说，当你在开发环境中，修改某个字段（包括名字，属性）时，该字段原有的数据便会清空。

因此针对数据库更新的操作最正确的做法是使用迁移(migrate)。

接入成本​

在 Nest 项目中，Prisma 的接入成本远比 TypeORM 来的容易许多。

相信你一定有在 xxx.module.ts 中在 imports 中导入 TypeOrmModule.forFeature([xxxEntity]) 的经历。就像下面代码这样：

@Module({
  imports: [TypeOrmModule.forFeature([UserEntity])],
  controllers: [UserController],
  providers: [UserService],
  exports: [TypeOrmModule, UserService],
})
export class UserModule {}

对于初学者而言，很大程度上会忘记导入 xxxEntity，就会出现这样的报错

Potential solutions:
 - Is UserModule a valid NestJS module?
 - If "UserEntityRepository" is a provider, is it part of the current UserModule?
 - If "UserEntityRepository" is exported from a separate @Module, is that module imported within UserModule?
   @Module({
     imports: [ /* the Module containing "UserEntityRepository" */ ]
   })

Error: Nest can't resolve dependencies of the userService (?). Please make sure that the argument "UserEntityRepository" at index [0] is available in the UserModule context.

此外这还不是最繁琐的，你还需要再各个 service 中，通过下面的代码来注入 userRepository。

@InjectRepository(UserEntity)
private readonly userRepository: Repository<UserEntity>

一旦实体一多，要注入的 Repository 也就更多，无疑不是对开发者心智负担的加深。

再来看看 Prisma 是怎么导入的，你可以使用 nestjs-prisma 或者按照官方文档中创建 PrismaService。

然后在 service 上，注入 PrismaService 后，就可以通过 this.prisma[model] 来调用模型(实体) ，就像这样

import { Injectable } from '@nestjs/common'
import { PrismaService } from 'nestjs-prisma'

@Injectable()
export class AppService {
  constructor(private prisma: PrismaService) {}

  users() {
    return this.prisma.user.findMany()
  }

  user(userId: string) {
    return this.prisma.user.findUnique({
      where: { id: userId },
    })
  }
}

哪怕创建其他新的实体，只需要重新生成 PrismaClient，都无需再导入额外服务，this.prisma 便能操作所有与数据库相关的 api。

更好的类型安全​

Prisma 的贡献者中有 ts-toolbelt 的作者，正因此 Prisma 的类型推导十分强大，能够自动生成几乎所有的类型。

而反观 TypeORM 虽说使用 Typescript 所编写，但它的类型推导真是一言难尽。我举几个例子：

在 TypeORM 中，你需要 select 选择某个实体的几个字段，你可以这么写

你会发现 post 对象的类型提示依旧还是 postEntity，没有任何变化。但从开发者的体验角度而言，既然我选择查询 id 和 title 两个字段，那么你所返回的 post 类型应该也只有 id 与 title 才更符合预期而后续代码中由于允许 post 有 body 属性提示，那么 post.body 为 null 这样不必要的结果。

再来看看 Prisma，你就会发现 post 对象的类型提示信息才符合开发者的预期。像这样的细节在 Prisma 有非常多。

这还不是最关键的，TypeORM 通常需要使用 createQueryBuilder 方法来构造 sql 语句来满足开发者所要查询的预期。而当你使用了该方法，你就会发现你所编写的代码与 js 无疑，我贴几张图给大伙看看。

这无疑会诱发一些潜在 bug，我就多次因为要 select 某表中的某个字段，却因拼写错误导致查询失败。

创建实体​

在 TypeORM 中，假设你要新增一条 User 记录，你通常需要这么做

const newUser = new User()
newUser.name = 'kuizuo'
newUser.email = 'hi@kuizuo.me'
const user = userRepository.save(newUser)

当然你可以对 User 实体中做点手脚，像下面这样加一个构造函数

@Entity()
export class User {
  @PrimaryGeneratedColumn()
  id: number

  @Column({ unique: true })
  username: string

  @Column()
  email: string

  constructor(partial?: Partial<UserEntity>) {
    Object.assign(this, partial)
  }
}

const newUser = new User({
  name: 'kuizuo',
  email: 'hi@kuizuo.me',
})
const user = userRepository.save(newUser)

于是你就可以传递一个 js 对象到 User 实体，而不是 newUser.xxx = xxx 像 Java 版的写法。

而要是涉及到多个关联的数据，往往需要先查询到关联数据，然后再像上面这样赋值+保存。这里就不展开了，使用过 TypeORM 的应该深有体会。

而在 Prisma 中，绝大多数的操作你都只需要一条代码语句外加一个对象结构，像上述 TypeORM 的操作对应 Prisma 的代码语句如下

const user = await prisma.user.create({
  data: {
    name: 'kuizuo',
    email: 'hi@kuizuo.me',
  },
})

根据条件来创建还是更新​

在数据库中操作经常需要判断数据库中是否有某条记录，以此来决定是更改该记录还是创建新的一条记录，而在 Prisma 中，完全可以使用 upsert，就像下面这样

const user = await prisma.user.upsert({
  where: { id: 1 },
  update: { email: 'example@prisma.io' },
  create: { email: 'example@prisma.io' },
})

聚合函数​

在 TypeORM 中，假设你需要使用聚合函数来查询的话，通常会这么写

const raw = await this.userRepository
  .createQueryBuilder('user')
  .select('SUM(user.id)', 'sum')
  .getRawOne()

const sum = raw.sum

如果只是像上面这样，单纯查询 sum，那么 raw 的值是 { sum: 1 } , 但最要命的就是 select 配合 getRawOne 还要额外查询 user 实体的属性，所得到的结果就像这样

const raw = await this.userRepository
  .createQueryBuilder('user')
  .select('SUM(user.id)', 'sum')
  .addSelect('user')
  .where('user.id = :id', { id: 1 })
  .getRawOne()

{
	user_id: 1,
	user_name: 'kuizuo',
	user_email： 'hi@kuizuo.me',
	sum: '1'
}

所有 user 的属性都会带有 user_ 前缀，这看上去有点不是那么合理，但如果考虑要联表查询的情况下，就会存在相同名称的字段，通过添加表名(别名)前缀就可以避免这种情况，这样来看貌似又有点合理了。

但还是回到熟悉的类型安全，这里的所返回的 raw 对象是个 any 类型，一样不会有任何提示。

而在 Prisma 中，提供了 专门用于聚合的方法 aggregate，可以特别轻松的实现聚合函数查询。

const minMaxAge = await prisma.user.aggregate({
  _count: {
    _all: true,
  },
  _max: {
    profileViews: true,
  },
  _min: {
    profileViews: true,
  },
})

{
  _count: { _all: 29 },
  _max: { profileViews: 90 },
  _min: { profileViews: 0 }
}

看到这里，你若是长期使用 TypeORM 的用户必定会感同身受如此糟糕的体验。那种开发体验真的是无法用言语来形容的。

Prisma 生态​

分页​

在 Prisma 你要实现分页，只需要在 prismaClient 继承 prisma-extension-pagination 这个库。就可像下面这样，便可在 model 中使用paginate方法来实现分页，如下代码。

import { PrismaClient } from '@prisma/client'
import { pagination } from 'prisma-extension-pagination'

const prisma = new PrismaClient().$extends(pagination())

const [users, meta] = prisma.user
  .paginate()
  .withPages({
    limit: 10,
    page: 2,
    includePageCount: true,
  });

// meta contains the following
{
  currentPage: 2,
  isFirstPage: false,
  isLastPage: false,
  previousPage: 1,
  nextPage: 3,
  pageCount: 10, // the number of pages is calculated
  totalCount: 100, // the total number of results is calculated
}

支持页数(page)或光标(cursor)。

而在 TypeORM 你通常需要自己封装一个 paginate方法，就如下面代码所示（以下写法借用 nestjs-typeorm-paginate）

async function paginate<T>(
  queryBuilder: SelectQueryBuilder<T>,
  options: IPaginationOptions,
): Promise<Pagination<T>> {
  const { page, limit } = options

  queryBuilder.take(limit).skip((page - 1) * limit)

  const [items, total] = await queryBuilder.getManyAndCount()

  return createPaginationObject<T>({
    items,
    totalItems: total,
    currentPage: page,
    limit,
  })
}

// example
const queryBuilder = userRepository.createQueryBuilder('user')
const { items, meta } = paginate(queryBuilder, { page, limit })

当然也可以自定义userRepository，为其添加 paginate 方法，支持链式调用。但这无疑增添了开发成本。

根据 Schema 自动生成数据验证​

得益于 Prisma 强大的数据建模 dsl，通过 generators 生成我们所需要的内容（文档，类型），比如可以使用 zod-prisma-types 根据 Schema 生成 zod 验证器**。**

举个例子，可以为 schema.prisma 添加一条 generator，长下面这样

generator client {
  provider = "prisma-client-js"
  output   = "./client"
}

generator zod {
  provider                         = "zod-prisma-types"
  output                           = "./zod"
  createModelTypes                 = true
	// ...rest of config
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  id         String      @id @default(uuid())
  email      String      @unique
  name       String?
}

执行构建命令后，这将会自动生成 zod/index.ts 文件，将包含 UserSchema 信息，其中片段代码如下

export const UserSchema = z.object({
  id: z.string().uuid(),
  email: z.string(),
  name: z.string().nullable(),
})

export type User = z.infer<typeof UserSchema>

再通过 createZodDto，将 zod 验证器转化为 dto 类，就像下面这样

当然你可能并不想在 nestjs 项目中使用 zod，而是希望使用传统的 class-validator 来编写 dto。可以使用社区提供的 prisma-class-generator 根据已有 model 生成 dto。

合理来说，Prisma 并不是一个传统的 ORM，它的工作原理并不是将表映射到编程语言中的模型类，为处理关系数据库提供了一种面向对象的方式。而是在 Prisma Schema 中定义模型。在应用程序代码中，您可以使用 Prisma Client 以类型安全的方式读取和写入数据库中的数据，而无需管理复杂模型实例的开销。

总而言之，你若想要更好的类型，简洁的实体声明语法，况且带有可视化桌面端应用，以及更好的生态完备，那么你就应该选 Prisma。

总结​

在写这篇文章时，我也是彻底的将 Nestjs 项目中由 TypeORM 迁移到 Prisma ，这期间给我最大的变化就是在极少的代码量却又能实现强大的功能。许多涉及多表的 CRUD操作可以通过一条简洁的表达式来完成，而在使用 TypeORM 时，常常需要编写繁琐臃肿的 queryBuilder。

TypeORM 有种被 nestjs 深度绑定的模样，一提到 TypeORM，想必第一印象就是 Nestjs 中所用到的 ORM 框架。然而，Prisma 却不同，是一个全能通用的选择，可以在任何的 js/ts 框架中使用。

从开发体验的角度不接受任何选择 TypeORM 的反驳，有了更优优秀的选择，便不愿意也不可能在回去了。如果你还未尝试过 Prisma，我强烈建议你亲身体验一番。

不过如今都大四了，也确实是要考虑实习的事了。我想结合我自身情况，谈谈我是怎么看待工作或者往远点说职业规划方面的想法。

一些经历​

工作经历​

我目前一共有 3 段工作经历

1. 休学一年在厦门本地某工作室(共4人)与他人创业。 2021.1 ~ 2022.1
2. 在北京的一家公司(规模不大)远程实习。 2022.8 ~ 2022.10
3. 在 3R 教室 兼任助教与开发组成员。 2023.1 ~ 2023.12

事实上，对我而言也仅有休学的那一段才能算是工作，而其他两者从年限与工作性质来看不能算是一份真正的工作。但也不能说不是，至少也替别人做过事、签过合同、领过工资的。

不过我想稍微提提我是怎么找到这三个工作的，或者说这三份工作是怎么找到我的 -> 全靠分享

我不止说过一次分享的重要性，我的第一份工作就是在网络分享了一个大学生自动完成视频、作业的程序，恰好被我当地一个工作室的同事看到，寻求我能否改进功能一同合作，于是一拍即可，便开始休学。

剩余的两个工作同样也是，一个契机是我当时正好在研究 Strapi 编写了一篇文章，这家公司恰好用到这门技术；而 3R教室则是因为创始人所用的与我博客相同的网站生成器 Docusaurus 在这个机缘下认识的，后来创始人创业开了3R教室，我也就利用业余时间在其中扮演助教身份，赚个零花钱。（其实我很热心肠的，哪怕我不当助教，只要时间允许的情况下，你有问题问我也会尽数回答）

接单经历​

同样的，分享也能很大程度上提升你接单的资本。

我并非想要炫耀什么，而是分享实实在在给我带来了很多好处，我希望你能够分享一些内容，一些见解心得，哪怕是一些笔记、对他人问题的回复，都可能给你带来一些意想不到的好处。

我就有一个同学将自己的笔记、课设以及每次专业课期末考试的文档放到 CSDN 上（没错就是那个 IT 界的毒瘤），现在这不到期末了嘛，他的私信就有一堆人找他写课设啥的。

回归到正题，我接过单不多也不少，绝大多数是那种对我而言挺简单的问题，但对于一些人而言就比较困难。例如前几天一个例子，我编写过 js-deobfuscator 一个 js 混淆还原的工具，正好有人需要将一份混淆代码还原出来，于是寻求我的帮助，发了个红包给我。有时哪怕只是回答别人一个问题，甚至都可能会收到来自他人的红包。想想看，你在技术群里是不是有过这个现象。

还有一个网站的单子我印象很深，是一个用于销售流量、虚拟会员等商品的网站，不同与普通的商城系统，充值是通过卡密，使用卡密到特定的网站上使用。当时一个网站全套 5000，客户也算熟人了，还帮我推荐几个人购买，相当于这一套网站(模版)，帮我赚了几 w，还省去我很多开发成本，后续我都无偿给他提供技术服务。

事实上至少现在为止我并不是很喜欢接单，也很少主动接单。小的单（也可叫零活）通常以一顿夜宵作为回报或是看在人情的份上；而大的单（通常为外包单），通常要求交付时间快，很多时候只为了更快的完成功能，而不考虑代码质量。并且通常没有维护性可言，就更别说写测试和重构了。写久了，代码虽然写的是快了，但堆屎山的速度都堪比屎壳郎了。代码能力的提升反而不是很大。

在我看来当因某种目的收了他的钱财时，往往就要花费时间精力去完成这个目的，而从我内心上很难平衡这点。所以只要我不收钱，我就可以不做事了（bushi

赚钱经历​

我赚的第一桶金其实还不是我工作，在上大学前我已经赚过对我两桶金了，还全都是依靠网络上的资源，而非现实打工。一次是初三当时向别人学习如何刷钻以及购买钻卡来接单帮别人刷钻，另一个是作为线报群群主（现如今更多的称之为羊毛群，但我更愿称撸界），发布一些活动和教程通过拉人头引流赚钱。而也是再次契机之下，学会了开发(定制)软件。

这并非本文重点，因此我并不想过多介绍，但或许这会作为后面的铺垫。

不过我还是想说：赚钱不易。我现在回看我过去的一些经历，只能说运气成分很大，而又恰好在风口之中。在如今的互联网环境下，想要复刻曾经的路, 无疑是死路一条。

为何不实习？​

背景介绍完了，那就来说说实习的事情，为何我都大四了，还不找实习？

不是不找，而是很难找到满意的。我在今年暑期的时候有尝试找过，投过几家大厂，无一例外，了无音讯。这对我当时而言，打击还蛮大的。因为三流学校出身，确实很难过（双关），加之没人内推，海投基本上是没希望的。

如今前端的职位卷之又卷，僧多粥少，在厦门一些中小公司所提供的前端实习待遇（薪资大约在 3k~4k），况且对自身的提升并不是特别大，在我不是一笔性价比划得来的买卖。

反观学校的情况那可就更头疼了，你敢相信在大四上最该实习的时候，极为不合理的教案却还要给学生安排课程，还是专业课的那种，以下我的课表。

此外，我还需要重修当初因休学而没去考试的几门课程（还挺多的，重修费还交了我不少😢），导致我最后一场考试时间是在 12月中旬。还是强调那一点，我不希望工作与学业这两者同时进行。关于这学校的诸多不满，待我毕业后我一定要说说，感受什么叫中国的私立大学。

此外还有一点，也是我不想提及的一点，这段期间我是处于“监视”状态，内心总悬着一个不知何时爆炸的炸弹，生怕突然爆炸将会打乱我的行程。

好在如今期限已到，心里悬着的一块石头终于放下来了，如释重负。

于是在上述的因素下，今年下半年我就不想找实习了。

为何又想实习了？​

最主要的一点就是以我目前学生(应届生)的身份，是可以有机会争取到一份好的实习的，乃至是大厂的实习。

其次是我并没有一个很好的项目演进经历，看完我的一些工作经历不难发现我所待的公司/工作室的体量都不大，甚至我到现在都没真正体验过打卡上班（当然我也希望不要有）。而这就是小厂或者初创公司的同病，各个流程所要负责的任务很模糊。我当时休学和他人创业工作，基本上都是我一人负责项目开发；第二个远程实习也是我当时主动退出的，因为工作形式与接单无疑；第三个就不用多说了。

尤其是在技术层面的团队协作之中，还缺乏相当多的实践经验。所以在自我分析下，为了学习某些只在公司才能学到的东西，就非常有必要到大公司去一趟。

我大概率以后是不太可能再考虑坐班，所以这或许是我仅有为数不多的上班经历了。不过我想既便真正要开始打卡上班，要开始适应国内 996，未来我铁定会后悔有过这段历程。

那么该怎么找呢？​

那么在如今就业形势如此严峻的时代，我又该如何找工作？

关于这点我其实并没有什么很好的经验分享，这也算是我首次主动找工作。不过我可以肯定的一点是，只单靠海投与某些招聘软件，想要拿到一份心意的 offer 很难。若是能通过一些关系，牵一条线（走内推），才是最佳选择，所以多积攒人脉交际圈是很有必要的。

这一部分我想待我后续找到工作后，再来做个心得分享也不为迟。（不说了，我去准备项目与简历去了）

远程工作​

电鸭的sologen：只工作，不上班。很好表明远程工作的意图。

远程工作（remote work）是我当下认为最具性价比的工作形式，你可以过着四五线城市的生活水平而不用考虑一线城市的房租与消费，却赚取一线城市的薪资。往大点说就是挣美元花人民币。

但是远程工作并非多数人想的那么轻松的，很多人对远程工作有个误区，就是可以自由决定上班时间，很自由。其实不是的，不用上下班通勤，那就把通勤的时间拿来工作。没有额外房补开销，那就拿来压低工资。而该开的会还是得开，说白了就是换个地方上班，懒床是睡不了一点的，好一点的是冬天起来不用遭受寒风的洗礼罢了。

有的远程工作还会要求你记录每个时间段(细到每小时)你都做了哪些工作，我暑期的就有一份我老师推荐的远程工作(实习)就是这样，我就没干了。要论自由，接单/自由职业是最自由的，项目进度、时间都由你自己把握。

此外还有一点就是技术栈的因素。我并没有跟随国内的主流的 Web 开发技术栈去学习什么 Java，也庆幸还好当初认为 Java 这门语言繁琐的要死，让我转变使用 JS/TS 来进行 Web 全栈的开发，而如今的重心也是在 JS/TS。

而这套技术栈在国外的远程工作的岗位占比很大，一些初创公司也会采用这套技术栈。而我本身学的就是 JS/TS，自身优势反而更能体现出来。但反观在国内绝大多数公司我也就是老老实实做前端的那种。况且如果只想靠国内的主流传统的技术栈而去争取一个远程岗位，我认为当下还是很难实现的。就国内的职场环境下，如今工作都难找了，就别说本身岗位就少的远程工作了。

正常坐班​

退而其次，那就正常上下班通勤，而这又有的抉择了。就以我自身举例把，我老家福建宁德且我在厦门某三流大学读书，意味着我只要在福建本地找工作，就可以过的相对来说舒服，人脉资源、衣食住行都不用过多考虑。但倘若选择在外打拼，意味着可能要适应陌生的城市生活，建立起新的人际网络，面对未知的困难和挑战。而这其中所能利用的、所要遭受的，都得由自个儿来承担。

今年冬至的时候我与家里人商讨过这个问题，家里人的意见更多偏向于留在本省，只求我稳稳当当，脚踏实地。因为我从小到大独立性很差，加上我确实有那么亿点宅，到外面恐怕是吃不消。所以在他们眼里哪怕在本省薪资不是令我那么满意，但至少可以过一种相对舒适的生活。而我自己则认为有必要去外面见见世面，有时候很多苦只有自己吃过才知道有苦。

不过最终如何选择，还得取决于我自己。这对于多数人也是值得花时间思考的。

最终如果选择重归故里，那么一开始就身在其中是否会更好？又何必在外漂泊，独自承受着一切。

我对打工/上班的看法​

我经常拿我高考结束的那个暑假来做例子，我的一些高中同学去当外卖骑手、餐厅服务员，将他们的假期时间拿来打工赚钱，而我却埋头苦干的学习编程(易语言)，以兴趣驱使我学习一门技术。

或许是因为有过几段赚钱经历，加上家境和个人意愿，所以至今为止我都不可能会去从事这种回报率不高，或者说没有“未来”的工作。与其打工/上班，尤其是耗费大量时间与体力劳动的，不如将时间拿来提升自己综合能力。（个人观点，或许有些极端）

可能是由于受自由的影响加上年轻有精力折腾，同时自己又是那么不走”寻常路“、不遵循“规则”的人。所以像那种安稳平淡，重复劳动的工作，如体制/编制内的职业就不太那么感冒。

但从现实是没人想打工/上班，却依旧有人从事这些工作。绝大多数打工人别无选择，因生活所迫，只得忍受和抱怨打工/上班的痛苦，却又寄人篱下。

期望的工作​

要说不工作是不可能的（但打工是不可能的），或许是因为这几年的一些工作经历有关，导致我有点习惯了远程，加上网间传闻 996 的压力下，我现在对坐班甚至还有些厌恶。对我最理想的工作环境就是能够自我在决定在某个时间点是否工作，例如在工作日放假，在节假日上班。

接单虽说也是，那这毕竟不是一份正经的工作，更多意义上来说是份兼职。更多是作为一时之需，接单又不可能接一辈子（搞得工作能工作一辈子似得）。

而我想说的是做个自由职业者，在细一点也就是独立开发者。但是现在来看这并非易事，不仅需要一定的技术能力和营销水平，最关键的想法就已经让绝大多数人对这份职业扼杀在摇篮中。

现状​

首先我对自己的生活方式定义是：偏向于自发的能量爆发，而不是有条理的持续努力。

今年我的 github contributions 出现过了几次长时间的空缺，那段期间我基本上没有在写代码，而是将心思用在其他事情上。例如只打游戏（好在游戏如今也是戒了）、只想摆烂（好在是摆的有点多了）、只想复习（好在该考的试都已经考了）。这就导致很多时候我会将全部精力专注在某件事情上，而抛弃其他与之无关的事情。

这也就导致了我很难养成一个良好的习惯，我的生物钟也因此而发生巨变。贴一张极为离谱的作息

总之持之以恒在我这还不存在过，多数的开始是因一腔热血，而最后结束时却草草了事。

我想是是过度的自由造就了这般现状，想要解决这个问题，坐班可能还真可以。

或许是因为比同龄人提前踏入过社会，有过几段工作经验，所以在就业形势严峻的时代，其实我反倒不是那么慌张。

何况目前经济状态也还算正常，哪怕不找工作也足够养活我自己好一整子。至少相比同龄人下，我已经挺富裕了。也没必要搞个打赏在自己的网站或项目上放置收款二维码等无关项目信息。对我而言，编写这些的目的不是为了接某个单，赚个打赏费，更多是一时兴起，分享给有需要的人，希望让其更为纯粹一些，仅此而已。

我对赚钱的态度也很简单，悦己便可（做点让自己愉悦的事情），数额能够维持自身生存便足够了。不过现在我还没开始到还贷的境地，或许只有压迫感来临时，才会让我激起对金钱的渴望，改变对金钱的态度。

取悦自己，生活最好的心态。

感慨​

接触 web 开发算下整整两年半的时间，在这期间我并没有很好地扩张自己的技术面。在折腾方面确实不如以往，学习主动性也欠缺许多。不同于一开始所学习那样，喜欢瞎捣鼓，看到某个东西就会想尝试安装。

明年也就 24 岁了，面对即将到来的本命年，下一个阶段的走向其实很迷茫，面对我的是留学还是工作，我到现在都没有定数…

虽说我现在大四还在读，但其实我已经比同龄人晚毕业 1-2 年了（此时怀着感慨的泪水不禁流下）。心智上还保留着校园少年的青雉 ，同时也多了份成熟的稳重。

有过这些经历让我收获了更为珍贵的经验和独特的成长路径，我想未来的日子必定是丰富多彩的。

往年回顾​

• 2022 · 逆向到Web开发
• 2021 · 休学一年
• 2020 · 编程之旅-起点

思考​

此时不妨思考一个问题，现在以下几个接口，你会怎么去设计 url 路径？

• 查询文章
• 查看文章详情
• 创建文章
• 更新文章
• 删除文章
• 查看我的文章
• 查看他人的文章

前 5 个接口想必不难设计，这边就给出标准答案。

• 查询文章 GET /articles
• 查看某篇文章详情 GET /articles/:id
• 创建文章 POST /articles/
• 更新文章 PUT /articles/:id
• 删除文章 DELETE /articles/:id

当然，我相信肯定也有GET /article—list POST /add-article 这样的答案，不过这些不在 restful api 风格的范畴，就不考虑了。

而这时 查看我的文章 或许就需要稍加思考，或许你会有以下几种方式

• GET /my-articles 从资源角度来看肯定不好，因为此时在 url 不能很直观地体现请求资源，同时在控制器文件(controller) 就与 article 分离了，并且还占用了 / 下路径。
• GET /articles/mine 则又不那么遵循 restful api 风格，挺违和的。

那么这时不妨遵循 资源从属关系，在这里 文章所属的对象就用户，因此查看他人的文章可以这么设计GET /users/:userId/articles 获取特定用户（userId）的文章列表。

而 查看我的文章 同样也可用此 URL，只需将 userId 更改为自己的便可。从 api 的 URL 来看是很舒服了，但是从代码开发的角度上问题又有了问题了。。。

对于 user 资源，是不是也有查询，创建，更新，删除等接口，即 查询用户 GET /users，创建用户POST /users/ 等等。。

我是不是就需要在 user 这么重要的资源控制器上去添加一些其他方法，所对应的代码就如下所示

@Controller('users')
export class UserController {
  constructor(private userService: UserService, private articleService: ArticleService) {}

  @Get()
  async list(@Query() dto: UserQueryDto) {
    return this.userService.findAll(dto)
  }

  @Get(':id')
  async info(@Param('id') id: number) {
    return this.userService.findOne(id)
  }

  @Post()
  async create(@Body() dto: UserCreateDto) {
    await this.userService.create(dto)
  }

  // 省略有关 User 部分接口，以下是其他 user 下的资源接口

  @Get(':userId/articles')
  async articles(@Param('userId') userId: number) {
    return this.userService.findAll(userId, articlesId)
  }

  @Get(':userId/articles/:articlesId')
  async articles(@Param('userId') userId: number, @Param('articlesId') articlesId: number) {
    return this.articleService.find(userId, articlesId)
  }
}

换做是我，肯定不会希望将用户的代码与文章的代码混杂在一起。解决办法也是有的，可以额外创建一个新的 UserController 文件，专门用于获取用户下的资源（这里指 article），这样可以 即与原有针对 user 资源进行解耦，有可以有比较清晰接口分类。

业务再稍微复杂一下，现在要为业务增加以下几个功能，你又会如何设计

• 收藏他人文章
• 获取我收藏的文章

答案应该会有两种，即 POST /articles/:articleId/collections 与 POST /collections

而这就令我特别头疼，因为这两个都符合 restful api 风格，也确实都能很好的满足业务功能。于是在我尝试抓包拥有相关的网站后，我发现几乎都是后者的 url。后来一想，前者更像是获取某种资源，而不是用于创建资源。后者确实更能胜任多数场景，比如说现在我需要收藏某个专栏，那么我用 POST /collections 足以胜任，只需要传递 条目id与条目类型，后端根据这两个条件找到对应条目数据便可。假设后续业务多一个资源需要收藏也不成问题。但换做前者的话，就得再多写一个重复性接口。

抽象资源​

restful 更多是针对实际存储的资源，核心是名词，对于增删改查的业务可以说非常适合，但现实情况下不只有增删改查，就例如上述的收藏功能。

对于一些个别接口需要另外表达，如 登录 POST /login、获取个人信息 GET /profile

对于一些非增删改查的操作，还是使用 RPC 式的 API 更为实在，即 POST /命名空间/资源类型/动作，至少不用再为某个操作决定 PATCH/PUT 还是 POST/DELETE。

针对同一实体，区分不同用户​

问题还没结束，不妨碍继续使用上述文章的例子，针对 文章 这一实体，又要怎么定义（区分）用户与作者或管理员路径呢？

管理员所看到的数据肯定远比用户来的多，如果使用同一个接口（如 /articles），那么业务代码必然会十分复杂。

使用不同的端点(end point) 是个解决方法，例如管理员在请求前添加 manage 或 admin，如 /manage/articles 或 /articles/manage 这样只需要多一步判断请求用户是否拥有管理的权限。

但对我个人而言，我一般都会以在一个命名空间下（这里指 /articles）编写，像前面的 /manage/articles 我是直接 pass 的。

在设计接口的原则就优先以拥有者的身份来设计，在去设计其他用户获取这个资源的接口。就比如说上述 article 为例， 针对增删改查而言，都是用于这个资源的拥有者可操作的，那么所获取到的数据就是尽可能符合拥有者需求的。而这时如果要将资源给其他角色请求，就会根据情况设计，如

• GET /articles 获取我的文章列表（针对拥有者）
• GET /articles/query 查询文章（针对所有用户）

权限区分​

在 restful 中有两个概念：resources 与 action，因此只需要定义好权限标识码便可，还是以文章举例，如 article:read article:create article:update article:delete ，这里的 resources 对应的就是 article ，action 则是 read，create 等。将这些权限码分配给不同的控制器方法，在某个请求的时候判断用户是否拥有这个权限码便可。

资源粒度问题​

但是复杂的实际业务中，仅仅单靠 restful API，往往需要发送多条请求，例如获取某篇文章数据与作者数据

GET /articles/1

GET /articles/1/author

要么两条请求获取相应数据，要么为调用方“定制”一个接口，如GET /getArticleInfo，这样只需一条请求便可得到想要的数据。但这个就破坏了 restful API 接口风格，并且在复杂的业务中，比如说还要获取博文的评论等等，后端就要额外提供一个接口，可以说是非常繁琐了。相比之下 GraphQL 就更为灵活了。

写到最后​

在我写这篇文章之前，我尝试抓包看过很多网站的请求 url，见识到各式各样的 url 路径，基本上很难找到遵循 restful api 风格的网站，绝大多数的操作除了获取外用 GET，其余全用 POST 。对于复杂的业务，restful api 风格实在过于难以胜任。

如果说变量命名是编程最大的痛苦，那么写接口最大的痛苦我想就是定义 url 路径了。

相关文章​

RESTful API 对于同一实体，如何定义管理员和用户的路径？

RESTful API设计经验总结

为什么很多后端写接口都不按照 restful 规范？

那我为何会接触算法呢？​

我在今年暑假期间有一个面试，当时面试官想考察下我的算法能力，而我直接明摆了说我不行（指算法上的不行），但面试官还是想继续考察，于是就出了道斐波那契数列作为考题。

但我毕竟也接触了 4 年的代码，虽说不刷算法，但起码也看过许多文章和代码，斐波那契数列使用递归实现的代码也有印象，于是很快我就写出了下面的代码作为我的答案。

function fib(n) {
  if (n <= 1) return n

  return fib(n - 1) + fib(n - 2)
}

面试官问我还有没有更好的答案，我便摇了摇头表示这 5 行不到的代码难道不是最优解？

事实上这份代码看起来很简洁，实际却是耗时最慢的解法

毫无疑问，在算法这关我肯定是挂了的，不过好在项目经验及后续的项目实践考核较为顺利，不然结局就是回去等通知了。最后面试接近尾声时，面试官友情提醒我加强基础知识（算法），强调各种应用框架不断更新迭代，但计算机的底层基础知识是不变的。于是在面试官的建议下，便有了本文。

好吧，我承认我是为了面试才去学算法的。

对上述代码进行优化​

在介绍我是从何处学习算法以及从中学到了什么，不妨先来看看上题的最优答案是什么。

对于有接触过算法的同学而言，不难看出时间复杂度为 O(n²)，而指数阶属于爆炸式增长，当 n 非常大时执行效果缓慢，且可能会出现函数调用堆栈溢出。

如果仔细观察一下，会发现这其中进行了非常多的重复计算，我们不妨将设置一个 res 变量来输出一下结果

function fib(n) {
  if (n <= 1) {
    return n
  }

  const res = fib(n - 1) + fib(n - 2)
  console.log(res)
  return res
}

当 n=7 时，所输出的结果如下

这还只是在 n=7 的情况下，便有这么多输出结果。而在算法中要避免的就是重复计算，这能够高效的节省执行时间，因此不妨定义一个缓存变量，在递归时将缓存变量也传递进去，如果缓存变量中存在则说明已计算过，直接返回计算结果即可。

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
}

此时所输出的结果可以很明显的发现没有过多的重复计算，执行时间也有显著降低。

这便是记忆化搜索，时间复杂度被优化至 O(n)。

可这还是免不了递归调用出现堆栈溢出的情况（如 n=10000 时）。

从上面的解法来看，都是从”从顶至底”，比方说 n=7，会先求得 n=6 的结果, 而 n=6 又要求得 n=5 的结果，依次类推直至得到底层 n=1 的结果。

事实上我们可以换一种思路，先求得 n=1，n=2 的结果，然后依次类推上去，最终得到 n=6，n=7 的结果，也就是“从底至顶”，而这就是动态规划的方法。

从代码上来分析，因此我们可以初始化一个 dp 数组，用于存放数据状态。

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 数组结果。

且由于不存在递归调用，因此你当 n=10000 时也不在会出现堆栈溢出的情况（只不过最终的结果必定超出了 JS 数值可表示范围，所以只会输出 Infinity）

对于上述代码而言，在空间复杂度上能够从 O(n) 优化到 O(1)，至于实现可以参考 空间优化，这里便不再赘述。

我想至少从这里你就能看出算法的魅力所在，这里我强烈推荐 hello-algo 这本数据结构与算法入门书，我的算法之旅的起点便是从这本书开始，同时激发起我对算法的兴趣。

两数之和​

于是在看完了这本算法书后，我便打开了大名鼎鼎的刷题网站 LeetCode，同时打开了究极经典题目的两数之和。

有人相爱，有人夜里开车看海，有人 leetcode 第一题都做不出来。

题干：

给定一个整数数组 nums  和一个整数目标值 target，请你在该数组中找出和为目标值 target 的那 两个 整数，并返回它们的数组下标。

你可以假设每种输入只会对应一个答案。但是，数组中同一个元素在答案里不能重复出现。

你可以按任意顺序返回答案。

以下代码将会采用 JavaScript 代码作为演示。

暴力枚举​