该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/notes/7

看完了？说点什么呢

前言

最近花时间学了 NestJS，从一个「听说过但没碰过」的状态，到能搭出一个完整的后端项目。这篇东西算是一个学习记录，把过程中的理解、踩过的坑、对框架的感悟写下来，也算是对自己这段时间的一个交代。

我对 NestJS 的理解

刚接触的时候，最直观的感受是：它和传统的 Node.js 框架不太一样。

以前写 Express ，都是"需要什么自己加"，很灵活，但也容易写散。NestJS 给我的感觉是 —— 它把规矩定好了。模块怎么拆、代码放哪里、请求怎么流转，都有一套明确的规范。

刚开始觉得有点束缚，但写多了发现，这种约束其实是一种解放。项目结构不会随着代码量增加而腐烂，回头看自己写的代码，思路是清晰的。

项目结构：模块化是核心

学 NestJS 最先要理解的就是模块化。每个功能都是一个模块，模块里放控制器、服务、数据实体，各司其职：

src/
├── main.ts             # 应用入口
├── app.module.ts       # 根模块，组装所有子模块
├── user/               # 用户模块
├── auth/               # 认证模块
├── roles/              # 角色模块
├── logs/               # 日志模块
├── guards/             # 自定义守卫
├── filters/            # 异常过滤器
├── interceptors/       # 拦截器
├── decorators/         # 自定义装饰器
├── enum/               # 常量枚举
└── utils/              # 工具函数

每个模块就像一个小盒子，有自己的职责，也能和其他模块通信。这种组织方式让项目不管多大，结构都是可预期的。

如果一个模块需要被其他多个模块复用，可以把它设为全局模块（@Global()），或者通过 exports 显式暴露出去。这种显式的依赖声明，比隐式的全局变量要健康得多。

学到最多的几个点

1. 依赖注入（DI）

NestJS 的依赖注入是我觉得最优雅的设计之一。不需要自己 new 对象，只需要在构造函数里声明需要什么，框架会自动给你注入：

constructor(private userService: UserService) {}

就一行，UserService 的实例就进来了。如果 UserService 又依赖了其他东西，框架会递归地帮你全部解析好。

这种机制带来的好处是：模块之间的耦合度低，测试也方便 —— 测试的时候可以轻松替换成 mock 对象。

2. 装饰器驱动的编程方式

NestJS 大量使用装饰器，开始的时候会觉得"到处都是 @ 符号"，看习惯了会发现这是它最方便的地方。

路由、参数提取、验证、权限控制……全都是装饰器。一个路由的处理函数，从上到下的装饰器就是它的完整"说明书"：

@Get(':id')
@UseGuards(AuthGuard)
@UsePipes(ValidationPipe)
getUser(@Param('id') id: string) { ... }

一眼就能看出来：这是个 GET 请求、需要登录、参数验证、从路径拿 id。

除了用内置装饰器，还可以自定义装饰器，把重复的逻辑封装起来。比如我写了一个 @Serialize(Dto) 装饰器，用来控制接口返回哪些字段，敏感字段不想暴露给前端，通过这个装饰器一键搞定。

3. 请求生命周期（完整流水线）

NestJS 的请求处理是一条完整的流水线，按顺序经过各个环节：

Middleware → Guard → Interceptor → Pipe → Controller → Service → Interceptor → Filter（出异常时）

每个环节各司其职：

• Middleware：最前置的处理，可以做一些通用逻辑，比如请求日志、耗时统计
• Guard：能不能进来？做权限校验，比如检查是否登录、是否有操作权限
• Interceptor：进来前/出去后做点什么，比如打日志、加缓存、序列化响应数据
• Pipe：进来的数据对不对？做参数验证和类型转换
• Filter：出错了怎么返回？统一异常响应格式

理解了这条流水线，写代码的时候就能清楚当前逻辑该放在哪个环节，出 bug 也能快速定位。

4. TypeORM 的数据库操作

数据库用了 TypeORM，最大的感受是：操作数据库像操作对象一样自然。

