讲个真实情况35岁的前端不是在改简历就是在改简历的路上。这两年我见了不少同龄人React、Vue 玩得滚瓜烂熟八股文背得比面试官还溜结果一开口薪资预期对面就沉默了。问题不在技术在于你能做的活儿一个27岁、会用 AI 辅助开发的年轻人也能做而且他要价还比你低。内卷的本质是差异化消失了而不是你的技术不够好。我当时的判断很简单得找一个跟“普通前端”有明显区隔、而且需求还在涨的方向。挑来挑去选了 Three.js WebGL 这条线也就是常说的Web 3D可视化方向。这篇是系列第一篇重点聊聊我做 SWOT 分析的过程以及一套踩过坑之后沉淀下来的落地学习路径给同样在焦虑里挣扎的朋友一个参考。先说清楚Three.js 不是银弹转过去也不等于立刻高薪。但它的确把“前端”和“数字孪生、智慧城市、工业互联网、产品3D配置器”这些高预算场景重新连接了起来。我从决定转型到做出第一版像样的作品集用了大概四个月之后入职一家做数字孪生平台的公司薪资涨幅超过三成。整个过程里踩过不少坑尤其是贴图不显示、模型发黑、摄像机运镜效果出不来这类问题几乎每个人都躲不掉。这篇文章不打算给你灌鸡汤只讲一个老前端在转型路上做的事、做的取舍以及每一步背后的原因。1. 为什么在35岁这个节点选择Three.js先回到一个根本问题35岁前端真正的困境是什么是学习能力下降吗不是。是对业务的理解跟不上吗也不是。最核心的问题在于可替代性变高了。以前一个前端要负责兼容IE、处理复杂交互、自己封装组件库这是有门槛的。现在呢AI能生成页面、低代码平台能拖出后台、组件库越来越完善普通增删改查页面确实不需要那么多资深前端了。那资深前端的价值体现在哪只能是技术深度的壁垒。Three.js 恰好具备这种壁垒它要求你懂三维数学、懂图形学基础、懂着色器、懂性能优化这些不是背一两个月的八股文就能拿下的也不是 AI 随随便便就能替你写对的。再说需求端。这两年数字孪生的概念从 PPT 走向落地智慧园区、智慧工厂、城市可视化、水利大屏每一个都需要在网页上展示三维场景。加上国产化替代的趋势越来越明显很多过去用桌面端软件实现的场景现在都要求用 Web 技术重写。我看到的机会正是这个——市场缺少的并不是会写页面的人而是能把工业数据、设备模型、地理信息放进浏览器、用 Three.js 做成交互式三维应用的人。还有一点非常关键这个方向离业务更近。普通前端改个按钮、调个布局你是很难证明自己价值的。但一个 Three.js 做的数字孪生项目客户看到的是直观的三维场景是肉眼可见的交付成果汇报的时候也能拿出很惊艳的 demo。你在这个链条里的位置从“写页面的”变成了“做可视化核心模块的”话语权完全不一样。我把这个判断写进了自己的转型文档里最开始也犹豫过是不是学 WebGPU 更前沿是不是直接转 Unity、UE 做元宇宙更彻底最后都否掉了。原因很现实Three.js 还是 JavaScript 生态前端基础不用扔它能跑的终端最广浏览器打开就能用WebGPU 还在快速演进想完全吃透还不成熟先用 Three.js 站住脚是最稳的路径。2. SWOT分析35前端转Three.js的真实评估SWOT 最忌讳的就是写得像自我安慰。我一开始列优势的时候差点把自己骗了后来逼着自己每一条都找反例、找证据才得到一个相对客观的结论。下面这个表格就是当时评估的结果后面我再逐条解释。维度关键点我的真实判断优势JavaScript功底扎实、组件化思想成熟、交互审美在线、懂业务落地保底能力能让我快速进入 Three.js 开发劣势图形数学底子差、WebGL底层原理不深入、没有3D建模经验必须用最短路径补否则会卡在进阶环节机会数字孪生/智慧城市/工业互联网项目增多、3D可视化人才缺口明显时间窗口存在但需要作品集证明威胁AI降低入门职业门槛、其他方向程序员也在转图形、项目周期不确定需要做差异化不是会Three.js而是能解决性能与工程化问题说优势。干了十来年前端最值钱的不是框架 API 记得多熟而是两点一是对浏览器渲染机制的理解二是对交互细节的敏感。这两点在 Three.js 开发里太好用了。Three.js 本质还是在 canvas 里画东西但动画流畅度、帧率、内存占用这些跟浏览器底层息息相关。一个从后端转过来的人做管理后台还行做实时渲染项目会非常痛苦。你过去在那堆老旧业务系统里调过的性能问题、摸过的内存泄漏排查经验全都能迁移过来。组件化思想也是刚需——Three.js 项目里如果不用组件化思路去拆场景、拆交互模块代码量一大就崩。再说劣势这块必须正视。线性代数、矩阵变换、点积叉积这些大学里学过的东西早还给老师了。我第一次写自定义着色器的时候看着 GLSL 代码里那些 mat4、vec3整个人是懵的。但后来发现Three.js 帮我们封装了绝大多数的数学操作你要写业务级的应用真正需要手工推导矩阵的机会并不多。你需要的是建立空间想象力知道相机在哪个方向、模型朝哪边、绕哪个轴旋转。这块我的办法是笨办法——拿实际项目练拖一个正方体出来自己调参数看坐标怎么变化。练上一个月体感自然就有了。建模不用学精但最好能看得懂 glTF 文件的导出选项、知道怎么用 Blender 把模型减面导出这些在工程协作里特别常用。机会这块我盯着三类项目在看。第一类是数字孪生尤其是有 IoT、物联网数据接入的项目需要把设备状态实时映射到三维场景里第二类是产品展示类电商、家居、汽车行业的3D在线配置器用户需要能旋转、换色、组装产品第三类是数据可视化大屏虽然不是纯3D但一定会用到三维元素。这三类有一个共同点客户愿意花钱而且对效果的要求高不是随便一个会 Vue 的人能顶上的。威胁也要说透。AI 生产力工具确实在压缩低端页面开发的需求但反过来想它也在降低我做 Three.js 项目时查文档、写模板代码的成本。以前写一个轨道控制器、调一个阴影参数可能要看半天文档现在直接问 AI 反而效率翻倍。真正的威胁是转行窗口不是永久的等大量人都意识到这个方向并涌入之后红利就会变薄。所以行动要快不要等学完完美了再投简历。我当时的策略是边学边做一个完整作品做到一半就把进度页面挂到简历上用反馈反推学习节奏。3. 落地学习路径四个月从入门到可求职学习路径这part容易写得假大空我只说我自己验证过的节奏。整体分四个阶段基础补课、核心上手、实战进阶、求职准备。每天保证两到三小时周末全天投入不是一口气激情学完而是稳定分配精力。3.1 第一阶段WebGL基础与数学感官重建很多人直接跳过 WebGL 学 Three.js这是我能理解但不太推荐的做法。你确实可以不用懂 WebGL 就拖出几个几何体但一遇到渲染不对、性能卡顿、模型发黑这些问题你就像盲人摸象只能靠猜。所以我花了大约三周时间做了这些事把 Canvas 2D 到 WebGL 的演进路径重新走了一遍理解为什么需要着色器、为什么要有顶点数据和片段数据。看了一遍 Three.js 官方手册里关于渲染器、相机的说明配合教程理解了视锥体、正交投影与透视投影的区别。补了矩阵和向量的基本概念重点搞懂平移、旋转、缩放这三个基础变换在矩阵里大概长什么样。没有死磕全部推导目标是看到 Matrix4 时不慌。做了一堆小实验在原生 WebGL 里画一个三角形、一个正方形体会顶点着色器到像素屏幕的管线过程。三周之后的效果是我再看 Three.js 报错信息不会觉得那是天书了。比如材质报“normal”相关问题我能本能地想到法线贴图到底干了什么事。提示不要花超过一个月去学原生 WebGL它是铺垫不是目标。核心是建立概念不是成为图形学专家。真正的工作里你写的大多数业务代码仍然是 Three.js 层的。3.2 第二阶段Three.js 核心能力拆解与掌握这个阶段最忌讳的是只会照着教程敲代码。我的策略是按“最小闭环”拆解场景、相机、渲染器这三板斧先打通然后逐个击破几何体、材质、灯光、模型加载、动画与交互。每一步都问自己一个问题它解决的是什么需求比如动画循环本质上就是让浏览器在每一帧重新绘制画面你需要用 requestAnimationFrame还要学会用时钟对象控制速度而不是简单地在循环里改 rotation。我给自己定了几个目标拆解表每天对着表检查进度模块需要掌握的要点检验标准场景与相机透视相机参数含义、相机位置与 lookAt 的关系能从不同视角观察一个立方体几何体与网格BufferGeometry 结构、常见几何体参数能用几何体拼出小房子、树木等组合物体材质与灯光基础材质、标准材质、环境光/平行光/点光源能调出真实感较强的金属质感纹理与贴图UV 贴图概念、TextureLoader 加载、颜色空间给立方体贴上正确的图片不出现发黑、错位模型加载glTF/GLB 格式、Draco 压缩、外部模型导入常用库加载一个外部模型并让它动起来动画系统缓动动画、关键帧、动画混合实现一个简单的开门/旋转动画交互控制Raycaster 射线拾取、OrbitControls 轨道控制点击模型弹窗并显示模型信息这里有一个我特别想强调的细节不要只学绘制要学会“点击拾取”。数字孪生项目里最核心的交互就是点击一个设备、看到它的实时数据。你如果只会渲染一个大场景不会做射线检测和事件绑定那离真实项目还差一大截。Raycaster 的用法不复杂但排错很折磨人。你要理解它是从相机位置发出一条射线穿过鼠标所在位置跟场景中的网格求交。一旦模型层级嵌套很深数组里的命中项顺序就会变代码里需要取哪个对象很多人栽在这里。3.3 第三阶段实战项目驱动积累可展示作品第四个月是最关键的实战月。我给自己定下三个必须完成的作品难度逐级递增。第一个是个人名片级的小场景一个旋转的几何体组合搭配自定义的背景色和光照。第二个是室内场景漫游加载一个从网上下载的 glTF 房间模型用键盘 WASD 控制相机走动碰到墙壁时做简单碰撞检测。第三个是数字孪生小项目模拟一个智慧园区用 BoxGeometry 拼出几栋建筑加上轨道控制器、点击弹窗显示楼宇信息、一个跟随时间的简易光照变化。第三个作品的费用不低为了找个好看的表现场景我搜集了不少 CC0 协议的模型资源也试着自己用 Blender 摆了几个简单物体。这个过程让我理解了一个重要概念Three.js 代码只是工程的一部分内容生产同样重要。真实项目里你需要跟建模师配合你要能判断模型面数是否合理、贴图尺寸是否过大、有没有必要用纹理压缩。3.4 第四阶段作品集的包装与求职准备作品集不是把三个 demo 链接丢给面试官就行而是要像做项目复盘一样讲清楚背景、难点、方案、效果。我的做法是为每个作品写了一个技术说明页包括核心思路、关键代码片段、性能数据比如帧率稳定在 60fps、模型顶点数量控制在多少、踩过的坑。面试官最常问的“你在这个项目里遇到过什么困难”就是靠这些记录撑起来的。我还把每一个作品都部署到可公开访问的地址保证移动端和 PC 端都能打开控制台没有报错。不要忽视部署这件事一个打不开的作品集比没有作品集还糟糕。部署时注意选一个国内访问稳定的托管平台同时把首屏加载体积做小毕竟面试官是在浏览器里打开你的作品的转圈超过十秒基本就劝退了。4. 实操核心环节细节从最基础的渲染框架到项目级坑解决法这个部分我把最常见、也最影响项目体验的几个核心环节拆开讲全部是我在实践里反复试错得来的细节。4.1 搭建最小渲染环境与摄像机效果先说初始化的代码骨架。用 Vite 建一个项目安装 Three.js 之后核心代码只有三行逻辑建场景、建相机、建渲染器。但实际写的时候有非常多的坑比如渲染器要追加到页面里尺寸要跟随窗口窗口变化后要重新设置宽高比否则画面会拉伸或模糊。我一开始就忘了处理 resize 事件导出作品后在一台宽屏显示器上看到被压扁的模型非常尴尬。import * as THREE from three; import { OrbitControls } from three/addons/controls/OrbitControls.js; const scene new THREE.Scene(); const camera new THREE.PerspectiveCamera(45, window.innerWidth / window.innerHeight, 0.1, 1000); camera.position.set(5, 5, 5); camera.lookAt(0, 0, 0); const renderer new THREE.WebGLRenderer({ antialias: true }); renderer.setSize(window.innerWidth, window.innerHeight); document.body.appendChild(renderer.domElement); const controls new OrbitControls(camera, renderer.domElement); controls.enableDamping true; function animate() { requestAnimationFrame(animate); controls.update(); renderer.render(scene, camera); } animate(); window.addEventListener(resize, () { camera.aspect window.innerWidth / window.innerHeight; camera.updateProjectionMatrix(); renderer.setSize(window.innerWidth, window.innerHeight); });关于摄像机我特别想聊一个关键词正方体摄像机效果。这个词我第一次是在一个作品需求里看到的当时不理解后来明白了——它说的其实是 Six-Sided 纹理映射或立方体环境映射也就是通过立方体六个面的相机视角来捕捉环境再做成反射或全景效果。如果你要做全景看房、环境反射这类效果本质上要理解 CubeCamera 的用法在场景中心放一个 CubeCamera渲染六个方向到立方纹理上然后再把这张纹理赋给物体材质作为 envMap。实际做的时候不是光贴代码就够。你要了解环境贴图的 RGBE/EXR 格式、颜色空间是不是 linear处理不好反射面就会发暗或者颜色怪异。我第一次做的时候金属质感发黑排查了一下午最后发现是环境贴图没有正确声明纹理颜色空间。这个坑在贴图章节我再展开说。4.2 贴图加载为什么贴图开始不显示“three.js 贴图开始不显示”是我在搜索记录里见到最多的问题自己第一次也踩了。贴图不显示的常见原因有几类网络加载失败、路径错误、跨域限制、纹理还没加载完成就开始渲染、颜色空间不对导致发黑。我的排查顺序是先看控制台有没有 404 或跨域报错再用网络面板确认贴图是否加载完成。如果文件加载没问题但物体还是白色或黑色就要考虑是不是材质没有设置 map 属性或者 UV 坐标不对。一个很隐蔽的坑是你给 MeshBasicMaterial 设置了 map但贴图是一张 PNG 且带透明通道渲染时没有开启 transparent 属性结果透明区域显示成黑块。const textureLoader new THREE.TextureLoader(); textureLoader.load(/textures/box.jpg, (texture) { texture.colorSpace THREE.SRGBColorSpace; const material new THREE.MeshBasicMaterial({ map: texture }); mesh.material material; });注意这里设置colorSpace THREE.SRGBColorSpace这是 Three.js 渲染画面偏暗/偏亮、整体色差的一个重要原因。早期版本里很多人习惯用texture.encoding THREE.sRGBEncoding新版已经改成colorSpace。我建议把官方文档的迁移指南读一遍否则网上搜到的老代码会让你怀疑人生。4.3 模型加载与共享序列化的进阶话题项目做多了就会发现模型加载不只是GLTFLoader.load这么简单。有几个工程化的坑必须提前考虑。第一是模型太大需要一个加载进度条否则用户以为页面卡死了。第二是多个模型重复使用比如园区里有十栋结构相同的建筑最好做共享几何体和材质不要加载十份。在这个基础上进阶一点的技术是共享与序列化。这个在热词里也出现了——“three.js 共享 序列化”。我可以简单聊聊我的用法当你在后台拖几个场景、想要把它们合并成一个展示项目时就需要把场景里对象的变换、材质、可见性等信息序列化为 JSON等前端拿到之后再用 Three.js 反序列化重建。Three.js 官方提供了一个SceneUtils相关的工具集也支持把 BufferGeometry 转成 JSON但我的实际体验是几何体序列化很容易材质序列化是难点尤其是自定义 ShaderMaterial几乎没法通用序列化。我的解决方案是核心数据只保存场景对象的 transform 和 metadata几何体和材质通过预定义的资源映射表去匹配而不是全量序列化。这样既避免 JSON 过大也规避了图片/着色器代码序列化不靠谱的问题。这个思路在做“多场景切换”“方案保存与回放”时非常有用面试聊到架构设计时也是加分项。// 序列化一个对象的基本变换 const serialized { name: mesh.name, position: mesh.position.toArray(), quaternion: mesh.quaternion.toArray(), scale: mesh.scale.toArray(), visible: mesh.visible, userData: mesh.userData, };4.4 性能优化从能跑到跑得流畅性能优化是 Three.js 面试必问也是项目成败的关键。我在前期做作品时一上来就往场景里塞了几十个模型帧率直接掉到 25fps画面一卡一卡。后来排查主要问题在于 draw call 数量太多。每渲染一个网格就是一次 draw call几十个网格就有几十次浏览器压力很大。优化的方法由浅入深先能用InstancedMesh做大量相同几何体的渲染一个场景里一百个路灯如果每个都是一个独立 Mesh就是一百次 draw call用 InstancedMesh 之后依然是一次 draw call性能提升非常明显。其次是合并几何体把静态且材质相同的物体合并成一个BufferGeometry但这个操作的代价是失去对单个物体的控制适合用于完全静态的装饰。再往后就是 LOD 策略根据相机距离切换高模低模以及限制阴影贴图的大小这都属于经典图形学范围。还有一个很容易忽略的优化点及时销毁资源。单页应用里切换场景时如果只是把 Mesh 从场景里 remove但不调用geometry.dispose()和material.dispose()内存泄漏会越来越严重。数字孪生项目通常需要反复切换楼宇层级这个习惯必须养成否则页面跑半小时后就开始卡顿甚至白屏。4.5 与 Vue/React 工程化项目集成Three.js 本身是命令式 API把它塞进 Vue/React 时最大的矛盾点是生命周期与渲染循环的融合。我见过不少同事把 Three.js 场景写成一个全局单例组件卸载的时候忘了清理渲染循环导致页面之间切换变得非常占内存。我用 Vue 的经验是封装成组件在 mounted 里初始化场景在 onBeforeUnmount 里停止动画循环并销毁 rendereronMounted(() { initThree(); animate () { renderer.render(scene, camera); animationFrameId requestAnimationFrame(animate); }; animate(); }); onBeforeUnmount(() { cancelAnimationFrame(animationFrameId); renderer.dispose(); scene.traverse((obj) { if (obj.geometry) obj.geometry.dispose(); if (obj.material) { obj.material.dispose(); } }); });React 生态里更推荐用react-three/fiber它的理念是声明式地描述 Three.js 场景组件思想很契合 React 用户。但注意它是对 Three.js 的封装不要指望完全绕开原生 API。我在学习时是先会用原生 Three.js 写一遍再迁移到 fiber这样出问题时能明确是哪一层的 bug不会两眼一抹黑。5. 常见问题与排查技巧实录这里放一份我自己整理的速查表。每一个问题都是我在作品开发中被真实卡住过的建议收藏遇到对应场景直接搜。现象可能原因排查与解决画布全黑/不显示相机朝向不对、场景无灯光、物体在视锥体外先确认相机 lookAt 位置再临时添加一个高亮光照或调试用 MeshBasicMaterial模型发黑光照不够、材质缺少 envMap、法线错误添加环境光与方向光必要时设置材质 envMapIntensity贴图不显示资源路径错误、跨域问题、纹理加载未完成打开控制台看报错用图片元素单测链接加载完成后回调里赋材质透明贴图黑边没有设置透明、深度写入问题材质 transparent true必要时 depthWrite false画面卡顿draw call过多、几何体面数过高、阴影过大看 Performance 面板统计 draw call用 InstancedMesh 或合并几何体点击不触发事件Raycaster 命中层级理解不对打印 intersect 数组确认 object.name注意事件绑定目标应该是可交互对象模型闪烁深度冲突z-fighting把相近的两个面拉开微小距离或调整相机远近裁剪面旋转动画速度不一致直接加在帧循环里依赖帧率用 THREE.Clock 或 delta 时间来计算旋转角度除了表格里的问题我再分享两个排查思路。第一个是分而治之当你怀疑是材质还是光照导致的显示问题时最快的方法是换材质。把标准材质换成 BasicMaterial不受光照影响如果模型正常显示说明问题出在光照或法线如果还是黑的说明问题出在几何本身或相机。这个办法帮我筛掉了至少一半的疑难杂症。第二个是“数值打印大法”。Three.js 里很多东西是对象直接在控制台打印某个 Mesh 的 position、rotation、scale、visible往往能立刻发现是不是某个属性被意外改掉。有一次模型突然斜着长排查半天发现是之前测试时给 scale 设了一个负数模型在 X 轴上被镜像了自己根本看不出来打印数值才发现。不要觉得这些方法笨调试效率最高往往就是这种最朴素的手段。6. 简历、面试与谈薪让转型能被市场认可技术学完只是第一步。我见过太多人Three.js demo 做得不错但一到简历和面试环节就弱势最后只能拿到初级待遇。这里有几条非常实用的策略是我自己验证过有效的。简历上不要写“熟悉 Three.js”要写“掌握 Three.js能独立完成数字孪生场景搭建、模型加载优化、动画交互与性能调优项目落地于 XX 场景”。每一条都对应具体能力和场景而不是泛泛的一句“了解”。项目经历部分不只要写“我做了什么”还要写“我为什么这样做”和“效果如何”。比如你在项目里用 InstancedMesh 优化了渲染写了场景帧率从 25fps 提升到 60fps这就是一个有说服力的量化结果。面试准备要分三个层次。第一层是基础概念比如渲染管线、相机投影、坐标系、材质类型这些必须烂熟于心。第二层是工程化问题比如怎么跟 Vue/React 集成、怎样管理内存泄漏、如何拆分大场景。第三层是开放设计题比如“如果给你一个园区建模需求你会怎么设计数据结构和加载方案”这类题没有标准答案考的是思考路径。我当时被问到过的一个类似问题是“多人协作的同一个场景如何避免冲突”这个问题让我想到了要往序列化方向去准备实际工作中确实用到了。谈薪时不要只盯着基础薪资要看项目类型和团队技术氛围。一个还在用 jQuery 做管理后台的团队突然要你带 Three.js大概率是接了一个临时外包项目这就未必适合长期发展。反而应该关注团队有没有持续的数字孪生、可视化产品线有的话才是你沉淀技术壁垒的地方。薪资涨幅多少取决于你上一份工作的基准但方向和平台比薪资更影响你未来三年。另外面试过程中不要害怕暴露“工作年限长却转行”的短板。35不是劣势经验本身有价值只是你要把价值翻译成对方听得懂的语言。你过去那些跨部门沟通、复杂项目推进、线上故障处理经验在 3D 可视化项目里同样需要。年轻程序员可能更会写 Shader但你更清楚一个项目从 0 到 1 需要经历哪些坑这是你的护城河。最后再提一个转行期间容易被忽略的事情保持输出。学 Three.js 的过程中我记录了很多笔记、写过踩坑复盘有些发到了技术社区面试时居然有面试官提过我写的帖子。这不是偶然——你在学习过程中的思考轨迹本身就是你学习能力和技术理解的证明。就算没有流量整理笔记也会逼着你把“好像懂了”变成“真的懂了”这个价值在后续合作里会被持续放大。我个人在带教新同学时最看重的反而不是他现在会多少 API而是遇到一个没见到的报错时他愿不愿意从原理出发去拆解。Three.js 的学习曲线虽然陡但它的反馈是极其直观的你改一个参数画面立刻变你是能看到自己在进步的。这是我认为它适合有经验但迷茫的前端去深耕的原因。方向对了剩下的无非是每天推进一点等时间给出答案。