我们都在赶任务，写代码、提 PR、上线、关卡。

这一切都很熟悉，甚至成了习惯。

你可能代码量不少、功能交付及时，但

一年后再回头看这些代码，你自己会满意吗？

工作中，我们常常把“做完”当成“做好”。

交付变成了默认目标，而不是思考的起点。

在交付压力下，“先写出来”成了底线，

而“写得优雅”“设计得合理”“维护方便”被悄悄让位。

✅ KISS：你写的函数有没有 100 行起步、逻辑嵌套 4 层？

✅ DRY：你是否为了“复用”提早抽象，导致 utils/utils/utils.ts ？

✅ WET：你是否担心“代码重复”，结果提前抽象出错误通用逻辑？

✅ AHA：你是否为了炫技构建了没人能读懂的“优雅体系”？

✅ YAGNI：你写了“以后肯定会用”的扩展点，结果一直没人用？

✅ SOLID：你是否写了一个组件负责了所有事情：表单展示 + 校验逻辑 + 错误提示？

4. 代码之外，成长才是核心任务

写完功能只是完成了基本工作，但

写得清晰、可维护、有积累价值的代码

结语：别做任务机器，做思考的工程师

交付很重要，但它不该遮蔽我们的眼睛。

养成了判断力、抽象力和传承意识。

不要被交付困住了方向，别让忙碌遮挡了成长。

每一次写代码的机会，都是你进阶工程师思维的练习场。

KISS、DRY、WET、AHA、YAGNI、SOLID 你真的在用吗？

不要让代码交付蒙蔽了你的职业发展

Long Zhao

 是软件工程中的一个术语，意味着“绿地”——一块全新的地皮，没有遗留代码、没有架构束缚、没有历史负债。你可以从一张白纸开始，设计系统、选择技术栈、定义模型、划分边界、建立工作流。

这与维护一个已有产品（也就是所谓的 Brownfield 项目）是完全不同的体验。

为什么 Greenfield 项目如此重要？

你必须做决策，而不是执行命令

在一个 Greenfield 项目中，没有人告诉你“后端用这个框架”、“数据库字段都在这里”、“登录流程已经搭好了”。你需要自己——或和团队一起——去

，并承担决策的后果。这是 developer 和 engineer 的分水岭。

你会真正理解“系统的完整生命周期”

从创建代码仓库，到上线第一个版本，再到后期维护和扩展。Greenfield 项目会让你体验：

这些并不是只有高级工程师才需要关心的事情，而是你早晚都会面对的成长关卡。

你学到的是“为什么”，而不是“怎么做”

很多初学者通过教程、代码抄写学会了“怎么做一个登录页”，但没学会“为什么这样做”。Greenfield 项目会逼迫你问出这些问题：

这是许多产品团队中的术语，用来指代

产品正式开发前的“第 0 次迭代”

换句话说，Iteration 0 是产品真正“从无到有”的开始阶段。

你在这个阶段的角色，不再只是一个执行者，而是一个系统构建者。能否参与 Iteration 0，往往决定了你是否具备“架构意识”和“系统思维”。

在你的职业道路上，你或许参与过许多项目维护、bug 修复、功能补丁、版本迭代……但如果你从未参与过一个 Greenfield 项目，那你可能还没有真正完成从“写代码的人”到“构建系统的人”的转变。

为什么你需要经历至少一个 Greenfield 项目，才能成为合格的 Developer？

很多正在找第一份 IT 工作的人，常常陷入一个误区：

学了很多教程、写了很多代码，却仍然没人理你，面试也讲不清楚自己做了什么。

误解了“写代码”这件事的真正意义。

写代码不是为了学技术，而是在训练“工程思维”

你以为你在写 React、写 API、写 TypeScript，

但你真正应该训练的，其实是：

你写出来的代码结构是否清晰？功能有没有合理拆分？有没有避免一股脑把所有逻辑堆在一个文件里？

面试的时候你能不能清楚地解释你的设计思路和实现过程？能不能讲得让非工程背景的人都听懂？

你有没有考虑用户输错内容？接口报错了怎么办？是否只考虑了“理想情况”？

你选择技术、工具或架构时有没有思考？比如为什么选 Context 而不是 Redux？能不能讲出理由？

你的 Git 提交是否体现了分阶段推进？有没有规划开发顺序，而不是一次性推所有代码？

面试不会看你写了什么代码，但会看你“有没有想清楚怎么写”

