我正在筹备一套前端工程化体系的实战课程。如果你在学习前端的过程中感到方向模糊、技术杂乱无章，那么前端工程化将是你实现系统进阶的最佳路径。它不仅能帮你建立起对现代前端开发的整体认知，还能提升你在项目开发、协作规范、性能优化等方面的工程能力。

✅ 本课程覆盖构建工具、测试体系、脚手架、CI/CD、Docker、Nginx 等核心模块，内容体系完整，贯穿从开发到上线的全流程。每一章节都配有贴近真实场景的企业级实战案例，帮助你边学边用，真正掌握现代团队所需的工程化能力，实现从 CRUD 开发者到工程型前端的跃迁。

详情请看前端工程化实战课程

学完本课程，对你的简历和具体的工作能力都会有非常大的提升。如果你对此项目感兴趣，或者课程感兴趣，可以私聊我微信 yunmz777

今年大部分时间都是在编码上和写文章上，但是也不知道自己都学到了啥，那就写篇文章来盘点一下目前的技术栈吧，也作为下一年的参考目标，方便知道每一年都学了些啥。

我的技术栈

首先我先来对整体的技术做一个简单的介绍吧，然后后面再对当前的一些技术进行细分吧。

React、Typescript、React Native、mysql、prisma、NestJs、Redis、前端工程化。

React

React 这个框架我花的时间应该是比较多的了，在校期间已经读了一遍源码了，对这些原理已经基本了解了。在随着技术的继续深入，今年毕业后又重新开始阅读了一遍源码，对之前的认知有了更深一步的了解。

也写了比较多跟 React 相关的文章，包括设计模式，原理，配套生态的使用等等都有一些涉及。

在状态管理方面，redux，zustand 我都用过，尤其在 Zustand 的使用上，我特别喜欢 Zustand，它使得我能够快速实现全局状态管理，同时避免了传统 Redux 中繁琐的样板代码，且性能更优。也对 Zustand 有比较深入的了解，也对其源码有过研究。

NextJs

Next.js 是一个基于 React 的现代 Web 开发框架，它为开发者提供了一系列强大的功能和工具，旨在优化应用的性能、提高开发效率，并简化部署流程。Next.js 支持多种渲染模式，包括服务器端渲染（SSR）、静态生成（SSG）和增量静态生成（ISR），使得开发者可以根据不同的需求选择合适的渲染方式，从而在提升页面加载速度的同时优化 SEO。

在路由管理方面，Next.js 采用了基于文件系统的路由机制，这意味着开发者只需通过创建文件和文件夹来自动生成页面路由，无需手动配置。这种约定优于配置的方式让路由管理变得直观且高效。此外，Next.js 提供了动态路由支持，使得开发者可以轻松实现复杂的 URL 结构和参数化路径。

Next.js 还内置了 API 路由，允许开发者在同一个项目中编写后端 API，而无需独立配置服务器。通过这种方式，前后端开发可以在同一个代码库中协作，大大简化了全栈开发流程。同时，Next.js 对 TypeScript 提供了原生支持，帮助开发者提高代码的可维护性和可靠性。

Typescript

今年所有的项目都是在用 ts 写了，真的要频繁修改的项目就知道用 ts 好处了，有时候用 js 写的函数修改了都不知道怎么回事，而用了 ts 之后，哪里引用到的都报红了，修改真的非常方便。

今年花了一点时间深入学习了一下 Ts 类型，对一些高级类型以及其实现原理也基本知道了，明年还是多花点时间在类型体操上，除了算法之外，感觉类型体操也可以算得上是前端程序员的内功心法了。

React Native

不得不说，React Native 不愧是接活神器啊，刚学完之后就来了个安卓和 ios 的私活，虽然没有谈成。

React Native 和 Expo 是构建跨平台移动应用的两大热门工具，它们都基于 React，但在功能、开发体验和配置方式上存在一些差异。React Native 是一个开放源代码的框架，允许开发者使用 JavaScript 和 React 来构建 iOS 和 Android 原生应用。Expo 则是一个构建在 React Native 之上的开发平台，它提供了一套工具和服务，旨在简化 React Native 开发过程。

React Native 的核心优势在于其高效的跨平台开发能力。通过使用 React 语法和组件，开发者能够一次编写应用的 UI 和逻辑，然后部署到 iOS 和 Android 平台。React Native 提供了对原生模块的访问，使开发者能够使用原生 API 来扩展应用的功能，确保性能和用户体验能够接近原生应用。

Expo 在此基础上进一步简化了开发流程。作为一个开发工具，Expo 提供了许多内置的 API 和组件，使得开发者无需在项目中进行繁琐的原生模块配置，就能够快速实现设备的硬件访问功能（如摄像头、位置、推送通知等）。Expo 还内置了一个开发客户端，使得开发者可以实时预览应用，无需每次都进行完整的构建和部署。

另外，Expo 提供了一个完全托管的构建服务，开发者只需将应用推送到 Expo 服务器，Expo 就会自动处理 iOS 和 Android 应用的构建和发布。这大大简化了应用的构建和发布流程，尤其适合不想处理复杂原生配置的开发者。

然而，React Native 和 Expo 也有各自的局限性。React Native 提供更大的灵活性和自由度，开发者可以更自由地集成原生代码或使用第三方原生库，但这也意味着需要更多的配置和维护。Expo 则封装了很多功能，简化了开发，但在需要使用某些特定原生功能时，开发者可能需要“弹出”Expo 的托管环境，进行额外的原生开发。

样式方案的话我使用的是 twrnc，大部分组件都是手撸，因为有 cursor 和 chatgpt 的加持，开发效果还是杠杠的。

rn 原理也争取明年能多花点时间去研究研究，不然对着盲盒开发还是不好玩。

Nestjs

NestJs 的话没啥好说的，之前也都写过很多篇文章了，感兴趣的可以直接观看：

• 面试官：为什么选择学习 Nestjs，而不是 Express？🧐🧐🧐


• NestJS 的生命周期钩子以及它们在不同阶段的都适合做什么？

对 Nodejs 的底层也有了比较深的理解了：

• 探究 CPU 密集型与 IO 密集型任务：提升对 Node.js 中 libuv 库的理解

Prisma & mysql

Prisma 是一个现代化的 ORM（对象关系映射）工具，旨在简化数据库操作并提高开发效率。它支持 MySQL 等关系型数据库，并为 Node.js 提供了类型安全的数据库客户端。在 NestJS 中使用 Prisma，可以让开发者轻松定义数据库模型，并通过自动生成的 Prisma Client 执行类型安全的查询操作。与 MySQL 配合时，Prisma 提供了一种简单、直观的方式来操作数据库，而无需手动编写复杂的 SQL 查询。

Prisma 的核心优势在于其强大的类型安全功能，所有的数据库操作都能通过 Prisma Client 提供的自动生成的类型来进行，这大大减少了代码中的错误，提升了开发的效率。它还包含数据库迁移工具 Prisma Migrate，能够帮助开发者方便地管理数据库结构的变化。此外，Prisma Client 的查询 API 具有很好的性能，能够高效地执行复杂的数据库查询，支持包括关系查询、聚合查询等高级功能。

与传统的 ORM 相比，Prisma 使得数据库交互更加简洁且高效，减少了配置和手动操作的复杂性，特别适合在 NestJS 项目中使用，能够与 NestJS 提供的依赖注入和模块化架构很好地结合，提升整体开发体验。

Redis

Redis 和 mysql 都仅仅是会用的阶段，目前都是直接在 NestJs 项目中使用，都是已经封装好了的，直接传参调用就好了：

import { Injectable, Inject, OnModuleDestroy, Logger } from "@nestjs/common";

import Redis, { ClientContext, Result } from "ioredis";



import { ObjectType } from "../types";



import { isObject } from "@/utils";



@Injectable()

export class RedisService implements OnModuleDestroy {

  private readonly logger = new Logger(RedisService.name);



  constructor(@Inject("REDIS_CLIENT") private readonly redisClient: Redis) {}



