在前端开发中，“生成唯一 ID” 是高频需求 —— 从列表项标识、表单临时存储，到数据缓存键值，都需要一个 “绝对不重复” 的标识符。但看似简单的需求下，藏着很多容易踩坑的实现方式，稍有不慎就会引发数据冲突、逻辑异常等问题。

今天我们就来拆解常见误区，带你掌握真正可靠的唯一 ID 生成方案。

一、为什么 “唯一 ID” 比想象中难？

唯一 ID 的核心要求是 “全局不重复”，但前端环境的特殊性（无状态、多标签页、高并发操作），让很多看似合理的方案在实际场景中失效。

下面两种常见实现，其实都是 “伪唯一” 陷阱。

❌ 误区 1：时间戳 + 随机数（Date.now() + Math.random()）

很多开发者会直觉性地将 “时间唯一性” 和 “随机唯一性” 结合，写出这样的代码：

// 错误示例：看似合理的“伪唯一”方案

function generateNaiveId() {

  // 时间戳转36进制（缩短长度）+ 随机数截取

  return Date.now().toString(36) + Math.random().toString(36).substr(2);

}

// 示例输出：l6n7f4v2am50k9m7o4

这种方案的缺陷在高并发场景下会暴露无遗：

• 时间戳精度不足：Date.now() 的精度是毫秒级（1ms），如果同一毫秒内调用多次（比如循环生成、高频接口回调），ID 的 “时间部分” 会完全重复；


• 伪随机性风险：Math.random() 生成的是 “非加密级随机数”，其算法可预测，在短时间内可能生成重复的序列，进一步增加冲突概率。

结论：仅适用于低频次、非核心场景（如临时展示用 ID），绝对不能用于生产环境的核心数据标识。

❌ 误区 2：全局自增计数器

另一种思路是维护一个全局变量自增，看似能保证 “有序唯一”：

// 错误示例：自增计数器方案

let counter = 0;

function generateIncrementId() {

  return `id-${counter++}`;

}

// 示例输出：id-0、id-1、id-2...

但在浏览器环境中，这个方案的缺陷更致命：

• 无状态丢失：页面刷新、路由跳转后，counter 会重置为 0，之前的 ID 序列会重复；


• 多标签页冲突：用户打开多个相同页面时，每个页面的 counter 都是独立的，会生成完全相同的 ID（比如两个页面同时生成 id-0）。

结论：浏览器环境中几乎毫无实用价值，仅能用于单次会话、单页面的临时标识。

二、王者方案：一行代码实现绝对唯一 —— crypto.randomUUID()

既然简单方案不可靠，我们需要借助浏览器原生提供的 “加密级” 能力。crypto.randomUUID() 就是 W3C 标准推荐的官方解决方案，彻底解决 “唯一 ID” 难题。

1. 用法：一行代码搞定

crypto 是浏览器内置的全局对象（无需引入任何库），专门提供加密相关能力，randomUUID() 方法可直接生成符合 RFC 4122 v4 规范 的 UUID（通用唯一标识符）：

// 正确示例：生成绝对唯一ID

const uniqueId = crypto.randomUUID();

// 示例输出：3a6c4b2a-4c26-4d0f-a4b7-3b1a2b3c4d5e

2. 为什么它是 “绝对唯一” 的？

crypto.randomUUID() 的可靠性源于三个核心优势：

• 极低碰撞概率：v4 UUID 由 122 位随机数构成，组合数量高达 2^122（约 5.3×10^36），相当于 “在地球所有沙滩的沙粒中，选中某一颗特定沙粒” 的概率，实际场景中碰撞概率趋近于 0；


• 加密级随机性：基于 “密码学安全伪随机数生成器（CSPRNG）”，随机性远优于 Math.random()，无法被预测或破解，避免恶意伪造重复 ID；


• 跨环境兼容：生成的 UUID 是全球通用标准格式（8-4-4-4-12 位字符），前端、后端（Node.js、Java 等）、数据库（MySQL、MongoDB）都能直接识别，无需格式转换。

3. 兼容性：覆盖所有现代环境

crypto.randomUUID() 的支持范围已经非常广泛，完全满足绝大多数新项目需求：

• 浏览器：Chrome 92+、Firefox 90+、Safari 15.4+（2022 年及以后发布的版本）；


• 服务器：Node.js 14.17+（LTS 版本均支持）；


• 框架：Vue 3、React 18、Svelte 等现代框架无任何兼容性问题。

三、兼容性兜底方案（针对旧环境）

如果需要兼容旧浏览器（如 IE11）或低版本 Node.js，可以使用第三方库 uuid（轻量、无依赖），其底层逻辑与 crypto.randomUUID() 一致：

安装依赖：

npm install uuid

# 或 yarn add uuid

使用方式：

// 旧环境兜底方案

import { v4 as uuidv4 } from 'uuid';

const uniqueId = uuidv4();

// 示例输出：同标准UUID格式

四、总结：唯一 ID 生成的 “最佳实践”

对于 2023 年后的新项目，直接使用 crypto.randomUUID() 即可 —— 一行代码、零依赖、绝对可靠，彻底告别 “ID 重复” 的烦恼！

前端架构师，这个岗位，在我的技术体系的认知中，是不需要这样的一个岗位的。但是市面上，我发现，在招聘的需求中，很多企业，依然在招聘前端架构师这个岗位。

为什么市场中，依然会有这个岗位呢？

真实的场景中，这个岗位的设立，是否真的是合理的呢？

作为前端出身的同学，这是我一直在思考的一个问题，因为这个问题，关乎一个人的职业发展，代表了我们前端的同学，职业的道路的天花板，到底在哪里。

如果前端架构师，这个岗位，本身是不应该出现的，那么我们前端的职业道路，就不应该走纯技术路线。真正应该走的是，技术兼管理的路线，也就是应该走前端leader的角色，再往上就是技术总监/CTO的职业角色。

如果前端架构师，这个岗位，是应该出现，那么前端的职业道路，其实完全可以走纯技术路线，从开发到前端架构师，然后持续深耕。

不同的方向，对人的要求是不一样的。

走纯技术路线，对一个人的更大要求是专注，持续的技术学习力，持续的自我技术进步，其他方面，作为辅助，协助你的技术能力在职场中进行发挥，你就能在这个行业和岗位上，有一定的立足之地。

走leader的路线，对一个人的要求是全面，关注点在技术，人，事务，项目，管理等等一系列比较杂乱的事情上，它注定了不能过于专注，而是站在高点，俯瞰整个大盘，才能真正的把事情做好。

作为自己，一直以来，努力的方向，也是走技术leader的路线。

真实的市场场景是什么样？

有一句很经典的话，世界是由一帮草台班子组成的。

这句话反馈到真实的工作场景中，就变成了这样的现状。

大多数的人的技术水准，真的让人一言难尽，很多人，真的也就是把技术，当作一份吃饭的差事，大多数人对技术，并没有追逐的热情。

我们这个行业，有太多的小公司了，小公司招聘人的标准，和大公司比，也是真的一言难尽，我见过有些公司，用四五千的薪资，招聘了一些人做事，真的是啥也不会。

大量的中小型企业，招聘技术人员，薪资大概给1万左右，这类研发人员，大多数的水准，大概就是能把项目做出来，会一些框架，仅此而已。

但是我们日常中，遇到的业务问题，往往是复杂的，比如前端的复杂表单问题，不同环境的运行容器差异问题，各种各样的兼容问题，复杂的数据处理和渲染问题等等。这类问题，其实在日常的开发中，很常见，但是往往很多人对此，难以处理。

这个时候，很多企业，潜意识就觉得，招聘一个技术更厉害的人，这个时候，前端架构师这个岗位，其实就出现了，而这也是市场中，需要这个岗位的现实情况。

不同规模企业的前端组织架构到底有哪些差异？

在大公司，我看到的更多的是，前端技术leader的岗位，一般而言，是由一个技术leader，带领团队，完成业务。

比如阿里，比较有钱，一般一个团队中，p8是前端leader，p6/p7是做事的主力，配备部分p4/p5的同学，一起完成业务。整体大概是，一个leader负责统筹全局，团队中真正做事的同学，完全由能力驾驭自己的业务。

再中小型公司，我看到的是，因为成本的原因，招聘的工程师偏于初中级，然后团队中，有那么一两位高级工程师作为主力成员。有些时候，这些高级工程师还会担任leader的角色。

但是这类团队有一些问题，就是因为技术能力问题，无法真正的做到，对企业的业务负责。

1、针对业务场景，无法给出合理的方案/方法。经常性的在日常工作中，这类团队，会提到这个需求改动太大，这个方案没法实现，这个东西做不了等等。但是其实正常的场景中，业务方提出一个需求，本身是有一定的运营目标/目的，这个时候，应该从业务的角度出发，再结合我们互联网技术，针对这个运营目标，提出我们的产品/技术方案，然后执行。

2、无法做出合理的判断。在大多数的场景中，我们对代码的要求是，高内聚和低耦合，代码的结构要清晰，可维护要高。但是还应该有技术之外的一些判断，我们完成一项业务，应该团队配备什么样的成员，市场中哪类程序员好招聘，技术的选型和业务是不是最优解，在人员、技术，业务、成本，这类问题中，如何达到更高的效率最优。

在中小型公司，大家习惯性的把问题简单化，做不了，判断不了，以为招聘一个技术更厉害的人，就能解决当下问题。

那到底需要前端架构师吗？

这个答案很显然，其实当下的市场中，市场有这样的职位诉求，原因就是一些复杂问题，很多企业搞不定。（但是这个问题的解决之道，不在于招聘前端架构师这么一个岗位，而是在于团队内在的一些问题，这些问题恰恰是需要一个前端leader来解决的）

从职业发展的角度来说，其实是不需要前端架构师的。

我们从技术的角度，来分析一下为什么不需要前端架构师。

前端的职责，是对UI负责，我们的工作，主要是针对，不同的容器环境（浏览器、手机app、桌面端内嵌h5等等）、不同的技术（RN、react、小程序等等），实现不同的端上的产品（App、小程序、网页、桌面端应用），我们通过接口协议，同后端进行数据通信。

端上的页面，主体是运行在用户端的设备上，最大的障碍是加载/渲染性能。接口方面，是和用户的网络环境相关。

这些东西，其实从技术的层面上，属于开发的职责。我们不得不承认，前端开发的层面，入手会比后端简单一些，但是做到一定程度，其实要求是要比后端更高的。

所以前端架构师，到底在架构什么东西？它不过就是，针对每一种端上的技术，使用的比普通开发，更好一些。