很多人问：“我写的项目面试官根本不看，那写得好还有用吗？”

答案是：有。因为你写代码的过程，决定了你有没有能力讲清楚自己的经历。

的体现，也是面试官真正看重的部分。

你说的这些话，不是因为你“技术多好”，而是因为你

求职导向写代码：请加入这 3 个思维维度

💭 提问自己：“我为什么选这个做法？有没有其他更好的方案？”

这会锻炼你在面试时解释技术选型的能力，也是在模拟真实工作中的 tradeoff 分析。

💭 提问自己：“用户会在什么地方卡住？如果输错、加载失败，我怎么处理？”

训练你具备产品思维和鲁棒性意识，让你写出来的东西不只是“能跑”。

💭 提问自己：“我能不能在 1 分钟内清楚地解释这段功能？”

能清楚表达是面试中极大的加分项，也让你更自信地呈现自己的能力。

第一份工作的关键，不在于你会多少技术，写了多少代码。

你写代码的方式，已经在决定你会不会被录用。

写代码不是为了“学技术”，而是为了训练思考方式、表达能力，这些才是真正决定你能否找到第一份 IT 工作的关键。

你写的代码，其实是在训练你自己能否找到工作

Playwright 是由微软开发的一款功能强大的浏览器自动化框架，支持 Chromium、Firefox 和 WebKit，可以用于测试、爬虫、自动化等用途。

import { chromium } from 'playwright';

async function getItemAvailability(url) {
  const browser = await chromium.launch();
  const page = await browser.newPage();

  await page.goto(url);
  // ...
}

XPath 是一种在 XML/HTML 树结构中查找元素的语言，适用于页面结构复杂或需要精确匹配的场景。

按 class 选择（适用于多个 class）

 来等候「BUY NOW」或「NOTIFY ME WHEN AVAILABLE」元素出现：

await Promise.race([
  page.waitForSelector('xpath=//div[text()="BUY NOW"]'),
  page.waitForSelector('xpath=//div[text()="NOTIFY ME WHEN AVAILABLE"]'),
]);

如果有货，则立刻发送 iMessage 提醒自己

function sendMacImessage(to, message) {
  const script = `osascript -e 'tell application "Messages" to send "${message}" to buddy "${to}"'`;
  exec(script);
}

无论是否有货，都会截图记录：

await page.screenshot({
  path: path.join(__dirname, "screenshots", productName + ".png"),
  fullPage: true,
});

定时执行：每天 8 点到 22 点，每分钟检查一次

cron.schedule("* 8-22 * * *", async () => {
  await Promise.all([
    getItemAvailability("https://www.popmart.com/au/products/1706/..."),
    getItemAvailability("https://www.popmart.com/au/products/643/..."),
  ]);
});

最近我写了一个小工具，用于定时监控 POPMART 上某些商品的库存状态。

使用 Playwright + Cron 构建一个 POPMART 商品库存监控器

1. 建立 Socket 连接（用于信令）

WebRTC 本身并不包含信令机制，因此我们需要借助 Socket.IO 实现客户端和服务端之间的参数交换。

建立连接后，所有后续的参数交换（如请求创建 transport、传递 dtls 参数等）都将通过这个 socket 通道完成。

const connectSocket = () =>
  new Promise((resolve) => {
    const socket = io(import.meta.env.VITE_SERVER_URL || "http://localhost:3000");
    socket.on("connect", () => resolve(socket));
  });


在 WebRTC 中，客户端必须了解服务端支持哪些音视频编码格式。

为了完成媒体协商，客户端需要通过 socket 向服务端请求当前 router 的能力信息：

创建 Transport（WebRTC 媒体通道）

为了发送本地的音视频轨道，客户端首先需要创建一个 

。但这个 Transport 并不是客户端自己构造的，而是通过 Socket 请求服务端协助完成。

1. 请求并创建 sendTransport 本地实例

socket.emit("createTransport", async (transportOptions) => {
  const sendTransport = device.createSendTransport({
    ...transportOptions,
    iceServers: [{ urls: "stun:stun.l.google.com:19302" }],
  });
});

这个过程可以看作是发送端媒体通道的“连接协商阶段”。

在创建 sendTransport 的阶段，我们就需要监听 "connect" 事件，是因为 WebRTC 的安全连接建立是一个渐进式过程：Transport 的构建知识准备阶段，只有当真正开始推流时 (例如 

), medisoup-client 才会发起 DLTS 握手流程