  onModuleDestroy(): void {

    this.redisClient.disconnect();

  }



  /**

   * @Description: 设置值到redis中

   * @param {string} key

   * @param {any} value

   * @return {*}

   */

  public async set(

    key: string,

    value: unknown,

    second?: number

  ): Promise<Result<"OK", ClientContext> | null> {

    try {

      const formattedValue = isObject(value)

        ? JSON.stringify(value)

        : String(value);



      if (!second) {

        return await this.redisClient.set(key, formattedValue);

      } else {

        return await this.redisClient.set(key, formattedValue, "EX", second);

      }

    } catch (error) {

      this.logger.error(`Error setting key ${key} in Redis`, error);



      return null;

    }

  }



  /**

   * @Description: 获取redis缓存中的值

   * @param key {String}

   */

  public async get(key: string): Promise<string | null> {

    try {

      const data = await this.redisClient.get(key);



      return data ? data : null;

    } catch (error) {

      this.logger.error(`Error getting key ${key} from Redis`, error);



      return null;

    }

  }



  /**

   * @Description: 设置自动 +1

   * @param {string} key

   * @return {*}

   */

  public async incr(

    key: string

  ): Promise<Result<number, ClientContext> | null> {

    try {

      return await this.redisClient.incr(key);

    } catch (error) {

      this.logger.error(`Error incrementing key ${key} in Redis`, error);



      return null;

    }

  }



  /**

   * @Description: 删除redis缓存数据

   * @param {string} key

   * @return {*}

   */

  public async del(key: string): Promise<Result<number, ClientContext> | null> {

    try {

      return await this.redisClient.del(key);

    } catch (error) {

      this.logger.error(`Error deleting key ${key} from Redis`, error);



      return null;

    }

  }



  /**

   * @Description: 设置hash结构

   * @param {string} key

   * @param {ObjectType} field

   * @return {*}

   */

  public async hset(

    key: string,

    field: ObjectType

  ): Promise<Result<number, ClientContext> | null> {

    try {

      return await this.redisClient.hset(key, field);

    } catch (error) {

      this.logger.error(`Error setting hash for key ${key} in Redis`, error);



      return null;

    }

  }



  /**

   * @Description: 获取单个hash值

   * @param {string} key

   * @param {string} field

   * @return {*}

   */

  public async hget(key: string, field: string): Promise<string | null> {

    try {

      return await this.redisClient.hget(key, field);

    } catch (error) {

      this.logger.error(

        `Error getting hash field ${field} from key ${key} in Redis`,

        error

      );



      return null;

    }

  }



  /**

   * @Description: 获取所有hash值

   * @param {string} key

   * @return {*}

   */

  public async hgetall(key: string): Promise<Record<string, string> | null> {

    try {

      return await this.redisClient.hgetall(key);

    } catch (error) {

      this.logger.error(

        `Error getting all hash fields from key ${key} in Redis`,

        error

      );



      return null;

    }

  }



  /**

   * @Description: 清空redis缓存

   * @return {*}

   */

  public async flushall(): Promise<Result<"OK", ClientContext> | null> {

    try {

      return await this.redisClient.flushall();

    } catch (error) {

      this.logger.error("Error flushing all Redis data", error);



      return null;

    }

  }



  /**

   * @Description: 保存离线通知

   * @param {string} userId

   * @param {any} notification

   */

  public async saveOfflineNotification(

    userId: string,

    notification: any

  ): Promise<void> {

    try {

      await this.redisClient.lpush(

        `offline_notifications:${userId}`,

        JSON.stringify(notification)

      );

    } catch (error) {

      this.logger.error(

        `Error saving offline notification for user ${userId}`,

        error

      );

    }

  }



  /**

   * @Description: 获取离线通知

   * @param {string} userId

   * @return {*}

   */

  public async getOfflineNotifications(userId: string): Promise<any[]> {

    try {

      const notifications = await this.redisClient.lrange(

        `offline_notifications:${userId}`,

        0,

        -1

      );

      await this.redisClient.del(`offline_notifications:${userId}`);



      return notifications.map((notification) => JSON.parse(notification));

    } catch (error) {

      this.logger.error(

        `Error getting offline notifications for user ${userId}`,

        error

      );



      return [];

    }

  }



  /**

   * 获取指定 key 的剩余生存时间

   * @param key Redis key

   * @returns 剩余生存时间（秒）

   */

  public async getTTL(key: string): Promise<number> {

    return await this.redisClient.ttl(key);

  }

}

前端工程化

前端工程化这块花了很多信息在 eslint、prettier、husky、commitlint、github action 上，现在很多项目都是直接复制之前写好的过来就直接用。

后续应该是投入更多的时间在性能优化、埋点、自动化部署上了，如果有机会的也去研究一下 k8s 了。

全栈性价比最高的一套技术

最近刷到一个帖子，讲到了

我目前也算是一个小全栈了吧，我也来分享一下我的技术吧：

剩下的描述也是和他下面那句话一样了（毕业后对技术态度的转变就是什么能让我投入最小，让我最快赚到钱的就是好技术）

总结

学无止境，任重道远。

最后再来提一下这两个开源项目，它们都是我们目前正在维护的开源项目：

• 在线代码协同编辑器


• 前端脚手架 create-neat

如果你想参与进来开发或者想进群学习，可以添加我微信 yunmz777，后面还会有很多需求，等这个项目完成之后还会有很多新的并且很有趣的开源项目等着你。

一、前言

下面纯手工画了一张在浏览器执行JavaScript代码的Event Loop(事件循环) 流程图。

后文会演示几个例子，把示例代码放到这个流程图演示其执行流程。

当然，这只是简单的事件循环流程，不过，却能让我们快速掌握其原理。

二、概念

事件循环是JavaScript为了处理单线程执行代码时，能异步地处理用户交互、网络请求等任务 (异步Web API)，而设计的一套任务调度机制。它就像一个永不停止的循环，不断地检查（结合上图就是不断检查Task Queue和Microtask Queue这两个队列）并需要运行的代码。

---

三、为什么需要事件循环

JavaScript是单线程的，这意味着它只有一个主线程来执行代码。如果所有任务（比如一个耗时的计算、一个网络请求）都同步执行，那么浏览器就会被卡住，无法响应用户的点击、输入，直到这个任务完成。这会造成极差的用户体验。

事件循环就是为了解决这个问题而生的：它让耗时的操作（如网络请求、文件读取）在后台异步执行，等这些操作完成后，再通过回调的方式来执行相应的代码，从而不阻塞主线程。

四、事件循环流程图用法演示

演示一：小菜一碟

先来一个都是同步代码的小菜，先了解一下前面画的流程图是怎样在调用栈当中执行JavaScript代码的。

console.log(1)



function funcOne() {

  console.log(2)

}



function funcTwo() {

  funcOne()

  console.log(3)

}



funcTwo()



console.log(4)

控制台输出：

1 2 3 4

下图为调用栈执行流程

每执行完一个同步任务会把该任务进行出栈。在这个例子当中每次在控制台输出一次，则进行一次出栈处理，直至全部代码执行完成。

演示二：小试牛刀

setTimeout+Promise组合拳，了解异步代码是如何进入任务队列等待执行的。

console.log(1)



setTimeout(() => {

  console.log('setTimeout', 2)

}, 0)



const promise = new Promise((resolve, reject) => {

  console.log('promise', 3)

  resolve(4)

})



setTimeout(() => {

  console.log('setTimeout', 5)

}, 10)



promise.then(res => {

  console.log('then', res)

})



console.log(6)

控制台输出：

1 promise 3 6 then 4 setTimeout 2 setTimeout 5

流程图执行-步骤一：

先执行同步代码，如遇到异步代码，则把异步回调事件放到后台监听或对应的任务队列。