相比而言，后端有太多的策略性的东西了，哪些数据是业务数据，哪些数据是缓存数据，哪些数据要支持实时查询，哪些数据支持统计查询，后端的基础组件也多，不同的组件，擅长的事情也不一样，适用的场景其实也有差异，kafka、redis这些东西，数据分库和分表，按什么维度分，机器的运行性能，支持的量到底有多大等等。

这些就是后端架构师的存在责任，同一块代码，在不同的场景下是完全不同的。在某些场景中可能是最优解，换一个场景，可能就是最差的代码。

这就是我一直推崇的价值观，前端和后端，不一样，前端不需要架构师。

合理的团队架构到底长什么样？

如我个人所评判的那样，一个团队中，是不需要前端架构师这个角色的，那么对于那些中小型公司的人来说，到底什么样的结构，符合自身最优价值的团队结构呢？

答案是这样的，一位专家级别的前端，带领一两个干活的主力，再加上多个初中级的工程师。专家级别的工程师-也就是leader，保障我们的技术和方案，是行业内标准方案，方向是最优的，一两个高级工程师，辅助这个leader把事情能落地下去，其他所有初中级工程师，就是干活的苦力，也就是团队内的技术体力劳动者。

这也就是，我认可的职业发展中，前端需要leader的原因，但是不需要架构师。

大家好！

最近面试，我发现一个很有意思的事情。几乎每个高级前端的简历上，都专门开辟了一栏，叫性能优化。

里面写满了各种高大上的名词😖：

使用Virtual List（虚拟列表）优化长列表渲染...

使用Web Worker把复杂计算移出主线程...

使用WASM重写核心算法...

看着这些，我通常会问一个问题：

你为什么要渲染一个有一万条数据的列表？用户真的看得过来吗？

候选人通常会愣住，然后支支吾吾地说：“呃...这是我们产品经理要求的🤷‍♂️。”

这就是今天我想聊的话题：

在2025年的今天，前端领域90%的所谓性能瓶颈，根本不是技术问题，而是产品问题。

我们这群工程师，拿着最先进的前端技术（Vite, Rust, WASM），却在日复一日地给一坨屎💩（糟糕的产品设计）雕花。

我们正在解决错误的问题

让我们还原一个经典的性能优化现场吧👇。

场景：一个中后台的超级表格（默认大家应该比较熟悉🤔）。

产品经理说需求：这个表格要展示所有订单，大概有50列，每页要展示500条，而且要支持实时搜索，还要支持列拖拽，每个单元格里可能还有下拉菜单...

开发者的第一反应（技术视角） ：

• 50列 x 500行 = 25000个DOM节点，浏览器肯定卡死。


• 快！上虚拟滚动（Virtual Scroll）！


• 快！上防抖（Debounce）！


• 快！上Memoization（缓存）！

我们为了这个需求，引入了复杂的 第三方库，写了晦涩难懂的优化代码，甚至为了解决虚拟滚动带来的样式问题（比如高度坍塌、定位异常），又打了一堆补丁。

最后，页面终于不卡了。我们觉得自己很牛逼，技术很强。

但我们从来没问过那个最核心的问题：

人类的视网膜和大脑，真的能同时处理50列 x 500行的数据吗？

答案是：不能。

当屏幕上密密麻麻挤满了数据时，用户的认知负荷已经爆表了。他根本找不到他要看的东西。他需要的不是高性能的渲染，他需要的是筛选和搜索。

我们用顶级的技术，去实现了一个反人类的设计。 这不是优化，这是叫作恶😠。

真正的优化，是从砍需求开始

我曾经接手过一个类似的项目，页面卡顿到FPS只有10。前任开发留下了几千行用来优化渲染的复杂代码，维护起来生不如死。

我接手后，没有改一行渲染代码。

我直接去找了产品总监，把那个页面投在大屏幕上，问了他三个问题：

1.你看这一列 订单原始JSON日志，平均长度3000字符，你把它全展示在表格里，谁会看？

砍掉！改成一个查看详情的按钮，点开再加载。DOM节点减少20%。

2.这50列数据，用户高频关注的真的有这么多吗？

默认只展示核心的8列。剩下的放在自定义列里，用户想看自己勾选。DOM节点减少80%。

3.我就不知道为什么🤷‍♂️ 要一次性加载500条？用户翻到第400条的时候，他还记得第1条是什么吗？

赶紧砍掉！改成标准的分页，每页20条。DOM节点减少96%。

做完这三件事，我甚至把之前的虚拟滚动代码全删了，回退到了最朴素的<table>标签。

结果呢？

• 页面飞一样快（因为DOM只有原来的1%）。


• 代码极其简单（维护就更简单了🤔）。


• 用户反而更开心了（因为界面清爽了，信息层级清晰了）。

这才是最高级的性能优化：不仅优化了机器的性能，更优化了人的体验。

技术自负的陷阱

为什么我们总是陷在技术优化的泥潭里出不来呢？😒

因为我们有技术自负。

作为工程师，我们潜意识里觉得：承认这个需求做不了（或者做不好），是因为我技术不行。

产品经理要五彩斑斓的黑，我就得给他做出来！

产品经理要在这个页面跑3D地球，我就得去学Three.js！

我们试图用技术去弥补产品逻辑上的懒惰！（非常有触感😖）

因为产品经理懒得思考信息的层级 ，所以他把所有信息一股脑扔给前端，让你去搞懒加载。

技术不是万能的。

浏览器的渲染能力是有上限的，JS的主线程是单核的，移动端的电量是有限的。更重要的是，用户的注意力是极其有限的。

当你发现你需要用极其复杂的新技术才能勉强让一个页面跑起来的时候

请停下来！

这时候，问题的根源通常不在代码里，而可能是在 PRD（需求文档） 里。

说了那么多，该怎么做呢？

下次，当你再面对一个导致卡顿的需求时，别急着打开Profiler分析性能。

请试着做以下几步：

我们真的需要在前端处理10万条数据吗？能不能在后端聚合好，只给我返回结果？

这个图表真的需要实时刷新吗？用户真的能看清1毫秒的变化吗？改成5秒刷新一次行不行？

在这个弹窗里塞个完整地图太卡了。能不能改成：点击缩略图，跳转到专门的地图页面？

你要告诉产品经理： 性能本身，也是一个产品功能。

如果为了塞下更多的功能，牺牲了流畅度这个最核心的功能，那是丢了西瓜捡芝麻。

最好的代码，是 没有代码（No Code）。

同理，最好的性能优化，是没有需求。

作为高级工程师，你的价值不仅仅体现在你会写Virtual List，更体现在你敢不敢在需求评审会上，拍着桌子说：

这个设计怎么这么反人类😠！我们能不能换个更好的方式？🤷‍♂️

别再给屎山💩雕花了。把那座山推了，才是真正的优化。

关于这个观点你们怎么看？

前言

我相信作为程序员Cuesor大家一定都很熟悉了，它是一款代码编辑工具，位于 Claude AI、o3、Gemini-3.5-Pro 和 GPT-4.1 等其他顶级 AI 模型之上，帮助我们提高工作效率以及体验。

Cursor AI 入门

导航到 cursor.com 时，可以下载 IDE：

下载并打开代码编辑器后，你将看到以下内容：

在上面的界面中，我们观察到一些事情：

• 代理模式 每当编码时，您都需要使用代理模式。它有助于处理端到端任务


• Ask 如果单击代理模式下拉列表：

你会看到“提问”选项——当你想提出问题时使用此选项，就像使用 ChatGPT 一样。

• Model selection（ 模型选择 ） 
  此下拉列表显示要从中选择的最喜欢的模型列表


• Context integration（上下文集成） “添加上下文”按钮，用于使用 @ 符号（@docs、@web 等）


• Chat interface（聊天界面） 
  “新聊天”，用于开始新的或后续的对话。

如何利用这些功能

传统的 Web 开发项目遵循以下工作流程：

但是在进行 vibe 编码时，您的工作流程将看起来更像这样：

而cursor可以帮你完成设计这一步骤，使用 Cursor AI 生成界面 。首先创建一个新项目;我们将在本例中使用 Next.js。

使用快捷键 Command+K，这非常适合您忘记基本命令

现在我们已经安装了项目，是时候进行提示了。

构建示例项目

使用聊天进行设计提示

导航到新建聊天 。
选择光标代理 ，然后选择您喜欢的模型。对我来说，我更喜欢 Claude 3.5

现在你可以提示它了。这是我的提示的样子：“在我的 page.tsx 中，重新创建 Logrocket 的登录页面。”

这是我们得到的：

接受更改，并使用 npm run dev 运行应用程序
如果生成的和我们所设想的效果不太一样，我们可以通过多种方式使用图像上下文使其更接近。

Attaching an image  附加图像

导航到聊天，单击图像图标，然后附加图像。这应该是您想要复制的设计图像。来不断迭代来达到我们想要的效果。

在迭代时，可能会有时ai误解了我们的意思，或者Cursor 发现这个问题有点难以修复。在这种情况下，我们可以通过单击恢复检查点轻松恢复到以前的设计。这可以在之前的聊天下找到：

模型上下文协议 （MCP） 服务器

MCP 是一种开放标准，使开发人员能够在其数据源和 AI 驱动的工具之间构建安全的双向连接。

Framelink.ai 为 Figma 构建了一个 MCP 服务器，它允许您直接访问和处理 Cursor 中的设计文件。按照本指南轻松设置。

充分利用 Cursor 的更多策略

利用 AI 代理模式

使用光标时，您最常使用 AI 代理模式。这是一个强大的功能，可以：

• 自动安装依赖项（不再需要手动包管理）


• 在整个项目中创建和修改文件


• 在确认后运行终端命令


• 处理复杂的多文件重构


• 端到端实现完整功能

使用 @ 符号进行上下文管理

了解上下文管理可以提升您使用 Cursor 的编码体验。 @ 符号是您在帮助您时告诉 Cursor 要查看什么或优先考虑什么的方式。主要的  @  类型是：

• @code – 您的整个项目


• @web – 搜索互联网


• @docs – 该工具或库的文档甚至可以是一个框架


• @files 和文件夹 – 特定文件


• 图像 – 拖放屏幕截图/设计


• @cursor 规则 – 甚至您过去的聊天记录

“新聊天”策略

根据经验，我建议您始终为新功能或项目开始新的聊天。当您在旧对话之上提示某些内容时，可能会分散 AI 的注意力并降低响应质量。

Cursor 添加了一项有用的功能，允许您使用旧聊天的摘要开始新的聊天，为您提供两全其美的体验 - 新鲜的上下文而不会丢失重要信息。

