谈谈你对前端工程化的理解
查看详情
定义：在前端开发和运维过程中，以降低成本、提高效率、保障质量为目的，通过一系列规范、工具、流程（分别对应软件工程中的方法、工具和过程）作为手段的实践体系。
- 工具化：针对业务场景集成所需的前端框架、组件库等，提供模块化、包管理、代码检查、预编译、编译打包部署等能力。
- 规范化：面向完成需求的整个研发流程，梳理需求管理、视觉交互设计、评审、开发、联调、测试验收、上线部署和质量监控等相关的规范，进一步建设规范来约束研发过程中的不确定性。
- 平台化：将支撑研发的有关工具和系统聚合起来。
谈谈你对DevOps的理解
查看详情
DevOps是一种文化和实践方法，旨在通过增强开发（Development）和运维（Operations）团队之间的协作与沟通，实现软件开发和IT运维的自动化和持续交付。DevOps不仅仅是工具和技术的集合，更是一种理念和工作方式，强调跨部门的协作、快速交付高质量软件以及持续改进。
- 核心哲学：CAMS 模型 DevOps 的本质可以概括为四个关键词：
- Culture (文化)： 开发和运维共享责任，目标一致（快速交付高质量产品）。
- Automation (自动化)： 凡是能自动化的，绝不手动。
- Measurement (度量)： 没有数据就没有改进。监控性能、错误率、部署频率。
- Sharing (共享)： 经验、工具和文档在团队间完全透明。
- DevOps 的三大关键支柱
- CI/CD (持续集成与持续部署)
- CI (Continuous Integration)： 开发者频繁地将代码合并到主分支。每次合并都会触发自动构建和自动测试（Unit/Integration Tests），确保新代码没有破坏原有功能。
- CD (Continuous Delivery/Deployment)： 自动化地将经过测试的代码部署到预发环境或生产环境。在 React 19 项目中，这通常意味着通过 GitHub Actions 自动完成 build、压缩、并上传到 S3/CDN。
- 基础设施即代码 (IaC)
- 像管理代码一样管理服务器和网络配置。
- 作为前端，我们现在接触的 Serverless (Vercel, AWS Lambda) 或是 Docker 容器化 都是 IaC 的体现。我们通过 Dockerfile 或配置文件定义运行环境，确保“在我的机器上能跑，在服务器上也能跑”。
- 可观测性 (Observability)
- 部署完成后，工作才刚刚开始。
- 我们需要通过 Sentry 监控前端报错，通过 Lighthouse/Web Vitals 监控线上性能数据。DevOps 要求我们将这些反馈闭环回开发环节。
png8, png24, png32的区别是什么
查看详情
- png8颜色数最多256色（8bit=2^8），只支持一位透明（要么透明要么不透明），文件体积小，适合色彩简单的纯色图标或线条图
- png24颜色数多（24bit = R 8bit + G 8bit + B 8bit），只有不透明，文件比png8大，画质好，适合做照片或复杂的渐变图
- png32颜色数多（R 8bit + G 8bit + B 8bit + A 8bit），支持256级透明度，文件最大，画质最好，适合做有阴影平滑和透明渐变的图片
简单说说你对pnpm的理解
查看详情
pnpm是一个高性能的javascript包管理工具。它具有以下特点：
- 磁盘复用率率
- 它不会像npm/yarn把依赖复制到项目中
- 它会将下载的包存储到全局store，然后用硬连接指向项目，极大的减少了磁盘的占用
- 安装速度快
- 因为包安装过的包存在于全局store中，因此不用重复下载或者解压，直接链接即可
- 多个项目可共享同一版本的依赖
- 依赖隔离更严格
- 默认不用把子依赖项提升到顶层node_modules，避免的幽灵依赖问题
- 对mono repo友好
- 提供了内置的workspace功能
pnpm中的硬连接和软连接（符号连接）是什么？
查看详情
- 硬连接：在pnpm中依赖项会下载到一个全局的store中，然后pnpm在项目中的直接依赖使用硬连接指过去。
- 软连接：pnpm为了保证依赖树的层级结构，会在node_modules中功过软连接构件子依赖的关系。
npm、yarn、和pnpm的优缺点是什么？
查看详情
- npm
- 优点
- node.js默认自带，开箱即用
- npm 开始支持workspace
- 缺点
- 安装速度慢
- node_modules 体积大
- 幽灵依赖问题
- 优点
- yarn
- 优点
- 解决了npm安装速度慢的问题
- 支持缓存和并发
- 支持mono repo
- 缺点
- yarn v1停止维护
- yarn v2改动过大，兼容性差，配置复杂，迁移成本高
- 优点
- pnpm
- 优点
- 节省磁盘空间
- 安装速度快
- 没有幽灵依赖问题
- 内置mono repo
- 缺点
- windows上可能存在链接问题
- 部分老旧工具不支持
- 优点
简单说说你对函数式编程的理解，有何优缺点？
查看详情
函数式编程的核心思想：
- 纯函数，输入相同必定输出也相同，无副作用
- 不可变数据，变量一旦赋值，修改需创建新的对象
- 高阶函数，函数可以作为参数或其它函数的返回值
- 函数组合，通过组合小的函数可以构建复杂的逻辑
- 声明式，更关注做什么
优缺点：
- 优点
- 可读性强，逻辑清晰
- 易于测试和调试
- 支持函数的组合、链式操作
- 缺点
- 对于大规模复杂的状态管理需要借助额外工具
- 在性能敏感场景会因频繁生成新对象而增加额外的开销
- 递归陷阱
eslint和prettier的区别是什么？
查看详情
| 工具 | 主要作用 | 关注点 | 举例 |
|---|---|---|---|
| ESLint | 检查代码质量、发现潜在问题 | 语法逻辑正确性、最佳实践 | 禁止未使用变量、检测未定义变量、避免副作用 |
| Prettier | 统一代码格式 | 代码排版样式 | 缩进、引号、分号、换行、括号位置等 |
graphQL是什么？它适合在什么场景使用？它和rest API相比优缺点是什么？
查看详情
GraphQL 是由 Facebook 提出的 API 查询语言（Query Language for APIs），用来替代传统的 REST API。REST 是“你给我什么，我拿什么”；GraphQL 是“我想要什么，我自己定义”。
适用场景 | 场景 | 为什么适合 | | ----------------------------- | --------------------- | | 前后端分离项目 | 前端可自定义所需数据结构，避免多余字段传输 | | 复杂关联数据（如社交、内容流） | 一次请求就能拿到嵌套数据 | | 多端共用 API（Web、App、小程序） | 不同端只取自己需要的字段 | | 快速迭代 / Schema 稳定但需求变化快的系统 | 无需频繁改后端接口 |
优缺点 | 对比点 | GraphQL | REST | | ----------- | ---------------------------------- | ------------------------ | | 数据获取 | 一次请求可拿多资源 | 每个资源独立请求 | | 字段控制 | 客户端决定返回字段 | 服务端固定返回结构 | | 网络效率 | 可避免 over-fetch / under-fetch | 容易多请求或冗余数据 | | 接口扩展性 | Schema 可扩展，不影响老客户端 | 增加字段需改接口或版本号 | | 缓存机制 | 较复杂，需要自定义 | HTTP 缓存天然支持 | | 错误处理 | 统一返回结构（data + errors） | 每个 API 各自定义 | | 调试体验 | 有 GraphiQL / Apollo Studio 等可视化工具 | 普通接口调试（Postman） | | 学习成本 | 较高，需理解 Schema/Resolver 概念 | 低，HTTP 请求即可 | | 文件上传/分页 | 需额外处理（Upload scalar, cursor-based） | 直接支持 multipart/form-data |
前端工程化的演进趋势？
查看详情
Rust化：
- Biome：面向 Web 项目的工具链，旨在提供维护所需的功能。它提供格式化工具和代码检查工具，可通过命令行界面 (CLI) 和本地脚本 (LSP) 使用。
- Rspack：基于 Rust 的快速 JavaScript 打包工具，具有与 webpack 兼容的 API
Vite 与 Webpack 的选型考虑？
查看详情
| 维度 | Webpack | Vite |
|---|---|---|
| 启动速度 | 慢（尤其大型项目） | 极速（利用 ES 模块按需加载） |
| 热更新 HMR | 较慢 | 几乎即时 |
| 生态成熟度 | 极高，插件丰富 | 新兴但插件生态快速发展 |
| 构建产物 | 优化成熟，适合复杂业务 | 构建快，适合中大型或模块化项目，复杂优化依赖插件 |
| 学习成本 | 配置复杂，需要掌握 Loader/Plugin | 零配置即可用，学习曲线平滑 |
| 跨端支持 | Web 为主，RN 需额外工具 | Web 为主，但可结合插件支持更多场景 |
browserslist是什么？它是如何工作的？
查看详情
- 什么是 Browserslist？ Browserslist 是一个在不同的前端工具之间共享目标浏览器范围的配置。
在没有它之前，你可能需要在 Babel 里写一遍兼容浏览器，在 Autoprefixer 里又写一遍。Browserslist 出现后，你只需要维护一份配置，以下工具都会自动读取它：
- Babel (通过 @babel/preset-env 决定转换哪些 JS 语法)
- Autoprefixer (决定 CSS 是否添加 -webkit- 等前缀)
- Stylelint (检查 CSS 兼容性)
- ESLint (检查 JS 兼容性)
- 它是如何工作的？ Browserslist 背后依赖于 Can I Use 的数据。
- 它会读取你定义的查询语句。
- 内部通过 browserslist 库将其解析为具体的浏览器版本列表（如 chrome 124, firefox 120...）。
- Babel 等工具拿到这个列表，去查对应的插件（如 plugin-transform-arrow-functions），如果列表中有浏览器不支持箭头函数，Babel 就会执行转换。