1. 执行console.log(1)，控制台输出1。
2. 执行定时器，遇到异步代码，后台注册定时器回调事件，时间到了，把回调函数() => {console.log('setTimeout', 2)}，放到宏任务队列等待。
3. 执行创建Promise实例，并执行其中同步代码：执行console.log('promise', 3),控制台输出promise 3;执行resolve(4)，此时Promise已经确定为完成fulfilled状态，把promise.then()的回调函数响应值设为4。
4. 执行定时器，遇到异步代码，后台注册定时器回调事件，时间未到，把回调函数() => { console.log('setTimeout', 5) }放到后台监听。
5. 执行promise.then(res => { console.log('then', res) })，出栈走异步代码，把回调函数4 => { console.log('then', 4) }放入微任务队列等待。

流程图执行-步骤二：

上面已经把同步代码执行完成，并且把对应异步回调事件放到了指定任务队列，接下来开始事件循环。

6. 扫描微任务队列，执行4 => { console.log('then', 4) }回调函数，控制台输出then 4。
7. 微任务队列为空，扫描宏任务队列，执行() => {console.log('setTimeout', 2)}回调函数，控制台输出setTimeout 2。
8. 每执行完一个宏任务，需要再次扫描微任务队列是否存在可执行任务（假设此时后台定时到了，则会把() => { console.log('setTimeout', 5) }加入到了宏任务队列末尾）。
9. 微任务队列为空，扫描宏任务队列，执行() => { console.log('setTimeout', 5) }，控制台输出setTimeout 5。

演示三：稍有难度

setTimeout+Promise组合拳+多层嵌套Promise

console.log(1)



setTimeout(() => {

  console.log('setTimeout', 10)

}, 0)



new Promise((resolve, reject) => {

  console.log(2)

  resolve(7)



  new Promise((resolve, reject) => {

    resolve(5)

  }).then(res => {

    console.log(res)



    new Promise((resolve, reject) => {

      resolve('嵌套第三层 Promise')

    }).then(res => {

      console.log(res)

    })

  })



  Promise.resolve(6).then(res => {

    console.log(res)

  })



}).then(res => {

  console.log(res)

})



new Promise((resolve, reject) => {

  console.log(3)



  Promise.resolve(8).then(res => {

    console.log(res)

  })



  resolve(9)

}).then(res => {

  console.log(res)

})



console.log(4)

上一个演示说明了流程图执行的详细步骤，下面就不多加赘叙了，直接看图！

talk is cheap, show me the chart

上图，调用栈同步代码执行完成，开始事件循环，先看微任务队列，发现不为空，按顺序执行微任务事件：

上图，已经把刚才排队的微任务队列全部清空了。但是在执行第一个微任务时，发现还有嵌套微任务，则把该任务放到微任务队列末尾，然后接着一起执行完所有新增任务。

最后微任务清空后，接着执行宏任务。到此全部事件已执行完毕！

控制台完整输出顺序：

1 2 3 4 5 6 7 8 9 10

演示四：setTimeout伪定时

setTimeout并不是设置的定时到了就马上执行，而是把定时回调放在task queue任务队列当中进行等待，待主线程调用栈中的同步任务执行完成后空闲时才会执行。

const startTime = Date.now()

setTimeout(() => {

  const endTime = Date.now()

  console.log('setTimeout cost time', endTime - startTime)

  // setTimeout cost time 2314

}, 100)



for (let i = 0; i < 300000; i++) {

  // 模拟执行耗时同步任务

  console.log(i)

}

控制台输出：

1 2 3 ··· 300000 setTimeout cost time 2314

下图演示了其执行流程：

演示五：fetch网络请求和setTimeout

获取网络数据，fetch回调函数属于微任务，优于setTimeout先执行。

setTimeout(() => {

  console.log('setTimeout', 2)

}, 510)



const startTime = Date.now()

fetch('http://localhost:3000/test').then(res => {

  const endTime = Date.now()

  console.log('fetch cost time', endTime - startTime)

  return res.json()

}).then(data => {

  console.log('data', data)

})

下图当前Call Stack执行栈执行完同步代码后，由于fetch和setTimeout都是宏任务，所以走宏任务Web API流程后注册这两个事件回调，等待定时到后了，由于定时回调是个普通的同步函数，所以放到宏任务队列；等待fetch拿到服务器响应数据后，由于fetch回调为一个Promise对象，所以放到微任务队列。

经过多番刷新网页测试，下图控制台打印展示了setTimeout延时为510ms，fetch请求响应同样是510ms的情况下，.then(data => { console.log('data', data) })先执行了，也是由于fetch基于Promise实现，所以其回调为微任务。

五、结语

这可能只是简单的JavaScript代码执行事件循环流程，目的也是让大家更直观理解其中原理。实际执行过程可能还会读取堆内存获取引用类型数据、操作dom的方法，可能还会触发页面的重排、重绘等过程、异步文件读取和写入操作、fetch发起网络请求，与服务器建立连接获取网络数据等情况。

但是，它们异步执行的回调函数都会经过图中的这个事件循环过程，从而构成完整的浏览器事件循环。

作者：vilan_微澜
来源：juejin.cn/post/7577395040592756746

大家好，我是小悟。