使用上面的  “添加 ”按钮创建新聊天，单击上下文选项的  @ ，滚动以选择  “最近的更改”，  单击它，然后继续提示：

总结

Cursor AI 的定价似乎偏高。但其功能确实还行，不过我们也可以选择trae来替代，毕竟Cursor也不比trae强多少

“当了 leader 才发现，公司最想裁掉的，不是上班总迟到的，也不是下班搞失联的，而是经常把这 3 句话挂在嘴边的”

这是最近在职场社区里又被聊热起来的一个老话题。

作为一个在职场上混迹了近 9 年的程序员，一路走来亲眼目睹和经历了程序员职场里的各种风雨。从一开始的大头兵到后来负责一个独立的小团队，从一个所谓的 leader 的视角上来看问题，对这个事情的理解似乎又有了一些变化。

在我刚成为小团队负责人时，和许多职场人一样，我以为那些显而易见的职业毛病——比如习惯性迟到、到点就消失联系不上——才是最让管理者头疼的。直到自己坐上这个位置，真实去参与招人、考核、决策，才明白有些表象问题在 leader 眼中其实根本不算什么。

回到文首的话题，说的似乎有些夸张，但在真实的职场里确实是存在的，工作能力当然重要，但是“沟通艺术”和“向上管理”同样也不容忽视。

今天，我们就来聊聊这 3 句看似平常却极具“杀伤力”的话，相信我们平时可能也听过。

1、“这个需求做不了”

这句话相信在平时的需求会或者评审会上经常会听到。

当接到一个新需求或任务时，有些同学的第一反应是：“这个需求做不了”。

当员工说出“这个需求做不了”时，背后的含义有可能是“我不想做”、“我不会做”或“我觉得没必要做”。无论是哪种情况，传递出来的都是拒绝和封闭的态度。

因为现代职场没有绝对“做不了”的事情，只有尚未找到的解决方案或者不够充分的资源支持而已。

如果面对平级的产品经理这样说倒还无所谓，如果面对大领导这样表达那就多少有些欠妥了。

所以遇到这类问题大可不必当场上头去否定，别急着说‘做不了’，我们不妨换一个方式来表达。

表达变换 Tips：

• “这个需求很有挑战，我需要先调研看看”


• “这个需求很有挑战，我需要XX资源和XX支持来实现它”


• “目前有几点困难，我需要先评估一下”


• “我需要XX资源和XX条件的支持，能否帮我协调”

2、“我以前都是这么做的”

当员工不断强调“以前都是这么做的”，他实际上是在拒绝创新，拒绝适应变化，拒绝接受新思想。

在 IT 互联网行业，方法和工具迭代速度极快。之前曾经高效的方法，现在可能已经落后了，而对过往的经验和标签的一味固守往往会阻碍人进行第二层、第三层的进一步思考。

所以面对这种表达情形，我们不妨也可以换一种表达方式。

表达变换 Tips：

• “我过去是这样做的，但不确定是否适合现在的情况，需要先确定一下”


• “过去我们是用XX方法做的，效果是XX。我们也可以探讨一下新方法，看看会不会更好”


• “我能分享一下过去做这类项目的经验教训，供大家参考”


• “我对这个新方法还不太熟，需要一点时间学习一下”

3、“这个不归我负责”

我认为这句话可能是这三句中最致命的一句，因为它通常反映的是一种界限感和团队协作意识的缺失。

“各人自扫门前雪”的心态在某些特殊的场景下确实“杀伤力”极大，尤其如果在上级领导问责面前这么说，那基本真就 gg 了。。

在团队工作中，职责边界清晰本是好事，但过度强调“不归我管”则是一种危险的信号。

而且有时候模糊地带的问题往往就是自己能创造价值的机会，而且即便自己不想插手，也完全没必要这样去表达，我们不妨也换一些表达方式。

表达变换 Tips：

• “这个事情谁更熟悉？我可以协助”


• “这个事情的负责人是xxx，我可以了解之后协助解决”


• “我不太熟悉这个领域，但可以了解一下，谁能给我指点”


• “我们需要先明确一下这个问题的负责人，我可以暂时跟进一下”

所以以上这三点沟通的艺术也是程序员职场生活里切实可能会遇到的问题。当你下次准备说出这三句话中的任何一句时，不妨先停顿三秒，换个表达方式。

虽说向上管理和沟通艺术是被很多程序员所诟病和瞧不上的，但是有时候因为一句上头的话或者表达而导致了某些通道的关闭那也实在是太可惜了，这很不公平，但这往往就是职场的现实。

程序员作为一个有个性的创造性群体要专注精进技术这本身没错，但是职场毕竟也是一个充满人情世故的江湖，掌握一些通用的职场规则和沟通艺术也是十分有必要的，所以埋头赶路的同时也不要忘记看看周围的环境和机会。

在这个快速变化的时代，唯一不变的就是需要不停地适应和成长。共勉。

好了，那以上就是今天的内容分享了，希望能对大家有所启发，我们下篇见。

注：本文在GitHub开源仓库「编程之路」 github.com/rd2coding/R… 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。

当你在会议室里争论需求时，

智慧工厂的数字孪生正同步着每一条产线的脉搏；

当你对着平面图想象空间时，

智慧小区的三维模型已在虚拟世界精准复刻每一扇窗的采光。

当你在CAD里调整参数时，

数字孪生城市的交通流正实时映射每辆车的轨迹；

当你等待客户确认方案时，

机械臂的3D仿真已预演了十万次零误差的运动路径；

当你用二维图纸解释传动原理时，

可交互的3D引擎正让客户‘拆解’每一个齿轮；

当你担心售后维修难描述时，

AR里的动态指引已覆盖所有故障点；

当你用PS拼贴效果图时，

VR漫游的业主正‘推开’你设计的每一扇门；

当你纠结墙面材质时，

光影引擎已算出了午后3点最温柔的折射角度；

从前端到Web3D，

不是换条赛道，

而是打开新维度。

韩老师说过：再牛的程序员都是从小白开始，既然开始了，就全心投入学好技术。

🔴 工具

所有的api都可以通过threejs官网的document，切成中文，去搜：

🔴 平面

⭕️ Scene 场景

场景能够让你在什么地方、摆放什么东西来交给three.js来渲染，这是你放置物体、灯光和摄像机的地方。

import * as THREE from "three";



// console.log(THREE);



// 目标：了解three.js最基本的内容



// 1、创建场景

const scene = new THREE.Scene();

⭕️ camera 相机

示例：threejs.org/examples/?q…

import * as THREE from "three";



// console.log(THREE);



// 目标：了解three.js最基本的内容



// 1、创建场景

const scene = new THREE.Scene();



// 2、创建相机

const camera = new THREE.PerspectiveCamera(

  75, // 相机的角度

  window.innerWidth / window.innerHeight, // 相机的宽高比

  0.1, // 相机的近截面

  1000 // 相机的远截面

);



// 设置相机位置

camera.position.set(0, 0, 10); // 相机位置 (X轴坐标, Y轴坐标, Z轴坐标)

scene.add(camera); // 相机添加到场景中

⭕️ 物体 cube

import * as THREE from "three";



// console.log(THREE);



// 目标：了解three.js最基本的内容



// 1、创建场景

const scene = new THREE.Scene();



// 2、创建相机

const camera = new THREE.PerspectiveCamera(

  75, // 相机的角度

  window.innerWidth / window.innerHeight, // 相机的宽高比

  0.1, // 相机的近截面

  1000 // 相机的远截面

);



// 设置相机位置

camera.position.set(0, 0, 10); // 相机位置 (X轴坐标, Y轴坐标, Z轴坐标)

scene.add(camera); // 相机添加到场景中



// 添加物体

// 创建几何体

const cubeGeometry = new THREE.BoxGeometry(1, 1, 1); // 创建立方体的几何体 (长, 宽, 高)

const cubeMaterial = new THREE.MeshBasicMaterial({ color: 0xffff00 }); // MeshBasicMaterial 基础网格材质 ({ color: 0xffff00 }) 颜色

// 根据几何体和材质创建物体

const cube = new THREE.Mesh(cubeGeometry, cubeMaterial); // 创建立方体的物体 (几何体, 材质)

// 将几何体添加到场景中

scene.add(cube); // 物体添加到场景中

⭕️ 渲染 render

// 初始化渲染器

const renderer = new THREE.WebGLRenderer();

// 设置渲染的尺寸大小

renderer.setSize(window.innerWidth, window.innerHeight); // 设置渲染的尺寸大小 (窗口宽度, 窗口高度)

// console.log(renderer);

// 将webgl渲染的canvas内容添加到body

document.body.appendChild(renderer.domElement); // 将webgl渲染的canvas内容添加到body



// 使用渲染器，通过相机将场景渲染进来

renderer.render(scene, camera); // 使用渲染器，通过相机将场景渲染进来 (场景, 相机)

⭕️ 效果

效果是平面的：

到这里，还不是3d的，如果要加3d，要加一下控制器。

🔴 3d

⭕️ 控制器

添加轨道。像卫星☄围绕地球🌏，环绕查看的视角：

// 导入轨道控制器

import { OrbitControls } from "three/examples/jsm/controls/OrbitControls";



// 目标：使用控制器查看3d物体



// // 使用渲染器，通过相机将场景渲染进来

// renderer.render(scene, camera);



// 创建轨道控制器

const controls = new OrbitControls(camera, renderer.domElement); // 创建轨道控制器 (相机, 渲染器dom元素)

controls.enableDamping = true; // 设置控制器阻尼，让控制器更有真实效果。



function render() {

  renderer.render(scene, camera); // 浏览器每渲染一帧，就重新渲染一次

  //   渲染下一帧的时候就会调用render函数

  requestAnimationFrame(render); // 浏览器渲染下一帧的时候就会执行render函数，执行完会再次调用render函数，形成循环，每秒60次

}



render();

⭕️ 加坐标轴辅助器

// 添加坐标轴辅助器

const axesHelper = new THREE.AxesHelper(5); // 坐标轴(size轴的大小)

scene.add(axesHelper);

⭕️ 设置物体移动

// 设置相机位置

camera.position.set(0, 0, 10);

scene.add(camera);

cube.position.x = 3;

// 往返移动

function render() {

  cube.position.x += 0.01;

  if (cube.position.x > 5) {

    cube.position.x = 0;

  }

  renderer.render(scene, camera);

  //   渲染下一帧的时候就会调用render函数

  requestAnimationFrame(render);

}



render();

⭕️ 缩放

cube.scale.set(3, 2, 1); // xyz, x3倍, y2倍

单独设置

cube.position.x = 3;

⭕️ 旋转