最常用的几种关系：

• 一对一：用户 ↔ 资料（一个用户只有一个资料页）
• 一对多：用户 ↔ 日志（一个用户有多条操作记录）
• 多对多：用户 ↔ 角色（一个用户可以有多个角色，一个角色也可以有多个用户，通过中间表关联）

常规的增删改查直接用 Repository 的方法就行。复杂查询用 QueryBuilder，写起来和写 SQL 差不多但更安全（参数化查询），支持分组、排序、分页等高级操作。

5. 数据验证与转换

验证：以前写接口的时候，参数校验经常是手写 if-else，又臭又长。NestJS 搭配 class-validator，用装饰器声明规则，简洁很多：

@IsString()
@IsNotEmpty()
@Length(2, 20)
username: string;

配合全局注册的 ValidationPipe，请求进来的时候自动校验，不合法直接返回 400，Controller 里拿到的数据一定是合法的。

转换：用 class-transformer 配合拦截器，可以控制接口返回的数据结构。比如把 User 实体转成 UserDto，只暴露前端需要的字段，密码、加密盐这些敏感字段自动过滤掉。这在写 API 的时候非常实用。

6. 认证与授权 (JWT)

用户认证用的是 JWT（JSON Web Token）方案。流程大概是：

1. 用户登录，服务端验证用户名密码
2. 验证通过，生成一个加密的 token 返回给前端
3. 前端后续请求带上这个 token
4. 服务端通过 Guards 校验 token，确定用户身份

密码不能明文存数据库，我用了第三方的包做加盐哈希处理（bcrypt），就算数据库泄露了，密码也是安全的。

权限控制方面还学了 CASL 这个库，可以定义细粒度的权限规则，比如"普通用户只能看自己的文章，管理员可以删任何文章"，配合自定义守卫来实现。

7. 环境配置管理

用 @nestjs/config 配合 .env 文件做环境配置。不同环境用不同的文件：

.env.development    # 开发环境
.env.production     # 生产环境
.env.test           # 测试环境
.env                # 公共默认配置

数据库连接信息、JWT 密钥、端口号这些都放在环境变量里，不写死在代码中。还用了 Joi 做配置验证，启动时如果缺少必要的配置项，程序会直接报错，避免带着错误配置上线。

8. 日志系统

用 nestjs-pino 做日志记录，配置了双输出：

• 控制台：彩色格式化输出，开发时看着清晰
• 文件：按天轮转，每个文件有大小限制，自动归档

日志记录了每次请求的路径、方法、参数、耗时等信息，线上排查问题的时候很有帮助。

9. 测试（Jest）

写了单元测试和端到端（e2e）测试。

单元测试：针对 Service 和 Controller 单独测试，用 mock 替换数据库操作，跑得很快。主要测业务逻辑是否正确。

端到端测试：模拟真实的 HTTP 请求，从路由到数据库全链路验证，确保接口整体功能正常。

用 Jest + Supertest 来写，虽然写测试确实多花一些时间，但改代码的时候有测试兜底，心里会踏实很多。

10. 异常过滤器

没有异常过滤器的时候，每个接口出错返回的格式可能都不一样。前端对接起来很痛苦。

NestJS 的异常过滤器可以把异常处理收拢到一处，统一返回格式：

{
  "code": 400,
  "message": "参数错误",
  "timestamp": "2026-07-26T00:00:00.000Z",
  "path": "/api/v1/user",
  "method": "POST"
}

不管是参数校验失败、数据库报错、还是业务逻辑异常，返回格式都是统一的。前端直接按统一格式处理就行。

写在最后

NestJS 不是那种"学完就能炫技"的框架，它更像一个规规矩矩的框架，提供了写后端应用的一整套方法论。回头看我以前用 Express 写的项目，如果当初用 NestJS，结构应该会清晰很多。