• 想象一下你去游乐园，买了一张通票（登录），然后就可以玩所有项目（访问各个系统），不用每个项目都重新买票（重新登录）。这就是单点登录（SSO）的精髓！
  
  

  SSO的日常比喻

  
  
  
  
  • 普通登录：像去不同商场，每个都要查会员卡
  
  
  • 单点登录：像微信扫码登录，一扫全搞定
  
  
  • 令牌：像游乐园手环，戴着就能证明你买过票
  
  
  
  

  下面用代码来实现这个"游乐园通票系统"：

  
  

  代码实现：简易SSO系统

  
  

  import java.util.*;
  
  
  
  // 用户类 - 就是我们这些想玩项目的游客
  
  class User {
  
      private String username;
  
      private String password;
  
      
  
      public User(String username, String password) {
  
          this.username = username;
  
          this.password = password;
  
      }
  
      
  
      // getters 省略...
  
  }
  
  
  
  // 令牌类 - 游乐园手环
  
  class Token {
  
      private String tokenId;
  
      private String username;
  
      private Date expireTime;
  
      
  
      public Token(String username) {
  
          this.tokenId = UUID.randomUUID().toString();
  
          this.username = username;
  
          // 令牌1小时后过期 - 游乐园晚上要关门的！
  
          this.expireTime = new Date(System.currentTimeMillis() + 3600 * 1000);
  
      }
  
      
  
      public boolean isValid() {
  
          return new Date().before(expireTime);
  
      }
  
      
  
      // getters 省略...
  
  }
  
  
  
  // SSO认证中心 - 游乐园售票处
  
  class SSOAuthCenter {
  
      private Map<String, Token> validTokens = new HashMap<>();
  
      private Map<String, User> users = new HashMap<>();
  
      
  
      public SSOAuthCenter() {
  
          // 预先注册几个用户 - 办了年卡的游客
  
          users.put("zhangsan", new User("zhangsan", "123456"));
  
          users.put("lisi", new User("lisi", "abcdef"));
  
      }
  
      
  
      // 登录 - 买票入场
  
      public String login(String username, String password) {
  
          User user = users.get(username);
  
          if (user != null && user.getPassword().equals(password)) {
  
              Token token = new Token(username);
  
              validTokens.put(token.getTokenId(), token);
  
              System.out.println(username + " 登录成功！拿到游乐园手环：" + token.getTokenId());
  
              return token.getTokenId();
  
          }
  
          System.out.println("用户名或密码错误！请重新买票！");
  
          return null;
  
      }
  
      
  
      // 验证令牌 - 检查手环是否有效
  
      public boolean validateToken(String tokenId) {
  
          Token token = validTokens.get(tokenId);
  
          if (token != null && token.isValid()) {
  
              System.out.println("手环有效，欢迎继续玩耍！");
  
              return true;
  
          }
  
          System.out.println("手环无效或已过期，请重新登录！");
  
          validTokens.remove(tokenId); // 清理过期令牌
  
          return false;
  
      }
  
      
  
      // 登出 - 离开游乐园
  
      public void logout(String tokenId) {
  
          validTokens.remove(tokenId);
  
          System.out.println("已登出，欢迎下次再来玩！");
  
      }
  
  }
  
  
  
  // 业务系统A - 过山车
  
  class SystemA {
  
      private SSOAuthCenter authCenter;
  
      
  
      public SystemA(SSOAuthCenter authCenter) {
  
          this.authCenter = authCenter;
  
      }
  
      
  
      public void accessSystem(String tokenId) {
  
          System.out.println("=== 欢迎来到过山车 ===");
  
          if (authCenter.validateToken(tokenId)) {
  
              System.out.println("过山车启动！尖叫声在哪里！");
  
          } else {
  
              System.out.println("请先登录再玩过山车！");
  
          }
  
      }
  
  }
  
  
  
  // 业务系统B - 旋转木马
  
  class SystemB {
  
      private SSOAuthCenter authCenter;
  
      
  
      public SystemB(SSOAuthCenter authCenter) {
  
          this.authCenter = authCenter;
  
      }
  
      
  
      public void accessSystem(String tokenId) {
  
          System.out.println("=== 欢迎来到旋转木马 ===");
  
          if (authCenter.validateToken(tokenId)) {
  
              System.out.println("木马转起来啦！找回童年记忆！");
  
          } else {
  
              System.out.println("请先登录再玩旋转木马！");
  
          }
  
      }
  
  }
  
  
  
  // 测试我们的SSO系统
  
  public class SSODemo {
  
      public static void main(String[] args) {
  
          // 创建认证中心 - 游乐园大门
  
          SSOAuthCenter authCenter = new SSOAuthCenter();
  
          
  
          // 张三登录
  
          String token = authCenter.login("zhangsan", "123456");
  
          
  
          if (token != null) {
  
              // 拿着同一个令牌玩不同项目
  
              SystemA systemA = new SystemA(authCenter);
  
              SystemB systemB = new SystemB(authCenter);
  
              
  
              systemA.accessSystem(token);  // 玩过山车
  
              systemB.accessSystem(token);  // 玩旋转木马
  
              
  
              // 登出
  
              authCenter.logout(token);
  
              
  
              // 再尝试访问 - 应该被拒绝
  
              systemA.accessSystem(token);
  
          }
  
          
  
          // 测试错误密码
  
          authCenter.login("lisi", "wrongpassword");
  
      }
  
  }
  
  

  
  

  运行结果示例：

  
  

  zhangsan 登录成功！拿到游乐园手环：a1b2c3d4-e5f6-7890-abcd-ef1234567890
  
  === 欢迎来到过山车 ===
  
  手环有效，欢迎继续玩耍！
  
  过山车启动！尖叫声在哪里！
  
  === 欢迎来到旋转木马 ===
  
  手环有效，欢迎继续玩耍！
  
  木马转起来啦！找回童年记忆！
  
  已登出，欢迎下次再来玩！
  
  === 欢迎来到过山车 ===
  
  手环无效或已过期，请重新登录！
  
  请先登录再玩过山车！
  
  用户名或密码错误！请重新买票！
  
  

  
  

  总结一下：

  
  

  单点登录就像：

  
  
  
  
  • 一次认证，处处通行 🎫
  
  
  • 不用重复输入密码 🔑
  
  
  • 安全又方便 👍
  
  
  
  

  好的SSO系统就像好的游乐园管理，既要让游客玩得开心，又要确保安全！

谢谢你看我的文章，既然看到这里了，如果觉得不错，随手点个赞、转发、在看三连吧，感谢感谢。那我们，下次再见。

您的一键三连，是我更新的最大动力，谢谢

山水有相逢，来日皆可期，谢谢阅读，我们再会

我手中的金箍棒，上能通天，下能探海

起因

周五快下班，老板过来看权限配置页面。

"这个每次都要手动输路径？"

"对，现在是这样。"我打开给他看：

角色：运营专员

路由路径：[手动输入] /user/list

组件路径：[手动输入] @/views/user/List.vue

"上次运营配错了，/user/list 写成 /user/lists，页面打不开找了半天。能不能做个下拉框，直接选？"

我想了想："可以，但得先有个页面列表。"

"那就搞一个，现在页面这么多，手动输容易出错。"

确实，项目现在几十个页面，每次配置权限都要翻代码找路径，复制粘贴，还担心复制错。

解决办法

周末琢磨了一下，其实就是缺个"页面清单"。views 目录下都是页面文件，扫描一遍不就有了？

写了个 Node 脚本，自动扫描 views 目录，生成路由映射表。配置权限的时候下拉框选，还能搜索。

实现

两步：扫描文件 + 生成映射。

扫描 .vue 文件

function getAllVueFiles(dir, filesList = []) {

  const files = fs.readdirSync(dir);

  

  files.forEach((file) => {

    const filePath = path.join(dir, file);

    

    if (fs.statSync(filePath).isDirectory()) {

      getAllVueFiles(filePath, filesList);  // 递归子目录

    } else if (file.endsWith(".vue")) {

      filesList.push(filePath);  // 收集 .vue 文件

    }

  });

  

  return filesList;

}

生成映射文件