cube.rotation.set(Math.PI / 4, 0, 0, "XZY"); // x轴旋转45度

单独设置

cube.rotation.x = Math.PI / 4;

⭕️ requestAnimationFrame

function render(time) {

  //   console.log(time);

  //   cube.position.x += 0.01;

  //   cube.rotation.x += 0.01;

  

  // time 是一个不断递增的数字，代表当前的时间

  let t = (time / 1000) % 5; // 为什么求余数，物体移动的距离就是t，物体移动的距离是0-5，所以求余数

  cube.position.x = t * 1; // 0-5秒，物体移动0-5距离

  

  //   if (cube.position.x > 5) {

  //     cube.position.x = 0;

  //   }

  renderer.render(scene, camera);

  //   渲染下一帧的时候就会调用render函数

  requestAnimationFrame(render);

}



render();

⭕️ Clock 跟踪事件处理动画

// 设置时钟

const clock = new THREE.Clock();

function render() {

  // 获取时钟运行的总时长

  let time = clock.getElapsedTime();

  console.log("时钟运行总时长：", time);

  //   let deltaTime = clock.getDelta();

  //     console.log("两次获取时间的间隔时间：", deltaTime);

  let t = time % 5;

  cube.position.x = t * 1;



  renderer.render(scene, camera);

  //   渲染下一帧的时候就会调用render函数

  requestAnimationFrame(render);

}



render();

大概是8毫秒一次渲染时间.

⭕️ 不用算 用 Gsap动画库

gsap.com/

// 导入动画库

import gsap from "gsap";



// 设置动画

var animate1 = gsap.to(cube.position, {

  x: 5,

  duration: 5,

  ease: "power1.inOut", // 动画属性

  //   设置重复的次数，无限次循环-1

  repeat: -1,

  //   往返运动

  yoyo: true,

  //   delay，延迟2秒运动

  delay: 2,

  onComplete: () => {

    console.log("动画完成");

  },

  onStart: () => {

    console.log("动画开始");

  },

});

gsap.to(cube.rotation, { x: 2 * Math.PI, duration: 5, ease: "power1.inOut" });



// 双击停止和恢复运动

window.addEventListener("dblclick", () => {

  //   console.log(animate1);

  if (animate1.isActive()) {

    //   暂停

    animate1.pause();

  } else {

    //   恢复

    animate1.resume();

  }

});



function render() {

  renderer.render(scene, camera);

  //   渲染下一帧的时候就会调用render函数

  requestAnimationFrame(render);

}



render();

⭕️ 根据尺寸变化 实现自适应

// 监听画面变化，更新渲染画面

window.addEventListener("resize", () => {

  //   console.log("画面变化了");

  // 更新摄像头

  camera.aspect = window.innerWidth / window.innerHeight;

  //   更新摄像机的投影矩阵

  camera.updateProjectionMatrix();



  //   更新渲染器

  renderer.setSize(window.innerWidth, window.innerHeight);

  //   设置渲染器的像素比

  renderer.setPixelRatio(window.devicePixelRatio);

});

⭕️ 用js控制画布 全屏 和 退出全屏

window.addEventListener("dblclick", () => {

  const fullScreenElement = document.fullscreenElement;

  if (!fullScreenElement) {

    //   双击控制屏幕进入全屏，退出全屏

    // 让画布对象全屏

    renderer.domElement.requestFullscreen();

  } else {

    //   退出全屏，使用document对象

    document.exitFullscreen();

  }

  //   console.log(fullScreenElement);

});

⭕️ 应用 图形 用户界面 更改变量

// 导入dat.gui

import * as dat from "dat.gui";



const gui = new dat.GUI();

gui

  .add(cube.position, "x")

  .min(0)

  .max(5)

  .step(0.01)

  .name("移动x轴")

  .onChange((value) => {

    console.log("值被修改：", value);

  })

  .onFinishChange((value) => {

    console.log("完全停下来:", value);

  });

//   修改物体的颜色

const params = {

  color: "#ffff00",

  fn: () => {

    //   让立方体运动起来

    gsap.to(cube.position, { x: 5, duration: 2, yoyo: true, repeat: -1 });

  },

};

gui.addColor(params, "color").onChange((value) => {

  console.log("值被修改：", value);

  cube.material.color.set(value);

});

// 设置选项框

gui.add(cube, "visible").name("是否显示");



var folder = gui.addFolder("设置立方体");

folder.add(cube.material, "wireframe");

// 设置按钮点击触发某个事件

folder.add(params, "fn").name("立方体运动");

🔴 结语

前端的世界，

不该只有Vue和React——

还有WebGPU里等待你征服的星辰大海。"

“当WebGL成为下一代前端的基础设施，愿你是最早站在三维坐标系里的那个人。”

写这篇文章的时候，我刚通宵处理完一个P0级（最高级别）的线上事故，天刚亮，烟灰缸是满的🚬。

事故的原因，说出来你可能不信，不是什么服务器宕机，也不是什么黑客攻击，就因为我们package.json里的一个依赖项，少写了一个小小的^（脱字符号） 。

这个小小的失误，导致我们给客户A的数据计算模块，在一次平平无奇的依赖更新后，全线崩溃。而我们，直到客户的业务方打电话来投诉，才发现问题。

等我们回滚、修复、安抚客户，已经是7个小时后。按照合同的SLA（服务等级协议），我们公司需要为这次长时间的服务中断，赔付客户十万块。

老板在事故复盘会上，倒没说什么重话，只是默默地把合同复印件放在了桌上。

今天，我不想抱怨什么，只想把这个价值 十万块 的教训，原原本本地分享出来，希望能给所有前端、乃至所有工程师，敲响一个警钟。

事故是怎么发生的？

我们先来复盘一下事故的现场。

我们有一个给客户A定制的Node.js数据处理服务。它依赖了我们内部的另一个核心工具库@internal/core。

在项目的package.json里，依赖是这么写的：

{

  "name": "customer-a-service",

  "dependencies": {

    "@internal/core": "1.3.5",

    "express": "^4.18.2",

    "lodash": "^4.17.21"

    // ...

  }

}

注意看，express和lodash前面，都有一个^符号，而我们的@internal/core，没有。

这个^代表什么？它告诉npm/pnpm/yarn：“我希望安装1.x.x版本里，大于等于1.3.5的最新版本。”

而没有^，代表什么？它代表：我只安装1.3.5这一个版本，锁死它，不许变。

问题就出在这里。

上周，core库的同事，修复了一个严重的性能Bug，发布了1.3.6版本，并且在公司群里通知了所有人。

我们组里负责这个项目的同学，看到了通知，也很负责任。他想：core库升级了，我也得跟着升。

于是，他看了看package.json，发现项目里用的是1.3.5。他以为，只要他去core库的仓库，把1.3.5这个tag删掉，然后把1.3.6的tag打上去，CI/CD在下次部署时，重新pnpm install，就会自动拉取到最新的代码。

他错了！

最致命的锁死版本

因为我们的依赖写的是"1.3.5"，而不是"^1.3.5"，所以我们的pnpm-lock.yaml文件里，把这个依赖的解析规则，彻底锁死在了1.3.5。

无论core库的同事怎么发布1.3.6、1.3.7，甚至2.0.0...

只要我们不去手动修改package.json，我们的CI/CD流水线，在执行pnpm install时，永远、永远，都只会去寻找那个被写死的1.3.5版本。

然后，灾难发生了。

core库的同事，在发布1.3.6后，为了保持仓库整洁，就把1.3.5那个旧的git tag给删掉了。

然后，客户A的项目，某天下午需要做一个常规的文案更新，触发了部署流水线。

流水线执行到pnpm install时，pnpm拿着lock文件，忠实地去找@internal/core@1.3.5这个包...

“Error: Package '1.3.5' not found.”

流水线崩溃了。一个本该5分钟完成的文案更新，导致了整个服务7个小时的宕机😖。

十万块换来的血泪教训

事故复盘会上，我们所有人都沉默了。我们复盘的，不是谁的锅，而是我们对依赖管理这个最基础的认知，出了多大的偏差。

^ (Caret) 和 ~ (Tilde) 不是选填，而是必填

• ^ (脱字符) ：^1.3.5 意味着 1.x.x (x >= 5)。这是最推荐的写法。它允许我们自动享受到所有 非破坏性 的小版本和补丁更新（比如1.3.6, 1.4.0），这也是npm install默认的行为。


• ~ (波浪号) ：~1.3.5 意味着 1.3.x (x >= 5)。它只允许补丁更新，不允许小版本更新。太保守了，一般不推荐。


• （啥也不写） ：1.3.5 意味着锁死。除非你是react或vue这种需要和生态强绑定的宿主，否则，永远不要在你的业务项目里这么干！

我们团队现在强制规定，所有package.json里的依赖，必须、必须、必须使用^。

关于lock文件

我们以前对lock文件（pnpm-lock.yaml, package-lock.json）的理解太浅了，以为它只是个缓存。

现在我才明白，package.json里的^1.3.5，只是在定义一个规则。

而pnpm-lock.yaml，才是基于这个规则，去计算出的最终答案。

lock文件，才是保证你同事、你电脑、CI服务器，能安装一模一样的依赖树的唯一路径。它必须被提交到Git。

依赖更新，是一个主动的行为，不是被动的

我们以前太天真了，以为只要依赖发了新版，我们就该自动用上。

这次事故，让我们明白：依赖更新，是一个严肃的、需要主动管理和测试的行为。

我们现在的流程是：

这十万块，是技术Leader（我）的失职，也是我们整个团队，为基础不牢付出的最昂贵的一笔学费。

一个小小的^，背后是整个npm生态的依赖管理的核心。

分享出来，不是为了博眼球，是真的希望大家能回去检查一下自己的package.json。

看看你的依赖前面，那个小小的^，它还在吗？😠

前言

前几天和前同事闲时聚餐，约了两个月的小聚终于达成了，程序员行业聚少离多，所幸大家的发量还坚挺着。

期间不可避免地聊到了自己的公司、行业状况以及对未来的看法，几杯老酒之后，大家畅所欲言，其中一位老哥侃起了他的职业生涯，既坎坷又无奈，饭后想起来挺有代表性的，征得他同意故记录在此。

以下是老哥的历程。

程序员的前半生

我今年35岁，有房有贷有妻女有老父母。

出生在90年代的农村，从小中规中矩，不惹事不喧哗不突出，三好学生没有我，德智体美没有全面发展。学习也算努力，不算小题做题家，因为只考了个本科。