这次学的东西挺多的：模块化架构、依赖注入、TypeORM 数据操作、JWT 认证、数据验证与转换、日志系统、单元测试和 e2e 测试、自定义装饰器和守卫、异常过滤、环境配置管理……每一样在生产中都是很实用的。

框架只是一个工具，但好的工具确实能帮人写出更干净的代码。但这次学习让我最大的收获不是记住了多少 API，而是理解了这套架构思维。未来写任何后端项目，这套思维方式都是通用的。

（其实在学的过程很难受，网上没有很好入门的NestJS课程，我看的这套很不适合小白入门，里面很绕，而且课程很老，不过老师水平确实高，好在硬着头皮学完了，但是说实话不一定记住了常见的API，因为自己代码量不够多。不过，后面肯定有要用到NestJS的时候，到那时候再提高吧）

一步一个脚印，比什么都重要。

Tailwind / Nuxt UI 经典套路速查

本项目开发过程中累积的高频、可直接复用的样式搭配速查表。 涵盖定位、毛玻璃浮岛、Tailwind 4 新语法、Nuxt UI 主题色别名、动效联动等。

一、定位 / 居中三件套

任意宽度元素的绝对居中(最经典)

<div class="fixed left-1/2 -translate-x-1/2">
  ...
</div>

• left-1/2:把元素左上角点放到屏幕水平中线
• -translate-x-1/2:再回拉自身宽度的一半,实现真正的几何居中
• 不依赖具体 px,任意宽度都居中,比 margin-left: -w/2 优雅

顶部悬浮岛(常用于导航 / FAB)

<div class="fixed top-2 sm:top-4 left-1/2 -translate-x-1/2 z-10">
  ...
</div>

参考本项目的 app/components/AppHeader.vue。

二、毛玻璃浮岛(macOS 风)

<div class="
  bg-muted/80
  backdrop-blur-sm
  rounded-full
  border border-muted/50
  shadow-lg shadow-neutral-950/5
">
  ...
</div>

拆解:

适用:任何浮层、popover、浮动按钮、顶部导航胶囊。

三、Tailwind 4 新语法(高频三招)

1️⃣ 任意 CSS 变量值

<div class="max-w-(--ui-container)">

等价于 max-width: var(--ui-container),括号内可放任意 CSS variable,替代旧版 max-w-[1400px] 死值。

2️⃣ data-attr 状态选择器

<!-- 本元素状态 -->
<button class="data-[state=active]:text-highlighted data-[state=inactive]:text-muted">

<!-- 父级挂 group 时,子元素响应父级 data-state -->
<div class="group">
  <Icon class="group-data-[state=open]:rotate-135" />
</div>

配合 Reka UI / Nuxt UI 的 data-state 自动 toggle,纯 CSS 响应组件状态,不写 JS 切 class。

3️⃣ important 后缀

<div class="pt-0! px-0!">

Tailwind 4 把 ! 移到末尾(旧版是 !pt-0)。压第三方库默认样式必备——比如压过 Nuxt UI 组件自带的 padding/ring。

四、响应式出血 + 兼容器锁宽

「让某区块出血到全宽,但又被 UI 容器限宽」的经典组合:

<div class="-mx-4 sm:-mx-12 lg:-mx-16 max-w-(--ui-container)">

参考本项目 app/components/landing/Testimonials.vue 的 UCarousel viewport 配置。

五、before: / after: 伪元素装饰

父 hover 子才显 + 滑一下(三件套)

<div class="group">
  <UIcon class="
    opacity-0
    group-hover:opacity-100
    group-hover:translate-x-1
    transition-all
  " />
</div>

• 父级挂 group
• 子元素常驻隐藏(opacity-0)
• group-hover:*:父级 hover 时子才响应
• 配 transition-all 做丝滑过渡

参考本项目 app/components/landing/Blog.vue 的 "Read Article" 箭头按钮。

适用:hover 时才渐显的图标、徽章、箭头、装饰元素。

大引号装饰

<p class="
  before:content-[open-quote]
  before:text-7xl
  before:text-dimmed
  before:absolute
  before:-ml-10
  before:-mt-4
  after:content-[close-quote]
  after:...对称
