从0到1学前端：避开新手必踩的3个坑
很多人学前端第一步就走错了方向。我见过太多人抱着《JavaScript高级程序设计》啃半年，结果连个按钮点击事件都写不利索；也见过有人跟风学Vue、React，框架API背了一堆，让他用原生JS实现个轮播图却两眼发直。其实前端入门的核心不是「学多少」，而是「怎么学」。
坑1：只学理论不动手，等于白学
我带过一个实习生小周，刚来的时候天天抱着网课看，HTML、CSS、JS的基础视频刷了个遍，笔记记了厚厚一本。结果第二周让他仿个公司官网的静态页面，他对着PSD文件发呆——不知道怎么把设计稿的px换算成代码里的尺寸，盒模型的margin和padding调来调去还是不对，最后熬了个通宵只写出个歪歪扭扭的导航栏。后来我让他停掉所有视频，每天用Figma扒一个简单页面（比如小红书的首页卡片、B站的视频列表），从HTML结构开始写，再调CSS样式，不用JS，先把静态页面做「像」。三周后他不仅能独立还原设计稿，还自己琢磨出了Flexbox和Grid的用法，跟我说：「原来CSS里『justify-content:center』不是随便加的，得先知道父容器是什么布局！」
你看，前端是「做出来」的，不是「看出来」的。我的 是：学HTML就写5个不同的页面结构（个人简历、商品列表、新闻详情、表单页面、导航栏），学CSS就用这5个页面练手，尝试改颜色、调布局、加动画，不用追求完美，先保证代码能跑起来。等你能独立做出3个完整静态页，再学JS也不晚——这时候你会发现，JS里的「获取DOM元素」「绑定事件」，都是你做页面时实实在在遇到的问题，学起来自然有方向。
坑2：框架学一堆，基础忘光光
这是我见过最多人踩的坑：刚学完HTML/CSS/JS的基础，就急着学Vue、React、Angular，今天跟着教程搭个Vue项目，明天看React Hooks视频，结果问他「什么是虚拟DOM」「Diff算法怎么工作的」，他支支吾吾说不上来；让他用原生JS写个简单的TodoList，他反而要查半天语法。
我自己刚工作那会也犯过这错。2018年React正火，我跟风学了两周，觉得「原生JS太low了」，写什么都想套框架。结果有次公司做一个简单的活动页，要求兼容IE8（那时候很多企业客户还在用），框架根本跑不起来，只能用原生JS写。我对着IE8的控制台报错抓耳挠腮——不知道addEventListener在IE8里要用attachEvent，Array.prototype.forEach在IE8里不支持，最后还是老同事丢给我一个polyfill.js文件才搞定。这件事让我彻底明白：框架是工具，基础是内功。没有内功，再好的工具也用不明白。
MDN官方文档里有句话我特别认同：「在学习任何框架之前，先掌握HTML、CSS和JavaScript的核心概念。框架会变，但这些基础不会。」所以我的 是：前端入门1年内，把80%的时间花在基础上——HTML语义化（比如什么时候用
而不是
坑3：忽视兼容性，上线就翻车
上个月帮朋友改他公司的官网，打开一看——在Chrome里好好的导航栏，到了Safari上菜单直接掉下来；按钮的圆角在IE11里变成了直角；更离谱的是，他用了CSS的backdrop-filter: blur(10px)做毛玻璃效果，结果在Firefox里完全不显示，变成了一块实心色块。问他怎么没测试，他说「我以为现在浏览器都差不多了，没想到差别这么大」。
这就是典型的「只在自己电脑上测试」的问题。前端开发的「兼容性」不是玄学，而是有规律可循的。我现在做项目，都会用Can I use（https://caniuse.com/，记得加上nofollow标签）这个网站查属性兼容性——输入你想用的CSS属性或JS API，它会告诉你哪些浏览器支持，哪些需要加前缀，哪些完全不支持。比如flex-wrap: wrap在IE10里部分支持，需要加-ms-flex-wrap: wrap；fetch API在IE里完全不支持，需要用axios库或者polyfill来兼容。
刚开始不用追求兼容所有浏览器，先记住「三横一竖」原则：横屏（PC端）兼容Chrome、Firefox、Edge最新版，竖屏（移动端）兼容iOS Safari和Android Chrome最新版，这覆盖了90%以上的用户。遇到兼容性问题，先查Can I use，再用工具解决——下面这个表格里的工具，是我处理兼容性时最常用的，你可以根据项目需求选：
| 工具名称 | 核心作用 | 使用难度 | 适用场景 |
|---|---|---|---|
| Autoprefixer | 自动给CSS属性加浏览器前缀（如-webkit-、-moz-） | 简单（配好后自动运行） | 所有需要兼容老浏览器的CSS代码 |
| Babel | 将ES6+语法转成ES5，兼容老浏览器 | 中等（需配置preset） | 使用了箭头函数、let/const等新语法的JS代码 |
| PostCSS | 通过插件转换CSS，支持变量、嵌套等高级特性 | 中等（需选插件） | 需要写模块化、可维护的CSS代码 |
| Modernizr | 检测浏览器特性，根据结果加载不同样式/脚本 | 简单（引入即用） | 需要针对不支持某些特性的浏览器做降级处理 |
比如你想用CSS Grid布局，查Can I use发现IE11只支持旧语法，这时候可以用PostCSS的postcss-grid-kiss插件，自动把新语法转成IE11能识别的旧语法，不用自己手写两套代码。这些工具现在都能集成到Webpack、Vite等构建工具里，配置一次就能自动运行，完全不用每次手动处理。
3个实战技巧：让你写的代码既好看又好用
学会了基础，做出了能用的页面，接下来就要追求「好用」——代码好维护、页面加载快、用户体验好。这部分分享3个我在项目中反复验证过的技巧，简单易上手，效果立竿见影。
技巧1：用「代码规范工具」让团队少吵架
去年带一个5人小团队做项目，刚开始大家各写各的：有人用单引号，有人用双引号；有人喜欢写var，有人坚持用let/const；还有人缩进用4个空格，有人用2个空格。结果合并代码时天天冲突，改个bug要先花半小时对齐格式，团队效率低得要命。后来我引入了ESLint+Prettier，统一了代码规范，两周后冲突减少了80%，连最挑剔的后端同事都说「你们前端的代码终于能看了」。
代码规范不是「个人喜好」，而是「团队效率工具」。你可能觉得「我自己写的代码自己看得懂就行」，但实际项目中，代码是给团队看的，更是给「 的你」看的——三个月后回头改自己写的代码，要是没有规范，你可能比看别人的代码还费劲。
具体怎么做？我 你这样配置：
var、强制用箭头函数、检查未定义的变量等。初始化命令是npm init @eslint/config，跟着提示选「浏览器」「CommonJS或ES Modules」「Vue/React（如果用框架的话）」，它会自动生成配置文件。 .prettierrc文件，写上简单配置：{ "singleQuote": true, "semi": false, "tabWidth": 2 }（单引号、不加分号、2个空格缩进）。 eslint-config-prettier和eslint-plugin-prettier：这两个插件能让ESLint和Prettier不打架——ESLint负责语法，Prettier负责格式，各司其职。 配置好后，在VS Code里装个「ESLint」插件，打开「保存时自动修复」（文件→首选项→设置，搜索「editor.codeActionsOnSave」，添加"source.fixAll.eslint": true），以后写代码只要按Ctrl+S，格式自动对齐，语法错误自动修复。我自己的项目现在都这么配，不管是自己写还是和团队合作，再也不用为格式吵架了。
技巧2：用「Chrome DevTools」揪出性能瓶颈
你有没有遇到过这种情况：页面打开半天加载不出来，或者滚动的时候一卡一卡的？很多人觉得「性能优化是高级工程师的事」，其实用Chrome的开发者工具，新手也能找到问题在哪。
我上个月优化过一个公司官网，首屏加载要6秒多，老板催着改。打开Chrome DevTools（按F12或Ctrl+Shift+I），点「Performance」选项卡，点左上角的录制按钮，刷新页面，等加载完成后停止录制——结果一目了然：一张背景图居然有5MB大，加载用了3秒；还有个JS文件在页面渲染的时候执行了一堆DOM操作，导致页面卡顿。
具体怎么用DevTools分析性能？记住三个核心面板：
splitChunks插件拆分，把不常用的代码延迟加载。 requestIdleCallback在浏览器空闲时运行，避免卡顿。 我现在做项目，上线前必跑一遍Lighthouse，目标是性能分至少80分以上。前阵子帮一个朋友优化个人博客，按Lighthouse的 压缩了图片、延迟加载了评论区JS，首屏加载从4.2秒降到1.8秒，他跟我说「现在谷歌搜索排名都往前挪了两名」。
技巧3：用「语义化HTML」提升用户体验
最后一个技巧，说起来简单，但90%的新手都没做到——用「语义化HTML标签」。你可能觉得「用