大学学费全靠助学贷款，勤工俭学补贴日用，埋头苦干成绩也只在年级中等偏下水平。有些同学早早就定下了大学的目标，比如考研、比如出国、比如考公，到了大三的时候大家基本都有了自己的目标。而我的目标就是尽早工作，争取早日还完贷款，因此早早就开始准备找工作。

也许是上天眷顾，不知道怎么就被华为看重了（那会华为还没现在的如日中天，彼时是BAT的天下），稀里糊涂的接受了offer，没想到却是改变了后面十年的决定。

2013年，深圳的夏天阳光明媚，热气扑鼻，提着一个简单的箱子进入了坂田基地。

刚开始，工作上的一切都很新鲜，每个人都在忙碌，虽然不知道他们在忙什么，但感觉很高级的样子。同期入职的同事都比较厉害，很快就适应了工作，而自己还是没完全应对工作内容，于是下班之后继续留在公司学习，顺便蹭饭。

就这样，很快就一年过去了，自己也慢慢熟悉了工作节奏，但是加班也越来越多了。对于自己来说，为了过节点，6点是晚饭时间，9点是下班时间，12点正式下班。

平凡的日子没什么值得留恋，过一天、一个月、一年、四年都没什么两样，四年里学习到了不少的知识，也数了很多次深圳凌晨的路灯数。

作为深漂，没有遇到深圳爱情故事，也对高昂的房价绝望，于是决定回到二线城市，成为一名蓉漂。
2017年，还是和四年前一样的行李箱，出现在了老家的省会城市，只是那时的我没有了助学打款，怀里也攒下了一些血汗钱。

那时互联网行业发展还是如火如荼，前端的需求量也很大，也得益于华为公司发展越来越好，自己的华为经历很快就拿到了几个offer，选了一家初创公司，幻想着能有一番成就。

2018年底，眼看着房价越长越高，某链中介不断地灌输再不买明天就是另一个价了，错过这个村就没这个店了，也许是想有个家，也许是想着父母能到省会里一起住，拿出自己做牛马几年的积蓄加上父母一辈子辛苦攒的小十万的养老钱购买了城区里的新房，那会儿的价格已经比前两年涨了一倍多，妥妥的高位站岗，不过想着自己是刚需也不会卖，因此咬咬牙掏出了全部的积蓄怒而背上了三十年的房贷。

房子的事暂时落定了，全身心的投入到工作中，没想到老板只想骗投资人的钱，产品没弄好投资人不愿跟进了，坚持了三年，期间各种断臂求生，最终还是落了个司破人走的境地。

2020年，30岁的我第一次被动失业了，幸运的是也找到了另一半。为了尽可能节省支出，房子装修的事我们都是亲力亲为，最后花了十多万终于将房子装好了，虽然很简单但毕竟是自己在大城市里的第一套房子，那一刻，感觉十年的付出都是值得的。

背着沉重的房贷，期望能找到一份薪资稍微过得去的工作，于是在简历上优势那行写了：“可加班”。依稀记得有些HR对我进行了灵魂拷问：结婚了吗？有小孩了吗？你都30岁了还能加班吗？。我斩钉截铁地说：只要公司有需要，我定会全力以赴！

2022年，我们的孩子出世了，队友辞去了工作全心全意带小孩，而我更加努力了，毕竟有了四脚吞金兽，不得不肝。

虽然工作很努力，但成果一般，不是公司的技术担当，也不会是技术洼地。

2023年的某一天，和之前的364天一样的平淡，在座位上解Bug的我突然感觉到一阵心悸，呼吸不畅，实在不行了呼唤同事叫了120，去医院一套检查下来没发现什么大问题。医生询问是不是工作压力太大，平时加班很多？我说还好，平时也就加班到9点。医生笑了笑说你这种年轻人我见多了，都是压力大的毛病，平时工作不要久坐盯着屏幕多站起来走走。他让我回家多休息，回去后观察了几天还是偶尔会有心悸，再去了另一个医院进行检查，也是没有明确的诊断结果，只是说可能是这个问题，又可能是另一个问题。

过了1个月后，身体上的问题不见好转，我辞去了工作。

2023年末，找了一家小公司，也就是我现在的公司，工资没有涨，仔细算起来还变相下降了。

还是做的业务需求，也没有领导什么人，管好自己就行，直属上级还是个工作几年的小伙。这家公司主要的特点是不加班，技术难度不高，能做多少就是多少，前提是要报风险，领导也不会强迫加班。

就这样到了2024，神奇的是我已经很久没有心悸的感觉了，不知道是不加班还是心态转变的原因。
家里的小朋友也长大了，会说话了。我现在每天下班最温馨的的是她开着门期待我回家的那一刻，她的期盼的眼神就是我回家的动力。

公司在2024年也裁了不少人，领导也找我谈过问问我的想法，我说：我还是能胜任这份工作的。领导说：公司觉得你年级大了一些，工资虽然不是最高，但不太符合行情，你懂的。我说：我懂，可以接受适当的降薪。
就这样，我挺过了2024，然而过了一周领导走了。

2025年，我35周岁了。
现在的我已经彻底接受自己的平庸的事实了。在学生时代，从来都不出色，也不会垫底，就是那类最容易被忽略的人。在工作时代，不是技术大牛，也不是完全的水货，就是普普通通的程序员。

如果说上半生吃到了什么红利，只能说入坑了计算机这行业，技术给我带了收入，有了糊口的基础。没进股市，却被房价狠狠割了一道。

35岁的我，没有彻底躺平摆烂，也没有足够奋发进取。

35岁的我，有着24年的房贷，还好61岁的时候我还在工作，应该还能还房贷。

35岁的我，不吃海鲜不喝酒，尿酸500+。

35岁的我，人体工学椅也挽救不了腰椎间盘突出。

35岁的我，头发依然浓密，只是白发越来越多。

35岁的我，已经不打游戏，只是会看这各种小说聊以慰藉。

35岁的我，两点一线，每天挤着地铁，看众生百态。

35岁的我，早睡早起，放空自己。

35岁的我，暂时还没有领取毕业大礼包，希望今年还能苟过。

35岁的我，希望经济能够好起来，让如我一般平凡的人能够有活下去的勇气。

诸君，下一年再会~祝你平安喜乐，万事顺遂！

太极分两仪，有程序员也有程序媛：30岁的程序媛，升值加薪与我无缘

相信我们经常这样写bug（不是 👇：

try {

  const res = await api.getUser()

  console.log('✅ 用户信息', res)

} catch (err) {

  console.error('❌ 请求失败', err)

}

看似没问题

• 每个接口都要 try-catch，太啰嗦了！


• 错误处理逻辑分散，不可控！


• 代码又臭又长💨！

💡 目标：不抛异常的安全请求封装

我们希望实现这样的调用👇：

const [err, data] = await safeRequest(api.getUser(1))

if (err) return showError(err)

console.log('✅ 用户信息：', data)

是不是清爽多了？✨

没有 try-catch，却能同时拿到错误和数据。

🧩 实现步骤

1️⃣ 先封装 Axios 实例

// src/utils/request.js

import axios from 'axios'

import { ElMessage } from 'element-plus'



const service = axios.create({

  baseURL: import.meta.env.VITE_API_BASE_URL,

  timeout: 10000,

})



// 🧱 请求拦截器

service.interceptors.request.use(

  (config) => {

    const token = localStorage.getItem('token')

    if (token) config.headers.Authorization = `Bearer ${token}`

    return config

  },

  (error) => Promise.reject(error)

)



// 🧱 响应拦截器

service.interceptors.response.use(

  (response) => {

    const res = response.data

    if (res.code !== 0) {

      ElMessage.error(res.message || '请求失败')

      return Promise.reject(new Error(res.message || '请求失败'))

    }

    return res.data

  },

  (error) => {

    ElMessage.error(error.message || '网络错误')

    return Promise.reject(error)

  }

)



export default service

拦截器的作用：

• ✅ 统一处理 token；


• ✅ 统一处理错误提示；


• ✅ 保证业务层拿到的永远是“干净的数据”。

2️⃣ 封装一个「安全请求函数」

// src/utils/safeRequest.js

export async function safeRequest(promise) {

  try {

    const data = await promise

    return [null, data] // ✅ 成功时返回 [null, data]

  } catch (err) {

    return [err, null] // ❌ 失败时返回 [err, null]

  }

}

这就是关键！

它让所有 Promise 都变得「温柔」——不再抛出异常，而是返回结构化结果。

3️⃣ 封装 API 模块

// src/api/user.js

import request from '@/utils/request'



export const userApi = {

  getUser(id) {

    return request.get(`/user/${id}`)

  },

  updateUser(data) {

    return request.put('/user', data)

  },

}

4️⃣ 在业务层优雅调用

<script setup>

import { ref, onMounted } from 'vue'

import { userApi } from '@/api/user'

import { safeRequest } from '@/utils/safeRequest'



const user = ref(null)



onMounted(async () => {

  const [err, data] = await safeRequest(userApi.getUser(1))

  if (err) return showError(err)

  console.log('✅ 用户信息：', data)

})

</script>

是不是很优雅、数据逻辑清晰、不需要 try-catch、 错误不崩溃。

老板说：牛🍺，你小子有点东西

🧱 我们还可以进一步优化：实现自动错误提示

我们可以给 safeRequest 增加一个选项，让错误自动提示：

// src/utils/safeRequest.js

import { ElMessage } from 'element-plus'



export async function safeRequest(promise, { showError = true } = {}) {

  try {

    const data = await promise

    return [null, data]

  } catch (err) {

    if (showError) {

      ElMessage.error(err.message || '请求失败')

    }

    return [err, null]

  }

}

使用时👇：

const [err, data] = await safeRequest(userApi.getUser(1), { showError: false })

这样你可以灵活控制是否弹出错误提示，

比如某些静默请求就可以关闭提示。

🧠 进阶：TypeScript 支持（超丝滑）

如果你用的是 TypeScript，可以让返回类型更智能👇：

export async function safeRequest<T>(

  promise: Promise<T>

): Promise<[Error | null, T | null]> {

  try {

    const data = await promise

    return [null, data]

  } catch (err) {

    return [err as Error, null]

  }

}

调用时：

const [err, user] = await safeRequest<User>(userApi.getUser(1))

if (user) console.log(user.name) // ✅ 自动提示类型

老板：写得很好，下次多写点，明天你来当老板

最近逛职场社区的时候，刷到一个职场话题，老生常谈了，但是每次参与讨论的同学都好多。

这个问题问得比较扎心：

“为什么有些企业的裁员首先从技术人员开始？”

关于这个问题，网上有一个被讨论很多的比喻：

“房子都盖起来了，还需要工人么？”