">
  推荐语正文...
</p>

关键点:content-[open-quote] 是 Tailwind 4 任意值语法,编译成 content: open-quote,引号自动按文档 lang 渲染(英文 " / 中文 「」)。

参考本项目 app/components/landing/Testimonials.vue 的 UPageCTA。

六、Nuxt UI 主题色别名(Semantic Colors)

这些 class 在 Tailwind 官网搜不到,但项目里到处都是。查看 Nuxt UI 主题文档。

颜色别名

高频组合

半透卡片底

<div class="bg-elevated/60">...</div>

60% 透明的凸起色,做卡片「轻微浮起」感。

hover 轻微反馈

<div class="hover:bg-muted/50">...</div>

鼠标进入变次要色 50% 透明,轻微 hover 反馈,不抢眼。

激活态文字色切换(Nuxt UI 标配!)

<button class="
  data-[state=active]:text-highlighted
  data-[state=inactive]:text-muted
">
  ...
</button>

Reka UI 状态切换时自动 toggle data-state,纯 CSS 被动响应。

参考本项目 app/components/landing/FAQ.vue 的 UTabs 样式覆盖。

七、group + group-hover: 联动机制

父级挂 group,子用 group-hover:* 响应父级 hover——Tailwind 不写 JS 切 class 的核心模式。

<div class="group">
  <!-- 子元素常驻不可见,鼠标 hover 到父级任意位置时才显 -->
  <Icon class="opacity-0 group-hover:opacity-100 group-hover:translate-x-1 transition-all" />
</div>

要点:

• 子元素自己常驻隐藏(opacity-0),鼠标根本 hover 不到它
• 鼠标 hover 父级任意位置 → 子响应
• 配合 group-data-[state=open]:* 还能响应父级特定 data-state

网页动效 80% 的 hover 联动都靠它,React / Vue 项目通用。

八、动画性能套件

折叠 / 抽屉 / Tab 切换等动画场景,给做 transform 的元素加这两个,防掉帧:

<div class="transform-gpu will-change-transform">
  ...
</div>

参考本项目 app/components/landing/FAQ.vue 的 UAccordion trigger 样式。

九、其他常用速记

完整 Cheatsheet

常见疑问

Q: 为什么 bg-elevated / text-muted 等在 Tailwind 官网搜不到?

A: 这些是 Nuxt UI 自己注入的语义化颜色别名(Semantic Colors),基于 CSS 变量,自动跟随 light/dark 模式切换。要在 Nuxt UI 主题文档 的 Semantic Colors 章节查,不是 Tailwind 原生类。

Q: ! 后缀是什么?

A: Tailwind 4 的 important 语法,放在 class 末尾(如 pt-0!),等价于 padding-top: 0 !important,主要用来压过第三方库的默认样式。

Q: group 和 group-hover: 必须配套吗?

A: 是的。group 标在父级,group-hover:* 才能在父级 hover 时生效。单独写 group-hover:* 而父级没 group,Tailwind 不会识别父级关系,会失效。

后续遇到新的经典套路继续追加到本文档。

Zod的学习, 非技术分享

什么是Zod

Zod 是一个 帮助Ts的使用者们在Ts的编写和运行时，进行类型的推断和校验的库，极大的维护了Ts类型安全，0外部依赖， 轻巧，十分流行。

Zod的简单用法

下面是在NuxtContent里面看见的Zod的用法，今天看文档的时候看见了Zod，发现不会使用于是就学习了下

// 代码
      schema: z.object({
        // Hero 区: CTA 按钮组 + 跑马灯图片组
        hero: z.object({
          links: z.array(createButtonSchema()),
          images: z.array(createImageSchema())
        }),

Zod的用法很简单，简单到把上面的代码翻译一遍给你听你就知道他应该如何去使用了

• schema必须是一个对象类型，下面必须要有hero属性
• hero属性必须是一个对象，必须要有links和images属性
• links必须是一个数组，并且数组内的元素类型必须是creatButtonSchema() 这个方法的返回值类型，或者说通过这个返回值的校验（这个方法名的后缀是Schema其实从侧面说明了，这个方法的返回值也是一个z。object约束的对象）
• images跟links同理 对吧，就是一看就会，一用也会（大概？）。然后你可以使用parse() 去验证你的数据，好比这样schema.parse(data)。如果在运行的时候parse的校验没有通过，那么会直接报错，而Ts只有当你使用这种错误数据类型的时候才会报错（比如你在String类型上使用了toFixed方法），这样也说明了他比Ts更加的安全，注重运行的数据安全。

如果你不希望他在运行时报错，你可以使用safeParse(使用这个api往往表示你希望数据是正确的)，方法会返回一个对象：

// 代码
{
  success:false,
  error:ZodError
}

如果数据正确则会返回这样的对象：

// 代码
{
  success:true,
  data:{
    name:"Tom",
    age:18
  }
}

在使用Ts的前端开发中，你想要去校验一个表单数据，不需要先interface 再去写校验数据逻辑了， 直接可以使用Zod去规定一个schema， 然后使用parse去验证，或者使用type register = z.infer直接生成一个interface，而且还有校验的规则。

// 代码
const RegisterSchema=z.object({

 username:z.string(),

 age:z.number()

})


type RegisterForm = z.infer<typeof RegisterSchema>

总结

Zod的出现给运行时候的Ts代码套上一层安全的外壳，也简便了一些基础的校验规则，更多特性等有需求的时候再看吧。

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/notes/6

看完了？说点什么呢

先说结果，面试过了，拿到了前端实习的offer，是个小公司，月薪3k不到，每天上7个半小时，双休不加班

简历准备及投简

说实话我原本是没想在期末周的时候就开始去找实习了，因为在我的认知里面，这种暑假实习，日常实习，在暑假的时候的时候应该也能找，让我改变了这个观点的是我一个朋友。事情是这样的，我有一个朋友，他妈妈嫌弃他暑假老是待在家里面无所事事，于是就让他去打暑假工，然后他就跟我分享了这件事情，说他已经找了暑假工了，是用58同城找的，在他家楼下的KFC工作。我很高兴，然后我就告诉他，我也不能懒惰了，我也要去找实习才行了，暑假就找。结果他说：你暑假找，别人早就招满，我这种兼职都这样，更别说实习了。我这一听，有道理啊！直接给我点醒了，不管三七二十一了，直接先去投简历再说！

问了下之前也投过简历的同学，参考了下他的简历，一眼看出是GPT生成的简历。然后我也开始了用GPT生成简历，我把我要找实习的事情告诉他，把我的技术栈，获得的奖，对开源项目的贡献，我之前做过的项目文件都喂给了他，然后就为我生成了一份真的非常贴合我的简历，在充分展示我的情况下，也不失应有的含蓄。于是我就开始用这份简历开始了投简（虽然中途有些修改，但是都是很细微的修改）

我是从6月27号开始投简历的，投了一天，差不多30多份，BOSS，实习僧， 智联等等，反正除了牛客我都投了。第二天醒来，没有一个人鸟我！意识到不能这样，赶快去网上查查投简历的攻略，问问学长，师兄们是怎么找实习， 怎么投简历的。28取完经之后，我依旧海投，不过更加的虎了，什么职业，什么要求也不看了，就是投，更前端有一点点相关的就是投，几个平台投的简历数也达到了100多份，但是当天依旧没有人鸟我！灰心失落的我就睡觉等待第二天了。

29号，11点半起床，打开手机，信息直接炸了！手机弹窗全是某某hr看了我的简历，于是赶快一个个给hr发信息，希望能求取一个实习的机会。其中有两个表示对我的感兴趣，一个发来了要线下面试机试的要求（河南郑州），另一个直接说明天能不能线下面试（长沙本地），但是两个都是0-20人的小公司，不过我也不挑剔，毕竟是第一次实习。激动坏了，同意了30号的长沙的面试。

面试的准备

知道我要面试后， 我有一个朋友直接给我算了下塔罗牌，分别是“时间沙漏”，“ 宝剑八正位”，“权杖八正位”，先说结论，准爆了！三张卡分别对应的是时间紧迫，心态是我的阻碍点，面试时间很快，快速推进。

明天这场面试是一个限时机会，机会摆在眼前，但留给你展示、扭转印象的时间很短。 同时暗示：面试官会快速判断你的适配度，不会给你长时间铺垫；当下你的履历、准备内容已经定型，能改变的只有临场发挥，过往积累无法临时突击弥补。 也代表这场面试是阶段性节点，过与不过都会快速敲定结果，不会无限拖延等待。

宝剑八代表自我束缚、自卑、视野受限、过度担忧。 你现在内心有很重的心理枷锁：

• 总觉得自己准备不足、短板明显，下意识放大自身缺点；
• 容易自我设限，不敢大胆展示优势，回答问题畏手畏脚；
• 会脑补面试官严苛挑剔，还没上场就先自我否定。 客观来看，大部分压力是你自己困住自己，面试官并没有刻意刁难你的意图，只是你内心的不自信遮住了你的闪光点。

权杖八是快速推进、沟通顺畅、消息来得快、高效沟通。 过程层面：面试节奏很快，问答流程紧凑，不会冷场拖沓，双方交流直白干脆，面试官提问直击重点，没有弯弯绕绕。 结果信号：沟通效率高，信息传递顺畅，只要你放下内心顾虑、放开表达，双方能快速达成共识；面试结束后反馈会来得很快，不会漫长等待。

当下你的履历、准备内容已经定型，能改变的只有临场发挥，过往积累无法临时突击弥补。面试要点是要我自信，要摆脱自我否定，大方展示自身优势。于是我就去找我的朋友进行了一场模拟面试，面试的是字节的题目，这次模拟确实给我增加了不少的信心，感觉自己曾经的知识并没有忘记，当我想调用他们的时候他们也能被我调用。

现在回顾一下这个塔罗牌，真的准呀，可以说完全一致。

11点面试，我10点10分就到了，10点20多开始面试，因为本来也就是心血来潮， 没做什么准备就去找的实习，八股根本没有背！只带着我绝对的自信，无条件的相信自己曾经自己的积累不会辜负现在自己。面试官是个东北大老爷，目测有45岁左右，整个人压迫感很强，确实对我的心态造成了不小的打击。但是还是很快稳住了脚步， 找到了自信，我本来就没有复习，就单单只有自信。

面试官一共问了我几个简单的八股，有这些：说下Vue的生命周期（一共8个我只说出了一个onMounted。。。，外加记混了的一些api。。。）， 说下Vue的父子通信是怎么通信的（这个顺利回答出来了，幸亏之前忘记了，问了GPT老师👍✌️），

啊啊啊啊啊啊啊啊啊啊啊啊啊啊， 为什么没有保存到我的草稿啊！全部都没了， 不写了！

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/notes/5

看完了？说点什么呢

驱动式学习，世界上最好的学习方式，不是为了解决学习而学习， 而是为了解决实际的问题。

第一次听到这个词语

我第一次听到这个词语，是我大一下的时候。那天有一个即将毕业的大四学长的讲座分享会，我在观众的名单中，看见了一个我在意的人的名字，于是也报名了这个讲座当观众的活动。算是赚大，学到了很多，也是在学长的分享会上我第一次听到了这个词语--驱动式学习。

学长很优秀，有过大厂的实习经验，即将毕业，手里已经收到了多份大厂的offer，小红书，快手，字节等。他说了他了大学四年的经历，很丰富，也很精彩。他说推荐我们一种学习方式：驱动式学习。听到这个词，那时我立刻就有了一种陌生又熟悉的感觉，随后他又讲解了什么是驱动式学习，简单来说就是：不是为了读书而读书，而是被一个 “目标 / 问题 / 任务” 推着走，为了解决它才去学。那时候我没什么感觉，但是却让我影响深刻，第一我不知道如何去运用这个学习方法，也不知道他的厉害之处在哪里，但是我却记住了，觉得可能在日后的某个瞬间，我可能会理解吧。

近日的驱动式学习

最近我实验室的互联网项目要开始进行联调，其中我就遇到了不是问题， 但是又让我很不舒服的事情。我是负责应用层（前后端），要和负责通信层的队友进行通信。理论上在比赛中，我们应该会是在同一个局域网之中，然后就能很方便的进行通信，他代码那边写我的ip，端口，然后连上我的mqtt服务器即可。但是在开发过程中，我们经常不在同一个局域网中，每次要进行调试，或者尝试连接之类的事情，我都得要背着我厚重的电脑去他们旁边进行联调。对我一个常年把电脑放在寝室的人来说，非常的不友好。（要带着电脑跑跑到9楼的高度，到地方了还得休息10分钟才能进入状态）虽说这种事情还称不上是问题，但是跟他们进行了一次联调之后， 我还是有了能不能我就在寝室，然后他们也能连接上我的mqtt服务器的想法。

刚好晚上，我实验室的兄弟就说了有关frp之类的言论，我并不知道什么是frp，但是他又说，他们组现在已经可以远程连接他的mqtt服务器了，这让我一下就感了兴趣，原来不是只有我有这种想法。第二天我就开始了frp的了解和学习。

frp是一个内网穿透的工具，让在本地的开的服务可以映射到公网上，然后别人通过公网上的ip加映射的端口就能访问你本地的服务。前提是你得有一个在公网上服务器。服务器通过下载配置frps，然后本地电脑通过下载配置frpc，就能很简单的实现别人远程访问你的电脑上开的服务。还可以通过ssh实现远程连接电脑，不过现在我是没有这个需求。

晚上跟朋友们出去浪完回来就开始了远程的联调（或许我应该发布下出去玩的手记），不出我意料，没有一点问题，他们设备端可以正常连接到我的mqtt服务器，也能发送消息。

感想

可以发现，我学习使用frp是很快的，一天时间都没有到， 我就解决了一个不是问题的，但是让我感觉不舒服的点，这也是我们当下这个时代的特点。各种资料的开源，工具，知识能很轻易地在网络上获取，信息不在是封闭的，也有Ai去辅助我们收集信息（如果不给Ai官网，他很可能出现信息过时，或者胡编乱造的情况），学习任何一个东西都是很迅速的（当然迭代也快）。这种情况下，驱动式学习更是能体现出它的优势点：

• 主动性强，不是别人给我灌输知识， 而是我需要什么知识：区别于传统形式的讲课式的学习，课上的知识是老师教我们的，是老师按照课程要求给我们灌输的知识，是他们想要我们学会的----要我学。而驱动式学习，则是我主动的去学习，我要解决一个问题，我需要什么知识----我要学。
• 理解更加的透彻，对知识的运用力更强：本身驱动式学习就是从问题出发的，学习对应的知识，然后解决的了对应的问题。这是实实在在的掌握理解了知识，并且在知识运用到了实践当中，不是空的。遇到对应的问题，也能快速调用相应知识去解决问题。
• 适配自学，长期，终生学习的必经之路：自主的解决问题，培养了主动性，这跟自学所需的主动性本质上是同一个东西，潜移默化地提高了自学的能力，而且“发现问题 — 学习知识 — 解决问题” 的良性循环，这会让人收到正反馈，让人坚持学习下去，无意识地就长期学习了，甚至终生学习。

只想到了3个点，果然啊，把自己的感悟描述出来很难，有些东西只可意会不可言传是对的。加油继续努力吧，第一次学习使用了MarkDown格式，感觉比编程简单。

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/notes/4

看完了？说点什么呢

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/posts/study&think/tailwind-nest-summary

看完了？说点什么呢