sendTransport.on("connect", ({ dtlsParameters }, callback) => {
  socket.emit("connectTransport", {
    transportId: transportOptions.id,
    dtlsParameters,
  }, callback);
});

客户端要接收远程媒体流，也需要一个 

 类似，也依赖服务端提供的 ICE 与 DTLS 配置。

1. 请求并创建本地 recvTransport 本地实例

socket.emit("createTransport", async (transportOptions) => {
  const recvTransport = device.createRecvTransport({
    ...transportOptions,
    iceServers: [{ urls: "stun:stun.l.google.com:19302" }],
  });

  recvTransport.on("connect", ({ dtlsParameters }, callback) => {
    socket.emit("connectTransport", {
      transportId: transportOptions.id,
      dtlsParameters,
    }, callback);
  });
});


 创建完接收通道后，mediasoup-client 会在第一次 

我们同样需要监听 "connect" 事件，并通过 socket 将 DTLS 参数发送给服务端完成握手。

recvTransport.on("connect", ({ dtlsParameters }, callback) => {
  socket.emit("connectTransport", {
    transportId: transportOptions.id,
    dtlsParameters,
  }, callback);
});

第一步是获取本地摄像头和麦克风的媒体流。这通常需要用户授权：

const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
const videoTrack = stream.getVideoTracks()[0];
sendTransport.produce({ track: videoTrack });

这一步是媒体采集的开始，只有用户授权之后，才能真正采集并上传媒体轨道。

2. 监听 produce 事件，协商流信息

 时，mediasoup-client 不会直接发送媒体，而是先触发 "produce" 事件。

sendTransport.on("produce", async ({ kind, rtpParameters }, callback) => {
  socket.emit("produce", {
    transportId: sendTransport.id,
    kind,
    rtpParameters,
  }, ({ id }) => {
    callback({ id });
    resolve(id);
  });
});

在这个事件中，客户端需要将当前轨道的类型（音频/视频）和参数（编码方式、分辨率等）发送给服务端，让服务端生成一个对应的 Producer。

当客户端想要订阅远端的某个 Producer 时，需要通过 Socket 请求服务端分配对应的 Consumer。

这个过程也属于 WebRTC 的信令交换：客户端提供自身能力信息，服务端校验兼容性并返回 Consumer 配置。

当客户端想要接收远端某个用户的视频时，必须先告诉服务端：“我准备好了，可以接收这个 Producer 的媒体。”

socket.emit("consume", {
  transportId: recvTransport.id,
  producerId,
  rtpCapabilities: device.rtpCapabilities,
}, async (data) => {
  const consumer = await recvTransport.consume({
    id: data.id,
    producerId,
    kind: data.kind,
    rtpParameters: data.rtpParameters,
  });

  const stream = new MediaStream();
  stream.addTrack(consumer.track);
});

本文将讲解如何在 React 应用中使用 mediasoup-client 与 Socket.IO 实现 WebRTC 多人视频通话客户端逻辑。

使用 mediasoup 创建一个多人视频聊天室 - 客户端

下面我们逐步拆解服务端代码的每个关键步骤，并辅以对应的代码段说明。

我们使用 Node.js 原生的 http 模块创建 HTTP 服务，并通过 Socket.IO 实现 WebSocket 通信：

const http = require("http");

let server;
const listener = (_, res) => {
  res.writeHead(200, { "Content-Type": "text/plain" });
  res.end("OK");
};

server = http.createServer(listener);

随后将 Socket.IO 实例挂载到 server 上：

const io = require("socket.io")(server, { cors: { origin: "*" } });

这样我们就完成了基础的 HTTP + WebSocket 信令服务搭建。

启动后我们需要初始化 mediasoup 的核心组件：

worker 是处理媒体的后台线程，router 是负责音视频流转发的“会议室”。

这样做的好处是便于后续清理资源，也能实现每用户隔离管理。

客户端请求 createTransport 后，服务端创建 WebRTC 传输通道：

socket.on("createTransport", async (callback) => {
  const listenIp = process.env.ANNOUNCED_IP
    ? { ip: "0.0.0.0", announcedIp: process.env.ANNOUNCED_IP }
    : { ip: "127.0.0.1", announcedIp: null };

  const transport = await router.createWebRtcTransport({
    listenIps: [listenIp],
    enableUdp: true,
    enableTcp: true,
    preferUdp: true,
  });

  transports[socket.id][transport.id] = transport;

  callback({
    id: transport.id,
    iceParameters: transport.iceParameters,
    iceCandidates: transport.iceCandidates,
    dtlsParameters: transport.dtlsParameters,
  });
});