有一说一，这个比喻虽然刺耳，但却非常形象地揭示了某些企业的用人逻辑，尤其在某些非技术驱动型的公司里。

在某些非技术驱动的公司（比如传统企业转型、或者业务模式成型的公司），其实技术部门很多时候是会被视为「成本中心」，而非「利润中心」的，我相信在这类企业待过的技术同学肯定是深有体会。

就像盖大楼一样，公司需要做一个 App，或者搞一个系统，于是高薪招来一帮程序员“垒代码”。

当这个产品上线，业务跑通了，进入了平稳运营期，公司某些大聪明老板总会觉得“房子”已经盖好了。

这时候，一些开发人员在老板眼里就变成了“冗余”的成本。

大家知道，销售部门、业务部门能直接带来现金流，市场部能带来用户，而技术部门的代码是最看不见摸不着的。

一旦没有新的大项目启动，老板会觉得技术人员坐在那里就是在“烧钱”。

那抛开这个“盖楼”的比喻，在这种非技术驱动的公司里，从纯粹的财务角度来看，裁技术岗往往是因为“性价比”太低。

所以这里我们不得不面对的一个现实是：技术人员通常是公司里薪资最高的一群人。

高薪是一把双刃剑呐。

一个初级程序员的月薪可能抵得上两个行政，一个资深架构师的年薪可能抵得上一个小团队的运营费用。当公司面临现金流危机，需要快速削减成本时，裁掉一个高级技术人员省下来的钱，相当于裁掉好几个非技术岗位人员。

除此之外还有一个比较尴尬的事情那就是，在技术团队中，往往存在着一种“金字塔”结构。

随着工龄增长，薪资涨幅很快，但产出效率（在老板眼里）未必能线性增长。

脑补一下这个场景就知道了：

• 一个 35 岁的高级工程师，月薪 4 万，可能要养家糊口，精力不如 20 多岁的小年轻，加班意愿低。


• 一个 23 岁的小年轻，月薪 1 万 5，充满激情，能扛能造。

这时候某些大聪明老板的算盘就又打起来了：

裁掉一个 4 万的老员工，招两个 1 万 5 的小年轻，代码量翻倍，团队氛围更活跃，成本还降了，这种“优化”在管理层眼里，简直是“降本增效”的典范。

所以综合上面这种种情形分析，这时候，文章开头的那个问题往往也就会逐渐形成了。

所以事就是这么个事，说再多也没用。

既然环境不能左右，那作为个体，我们又该如何自处呢？

这里我不想灌鸡汤，只想务实地聊一聊我所理解的一些对策，希望能对大家有所启发。

同时这也是我给很多后台私信我类似问题小伙伴们的一些共同建议。

1、跳出技术思维，建立业务思维

千万不要只盯着你的 IDE 和那一亩三分地代码，抽空多了解了解业务和流程吧，比如：

• 项目是靠什么赚钱的？


• 你的代码在哪个环节为公司省钱或挣钱？


• 如果你是老板，你会怎么优化现在的系统？

当你能用技术手段去解决业务痛点（比如提升转化率、降低服务器成本）时，你就不再是成本，而是资产。

2、别温水煮青蛙，要保持技能更新

这一点之前咱们这里多次提及，在技术行业，吃“老本”是最危险的。

当今的技术世界变化太快，而作为程序员的我们则恰好处于这一洪流之中，这既是挑战，也是机会。

还是那句话，一定要定期评估一下自己的市场价值：如果明天就离开现在的公司，你的技能和经验是否足以让你在市场上获得同等或更好的位置？

无论在公司工作多久，都要不断更新自己的技能和知识，确保自己始终具有市场竞争力。

3、别让自己的工作经验烂掉，有意识地积累职业资产

这一点我们之前其实也聊过。

除了特定的技术、代码、框架可以作为自己可积累的能力资产之外，其实程序员的职业生涯里也是可以有很多可固化和可积累的有形资产的。

比如你的技术经历、思维、经验、感悟是不是可以写成技术博客文字？你写的代码、工具、框架是不是可以形成开源项目？你的工作笔记和踩坑记录是不是可以整理成技术手册？

千万不要让自己的工作经验烂掉，而是要有意识地将自己的技术资产化，将自己的过往经验、知识、能力转化成在行业里有影响力的硬通货。

4、尽早构建 Plan B，提升抗风险能力

当然这一点虽然说的简单，其实对人的要求是比较高的。前面几点做好了，这一点有时候往往就会水到渠成。

我觉得总体的方向应该是：尽量利用你的技术特长来构建一个可持续的 Plan B。

比方说：开发一个小工具、写写技术专栏、或者运营一个 GitHub 项目、在技术博客或社区中建立个人品牌...等等，这些不仅仅能增加收入，往往还能拓展你的人脉圈。

其实很多程序员在年龄大了之后越来越焦虑的一个重要原因就是因为生存技能太过单一了，所以千万不要给自己设限，埋头赶路的同时也不要忘记时常抬头看看周围的环境和机会。

好了，今天就先聊这么多吧，希望能对大家有所启发，我们下篇见。

注：本文在GitHub开源仓库「编程之路」 github.com/rd2coding/R… 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。

前言

分享一个基于Three.js封装的树生成器插件，可以实现创建不同类型且渲染效果真实的3D树

说实话，第一次在这个插件官网看到这个效果时我一度以为这只是一个视频，树的内容不仅仅是动态的而且整体的渲染效果也十分真实。

在three.js中使用起来也是非常的简单的仅仅需几行代码就可以搞定，下面给大家简单的介绍一下。

安装

通过 npm/pnpm 安装到项目本地即可

npm i @dgreenheck/ez-tree



pnpm add @dgreenheck/ez-tree

使用

使用起来也是非常简单的，只需要将插件import 引入然后在 new 实例化出来 在添加到 场景中就可以了

最后在一个requestAnimationFrame 动画函数中更新树的内容就行了

import { Tree } from '@dgreenheck/ez-tree';



createTree(){



      const tree = new Tree();

      tree.generate();

      // 设置一下位置

      tree.position.set(0, 0, 0);

      // 设置一下大小缩放

      tree.scale.set(0.1, 0.1, 0.1);

      // 添加到场景中

      this.scene.add(tree);

      

}



  sceneAnimation(): void {

    // 确保动画循环持续进行

    this.renderAnimation = requestAnimationFrame(() => this.sceneAnimation());



      // 更新时钟

      const elapsedTime = this.clock.getElapsedTime();





      // 更新控制器 如果当前是第一人称控制器则不更新

      if (!this.pointerLockControls) {

        this.controls.update();

      }



      // 更新 Tree 动态效果（风动效果等）

      if (this.tree) {

        this.tree.update(elapsedTime);

      }

      // 渲染场景

      this.renderer.render(this.scene, this.camera);

  }

本地项目效果

因为本地项目对光照等参数没有专门调试所以和官网展示的效果有一定的差距

将相机放大查看树渲染的效果细节处理个人觉得是非常nice的，十分真实

参数

该插件还提供了创建不同类型树的方法，通过官网的在线调试就可以看到效果了

创建一个别的类型树

修改树枝的方向

树叶的多少

项目地址

该项目插件是一个外国大佬开发，如果你的项目或者个人网站需要丰富一下页面内容，那么这个插件或许是个不错的选择

官网：http://www.eztree.dev/

项目地址：github.com/dgreenheck/…

“我永远记得第一次用Python写出自动化脚本的那个深夜——原来编程语言间的鸿沟，远没有想象中那么深。”

作为一名纯前端出身的开发者，我曾以为JavaScript就是编程世界的全部。直到被迫接手一个数据分析项目，才在焦虑中踏上了Python学习之路。今天分享我的真实转型经验，带你避开我踩过的坑。

我的认知颠覆时刻

初学JS时，我以为死记语法是王道：

// 曾经的我：疯狂背诵语法

const arrowFn = (a, b) => a + b; 

const promise = new Promise((res) => setTimeout(res, 1000));

转学Python后才发现：

# 现在的我：理解概念重于记忆

add = lambda a, b: a + b  

await asyncio.sleep(1)

核心顿悟：编程语言的本质是表达逻辑的工具，掌握变量/函数/循环这些通用概念，比记住特定语法重要十倍。

为什么JS开发者必学Python？

当我的项目经理扔来一份Python需求时，我发现了它的不可替代性：

最打动我的点：用Python写算法时，代码就像伪代码一样直白：

# 快速实现斐波那契数列

def fib(n):

    a, b = 0, 1

    for _ in range(n):

        yield a

        a, b = b, a + b

我的语法转换血泪史

这些细节坑惨了我这个JS老手：

1. 花括号→缩进的地狱

// JS习惯：靠{}划分作用域

if (loggedIn) {

  const user = fetchUser()

  console.log(user)

}

# Python的缩进陷阱（初学者的噩梦）

if logged_in:

    user = fetch_user()

print(user)  # 这里居然还能访问user！

我的教训：安装Pylint插件强制4空格缩进，避免混合制表符

2. 变量命名的文化冲突

// JS：驼峰式

const currentUser = { firstName: "John" };

# Python：蛇形命名

current_user = { "first_name": "John" }

适应技巧：在VSCode中设置自动转换规则

3. 空值判断的深坑

// JS的魔幻三兄弟：null, undefined, false

let value = undefined;

if (!value) { /* 会触发 */ }

# Python的明确哲学

value = 

if value is :  # 必须显式判断

    print("空值")

让我惊艳的Python特性

列表推导式（List Comprehensions）

# 一行完成JS需要5行的操作

squares = [x**2 for x in range(10) if x % 2 == 0]



# 等效JS代码：

# const squares = [];

# for(let x=0; x<10; x++) {

#   if(x%2===0) squares.push(x**2)

# }

解构赋件的优雅

# 交换变量值

a, b = b, a



# JS等价操作：

# let temp = a;

# a = b;

# b = temp;

类型提示的救赎

def greet(name: str) -> str:

    return f"Hello, {name}"



# 作为TS爱好者狂喜！

我的学习路线图

那些我希望早点知道的技巧

# 1. 虚拟环境是救命稻草

python -m venv .venv

source .venv/bin/activate



# 2. 使用pathlib代替os.path

from pathlib import Path

config = Path.home() / ".config" / "myapp.json"



# 3. 活用f-string

print(f"{user.name=} {user.age=}") # 输出：user.name='John' user.age=30

转型后的真实感受

开发体验变化：

• ✅ 少了npm install的依赖地狱


• ✅ 错误信息更人性化


• ❌ 前端调试体验不如Chrome DevTools

心态转变：

“以前觉得Python是‘其他语言’，现在明白它和JS是互补的左右手——JS构建用户界面，Python处理背后逻辑。”

