前端开发
快来分享你的内容吧～
01-04 17:43·后端正式开始前先郑重声明，由于每个前端技术都有自己的应用场景，很多时候没办法完全公平地去比较，所以接下来的排行会带有一定的主观性。本期鱼皮只是希望帮大家学到知识、认识更多的技术。查看全文加油鸭：Vibe Coding 真是太会了！AI 辅助开发改变的不只是效率，更是整个编程思维，未来已来！1026分享
2025-12-21·前端开发
小米题真够难的，我面挂了…
上周五，晚上六点，参加了小米一面，整体时长1.5个小时，算是比较长的吧 面试官看起来比较年轻，刚开始自己的心态也挺轻松，随着面试的进展，心情变的越加的不对劲，怎么问的每一道题都只知道一点，这是知道了自己的打法，专门来拆台来了 （让我自己认识到自己真不专业，基础太差） 问题的答案，我都用一个链接的形式来呈现，相对简单的会做出解释 px em rem vw vh 分别解释一下这几个单位 www.jianshu.com/p/82f02af17…$ padding-top, 10%, 10rem，10vh， 10em 取值逻辑是什么 这个里面有个坑 就是10% ,取的是父容器的宽度的10% em 也有个坑，不一定取的是父级，position会影响这个取值 npm cpm pnpm yarn 介绍一下，各自的优点 esm 和 commonJs 物理像素 逻辑像素 分辨率 像素比 juejin.cn/post/719072…$ 介绍一下flex， 并计算一下 下面的宽度 大致从 flex-direction flex-wrap 说起，说到align-self重点的就是 flex-grow, flex-shrink 这两个的换算 **机会** 顺便吆喝一句，技术大厂 [[前-后端-测试]](https://jsj.top/f/o38ijj) ，待遇和稳定性还不错，感兴趣来~ juejin.cn/post/714287…$ `flex-grow: 1 container: 100px; A:30px; B: 40px; // 计算A和B渲染的真实宽度 flex-shrink: 1; container: 500px; A: 200px; B: 400px; // 计算A和B渲染的真实宽度 ` transform: translateX(100px) rotate(50deg); trabsform: rotate(50deg) translateX(100px); 这两个动画有什么区别，效果是否一样 ` transform: translateX(100px) rotate(50deg); trabsform: rotate(50deg) translateX(100px); 这两个动画有什么区别，效果是否一样 ` 让我想起来另外一道面试题，如何用js写动画，不能出现css的属性，（深势科技一面） 类组件 和 函数式组件，函数式组件有什么优点 问这个问题，面试官主要想了解： 对组件的两种编写模式是否了解 是否具备在合适的场景下选用合适的技术栈的能力。 共同点 他们的实际用途都是一样的，无论是高阶组件还是异步加载，都可以用它们作用基础组件展示 UI。也就是作用组件本身的所有基础功能都是一致的。（类组件可以改为函数组件，函数也可以改为类组件） 不同点 类组件是基于 OOP（面向对象编程），所以它有继承、有属性、有内部状态的管理。 函数组件的根基是 FP，也就是函数式编程。它属于”结构化编程“的一种，与数学函数思想类似。也就是假定输入与输出存在某种特定的映射关系，那么输入一定的情况下，输出必然是确定的。 想较于类组件，函数组件更纯粹、简单、易测试、这是他们本质上的最大不同。 类组件和函数组件有个最经典的问题，就是 this 的问题，类组件中 this 存在一定的模糊性，容易引起错误。函数组件在同一个闭包中，不会有这样的问题。 独有能力 类组件可以通过生命周期包装业务逻辑，这是类组件所”特有的“ sunchang612.github.io/blog/react/… react 类组件 onClick 和 addEventListener 的区别 setState 是同步的还是异步的，什么时候同步 和 异步 github.com/Advanced-Fr… hook组件 虚拟dom， diff, fiber， fiber中schedular 调度的优先级 都有哪些任务，任务的优先级是什么 fiber render阶段 commit 阶段, 哪一个阶段是可以被打断的， commit的阶段能被打断吗 js的eventLoop jsBridege , web端 如何 调用 App的异步任务 > 算法 找出最后一块石头 `function myPrimiseAll(proms) { let i = 0; let length = proms.length; let result = []; let res = []; let rej = []; let fullfulledIndex = 0; let p = new Promise((resolve, reject) => { res = resolve; rej = reject; }); for (let prom of proms) { const index = i; i++; Promise.resolve(prom) .then( (data) => { result[index] = data; fullfulledIndex++; if (fullfulledIndex === length) { res(result); } }, (rej) => { rej(rej); } ) .catch((e) => { rej(e); }); } if (length === 0) { res([]); } return p; } ` 实现lodash 的 set功能 `function set(obj, path, value) { if (!obj || typeof obj !== 'object') { return obj; } const keys = path.split('.'); const lastKey = keys.pop(); let currentObj = obj; for (const key of keys) { if (!currentObj[key] || typeof currentObj[key] !== 'object') { currentObj[key] = {}; } currentObj = currentObj[key]; } currentObj[lastKey] = value; return obj; }` 大家可以看一下题目，对应自己身上是否能全部回答的上来，我是一个菜鸟，回答的很简单 ——转载自：圆心角
React & Next.js官方教你的编程技巧！
# Vercel React & Next.js 最佳实践指南 > **简介**：本文档基于 Vercel 工程团队为 AI 编程助手（Agent）制定的 `react-best-practices` 标准。这套标准将 40 多条工程规则按优先级分类，旨在指导开发者编写默认高性能、健壮的现代 Web 应用。 有没有过工作了好多年，知识方面业务方面懂的很多了，但是编程的技巧没有提高多少，现在好消息来了！ 最近vercel公司发布了一系列skills，其中一个就是教你怎么写react和NextJS的（react-best-practices），vercel是收编了react团队和Next的公司。所以它的skill可以说是官方指导。我把它翻译成了中文。 虽然说skill是指导ai编程的，但是如果你学会了，以后在审阅ai生成的代码时自然知道何为规范标准，最重要的是面试的时候也是一份谈资！ 因为优化项很多，所以我先举例出一些常用的，全部清单放在结尾。 ## 第一部分：关键技术点深度解析 (Deep Dive) 针对下述清单中 10 个较难理解或较为重要的技术点，以下是详细的例子教学解析。 1. ### 单次初始化 (Advanced Init Once) **问题**：在 React 18+ 的 Strict Mode（开发环境）下，Effect 会执行两次，可能导致埋点 SDK 初始化两次或建立两个 WebSocket 连接。 **解决方案**：使用模块级变量或 `useRef` 做标记。 TypeScript ``` import { useEffect, useRef } from 'react'; export function App() { const initialized = useRef(false); useEffect(() => { // 即使 Effect 跑两次，if 内部的代码只跑一次 if (!initialized.current) { Analytics.init({ key: '...' }); // 全局只需一次的逻辑 initialized.current = true; } }, []); } ``` 2. ### Event Handler Refs **问题**：`useEffect` 需要调用外部传入的函数（如 `onMessage`），但该函数经常变化，导致 Effect 频繁重启（断开重连）。 **解决方案**：用 Ref 存函数，打破依赖链。什么意思呢？就是有时候我们为了避免闭包陷阱需要使用到函数的最新值，但是如果用useState去存储的话会导致重复渲染，所以用useRef是个好方法。 TypeScript ``` function Chat({ onMessage }) { // 1. 将最新的函数存入 Ref const onMessageRef = useRef(onMessage); useEffect(() => { onMessageRef.current = onMessage; }); useEffect(() => { const socket = createSocket(); socket.on('msg', (data) => { // 2. 在这里调用 Ref，不需要将 onMessage 加入依赖数组 onMessageRef.current(data); }); // 3. 依赖项很干净，连接稳定 }, []); } ``` 3. ### 交互逻辑移出 Effect (Rerender Event Logic) **原则**：如果是用户点击引起的逻辑，直接写在 `onClick` 里，不要通过 State 触发 Effect。 - ❌ **反面教材**：点击 -> 设置 `isSubmitted(true)` -> 触发 Effect -> 发请求 -> 设置 `isSubmitted(false)`。 - ✅ **最佳实践**：点击 -> `handleClick` -> 发请求。 TypeScript ``` function Form() { // ✅ Good: 逻辑清晰，少一次渲染 function handleSubmit() { api.post('/submit'); } return <button onClick={handleSubmit}>提交</button>; } ``` 4. ### 派生状态 (Derived State) **原则**：**渲染时计算**。减少 `useState` 和 `useEffect` 的滥用。 **坏例子（冗余状态）** ： ``` function BadList({ items }) { const [count, setCount] = useState(0); // 浪费性能：当 items 变了，先渲染一次，运行 Effect，setCount，再渲染一次 useEffect(() => { setCount(items.length); }, [items]); return <div>Count: {count}</div>; } ``` **好例子（直接计算）** ： ``` function GoodList({ items }) { // 渲染时直接算。没有 Effect，没有额外的重渲染。 const count = items.length; return <div>Count: {count}</div>; } ``` 5. ### LocalStorage 版本控制 (Schema Versioning) **问题**：前端发版更新了数据结构，但用户本地存的是旧结构 JSON，导致解析报错白屏。 **解决方案**：存储时带上版本号，读取时校验。 TypeScript ``` const CURRENT_VER = 2; function loadSettings() { const raw = localStorage.getItem('cfg'); const data = JSON.parse(raw); // 版本不匹配，丢弃旧数据，返回默认值 if (data?.version !== CURRENT_VER) { localStorage.removeItem('cfg'); return DEFAULT_SETTINGS; } return data.payload; } ``` 6. ### 被动监听器 (Passive: true) **含义**：告诉浏览器“我承诺不调用 `preventDefault()`”。 **作用**：在移动端，浏览器不需要等待 JS 执行完就能立即滚动页面，极大提升滚动流畅度。 JavaScript ``` // 适用于 scroll, touchstart, touchmove window.addEventListener('scroll', onScroll, { passive: true }); ``` 7. ### Next.js `after()` (Server After) **场景**：Serverless 函数在返回响应后会立即冻结。如果你想在 `return` 之后写日志，可能写不进去。 **用法**：使用 `after()` 延长 Serverless 函数的生命周期，直到任务完成。 TypeScript ``` import { after } from 'next/server'; export async function POST() { const result = await doWork(); // 这里的代码会在响应返回给用户【之后】并在服务器关闭【之前】执行 after(() => { logger.log('Task completed'); }); return Response.json(result); } ``` 8. ### 跨请求缓存 (LRU Cache) **概念**：Node.js 服务端是长期运行的。如果在全局变量存数据且不清理，内存会爆。 **策略**：LRU (Least Recently Used) 是一种“淘汰算法”，当缓存满了，优先删除“最近最少使用”的那条数据。 **注意**：只缓存公共数据（如菜单、配置），**严禁**缓存用户私有数据。 9. ### 桶文件陷阱 (Barrel Files) **概念**：桶文件指包含大量导出的 `index.ts`。 **弊端**： 1. **变慢**：开发环境启动时，Webpack 需要分析 `index.ts` 里的所有导出，即使你只用了一个。 1. **Tree-shaking 失败**：构建工具可能无法确定副作用，导致为了引入一个 Button 而打包了整个组件库。 **对策**：`import { Button } from './components/Button';` (精确路径)。 <!----> 10. ### 推迟 Await (Async Defer Await) **核心**：**并行优于串行**。 - ❌ **串行 (慢)** ： - TypeScript ``` const user = await getUser(); // 等 1s const posts = await getPosts(); // 再等 1s (总耗时 2s) ``` - ✅ **并行 (快)** ： - TypeScript ``` const userPromise = getUser(); // 开始跑 const postsPromise = getPosts(); // 同时开始跑 // 等两个都好了再继续 (总耗时 ~1s) const [user, posts] = await Promise.all([userPromise, postsPromise]); ``` ## 第二部分：最佳实践完整清单 (The Full List) 本清单按 **影响力 (Impact)** 从高到低排序。在进行代码审查 (Code Review) 时，应优先关注高优先级的优化。 11. ### 消除瀑布流加载 (Eliminating Waterfalls) - [关键/CRITICAL] *核心目标：减少网络请求等待时间，提升首屏速度。* - **async-defer-await**: 不要过早 `await`，只在真正需要数据时才等待，让 Promise 在后台预先运行。 - **async-parallel**: 独立的异步操作必须使用 `Promise.all` 并行处理。 - **async-dependencies**: 优化请求依赖链，非依赖请求不应被阻塞。 - **async-api-routes**: 在 API 路由中尽早启动数据库查询等 Promise。 - **async-suspense-boundaries**: 使用 Suspense 流式传输内容，避免阻塞整个页面。 2. ### 包体积优化 (Bundle Size Optimization) - [关键/CRITICAL] *核心目标：减小 JavaScript 体积，加快下载和解析速度。* - **bundle-barrel-imports**: **禁止**从桶文件 (`index.js`) 导入，必须直接从具体文件路径导入。 - **bundle-dynamic-imports**: 对重型组件（图表、地图）使用 `next/dynamic` 或 `React.lazy` 懒加载。 - **bundle-defer-third-party**: 推迟加载非首屏必须的第三方脚本。 - **bundle-preload-intent**: 根据用户意图（如 Hover）预加载资源。 3. ### 服务端性能 (Server-Side Performance) - [高/HIGH] *核心目标：优化 Next.js 服务端资源占用与响应速度。* - **server-action-auth**: Server Actions 必须包含权限校验。 - **server-rsc-props-dupe**: 避免在 RSC Props 中传递重复的大型数据对象。 - **server-cross-request-cache**: 使用 LRU 策略在请求间复用通用数据。 - **server-rsc-serialization**: 仅传递必要数据到客户端，减少序列化开销。 - **server-request-dedup**: 利用 `React.cache` 对同一周期的请求去重。 - **server-after**: 使用 `after()` 处理不阻塞响应的后台任务（日志、统计）。 4. ### 客户端数据获取 (Client-Side Data Fetching) - [中高/MEDIUM-HIGH] - **client-swr-dedup**: 使用 SWR/React Query 处理客户端请求去重。 - **client-event-listeners**: 确保全局事件监听器不重复添加，且在组件卸载时清理。 - **client-passive-event-listeners**: 滚动类事件必须开启 `{ passive: true }`。 - **client-localstorage-schema**: 对本地存储的数据进行版本控制。 5. ### 重渲染优化 (Re-render Optimization) - [中/MEDIUM] *核心目标：减少 React 组件不必要的渲染次数。* - **rerender-derived-state**: 能计算得出的值，绝不设为 State。 - **rerender-event-logic**: 交互逻辑写在事件处理函数中，而非 `useEffect`。 - **rerender-defer-read**: 状态读取下沉到子组件。 - **rerender-no-primitive-memo**: 不要 Memo 简单类型（字符串/数字）。 - **rerender-extract-default**: 提取复杂的默认对象为常量。 - **rerender-narrow-deps**: 精简 `useEffect` 依赖项。 - **rerender-subscribe-derived**: 只订阅状态的一部分。 - **rerender-functional-updates**: 使用 `setState(prev => ...)` 减少依赖。 6. ### 渲染性能 (Rendering Performance) - [中/MEDIUM] - **rendering-list-virtualization**: 长列表使用虚拟滚动。 - **rendering-image-optimization**: 强制使用 Next.js `<Image>` 组件。 - **rendering-font-optimization**: 使用 `next/font`。 7. ### JavaScript 性能 (JavaScript Performance) - [低中/LOW-MEDIUM] - **js-heavy-computation**: 繁重计算移至 Web Worker。 - **js-timers**: 严格管理定时器清理。 8. ### 高级模式 (Advanced Patterns) - [低/LOW] - **advanced-event-handler-refs**: 使用 Ref 存储最新回调以打破依赖链。 - **advanced-init-once**: 确保全局逻辑单次初始化。 - **advanced-use-latest**: 使用自定义 Hook 保持最新引用。 * * * 如果你对清单中的优化项有切身的实践经历，恳求评论区分享。
从夯到拉，锐评 39 个前端技术！
大家好，我是程序员鱼皮。从夯到拉，锐评 39 个前端技术，一口气说完！  之前我做了后端技术的从夯到拉排名，很多同学留言说想看前端版。说实话，刚开始我是拒绝的，因为前端技术实在是太多了、而且更新速度非常快，之前有个学弟还跟我吐槽什么前端娱乐圈之类的，咱也不懂好吧。 但是！既然大家想看，那我就来一期。而且这期我还会评选出唯一的 **前端技术之王**（frontend king），大家可以先猜一猜，会是哪个？我敢说不超过 1% 的同学能猜对。 正式开始前先郑重声明，由于每个前端技术都有自己的应用场景，很多时候没办法完全公平地去比较，所以接下来的排行会带有一定的主观性。本期鱼皮只是希望帮大家学到知识、认识更多的技术。 大家可以在评论区打出自己的评价，看看跟我想的是否一样。 - 视频版 - 前端排行：https://bilibili.com/video/BV11yigBfEkL - 视频版 - 后端排行：https://bilibili.com/video/BV1HiqQBgEoN ## 评价维度 接下来我将从 5 个维度来评价这些前端技术： 1. 实用性：能解决多少实际问题、是否为项目必备 2. 生态成熟度：包括社区活跃度、文档完善度、第三方库丰富度 3. 学习成本：上手难度和学习曲线 4. 开发效率：开发速度和体验 5. 稳定性：版本迭代是否破坏兼容性、出现安全漏洞的频率 作为开发者，我个人最看重的是 **实用性和生态成熟度**。 实用性就不多说了，毕竟技术是用来解决问题或者找工作赚米的。 生态好不仅意味着遇到问题能快速找到解决方案，更重要的是，因为训练数据多、社区案例丰富，AI 生成的代码质量会更高。 **所以再次声明，下面的排名并不代表技术本身的优劣，会具有一定的主观性。** ## 前端技术从夯到拉排行榜 先说说跟样式相关的前端技术。 ### 1、Sass【人上人】 CSS 预处理器，让你用编程的方式写样式。写过原生 CSS 的都知道，一堆重复的颜色值、一层套一层的选择器，维护起来非常头疼。Sass 支持变量、嵌套、混合、继承等高级特性，可以解决这些问题。 Sass 的优点是功能强大、社区成熟，缺点是需要编译，而且现在 CSS 原生也支持变量和嵌套了。考虑到它仍然是很多大型项目的标配，给到 **人上人**。  ### 2、Bootstrap【拉】 Twitter 开源的 UI 框架，提供现成的样式和组件，让你不用从零写 CSS。曾经是前端开发的标配，一套栅格系统打天下. 但是 2025 年了，还在用 Bootstrap 的项目基本都是遗留系统。组件样式过时、定制困难、体积臃肿，React、Vue 当道，谁还用这种全局样式污染的方案？给到 **拉**。  ### 3、Tailwind CSS【夯】 原子化 CSS 框架的代表，快速写样式的神器。它的理念是：不写 CSS 文件，直接在 HTML 里用 class 拼样式。比如 `flex justify-center items-center`，一行搞定居中。 有朋友刚开始可能会觉得这玩意儿丑，class 名字一大串，觉得不就是把 CSS 写到 HTML 里了吗？但是用习惯后真香，能明显提升开发效率；再配合组件化开发，完全不用担心样式冲突。 还有一个加分项，现在很多 AI 工具生成的前端代码，默认都用 Tailwind！像很多朋友好奇为什么 AI 生成的很多界面是蓝紫色？因为 AI 训练时吃了太多使用 Tailwind UI 的网站，而 Tailwind UI 的默认配色就是蓝紫色。 考虑到它对开发效率的巨大提升和 AI 生成界面的巨大贡献，给到 **夯**！  ### 4、Element Plus【人上人】 Vue 框架的主流 UI 组件库，由饿了么团队开发。如果你用 Vue 做中后台系统，那 Element 基本是标配。 优点是组件丰富、文档清晰、国内社区活跃。 缺点是样式偏传统，不太适合 C 端项目，而且有些组件不够灵活。但考虑到国内 Vue 生态的主流地位，Element 是很多前端新人的启蒙组件库，给到 **人上人**。  ### 5、Ant Design【人上人】 蚂蚁金服出品的企业级 UI 组件库，在开发 B 端中后台管理系统方面一手遮天。它不仅组件质量高、设计规范完善，而且生态非常丰富，推出了 Ant Design Pro 脚手架、ProComponents 高级组件、AntV 数据可视化方案，以及最近很火的 Ant Design X AI 组件库。而且同时有 React 和 Vue 版本，我个人非常喜欢用它。 但缺点也很明显，体积大、样式定制麻烦，没有那么适合 C 端系统。考虑到国内 B 端的统治地位，给到 **人上人**。  ### 6、LayUI【NPC】 老牌轻量级 UI 框架，情怀之作。采用原生 JavaScript，不依赖 Vue/React。适合那些不想学现代前端框架、只想快速搭个后台的同学，我大学刚开始学前端的时候就在用。 但是它在组件化时代显得格格不入，整体生态和社区活跃度比不上主流方案，AI 生成代码也不会选择这个 UI 吧，只能给到 **NPC**。  ### 7、Shadcn/UI【人上人】 可能是 2025 年最火的 UI 方案。注意，它不是一个组件库，而是一套 **可复制粘贴的代码集合**。不需要使用 npm 来安装依赖，而是直接把组件代码复制到你的项目里。 好处是极度灵活，代码在你手里，想怎么改就怎么改；缺点是需要自己维护组件代码，版本升级比较麻烦。给到 **人上人**。  接下来聊聊构建工具。 ### 8、Webpack【NPC】 前端工程化的奠基者，模块打包的开山鼻祖。 构建工具的作用是把你写的代码打包、压缩、转换成浏览器能运行的文件。很多年前做前端，Webpack 配置是必修课，什么 loader、plugin、code splitting，面试必问。 虽然它生态成熟、功能强大。但问题是配置文件动辄几百行，你如果学会了 Webpack 配置，就能去应聘配置工程师了。而且热更新慢到怀疑人生，改个代码等半天才生效。开发体验被 Vite 降维打击，正在逐渐被时代淘汰，只能给到 **NPC**。  ### 9、Vite【夯】 新一代构建工具，Webpack 终结者。它用原生 ES Module 实现毫秒级热更新，冷启动速度吊打 Webpack。配置简单、开箱即用，开发体验好到飞起。而且支持各种主流前端框架，已经成为现代前端项目的标配，必须给到 **夯**！  ### 10、Grunt/Gulp【拉】 上古时代的任务运行器，比 Webpack 还老的构建方案。通过配置任务来处理文件压缩、代码编译、合并等操作。 但是现代构建工具早就内置了这些功能，还在用这俩的项目，估计都是几代员工的祖传代码了，给到 **拉中拉**！  接下来聊聊包管理工具。 ### 11、npm【顶级】 前端包管理的祖师爷，帮你安装和管理项目依赖的工具。由于安装 Node.js 就自带 npm，所以 npm 生态特别成熟，几乎所有的 JS 包都会发布到 npm。 但缺点是安装速度慢、node_modules 文件夹动辄几个 G（宇宙中最重的物体）、还有幽灵依赖问题。不过考虑到它是前端开发的核心工具，生态无可替代，给到 **顶级**。  ### 12、pnpm【夯】 性能更高的 npm，目前最高效的包管理工具。它用硬链接和符号链接的方式共享依赖，一个包只存一份，多个项目共用，从而节省空间、安装更快。因此越来越多的项目都在迁移到 pnpm，给到 **夯**！  ### 13、Yarn【NPC】 为了解决 npm 的速度和一致性问题而生，曾经风流一时的包管理工具。像 lock 文件、离线缓存、并行安装，这些概念都是 Yarn 先提出来的。 但是 npm 后来也跟进了这些特性，而 pnpm 在性能上又超越了 Yarn。所以导致现在的 Yarn 处于一个非常尴尬的位置，给到 **NPC**。  ### 14、Bower【拉】 上古时代的前端包管理器，老前辈了。但自从 npm 支持前端包管理、Webpack 统一了模块化方案之后，Bower 就彻底退出历史舞台了。官方都宣布不再维护，给到 **拉**！  接下来聊聊前端工程化相关的技术。 ### 15、TypeScript【夯】 全体起立！ TypeScript 是 JavaScript 的超集，前端大项目的救世主。以前写 JS，变量类型全靠猜，运行时才知道哪里报错。TypeScript 给 JS 加上了类型系统，通过类型安全、IDE 智能提示、编译时检查，解决了 JS 的类型混乱问题。大型项目没有 TypeScript 简直寸步难行。 2025 年 8 月，TypeScript 超越 Python 和 JavaScript，成为 GitHub 上最广泛使用的语言！现在连 AI 生成代码都优先生成 TS。 要说不足之处，就是有一定的学习成本，什么 “类型体操” 对于前端新人来说还是挺头疼的吧，一不留神就变成 AnyScript。作为现代前端的标配，必须给到 **夯**！  ### 16、Prettier【人上人】 代码格式化工具，团队协作神器。它能自动把你的代码按统一规则格式化，保存时自动整理缩进、换行、引号等。不管你喜欢单引号还是双引号，Prettier 说了算，同一个项目的代码就是要整整齐齐。但考虑到不是刚需，给到 **人上人**。  ### 17、ESLint【顶级】 代码规范检查工具，团队协作必备。它能帮你发现潜在的 Bug、统一代码风格、强制使用最佳实践。比如什么未使用的变量、可能的空指针、不规范的写法，ESLint 都能帮你揪出来。 现代前端项目几乎都会配置 ESLint，配合 TypeScript 和 Prettier 使用，能大大提升代码质量，给到 **顶级**。  ### 18、Turborepo【顶级】 现代前端大厂的 Monorepo（巨型仓库）管理神器。 Monorepo 就是把多个项目放在一个代码仓库里统一管理。比如你有官网、管理后台、移动端 App，传统做法是建 3 个仓库，但 Monorepo 就把它们放在一起，共享代码、统一构建。 Turborepo（还有 Nx）能帮你管理这种复杂的项目结构，提供增量构建、智能缓存、任务编排等功能。改了一个包，只重新构建受影响的部分，构建速度甚至可以提升几十倍。 注意，Monorepo 不是必要的，更多的是大厂在采用，给到 **顶级**。  ### 19、qiankun【顶级】 蚂蚁金服开源的微前端框架的扛把子。 微前端就是把一个大型前端应用拆分成多个独立的小应用，每个小应用可以独立开发、独立部署、独立运行，最后由一个主应用把它们整合在一起。 qiankun 提供了应用加载、沙箱隔离、应用通信等核心能力，可以让不同技术栈的项目共存，比如主应用用 React，子应用可以用 Vue、Angular，互不干扰。 适用于大型企业应用、多团队协作和遗留系统改造。缺点是架构复杂度高，调试麻烦，而且性能开销比单体应用大，不是所有项目都需要微前端，给到 **顶级**。  下面重点来了，我们来聊聊前端开发框架。 ### 20、Angular【NPC】 Google 出品的企业级前端框架，大而全的重量级选手。路由、表单、HTTP、状态管理通通内置，开箱即用。原生支持 TypeScript，采用依赖注入、模块化设计，写起来很有 Java 的 Spring 那味儿。 缺点是概念太多、学习成本高、项目启动慢。学 Angular 的时间，都够学完 Vue 和 React 了。 虽然 Angular 的全球市场还行，但在国内的存在感越来越弱了，基本只有外企在用。给到 **NPC**。  ### 21、jQuery【拉】 前端活化石，DOM 操作的老祖宗。每当我看到 `$('.class').click()` 这种写法，都忍不住落下两滴晶莹剔透的小泪珠，满满的回忆杀。 如今随着 React、Vue 这些组件化框架的崛起，以及浏览器原生 API 的完善，jQuery 的优势荡然无存，已经被干成时代的眼泪了。现在除了维护老项目外，基本上没有理由用 jQuery 了。给到 **拉**！  ### 22、Svelte【NPC】 编译型前端框架，性能怪兽。它在编译时把组件转成原生 JavaScript，运行时没有框架开销，包体积小、速度快。 我在 20 年用 Svelte 写过一些 Demo，开发体验还是挺不错的，响应式变量的声明很简洁。但是生态比 React 和 Vue 差了不少，尤其是国内用的更少，想快点儿找前端工作就先别学它了。暂时给到 **NPC**。  ### 23、Vue 3【夯】 接下来终于到了大家期待的 Vue 了，国内最受欢迎的前端框架。它采用 **渐进式设计**，你可以只用它做页面的一小部分，也可以用它搭建完整的单页应用，非常灵活。它的单文件组件和模板语法简单直观；而且生态完善，像 Vite、Pinia、VueUse 这些配套工具支持都很好，官方文档写的也清晰易懂，上手难度比 React 低不少。 在国内找前端工作，不会 Vue 等于少了一半机会，考虑到面向薪资编程，给到 **夯**！  ### 24、React【顶级】 如果说 Vue 是国内老大，那 React 就是全球前端霸主。像组件化思想、虚拟 DOM、单向数据流这些概念都是 React 带火的。 虽然学习难度略大一些（JSX 语法），但我个人更喜欢 React，我们团队的产品也基本都是基于 React 开发。一方面 React 的 Hooks 用起来很爽；另一方面，跟 Vue 比起来，React 全球范围的生态更强。 按理说应该给到 “夯”，但是最近 React 服务端组件曝出了一个严重的远程代码执行漏洞，我们团队好几个项目都中招了，服务器沦为矿机、让我们被迫加班。 考虑到这种全栈化带来的安全风险，我这次只能把 React 降到 **顶级**，不是说 React 不行啊，纯个人情绪好吧。  ### 25、Next.js【顶级】 目前最火的 React 全栈框架，支持服务端渲染（SSR）、静态站点生成（SSG）、API 路由等功能，让前端也能写后端接口。 和它类似的还有 Nuxt.js，这是 Vue 生态的 SSR 首选，国内用的很多。如果你要做 SEO 友好的网站，或者想用前端技术栈搞定整个项目，优先选这两者，给到 **顶级**。  接下来聊聊前端开发的一些工具和库。 ### 26、VitePress【NPC】 Vue 官方出品的文档站生成器，VuePress 的继任者。如果你要搭建技术文档网站，用 Markdown 来写文档，那么 VitePress 的体验很好，主题定制也灵活。Vue 3 和 Vite 的官方文档都在用它。 但使用场景比较窄，主要就是做文档网站，实用性相对有限，给到 **NPC**。  ### 27、Astro【顶级】 最近增长最快的静态站点生成器，它的核心理念是群岛架构：页面默认是静态 HTML，只有需要交互的部分才加载 JS，所以页面加载飞快。 而且 Astro 很灵活，可以同时使用 React、Vue、Svelte 组件，不挑框架。如果你要做博客、文档站、营销页这些内容型网站，Astro 非常合适，像我们团队的剪切助手官网就是用 Astro 生成的。给到 **顶级**。  ### 28、Pinia【人上人】 Vue 3 官方推荐的状态管理库，用来管理组件间共享的数据。相比 Vuex，Pinia 的语法更简洁，TypeScript 支持更好，没有那些 mutations、actions 的繁琐概念，用起来更舒服。 现在 Vue 3 项目标配都是 Pinia，Vuex 基本退休了。给到 **人上人**。  ### 29、Axios【夯】 HTTP 请求库的标配，前后端数据交互必备工具。虽然浏览器有原生的 fetch，但 Axios 的 API 设计更友好，而且支持自动转换 JSON、请求拦截、响应拦截这些功能都帮你封装好了，用起来很方便。 优点是国内外项目都在用，生态成熟，文档完善。缺点是包体积略大，但 5G 时代无伤大雅，再加上请求库本身的重要性，给到 **夯**！  ### 30、ky【NPC】 轻量级 HTTP 请求库（不是骂人的那个 ky）。基于 Fetch API 封装，体积只有 2KB！如果你追求极致的包体积，ky 是个不错的选择。 但知名度和使用率远不如 Axios，国内用的更少，生态也差一些。给到 **NPC**。  ### 31、Lodash【NPC】 JS 工具函数库的老大哥，类似 Java 的 Hutool，帮你封装了像数组操作、对象处理、函数节流防抖等等的常用功能，拿来就用。 听起来很强大对吧？ 但问题是，Lodash 沉寂了整整 5 年，直到最近才更新了一个小版本。而且现在 ES6+ 已经原生支持了很多功能，像 `Array.find`、`Object.assign`、展开运算符等，新项目越来越少主动引入 Lodash 了。属于 “还在用但可以不用，并且不推荐新项目用” 的状态，给到 **NPC**。  接下来聊聊跨端开发框架。 ### 32、Uni-app【顶级】 基于 Vue 的跨端框架，国内小程序开发的神器。它最大的优势是一套代码可以发布到各个平台，像微信小程序、H5、App 全都支持，省了大量重复开发的工作。 优点是应用广泛；缺点是性能不如原生开发，不过这也是跨端开发框架的通病了。给到 **顶级**！  ### 33、Taro【人上人】 京东开源的跨端解决方案，React 技术栈的小程序开发首选。跟 Uni-app 类似，也是一套代码多端运行。 如果你的团队习惯 React，就选 Taro；习惯 Vue，就选 Uni-app。相比 Uni-app，Taro 的市场占有率稍低一些，所以给到 **人上人**。  ### 34、React Native【人上人】 跨平台移动开发的主流选择，跟 Flutter 并称跨平台双雄。用 React 语法写原生 App，一套代码 iOS、Android 都能跑。而且支持热更新，调试很方便，生态也很成熟。 缺点是性能不如纯原生开发，某些复杂动画需要写原生代码。给到 **人上人**。  ### 35、Electron【人上人】 跨平台桌面应用框架。如果你会前端，用 Electron 就能开发桌面应用，一套代码 Windows、Mac、Linux 上都能跑。VS Code、QQ、还有我们的剪切助手软件都是用 Electron 写的。 优点是开发效率高，直接复用前端技术栈，能快速把网页变成桌面应用。缺点是内存占用大、包体积大，一个简单应用动辄上百 M。考虑到它的成熟度，虽然有 Tauri 这些新框架，还是给到 **人上人**。  最后再聊一些有点儿特殊的前端技术。 ### 36、Three.js【人上人】 Web 3D 领域的绝对王者，高薪的敲门砖。让你用 JavaScript 在浏览器里渲染 3D 场景，像元宇宙、数字孪生、可视化大屏这些高大上的项目，基本都离不开 Three.js。 缺点是学习难度很大，需要一定的图形学知识。不过现在有 AI 了，可以直接让 AI 帮你生成复杂的 3D 场景代码，学习成本大大降低。给到 **人上人**。  ### 37、WebAssembly【顶级】 Web 性能的天花板，处理重型计算的幕后英雄。 WebAssembly 是一种可以在浏览器里运行的二进制指令格式，性能接近原生代码。你可以用 C/C++、Rust 等语言写高性能模块，编译成 Wasm，然后在浏览器里跑。它最大的优势就是 **快**，像视频剪辑、图像处理、3D 渲染、游戏引擎这些计算密集型任务，用 Wasm 能提升几十倍性能。 缺点是开发门槛高，而且调试比较麻烦。但随着工具链的完善和 AI 生成代码能力的增强，Wasm 的应用场景会越来越广，给到 **顶级**。  ### 38、CoffeeScript【拉】 等等，这不是 Java 么？ 这是曾经风流一秒的 JavaScript 替代方案，它的理念是用更简洁优雅的语法写代码，然后编译成 JavaScript。但 ES6 出来之后，JS 自己支持了箭头函数、类、模板字符串这些特性，CoffeeScript 瞬间没了存在价值，被 TypeScript 完全取代，给到 **拉**！  ### 39、Vibe Coding【夯爆了】 最后的最后，揭晓我们的前端技术之王、唯一真夯 —— Vibe Coding！ 你猜对了么？ 什么是 Vibe Coding？就是用 AI 辅助编程，你描述需求说人话，AI 帮你写代码。 它不是某个特定的框架或库，而是一种全新的编程范式。它改变的不是某个技术环节，而是整个开发流程。这是近年来前端开发最革命性的变化，没有之一。 虽然 Vibe Coding 不算是前端技术，但是我就问一句：现在哪个前端不用 AI 来写代码？！ 像我现在写代码基本离不开 Cursor 了，开发效率提升 10 倍以上不是吹的。必须 **夯爆了**！  ## 最终排行榜  ## 最后 OK 就分享到这里，如果你们还想看哪些技术的排名，或者你觉得哪个技术的排名不合理，都可以在评论区告诉我哦。我是鱼皮，关注我，带你解锁更多编程和 AI 知识~ ## 更多 💻 编程学习交流：[编程导航](https://www.codefather.cn/) 📃 简历快速制作：[老鱼简历](https://www.laoyujianli.com) ✏️ 面试刷题神器：[面试鸭](https://www.mianshiya.com) 📖 AI 学习指南：[AI 知识库](https://ai.codefather.cn/)
搞懂前端代理：Axios baseURL 与 Vite Proxy 的协作机制
#前端工程化 #网络请求与跨域 #环境配置与部署 #Vite #Axios ### 在搭建前端项目时，我们常会发现 myAxios.ts（请求封装）和 vite.config.ts（构建配置）中似乎都在配置后端地址。为什么myAxios和vite.config都要配置请求地址？能不能只写一个？ ### 这两者虽然看似重复，实则各司其职，**缺一不可**。 ### **1.职责分离** * **myAxios.ts (baseURL)：是"暗号"** 它给所有请求加上统一前缀（如 /api），告诉代码：“凡是带这个前缀的，都是发给后端的”。 生效范围：开发环境 + 生产环境 * **vite.config.ts (Proxy)：是"翻译官"** 它拦截带有“暗号”的请求，将其转发到真实的后端地址（如 localhost:8080），解决浏览器的同源策略 （跨域）限制 生效范围：仅限开发环境 * * * **2.流量流向对比** * **开发环境 (Dev)：** Axios 发送 '/api/user' ➔ Vite 服务器拦截 ➔ 代理转发到 'http://localhost:8080/user' * **生产环境 (Prod)：** Axios 发送 '/api/user' ➔ Nginx/后端服务器直接接收 (此时没有 Vite 了) * * * **3.为什么不能只写一个：** * 如果只在 Axios 写死 'http://localhost:8080' ， 生产环境会报错（地址变了），且开发环境会有跨域问题。 * 如果只在 Vite 配代理：Axios 不加前缀，Vite 就不知道哪些请求需要被代理转发。 以此确保： * 开发环境可以正常工作（通过代理解决跨域） * 生产环境可以正确部署（直接请求后端） * 代码的可维护性（清晰的职责分离） * * * **4.代码实例：** ```typescript // 开发和生产都用这个相对路径 const myAxios = axios.create({ baseURL: '/api' // 统一前缀，不写死 IP }); ``` ```typescript // 只在开发环境使用 server: { proxy: { '/api': {// 捕获前缀 target: 'http://localhost:8080',// 真实后端地址 changeOrigin: true } } } ```