这里返回的参数会由客户端用来建立 WebRTC 安全连接。

客户端调用 connectTransport 时，我们完成 DTLS 握手过程：

socket.on("connectTransport", async ({ transportId, dtlsParameters }, callback) => {
  await transports[socket.id][transportId].connect({ dtlsParameters });
  callback();
});

客户端准备发送音频或视频后，会请求 produce：

socket.on("produce", async ({ transportId, kind, rtpParameters }, callback) => {
  const producer = await transports[socket.id][transportId].produce({ kind, rtpParameters });
  producers[socket.id][producer.id] = producer;
  callback({ id: producer.id });
});

Producer 代表一个发布出去的媒体轨道。

用户想订阅其他人的流时会调用 consume，服务端验证并创建：

socket.on("consume", async ({ transportId, producerId, rtpCapabilities }, callback) => {
  if (!router.canConsume({ producerId, rtpCapabilities })) {
    return callback({ error: "Cannot consume" });
  }
  const consumer = await transports[socket.id][transportId].consume({
    producerId,
    rtpCapabilities,
    paused: false,
  });
  consumers[socket.id][consumer.id] = consumer;
  callback({
    id: consumer.id,
    kind: consumer.kind,
    rtpParameters: consumer.rtpParameters,
  });
});

这一步客户端会用返回的参数创建 MediaStreamTrack 播放远端视频。

socket.on("pauseProducer", async ({ producerId }, callback) => {
  await producers[socket.id][producerId].pause();
  callback?.();
});

socket.on("resumeProducer", async ({ producerId }, callback) => {
  await producers[socket.id][producerId].resume();
  callback?.();
});

socket.on("pauseConsumer", async ({ consumerId }, callback) => {
  await consumers[socket.id][consumerId].pause();
  callback?.();
});

socket.on("resumeConsumer", async ({ consumerId }, callback) => {
  await consumers[socket.id][consumerId].resume();
  callback?.();
});

适用于静音、隐藏摄像头等场景。

清理断开用户的所有资源，确保服务器稳定运行：

socket.on("disconnect", () => {
  Object.values(transports[socket.id] || {}).forEach((t) => t.close());
  Object.values(producers[socket.id] || {}).forEach((p) => p.close());
  Object.values(consumers[socket.id] || {}).forEach((c) => c.close());
  delete transports[socket.id];
  delete producers[socket.id];
  delete consumers[socket.id];
});

下一篇文章我们将介绍客户端部分的实现，包括如何初始化 Device、创建发送和接收通道，并播放远程媒体流。

本文聚焦于服务端实现，讲解如何使用 mediasoup 搭建一个稳定高效的多人视频聊天室服务，包含服务端代码逐段讲解。

使用 mediasoup 创建一个多人视频聊天室 - 服务器

mediasoup 是一个现代化、性能强大的 WebRTC SFU（Selective Forwarding Unit）库，适合构建高效、可扩展的实时音视频应用。

在实时音视频系统中，媒体流的传输架构对性能有巨大影响，常见的三种模式包括：

const worker = await mediasoup.createWorker();

const router = await worker.createRouter({
  mediaCodecs: [
    { kind: "audio", mimeType: "audio/opus", clockRate: 48000, channels: 2 },
    { kind: "video", mimeType: "video/VP8", clockRate: 90000 },  
  ],
});

const transport = await router.createWebRtcTransport(...);

const producer = await transport.produce({ track });

const consumer = await transport.consume({ producerId });

在 mediasoup 中，Device 是客户端（通常是浏览器端）用来与服务器（SFU）进行媒体协商的核心组件。

，以确保双方支持的编码格式兼容。

const device = new mediasoupClient.Device();
await device.load({ routerRtpCapabilities });

加载完成后，Device 才能创建 WebRTC transport 来发送（produce）或接收（consume）音视频流。

const sendTransport = device.createSendTransport({});
const recvTransport = device.createRecvTransport({});

浏览器 <---> WebSocket <---> mediasoup server <---> mediasoup worker

在这篇文章中，我们将通过 mediasoup 构建一个简单的多人视频聊天室，涵盖 mediasoup 的基本概念、代码结构以及关键实现细节。

Make Your Voice Heard

In-text comments for more connection

Explore Our Tags

Explore Our Blogs