给同行的建议：不要试图“转行”，而要“扩列”。我的GitHub个人主页现在 proudly displays：

JavaScript | Python | 持续学习者

最后忠告：当你在Python中写import this，输出的禅意哲学，正是这门语言的精髓——优美胜于丑陋，明了胜于晦涩。这大概就是我从JS的“灵活”走向Python的“优雅”时，最深的共鸣。

红中老大 快醒吧。 我们要成啦！！！

前言

人类的悲喜并不相通，有人欢喜有人愁，更多的是看热闹。

就在上周，"苟住"群里的一个小伙伴也苟不住了。

在苟友们的"墙裂"要求下，他分享了他的经验，以他的视角看看他是怎么操作的。

1. 组织变动，意外晋升

两年前加入公司，依然是一线搬砖的码农。

干到一年的时候公司空降了一位号称有诸多大厂履历的大佬来带领研发，说是要给公司带来全新的变化，用技术创造价值。

大领导第一件事：抓人事，提效率。

在此背景下，公司不少有能力的研发另谋出处，也许我看起来人畜无害，居然被提拔当了小组长。

2. 领取任务，开启副本

当了半年的小组长，我的领导就叫他小领导吧，给我传达了大领导最新规划：团队需要保持冲劲，而实现的手段就是汰换。

用人话来说就是：

当季度KPI得E的人，让其填写绩效改进目标，若下一个季度再得到E，那么就得走人

我们绩效等级是ABCDE，A是传说中的等级，B是几个人有机会，大部分人是C和D，E是垫底。

而我们组就有两位小伙伴得到了E，分别是小A和小B。

小领导意思是让他们直接走得了，大不了再招人顶上，而我想着毕竟大家共事一场，现在大环境寒气满满，我也是过来人，还想再争取争取。

于是分析了他们的基本资料，他俩特点还比较鲜明。

小A资料：

1. 96年，单身无房贷


2. 技术栈较广，技术深度一般，比较粗心


3. 坚持己见，沟通少，有些时候会按照自己的想法来实现功能

小B资料：

1. 98年，热恋有房贷


2. 技术基础较薄弱，但胜在比较认真


3. 容易犯一些技术理解上的问题

了解了小A和小B的历史与现状后，我分别找他们沟通，主要是统一共识：

1. 你是否认可本次绩效评估结果？


2. 你是否认可绩效改进的点与风险点（未达成被裁）？


3. 你是否还愿意在这家公司苟？

最重要是第三点，开诚布公，若是都不想苟了，那就保持现状，不要浪费大家时间，我也不想做无用功。

对于他们，分别做了提升策略：

对于小A：

1. 每次开启需求前都要求其认真阅读文档，不清楚的地方一定要做记录并向相关人确认


2. 遇到比较复杂的需求，我也会一起参与其中梳理技术方案


3. 需求开发完成后，CR代码看是否与技术方案设计一致，若有出入需要记录下来，后续复盘为什么


4. 给足时间，保证充分自测

对于小B：

1. 每次需求多给点时间，多出的时间用来学习技术、熟悉技术


2. 要求其将每个需求拆分为尽可能小的点，涉及到哪些技术要想清楚、弄明白


3. 鼓励他不懂就要问，我也随时给他解答疑难问题，并说出一些原理让他感兴趣的话可以继续深究


4. 分配给他一些技术调研类的任务，提升技术兴趣点与成就感

3. 结束？还是是另一个开始？

半年后...

好消息是：小A、小B的考核结果是D，达成了绩效改进的目标。

坏消息是：据说新的一轮考核算法会变化，宗旨是确保团队血液新鲜（每年至少得置换10%的人）。

随缘吧，我尽力了，也许下一个是我呢？

XunDoc开发之旅：当AI医生遇上家庭健康管家

当我在生活中目睹家人为管理复杂的健康数据、用药提醒而手忙脚乱时，一个想法冒了出来：我能否打造一个App，像一位贴心的家庭健康管家，把全家人的健康都管起来？它不仅要能记录数据，还要够聪明，能解答健康疑惑，能主动提醒。这就是 XunDoc App。

1. 搭建家庭的健康数据中枢

起初，我转向AI助手寻求架构指导。我的构想很明确：一个以家庭为单位，能管理成员信息、记录多种健康指标（血压、血糖等）的系统。AI很快给出了基于SwiftUI和MVVM模式的代码框架，并建议用UserDefaults来存储数据。

但对于一个完整的应用而言，我马上遇到了第一个问题：数据如何在不同视图间高效、准确地共享？ 一开始我简单地使用@State，但随着功能增多，数据流变得一团糟，经常出现视图数据不同步的情况。

接着在Claude解决不了的时候我去询问Deepseek，它一针见血地指出：“你的数据管理太分散了，应该使用EnvironmentObject配合单例模式，建立一个统一的数据源。” 这个建议成了项目的转折点。我创建了FamilyShareManager和HealthDataManager这两个核心管家。当我把家庭成员的增删改查、健康数据的录入与读取都交给它们统一调度后，整个应用的数据就像被接通了任督二脉，立刻流畅稳定了起来。

2. 请来AI医生：集成Moonshot API

基础框架搭好，接下来就是实现核心的“智能”部分了。我想让用户能通过文字和图片，向AI咨询健康问题。我再次找到AI助手，描述了皮肤分析、报告解读等四种咨询场景，它很快帮我写出了调用Moonshot多模态API的代码。

然而，每件事都不能事事如意的。文字咨询很顺利，但一到图片上传就频繁失败。AI给出的代码在处理稍大一点的图片时就会崩溃，日志里满是编码错误。我一度怀疑是网络问题，但反复排查后，我询问Deepseek，他告诉我：“多模态API对图片的Base64编码和大小有严格限制，你需要在前端进行压缩和校验。”

我把他给我的建议给到了Claude。claude帮我编写了一个“图片预处理”函数，自动将图片压缩到4MB以内并确保编码格式正确。当这个“关卡”被设立后，之前桀骜不驯的图片上传功能终于变得温顺听话。看着App里拍张照就能得到专业的皮肤分析建议，那种将前沿AI技术握在手中的感觉，实在令人兴奋。

3. 打造永不遗忘的智能提醒系统

健康管理，贵在坚持，难在记忆。我决心打造一个强大的医疗提醒模块。我的想法是：它不能是普通的闹钟，而要像一位专业的护士，能区分用药、复查、预约等不同类型，并能灵活设置重复。

AI助手根据我的描述，生成了利用UserNotifications框架的初始代码。但很快，我发现了一个新问题：对于“每周一次”的重复提醒，当用户点击“完成”后，系统并不会自动创建下一周的通知。这完全违背了“提醒”的初衷。

“这需要你自己实现一个智能调度的逻辑，在用户完成一个提醒时，计算出下一次触发的时间，并重新提交一个本地通知。” 这是deepseek告诉我的，我把这个需求告诉给了Claude。于是，在MedicalNotificationManager中， claude加入了一个“重新调度”的函数。当您标记一个每周的用药提醒为“已完成”时，App会悄无声息地为您安排好下一周的同一时刻的提醒。这个功能的实现，让XunDoc从一个被动的记录工具，真正蜕变为一个主动的健康守护者。

4. 临门一脚：App Store上架“渡劫”指南

当XunDoc终于在模拟器和我的测试机上稳定运行后，我感觉胜利在望。但很快我就意识到，从“本地能跑”到“商店能下”，中间隔着一道巨大的鸿沟——苹果的审核。证书、描述文件、权限声明、截图尺寸……这些繁琐的流程让我一头雾水。

这次，我直接找到了DeepSeek：“我的App开发完了，现在需要上传到App Store，请给我一个最详细、针对新手的小白教程。”

DeepSeek给出的回复堪称保姆级，它把整个过程拆解成了“配置App ID和证书”、“在App Store Connect中创建应用”、“在Xcode中进行归档打包”三大步。我就像拿着攻略打游戏，一步步跟着操作：

• 创建App ID：在苹果开发者后台，我按照说明创建了唯一的App ID com.[我的ID].XunDoc。


• 搞定证书：最让我头疼的证书环节，DeepSeek指导我分别创建了“Development”和“Distribution”证书，并耐心解释了二者的区别。


• 设置权限：因为App需要用到相机（拍照诊断）、相册（上传图片）和通知（医疗提醒），我根据指南，在Info.plist文件中一一添加了对应的权限描述，确保审核员能清楚知道我们为什么需要这些权限。

一切准备就绪，我在Xcode中点击了“Product” -> “Archive”。看着进度条缓缓填满，我的心也提到了嗓子眼。打包成功！随后通过“Distribute App”流程，我将我这两天的汗水上传到了App Store Connect。当然不是一次就通过上传的。

5. 从“能用”到“好用”：三次UI大迭代的觉醒

应用上架最初的兴奋感过去后，我陆续收到了一些早期用户的反馈：“功能很多，但不知道从哪里开始用”、“界面有点拥挤，找东西费劲”。这让我意识到，我的产品在工程师思维里是“功能完备”，但在用户眼里可能却是“复杂难用”。

我决定重新设计UI。第一站，我找到了国产的Mastergo。我将XunDoc的核心界面截图喂给它，并提示：“请为这款家庭健康管理应用生成几套更现代、更友好的UI设计方案。”

Mastergo给出的方案让我大开眼界。它弱化了我之前强调的“卡片”边界，采用了更大的留白和更清晰的视觉层级。它建议将底部的标签栏导航做得更精致，并引入了一个全局的“+”浮动按钮，用于快速记录健康数据。这是我第一套迭代方案的灵感来源：从“功能堆砌”转向“简洁现代” 。

然而，Mastergo的方案虽然美观，但有些交互逻辑不太符合iOS的规范。于是，第二站，我请来了Stitch。我将完整的产品介绍、所有功能模块的说明，以及第一版的设计图都给了它，并下达指令：“请基于这些材料，完全重现XunDoc的完整UI，但要遵循iOS Human Interface Guidelines，并确保信息架构清晰，新用户能快速上手。”等到他设计好了后 我将我的设计图UI截图给Claude，让他尽可能的帮我生成。

（以上是我的Stitch构建出来的页面）
Claude展现出了惊人的理解力。它不仅仅是在画界面，而是在重构产品的信息架构。它建议将“AI咨询”的四种模式（皮肤、症状、报告、用药）从并列排列，改为一个主导航入口，进去后再通过图标和简短说明让用户选择。同时，它将“首页”重新定义为真正的“健康概览”，只显示最关键的数据和今日提醒，其他所有功能都规整地收纳入标签栏。这形成了我的第二套迭代方案：从“简洁现代”深化为“结构清晰” 。