function start() {

  const viewsDir = path.resolve(__dirname, "../views");

  let files = getAllVueFiles(viewsDir);

  

  // 兼容 Windows 路径

  files = files.map(item => item.replace(/\\/g, "/"));

  

  // 拼接成 import 映射

  let str = "";

  files.forEach(item => {

    let n = item.replace(/.*src\//, "@/");

    str += `"${n}":()=>import("${n}"),\r\n`;

  });

  

  // 写入文件

  fs.writeFileSync(

    path.resolve(__dirname, "../router/all.router.js"),

    `export const ROUTERSDATA = {\n${str}}`

  );

}

最后生成的文件大概是这样：

// src/router/all.router.js

export const ROUTERSDATA = {

  "@/views/Home.vue": () => import("@/views/Home.vue"),

  "@/views/About.vue": () => import("@/views/About.vue"),

  "@/views/user/List.vue": () => import("@/views/user/List.vue"),

}

怎么用

权限配置页面

<template>

  <el-select 

    v-model="selectedRoute" 

    filterable 

    placeholder="搜索并选择页面">

    <el-option

      v-for="(component, path) in ROUTERSDATA"

      :key="path"

      :label="path"

      :value="path">

      {{ path }}

    </el-option>

  </el-select>

</template>



<script setup>

import { ROUTERSDATA } from '@/router/all.router.js'



// 后台返回的权限路由配置

const permissionRoutes = [

  { path: '/user/list', component: '@/views/user/List.vue' },

  { path: '/order/list', component: '@/views/order/List.vue' }

]



// 直接从映射表取组件

const routes = permissionRoutes.map(route => ({

  path: route.path,

  component: ROUTERSDATA[route.component]  // 这里直接用

}))

</script>

好处：

• 下拉框自动包含所有页面


• 支持搜索，输入 "user" 就能找到所有用户相关页面


• 新加页面自动出现在列表里

动态路由

后台返回权限配置，前端从映射表取组件：

function generateRoutes(backendConfig) {

  return backendConfig.map(item => ({

    path: item.path,

    component: ROUTERSDATA[item.component]  // 直接用

  }))

}

效果

周一把代码提上去，改了权限配置页面：

<!-- 配置页面 -->

<el-select v-model="route" filterable placeholder="搜索页面">

  <el-option 

    v-for="(component, path) in ROUTERSDATA" 

    :key="path" 

    :label="path" 

    :value="path" />

</el-select>

老板过来试了一下，在下拉框输入 "user" 就搜到所有用户相关页面。

"嗯，这个好用。新加页面也会自动出现在这里吧？"

"对，每次启动项目会自动扫描。"

"行，那就这样。"

后来发现还有些意外收获：

• 新人看这个映射表就知道项目有哪些页面


• 后台只存路径字符串，数据库干净


• 顺带解决了手动 import 几十个路由的问题

在 package.json 加个脚本：

{

  "scripts": {

    "dev": "node src/start/index.js && vite"

  }

}

每次 npm run dev 会先扫描 views 目录，生成最新的映射表。

完整代码

// src/start/index.js

const fs = require("fs");

const path = require("path");



function getAllVueFiles(dir, filesList = []) {

  const files = fs.readdirSync(dir);



  files.forEach((file) => {

    const filePath = path.join(dir, file);

    const stat = fs.statSync(filePath);



    if (stat.isDirectory()) {

      getAllVueFiles(filePath, filesList);

    } else if (file.endsWith(".vue")) {

      filesList.push(filePath);

    }

  });



  return filesList;

}



function start() {

  console.log("[自动获取全部可显示页面]");



  const viewsDir = path.resolve(__dirname, "../views");

  let files = getAllVueFiles(viewsDir);



  // 统一路径分隔符，兼容 Windows 反斜杠

  files = files.map((item) => item.replace(/\\/g, "/"));



  let str = "";

  // 构造 import 映射："@/views/xxx.vue": ()=>import("@/views/xxx.vue")

  files.forEach((item) => {

    let n = item.replace(/.*src\//, "@/"); 

    str += `"${n}":()=>import("${n}"),\r\n`;

  });



  const routerFilePath = path.resolve(__dirname, "../router/all.router.js");

  // 将映射写入路由聚合文件，供路由动态引用

  fs.writeFileSync(

    routerFilePath,

    `

    export const ROUTERSDATA = {

    ${str}

    }`,

  );

  console.log("[./src/router/all.router.js 写入]");

}



start();

注意事项

记得把生成的 src/router/all.router.js 加到 .gitignore，毕竟是自动生成的文件，没必要提交。

# .gitignore

src/router/all.router.js

后来

用了一个多月，运营配置权限再也没出过错。上周老板说："这个功能不错，其他项目也加上。"

代码其实挺简单的，但确实解决了问题。

前言

前些天有位小伙伴和我吐槽他在外包工作的经历，语气颇为激动又带着深深的无奈。

1. 上岸折戟尘沙

本人男，安徽马鞍山人士，21年毕业于江苏某末流211，在校期间转码。

上网课期间就向往大城市，于是毕业后去了深圳，找到了一家中等IT公司（人数500+）搬砖，住着宝安城中村，来往繁华南山区。

待了三年多，自知买房变深户无望，没有归属感，感觉自己也没那么热爱技术，于是乎想回老家考公务员，希望待在宇宙的尽头。

24年末，匆忙备考，平时工作忙里偷闲刷题，不出所料，笔试卒，梦碎。

2. 误入外包

复盘了备考过程，觉得工作占用时间过多，想要找一份轻松点且离家近的工作，刚好公司也有大礼包的指标，于是主动申请，辞别深圳，前往徽京。

Boss上南京的软件大部分是外包（果然是外包之都），前几年外包还很活跃，这些年外包都沉寂了不少，找了好几个月，断断续续有几个邀约，最后实在没得选了，想着反正就过渡一下挣点钱不寒碜，接受了外包，作为WX服务某为。薪资比在深圳降了一些，在接受的范围内。

想着至少苟着等待下一次考公，因此前期做项目比较认真，遇到问题追根究底，为解决问题也主动加班加点，同为WX的同事都笑话我说比自有员工还卷，我却付之一笑。

直到我经历了几件事，正所谓人教人教不会，事教人一教就会。

3. 我在外包的二三事

有一次，我提出了自有员工设计方案的衍生出的一个问题，并提出拉个会讨论一下，他并没有当场答应，而是回复说：我们内部看看。

而后某天我突然被邀请进入会议，聊了几句，意犹未尽之际，突然就被踢出会议...开始还以为是某位同事误触按钮，然后再申请入会也没响应。

后来我才知道，他们内部商量核心方案，因为权限管控问题，我不能参会。

这是我第一次体会到WX和自有员工身份上的隔阂。

还有一次和自有员工一起吃饭的时候，他不小心说漏嘴了他的公积金，我默默推算了一下他的工资至少比我高了50%，而他的毕业院校、工作经验和我差不多，瞬间不平衡了。

还有诸如其它的团建、夜宵、办公权限、工牌等无一不是明示着你是外包员工，要在外包的规则内行事。
至于转正的事，头上还有OD呢，OD转正的几率都很低，好几座大山要爬呢，别想了。

3. 反求诸己

以前网上看到很多吐槽外包的帖子，还总觉得言过其实，亲身经历了才刻骨铭心。

我现在已经摆正了心态，既来之则安之。正视自己WX的身份，给多少钱干多少活，给多少权利就承担多少义务。

不攀比，不讨好，不较真，不内耗，不加班。

另外每次当面讨论的时候，我都会把工牌给露出来，潜台词就是：快看，我就是个外包，别为难我😔~

另外我现在比较担心的是：

万一我考公还是失败，继续找工作的话，这段外包经历会不会是我简历的污点😢

当然这可能是我个人感受，其它外包的体验我不知道，也不想再去体验了。

对，这辈子和下辈子都不想了。
附南京外包之光，想去或者不想去的伙伴可以留意一下：

作者：面汤放盐 / uzong

在软件开发的世界里，我们习惯用代码表达逻辑，但当系统涉及多个角色、多个服务、甚至跨团队协作时，光靠代码注释或口头沟通，往往不够。这时候，一张清晰的流程图，胜过千行文档。

泳道图 ：它可能不像 UML 那样“高大上”，也不如架构图那样宏观，但在梳理业务流程、厘清责任边界、排查系统瓶颈时，它真的非常实用。

1. 什么是泳道图

泳道图的核心思想很简单：把流程中的每个步骤，按执行者（人、系统、模块）分组排列，就像游泳池里的泳道一样，各走各道，互不干扰又彼此关联。

每一列就是一个“泳道”，代表一个责任主体。流程从左到右、从上到下流动，谁在什么时候做了什么，一目了然

一眼就能看出：谁干了什么，谁依赖谁，边界是什么。

与流程的差异点：

• 流程图聚焦：“步骤顺序”，侧重 “先做什么、再做什么”，适合梳理线性业务流程；


• 泳道图聚焦： “流转通道”，侧重 “什么东西在什么约束下通过什么路径流转”，适合拆解复杂、多路径、有规则约束的流转场景（如分布式系统数据同步、供应链物料流转、微服务请求链路等）

2. 泳道图分类

2.1. 垂直泳道图

垂直泳道图采取上下布局结构，‌主要强调职能群体。这种布局方式更适合于展示跨职能任务和流程中，‌各职能部门或角色之间的垂直关系和职能分工。

2.2. 水平泳道图

水平泳道图则采用左右布局结构，‌重点在于事件进程的展示。这种布局方式更适合于强调事件或过程的水平流动，‌以及不同阶段或部门在流程中的水平参与

3. 泳道图组成元素

泳池： 泳池是泳道图的外部框架，泳道、流程都包含于泳池内。

泳道： 泳池里可以创建多个泳道。

流程： 实际的业务流程。

部门： 通过部门或者责任来区分，明确每个部门/人/信息系统负责完成的任务环节。

阶段： 通过任务阶段来区分，明确每个阶段需要处理的任务环节。

4. 泳道图应用场景

4.1. 项目管理

展示项目从启动到完成的各个阶段，明确每个团队或成员在项目中的角色和职责，便于进行项目管理和监控，同时促进团队协作和沟通

4.2. 业务流程分析

展示业务流程的各个环节和涉及的不同部门或职能。通过分析泳道图，可以发现业务流程中的瓶颈、冗余环节或不合理之处，进而进行流程优化和改进。

4.3. 系统设计

展示系统的整体架构和各个组件之间的关系，描述系统的工作流程，包括数据的输入、处理、输出等各个环节，有助于系统开发人员更好地理解系统的功能和需求

5. 更多参考模板

故障处理多维泳道图

资源扩容泳道图

6. 最后

我刚工作时，看到导师抛出一份精致的泳道图，把一团乱麻的问题讲得透亮，心里特别佩服。直到自己多年后用上才真正体会：在面对跨部门协作、复杂故障排查、关键流程设计时，掏出这么一张图，往往就是高效沟通的开始。

作为开发者，我们常陷入“只要代码跑得通就行”的思维惯性。但软件不仅是机器执行的指令，更是人与人协作的媒介。泳道图这样的工具，本质上是在降低认知成本——让复杂的事情变得可沟通、可验证、可迭代。 其实泳道图的核心不是“画图”，而是“梳理流程、明确权责”。

在跨部门、协同需求、故障分析等关键场景使用泳道图是非常合适，并且也能把问题讲清楚。技术世界充满了抽象和复杂性，而优秀工程师的能力之一，就是创建合适的可视化工具，让复杂问题变得简单可见。

本文中的大部分图片来源于 ProcessOn，ProcessOn 是一个非常不错的画图软件，功能强大，界面优美。

你是小阿巴，刚入职的低级程序员，正在开发一个批量导入数据的程序。

没想到，程序刚上线，产品经理就跑过来说：小阿巴，用户反馈你的程序有 Bug，刚导入没多久就报错中断了！

你赶紧打开服务器，看着比你发量都少的报错信息：

你一脸懵逼：只有这点儿信息，我咋知道哪里出了问题啊？！

你只能硬着头皮让产品经理找用户要数据，然后一条条测试，看看是哪条数据出了问题……

原本大好的摸鱼时光，就这样无了。

这时，你的导师鱼皮走了过来，问道：小阿巴，你是持矢了么？脸色这么难看？

你无奈地说：皮哥，刚才线上出了个 bug，我花了 8 个小时才定位到问题……

鱼皮皱了皱眉：这么久？你没打日志吗？

你很是疑惑：谁是日志？为什么要打它？

鱼皮叹了口气：唉，难怪你要花这么久…… 来，我教你打日志！

⭐️ 本文对应视频版：bilibili.com/video/BV1K7…

什么是日志？

鱼皮打开电脑，给你看了一段代码：

@Slf4j

public class UserService {

   public void batchImport(List<UserDTO> userList) {

       log.info("开始批量导入用户，总数：{}", userList.size());

       

       int successCount = 0;

       int failCount = 0;

       

       for (UserDTO userDTO : userList) {

           try {

               log.info("正在导入用户：{}", userDTO.getUsername());

               validateUser(userDTO);

               saveUser(userDTO);

               successCount++;

               log.info("用户 {} 导入成功", userDTO.getUsername());

          } catch (Exception e) {

               failCount++;

               log.error("用户 {} 导入失败，原因：{}", userDTO.getUsername(), e.getMessage(), e);

          }

      }

       

       log.info("批量导入完成，成功：{}，失败：{}", successCount, failCount);

  }

}

你看着代码里的 log.info、log.error，疑惑地问：这些 log 是干什么的？

鱼皮：这就是打日志。日志用来记录程序运行时的状态和信息，这样当系统出现问题时，我们可以通过日志快速定位问题。

你若有所思：哦？还可以这样！如果当初我的代码里有这些日志，一眼就定位到问题了…… 那我应该怎么打日志？用什么技术呢？

怎么打日志？

鱼皮：每种编程语言都有很多日志框架和工具库，比如 Java 可以选用 Log4j 2、Logback 等等。咱们公司用的是 Spring Boot，它默认集成了 Logback 日志框架，你直接用就行，不用再引入额外的库了~

日志框架的使用非常简单，先获取到 Logger 日志对象。

1）方法 1：通过 LoggerFactory 手动获取 Logger 日志对象：

public class MyService {

   private static final Logger logger = LoggerFactory.getLogger(MyService.class);

}

2）方法 2：使用 this.getClass 获取当前类的类型，来创建 Logger 对象：

public class MyService {

   private final Logger logger = LoggerFactory.getLogger(this.getClass());

}

然后调用 logger.xxx（比如 logger.info）就能输出日志了。

public class MyService {

   private final Logger logger = LoggerFactory.getLogger(this.getClass());

​

   public void doSomething() {

       logger.info("执行了一些操作");

  }

}

效果如图：

小阿巴：啊，每个需要打日志的类都要加上这行代码么？

鱼皮：还有更简单的方式，使用 Lombok 工具库提供的 @Slf4j 注解，可以自动为当前类生成日志对象，不用手动定义啦。

@Slf4j

public class MyService {

   public void doSomething() {

       log.info("执行了一些操作");

  }

}

上面的代码等同于 “自动为当前类生成日志对象”：

private static final org.slf4j.Logger log = 

   org.slf4j.LoggerFactory.getLogger(MyService.class);

你咧嘴一笑：这个好，爽爽爽！

等等，不对，我直接用 Java 自带的 System.out.println 不也能输出信息么？何必多此一举？

System.out.println("开始导入用户" + user.getUsername());

鱼皮摇了摇头：千万别这么干！

首先，System.out.println 是一个同步方法，每次调用都会导致耗时的 I/O 操作，频繁调用会影响程序的性能。

而且它只能输出信息到控制台，不能灵活控制输出位置、输出格式、输出时机等等。比如你现在想看三天前的日志，System.out.println 的输出早就被刷没了，你还得浪费时间找半天。

你恍然大悟：原来如此！那使用日志框架就能解决这些问题吗？

鱼皮点点头：没错，日志框架提供了丰富的打日志方法，还可以通过修改日志配置文件来随心所欲地调教日志，比如把日志同时输出到控制台和文件中、设置日志格式、控制日志级别等等。

在下苦心研究日志多年，沉淀了打日志的 8 大邪修秘法，先传授你 2 招最基础的吧。

打日志的 8 大最佳实践

1、合理选择日志级别

第一招，日志分级。

你好奇道：日志还有级别？苹果日志、安卓日志？

鱼皮给了你一巴掌：可不要乱说，日志的级别是按照重要程度进行划分的。

其中 DEBUG、INFO、WARN 和 ERROR 用的最多。

• 调试用的详细信息用 DEBUG


• 正常的业务流程用 INFO


• 可能有问题但不影响主流程的用 WARN


• 出现异常或错误的用 ERROR

log.debug("用户对象的详细信息：{}", userDTO);  // 调试信息

log.info("用户 {} 开始导入", username);  // 正常流程信息

log.warn("用户 {} 的邮箱格式可疑，但仍然导入", username);  // 警告信息

log.error("用户 {} 导入失败", username, e);  // 错误信息

你挠了挠头：俺直接全用 DEBUG 不行么？

鱼皮摇了摇头：如果所有信息都用同一级别，那出了问题时，你怎么快速找到错误信息？

在生产环境，我们通常会把日志级别调高（比如 INFO 或 WARN），这样 DEBUG 级别的日志就不会输出了，防止重要信息被无用日志淹没。

你点点头：俺明白了，不同的场景用不同的级别！

2、正确记录日志信息

鱼皮：没错，下面教你第二招。你注意到我刚才写的日志里有一对大括号 {} 吗？

log.info("用户 {} 开始导入", username);

你回忆了一下：对哦，那是啥啊？

鱼皮：这叫参数化日志。{} 是一个占位符，日志框架会在运行时自动把后面的参数值替换进去。

你挠了挠头：我直接用字符串拼接不行吗？

log.info("用户 " + username + " 开始导入");

鱼皮摇摇头：不推荐。因为字符串拼接是在调用 log 方法之前就执行的，即使这条日志最终不被输出，字符串拼接操作还是会执行，白白浪费性能。

你点点头：确实，而且参数化日志比字符串拼接看起来舒服~

鱼皮：没错。而且当你要输出异常信息时，也可以使用参数化日志：

try {

   // 业务逻辑

} catch (Exception e) {

   log.error("用户 {} 导入失败", username, e);  // 注意这个 e

}

这样日志框架会同时记录上下文信息和完整的异常堆栈信息，便于排查问题。

你抱拳：学会了，我这就去打日志！

3、把控时机和内容

很快，你给批量导入程序的代码加上了日志：

@Slf4j

public class UserService {

   public BatchImportResult batchImport(List<UserDTO> userList) {

       log.info("开始批量导入用户，总数：{}", userList.size());

       int successCount = 0;

       int failCount = 0;

       for (UserDTO userDTO : userList) {

           try {

               log.info("正在导入用户：{}", userDTO.getUsername());   

               // 校验用户名

               if (StringUtils.isBlank(userDTO.getUsername())) {

                   throw new BusinessException("用户名不能为空");

              }

               // 保存用户

               saveUser(userDTO);

               successCount++;

               log.info("用户 {} 导入成功", userDTO.getUsername());

          } catch (Exception e) {

               failCount++;

               log.error("用户 {} 导入失败，原因：{}", userDTO.getUsername(), e.getMessage(), e);

          }

      }

       log.info("批量导入完成，成功：{}，失败：{}", successCount, failCount);

       return new BatchImportResult(successCount, failCount);

  }

}

光做这点还不够，你还翻出了之前的屎山代码，想给每个文件都打打日志。

但打着打着，你就不耐烦了：每段代码都要打日志，好累啊！但是不打日志又怕出问题，怎么办才好？

鱼皮笑道：好问题，这就是我要教你的第三招 —— 把握打日志的时机。

对于重要的业务功能，我建议采用防御性编程，先多多打日志。比如在方法代码的入口和出口记录参数和返回值、在每个关键步骤记录执行状态，而不是等出了问题无法排查的时候才追悔莫及。之后可以再慢慢移除掉不需要的日志。

你叹了口气：这我知道，但每个方法都打日志，工作量太大，都影响我摸鱼了！

鱼皮：别担心，你可以利用 AOP 切面编程，自动给每个业务方法的执行前后添加日志，这样就不会错过任何一次调用信息了。

你双眼放光：这个好，爽爽爽！

鱼皮：不过这样做也有一个缺点，注意不要在日志中记录了敏感信息，比如用户密码。万一你的日志不小心泄露出去，就相当于泄露了大量用户的信息。

你拍拍胸脯：必须的！

4、控制日志输出量

一个星期后，产品经理又来找你了：小阿巴，你的批量导入功能又报错啦！而且怎么感觉程序变慢了？

你完全不慌，淡定地打开服务器的日志文件。结果瞬间呆住了……

好家伙，满屏都是密密麻麻的日志，这可怎么看啊？！

鱼皮看了看你的代码，摇了摇头：你现在每导入一条数据都要打一些日志，如果用户导入 10 万条数据，那就是几十万条日志！不仅刷屏，还会影响性能。

你有点委屈：不是你让我多打日志的么？那我应该怎么办？

鱼皮：你需要控制日志的输出量。

1）可以添加条件来控制，比如每处理 100 条数据时才记录一次：

if ((i + 1) % 100 == 0) {

   log.info("批量导入进度：{}/{}", i + 1, userList.size());

}

2）或者在循环中利用 StringBuilder 进行字符串拼接，循环结束后统一输出：

StringBuilder logBuilder = new StringBuilder("处理结果：");

for (UserDTO userDTO : userList) {

   processUser(userDTO);

   logBuilder.append(String.format("成功[ID=%s], ", userDTO.getId()));

}

log.info(logBuilder.toString());

3）还可以通过修改日志配置文件，过滤掉特定级别的日志，防止日志刷屏：

<appender name="FILE" class="ch.qos.logback.core.FileAppender">

   <file>logs/app.log</file>

   <!-- 只允许 INFO 级别及以上的日志通过 -->

   <filter class="ch.qos.logback.classic.filter.ThresholdFilter">

       <level>INFO</level>

   </filter>

</appender>

5、统一日志格式

你开心了：好耶，这样就不会刷屏了！但是感觉有时候日志很杂很乱，尤其是我想看某一个请求相关的日志时，总是被其他的日志干扰，怎么办？

鱼皮：好问题，可以在日志配置文件中定义统一的日志格式，包含时间戳、线程名称、日志级别、类名、方法名、具体内容等关键信息。

<!-- 控制台日志输出 -->

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">

   <encoder>

       <!-- 日志格式 -->

       <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>

   </encoder>

</appender>

这样输出的日志更整齐易读：

此外，你还可以通过 MDC（Mapped Diagnostic Context）给日志添加额外的上下文信息，比如请求 ID、用户 ID 等，方便追踪。

在 Java 代码中，可以为 MDC 设置属性值：

@PostMapping("/user/import")

public Result importUsers(@RequestBody UserImportRequest request) {

   // 1. 设置 MDC 上下文信息

   MDC.put("requestId", generateRequestId());

   MDC.put("userId", String.valueOf(request.getUserId()));

   try {

       log.info("用户请求处理完成");      

       // 执行具体业务逻辑

       userService.batchImport(request.getUserList());     

       return Result.success();

  } finally {

       // 2. 及时清理MDC（重要！）

       MDC.clear();

  }

}

然后在日志配置文件中就可以使用这些值了：

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">

   <encoder>

       <!-- 包含 MDC 信息 -->

       <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - [%X{requestId}] [%X{userId}] %msg%n</pattern>

   </encoder>

</appender>

这样，每个请求、每个用户的操作一目了然。

6、使用异步日志

你又开心了：这样打出来的日志，确实舒服，爽爽爽！但是我打日志越多，是不是程序就会更慢呢？有没有办法能优化一下？

鱼皮：当然有，可以使用 异步日志。

正常情况下，你调用 log.info() 打日志时，程序会立刻把日志写入文件，这个过程是同步的，会阻塞当前线程。而异步日志会把写日志的操作放到另一个线程里去做，不会阻塞主线程，性能更好。

你眼睛一亮：这么厉害？怎么开启？

鱼皮：很简单，只需要修改一下配置文件：

<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">

   <queueSize>512</queueSize>  <!-- 队列大小 -->

   <discardingThreshold>0</discardingThreshold>  <!-- 丢弃阈值，0 表示不丢弃 -->

   <neverBlock>false</neverBlock>  <!-- 队列满时是否阻塞，false 表示会阻塞 -->

   <appender-ref ref="FILE" />  <!-- 引用实际的日志输出目标 -->

</appender>

<root level="INFO">

   <appender-ref ref="ASYNC" />

</root>

不过异步日志也有缺点，如果程序突然崩溃，缓冲区中还没来得及写入文件的日志可能会丢失。

所以要权衡一下，看你的系统更注重性能还是日志的完整性。

你想了想：我们的程序对性能要求比较高，偶尔丢几条日志问题不大，那我就用异步日志吧。

7、日志管理

接下来的很长一段时间，你混的很舒服，有 Bug 都能很快发现。

你甚至觉得 Bug 太少、工作没什么激情，所以没事儿就跟新来的实习生阿坤吹吹牛皮：你知道日志么？我可会打它了！

直到有一天，运维小哥突然跑过来：阿巴阿巴，服务器挂了！你快去看看！

你连忙登录服务器，发现服务器的硬盘爆满了，没法写入新数据。

你查了一下，发现日志文件竟然占了 200GB 的空间！

你汗流浃背了，正在考虑怎么甩锅，结果阿坤突然鸡叫起来：阿巴 giegie，你的日志文件是不是从来没清理过？

你尴尬地倒了个立，这样眼泪就不会留下来。

鱼皮叹了口气：这就是我要教你的下一招 —— 日志管理。

你好奇道：怎么管理？我每天登服务器删掉一些历史文件？

鱼皮：人工操作也太麻烦了，我们可以通过修改日志配置文件，让框架帮忙管理日志。

首先设置日志的滚动策略，可以根据文件大小和日期，自动对日志文件进行切分。

<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">

   <fileNamePattern>logs/app-%d{yyyy-MM-dd}.%i.log</fileNamePattern>

   <maxFileSize>10MB</maxFileSize>

   <maxHistory>30</maxHistory>

</rollingPolicy>

这样配置后，每天会创建一个新的日志文件（比如 app-2025-10-23.0.log），如果日志文件大小超过 10MB 就再创建一个（比如 app-2025-10-23.1.log），并且只保留最近 30 天的日志。

还可以开启日志压缩功能，进一步节省磁盘空间：

<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">

   <!-- .gz 后缀会自动压缩 -->

   <fileNamePattern>logs/app-%d{yyyy-MM-dd}.log.gz</fileNamePattern>

</rollingPolicy>

你有些激动：吼吼，这样我们就可以按照天数更快地查看日志，服务器硬盘也有救啦！

8、集成日志收集系统

两年后，你负责的项目已经发展成了一个大型的分布式系统，有好几十个微服务。

如今，每次排查问题你都要登录到不同的服务器上查看日志，非常麻烦。而且有些请求的调用链路很长，你得登录好几台服务器、看好几个服务的日志，才能追踪到一个请求的完整调用过程。

你简直要疯了！

于是你找到鱼皮求助：现在查日志太麻烦了，当年你还有一招没有教我，现在是不是……

鱼皮点点头：嗯，对于分布式系统，就必须要用专业的日志收集系统了，比如很流行的 ELK。

你好奇：ELK 是啥？伊拉克？

阿坤抢答道：我知道，就是 Elasticsearch + Logstash + Kibana 这套组合。

简单来说，Logstash 负责收集各个服务的日志，然后发送给 Elasticsearch 存储和索引，最后通过 Kibana 提供一个可视化的界面。

这样一来，我们可以方便地集中搜索、查看、分析日志。

你惊讶了：原来日志还能这么玩，以后我所有的项目都要用 ELK！

鱼皮摆摆手：不过 ELK 的搭建和运维成本比较高，对于小团队来说可能有点重，还是要按需采用啊。

结局

至此，你已经掌握了打日志的核心秘法。

只是你很疑惑，为何那阿坤竟对日志系统如此熟悉？

阿坤苦笑道：我本来就是日志管理大师，可惜我上家公司的同事从来不打日志，所以我把他们暴打了一顿后跑路了。

阿巴 giegie 你要记住，日志不是写给机器看的，是写给未来的你和你的队友看的！

你要是以后不打日志，我就打你！

更多

💻 编程学习交流：编程导航 📃 简历快速制作：老鱼简历 ✏️ 面试刷题神器：面试鸭

前言

“分库分表这种架构模式会逐步的被淘汰！” 不知道在哪儿看到的观点

如果我们现在在搭建新的业务架构，如果说你们未来的业务数据量会达到千万 或者上亿的级别 还在一股脑的使用分库分表的架构，那么你们的技术负责人真的就应该提前退休了🙈

如果对未来的业务非常有信心，单表的数据量能达到千万上亿的级别，请使用NewSQL 数据库，那么NewSQL 这么牛，分布库分表还有意义吗？

今天虽然写的是一篇博客，但是更多的是抱着和大家讨论的心态来的，所以大家目前有深度参与分库分表，或者NewSQL 的都可以在评论区讨论！

什么是NewSQL

NewSQL 是21世纪10年代初出现的一个术语，用来描述一类新型的关系型数据库管理系统（RDBMS）。它们的共同目标是：在保持传统关系型数据库（如Oracle、MySQL）的ACID事务和SQL模型优势的同时，获得与NoSQL系统类似的、弹性的水平扩展能力

NewSQL 的核心理念就是 将“分库分表”的复杂性从应用层下沉到数据库内核层，对上层应用呈现为一个单一的数据库入口，解决现在 分库分表的问题；

分库分表的问题

分库分表之后，会带来非常多的问题；比如需要跨库联查、跨库更新数据如何保证事务一致性等问题，下面就来详细看看分库分表都有那些问题

选择TiDB还是采用mysql 分库分表的设计

数据量非常大，需要满足OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 且预算充足（分布式数据库的成本也是非常高的这一点非常的重要），并且是新业务新架构落地 优先推荐使用TiDB。
当然实际上选择肯定是需要多方面考虑的，大家有什么观点都可以在评论区讨论。

可以看看一个资深开发，深度参与TiDB项目，他对TiDB的一些看法：

1 什么是TiDB？

TiDB是PingCAP公司研发的开源分布式关系型数据库，采用存储计算分离架构，支持混合事务分析处理（HTAP） 。它与MySQL 5.7协议兼容，并支持MySQL生态，这意味着使用MySQL的应用程序可以几乎无需修改代码就能迁移到TiDB。

🚀目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

官方文档：docs.pingcap.com/zh/tidb/dev…

TiDB五大核心特性

TiDB之所以在分布式数据库领域脱颖而出，得益于其五大核心特性：

• 一键水平扩容或缩容：得益于存储计算分离的架构设计，可按需对计算、存储分别进行在线扩容或缩容，整个过程对应用透明。


• 金融级高可用：数据采用多副本存储，通过Multi-Raft协议同步事务日志，只有多数派写入成功事务才能提交，确保数据强一致性。


• 实时HTAP：提供行存储引擎TiKV和列存储引擎TiFlash，两者之间的数据保持强一致，解决了HTAP资源隔离问题。


• 云原生分布式数据库：通过TiDB Operator可在公有云、私有云、混合云中实现部署工具化、自动化。


• 兼容MySQL 5.7协议和生态：从MySQL迁移到TiDB无需或只需少量代码修改，极大降低了迁移成本。

2 TiDB与MySQL的核心差异

虽然TiDB兼容MySQL协议，但它们在架构设计和适用场景上存在根本差异。以下是它们的详细对比：

2.1 架构差异

表1：TiDB与MySQL架构对比

2.2 性能表现对比

性能方面，TiDB与MySQL各有优势，主要取决于数据量和查询类型：

• 小数据量简单查询：在数据量百万级以下的情况下，MySQL的写入性能和点查点写通常优于TiDB。因为TiDB的分布式架构在少量数据时无法充分发挥优势，却要承担分布式事务的开销。


• 大数据量复杂查询：当数据量达到千万级以上，TiDB的性能优势开始显现。一张千万级别表关联查询，MySQL可能需要20秒，而TiDB+TiKV只需约5.57秒，使用TiFlash甚至可缩短到0.5秒。


• 高并发场景：MySQL性能随着并发增加会达到瓶颈然后下降，而TiDB性能基本随并发增加呈线性提升，节点资源不足时还可通过动态扩容提升性能。

2.3 扩展性与高可用对比

MySQL的主要扩展方式是一主多从架构，主节点无法横向扩展（除非接受分库分表），从节点扩容需要应用支持读写分离。而TiDB的存储和计算节点都可以独立扩容，支持最大512节点，集群容量可达PB级别。

高可用方面，MySQL使用增强半同步和MGR方案，但复制效率较低，主节点故障会影响业务处理[]。TiDB则通过Raft协议将数据打散分布，单机故障对集群影响小，能保证RTO（恢复时间目标）不超过30秒且RPO（恢复点目标）为0，真正实现金融级高可用。

2.4 SQL功能及兼容性

虽然TiDB高度兼容MySQL 5.7协议和生态，但仍有一些重要差异需要注意：

不支持的功能包括：

• 存储过程与函数


• 触发器


• 事件


• 自定义函数


• 全文索引（计划中）


• 空间类型函数和索引

有差异的功能包括：

• 自增ID的行为（TiDB推荐使用AUTO_RANDOM避免热点问题）


• 查询计划的解释结果


• 在线DDL能力（TiDB更强，不锁表支持DML并行操作）

3 如何选择：TiDB还是MySQL？

选择数据库时，应基于实际业务需求和技术要求做出决策。以下是具体的选型建议：

3.1 选择TiDB的场景

TiDB在以下场景中表现卓越：

3.2 选择MySQL的场景

MySQL在以下情况下仍是更合适的选择：

3.3 决策参考框架

为了更直观地帮助决策，可以参考以下决策表：