前端工程师要学的前端技术

三年前我面试一个自称“五年经验”的候选人，他简历上写着精通Vue和React。工程我让他手写一个debounce函数，师学术他愣了两分钟，前端然后掏出手机开始查。工程最后他打开了一个GitHub仓库，师学术那是前端他自己写的工具库——里面确实有debounce，但代码是工程从Stack Overflow复制来的，连注释都没删。师学术

前端这行当最坑的前端地方在于：工具链更新速度远超你的学习速度。你刚把Webpack配置玩明白，工程Vite已经成了默认选项；你刚学会用Redux管理状态，师学术Zustand和Jotai又冒出来了。前端但别慌，工程真正要死磕的师学术从来不是某个具体框架，而是那些底层且稳定的东西。

JavaScript本身才是地基。 原型链、闭包、事件循环、异步编程——这些玩意儿不会因为框架迭代而过时。我见过太多人只会用await，却说不清Promise的微任务队列怎么运作。结果遇到一个诡异的竞态条件，调试三天三夜，最后发现是setTimeout和微任务的执行顺序搞错了。ES6+的新语法当然要学，但更重要的是理解语言设计的初衷。比如Proxy为什么能替代Object.defineProperty？因为前者能拦截更多操作，包括属性删除和in操作符——这在写响应式系统时是质的区别。

浏览器API是你的第二语言。 别只盯着框架文档看，打开MDN，把Fetch、IntersectionObserver、ResizeObserver、Web Worker这些原生能力摸透。我有个同事，做图片懒加载时非要引一个第三方库，结果那个库内部就是用了loading="lazy"属性——原生就支持的东西，何必多此一举？还有性能优化，很多人一上来就上CDN、搞代码分割，但最简单的content-visibility: auto就能让长页面渲染快一倍，知道这个的人却很少。

工程化不是装个脚手架就完事。 你要理解构建工具到底在干嘛。为什么打包出来的代码有那么多__webpack_require__？为什么Tree Shaking有时候失效？因为这些工具的本质是“代码转换”，不是魔法。我建议你亲手写一个简易的打包器，几十行代码那种，就能彻底搞懂模块依赖是怎么解析的。CSS也一样，别只会用Tailwind，得知道@layer的优先级规则，不然项目一大，样式冲突能让你崩溃。

TypeScript现在不是可选项，是默认项。 但学它的正确姿势不是背类型体操，而是理解类型系统如何帮你表达业务约束。比如type User = { id: string; name: string; role: 'admin' | 'user' }——这比写一堆注释管用多了。我见过最蠢的代码是全部用any，然后抱怨TS难用。类型是给代码画边界，不是给你添堵的。

最后说点实际的：别只学前端，稍微懂点后端和数据库。 因为你要联调接口，至少得知道status code是干嘛的，SQL注入是怎么回事。我面试时会问候选人“如果后端返回的字段命名是下划线风格，你怎么处理？”——能答出用映射层转换的人，比直接JSON.parse然后到处用user_name的人强十倍。

前端技术栈看着五花八门，核心就几条线：语言（JS/TS）、浏览器（DOM/API）、工程化（构建/部署）、协作（Git/代码规范）。把这四条线打扎实，框架换个皮你也能快速上手。工具会过时，但底层逻辑不会。那些天天追新的人，反而最容易焦虑——因为永远追不完。

本文地址：http://www.79wt.cn/news/526d1999454.html