拿着Claude的输出，我结合Mastergo和Stitch的视觉灵感，再让Cluade一步一步的微调。我意识到，颜色不仅是美观，更是传达情绪和功能的重要工具。我将原本统一的蓝色系，根据功能模块进行了区分：健康数据用沉稳的蓝色，AI咨询用代表智慧的紫色，医疗提醒用醒目的橙色。图标也设计得更加线性轻量，减少了视觉负担。（其实这是Deepseek给我的建议）这就是最终的第三套迭代方案：在清晰的结构上，注入温暖与亲和力。

这次从Stitch到Claude的UI重塑之旅，让我深刻意识到，一个成功的产品不仅仅是代码的堆砌。它是一次与用户的对话，而设计，就是这门对话的语言。通过让不同的AI助手在我的引导下“协同创作”，我成功地让XunDoc从一個工程师的作品，蜕变成一个真正为用户着想的产品。

现在这款app已经成功上架到了我的App store上 大家可以直接搜索下来进行使用和体验，我希望大家可以在未来可以一起解决问题！

前言

给大家分享一下个人在探索开发three.js编辑器项目期间发现的一些比较不错的3D编辑器类型的开源项目，如果你也正打算做类似相关的项目，那么这些开源项目会是一个不错的参考借鉴

以下排名不分先后🙏🏻

项目一：Astral3D

描述：基于Vue3 + THREE.JS 免费开源的三维引擎及配套编辑器，包含BIM轻量化、CAD解析预览、粒子系统、插件系统等功能。

特点：强大的3D场景内容元素的编辑和保存功能和丰富多样的3D元素内容，同时支持BIM和CAD等工业建模文件的加载渲染

注意⚠️：项目是Apache-2.0 license 的开源协议，项目作者本人也声明了项目可用于个人学习，如有商用需要向作者申请商用授权

界面：

在线地址：editor.astraljs.com/#/

Github: github.com/mlt131220/A…

项目二：thebrowserlab

描述：一个「运行在浏览器里的 3D 编辑器 + 创意编码 (creative-coding) 环境」

特点：支持加载视频、文本、图片、粒子等内容并提供了丰富的编辑表单参数可视化编辑配置，同时还支持在线代码的脚本内容写入设置3D场景内容。

注意⚠️：项目使用 MIT 授权 (MIT license)，意味着你可以自由地 fork、修改、商用 (遵守 MIT 即可)

界面：

在线地址：thebrowserlab.com/

Github: github.com/icurtis1/th…

项目三：threepipe

描述：一个基于 Three.js 构建的现代 3D 框架

特点：项目基于了Three.js进行了二次封装，提供了不少高级功能，使其适合从简单 3D 模型预览到复杂 交互 / 渲染应用，通过简单的API 使用就可以快速创建复杂的3D模型预览器，模型编辑器等内容。

注意⚠️：既然是封装好的框架，在享受使用的便利时，新的学习成本也是不可避免的，项目使用 Apache-2.0-1协议，商用也许需要授权，不过毕竟是歪果仁开发的，即使未授权也难以知晓

界面：

在线地址：editor.threepipe.org/

Github: github.com/repalash/th…

项目四：ShadowEditor

描述：基于Three.js、Go语言和MongoDB的跨平台的3D场景编辑器，支持桌面版和Web版。

特点：跨平台的支持 Windows / Linux / Mac，在桌面 (desktop) 和浏览器 (web) 中都能运行，前后端一体的项目

注意⚠️：使用 MIT 许可证的项目，可以自由用于学习、实验或商业用途。从界面不难看出，应该是属于上古时期的项目了，three.js版本也是107的。作者也推出了商业版的，如有需要也可以试用一下商业版的

界面：

在线地址：http://www.hylab.cn/shadowedito…

Github: gitee.com/tengge1/Sha…

项目五：three-editor

描述：一个基于 Three.js 的 可视化 / 低代码 3D 编辑器 / 内核／框架。它的目标是降低使用 Three.js 的门槛，让构建 Web 3D 场景更简单、更迅速

特点：提供了一整套“可视化 + 配置 + 编辑 + 渲染”的能力，使得即使不深入了解 Three.js，也能快速构建 3D 场景 / 项目，：如果你只是想在网页中展示某个 3D 模型、场景或交互，而不想编写大量 Three.js boilerplate，three-editor 能极大降低门槛

注意⚠️：因为场景内容都是封装处理好的，提供的可编辑参数内容配置并不多，如果你的自定义需求很多的话使用这个项目前需要谨慎考虑一下

界面：

在线地址：z2586300277.github.io/threejs-edi…

Github: github.com/z2586300277…

项目六：scene-editor

描述：vis-three/scene-editor 是基于 vis-three 框架构建的 —— vis-three 本身是一个封装自 Three.js 的前端 3D 开发框架，用于简化 Web3D 开发

特点：基于vis-three 衍生开发的一个3D编辑器提供了一套较为完整的 Web 3D 场景编辑功能 — 目标是让你即使对 3D 或 Three.js 不熟，也能比较轻松地 “拖／配／编辑” 出一个 3D 场景

注意⚠️：仓库地址的代码是Vue3项目编译打包后的，作者并没有直接提供Vue3项目的源代码，如果有二次开发需求，无法直接性修改源代码

界面：

在线地址：z2586300277.github.io/threejs-edi…

Github: github.com/Shiotsukika…

Gitee:gitee.com/vis-three/s…

项目七： three.js官方编辑器

描述：Three.js（著名的 WebGL / Web 3D 渲染库）自带 / 官方提供的可视化编辑器，接触过three.js的应该都知道吧

特点：3D编辑器的鼻祖了也是唯一一个能和three.js最新版本保持随时同步的编辑器，很多现有的商业项目和开源项目的功能，或多或少都参考了这个项目去实现的

注意⚠️：使用原生js 去实现的，二次开发和扩展功能成本较大

界面：

在线地址：threejs.org/editor/

Github: github.com/mrdoob/thre…

项目八： threejs-3dmodel-edit

描述：一个基于 Three.js + Vue 3 + TypeScript + Pinia 的前端 3D 模型编辑器 / 可视化编辑平台

特点：是一个比较完整、现代、易用的 Web-based 3D 模型编辑器 — 它把 Three.js 的功能通过 Vue / TS / Pinia 封装起来，让非专业 3D 建模背景的人也能比较容易地加载 /编辑 /导出 /展示 3D 模型。基于企业级项目代码开发的标准规范，如果你正在开发自己的第一个企业级Three.js 项目那么这个项目的代码设计思路将会是一个不错的参考

注意⚠️：作者本人的3D开源项目，毛遂自荐一下，哈哈哈哈

界面：

在线地址：threeflowx.cn/open/#/

Github: github.com/zhangbo126/…

Gitee:gitee.com/ZHANG_6666/…

结语

ok以上就是作者本人已知的一些不错的开源3D编辑器合集了，如果你还知道一些好的3D编辑器项目欢迎评论区补充

AntD 6 发布之后，网上很多人都在观望：

“要不要升级？”

“会不会炸？”

“我的项目能不能扛得住？”

其实 AntD 官方已经在文档里把升级路径写得非常清楚，只是稍显简略。

下面我用更真实、更工程化的方式，把 v5 → v6 的升级步骤 做了一次加强版讲解，

让你升级时不至于踩坑。

① 第一步：升级到 v5 最新版本（必须执行）

在升级到 AntD 6 之前，官方强烈建议你先把项目从 v5 升到 v5 最新版本：5.29.1。

为什么？

✔ v5 的最新版本会给出所有废弃 API 的 warning

✔ 不处理这些 warning，到 v6 会直接报错

✔ v5 → v6 是平滑升级路径，只要你处理掉 v5 的 warning，升级 v6 就不会炸

执行命令：

npm install antd@5

装完以后，启动项目，务必一条一条看控制台 warning。

比如：

• 某个 API 将被移除


• 某个 props 已废弃


• 某个组件 v6 即将删除

所有 warning 都处理完，再继续下一步。

这阶段非常关键，等于是在做“升级前全身检查”。

其实你只要用了5的版本基本没啥大问题

② 第二步：确保项目运行在 React 18（或以上）

AntD 6 不再支持 React 17 及以下版本。

AntD 官方的态度非常明确：

“React 17，我们不救了。”

好消息是：绝大多数前端项目早就 React 18 了。

如果你还停留在 React 17，那建议你别升级 AntD，

你升级 React 本身都要做好打仗的准备。

检查你的 package.json：

"react": "^18.x.x",

"react-dom": "^18.x.x"

如果不是，那你真的得升级个 der（官方术语：赶紧升 😅）。

React 17 升到 React 18 已经是必经之路，

Suspense、Concurrent、SSR 都已经进入新阶段，不升会拖累整个项目生态。

③ 第三步：开干！升级到 AntD 6

前面两步做完，你的项目基本已经“具备上 6 条件”了。

现在就可以正式开刀：

npm install --save antd@6

或者你爱用的包管理器：

yarn add antd@6

# or

pnpm add antd@6

# or

npm install antd@latest

安装完成后，你的项目就是 AntD 6 正式用户。

④ 第四步：启动项目，处理残留 warning

升级完成以后，重启项目。

你可能会看到一些：

• 类型定义变动 warning


• 某些行为变更 warning


• 某些组件结构调整提示


• mask blur 带来的视觉差异


• 你自己写的样式被 DOM 改动影响

这些属于正常“升级后适配”。

根据提示处理即可。

建议你重点检查以下区域：

✔ 自定义覆盖类名（AntD 6 DOM 有变化）

✔ Modal、Drawer 的 mask 是否出现模糊效果

✔ Table、Form 是否有类型冲突

✔ 已废弃 API 是否仍然使用

✔ 第三方依赖是否引用了 AntD 内部 class

通常处理 1-2 小时就可以全部解决 （ 不解决也行，能跑就行😉）。

⑤ 最终：你就正式吃上了 AntD 6 的“螃蟹”

完成以上步骤后，你就完成了整个升级链路：

• 清理 v5 废弃 API


• 升到 React 18（如果你的项目还没）


• 升到 AntD 6


• 修复升级后剩余 warning

从此以后：

• 你可以用 Masonry 瀑布流


• 你可以用更快的 Tooltip


• 你可以享受 ZeroRuntime


• 你可以用语义化 DOM 更好写主题


• 你的项目正式进入 2025 年的前端栈

一句话：

你是第一个吃螃蟹的人，但这次螃蟹真的不难吃，而且还挺香，哥们已经升级，满嘴流油了。