面试官考察的是你是否建立效率闭环:识别重复劳动、代码质量敏感度、协作意识;需结合场景说明插件作用,如eslint发现漏删console、prettier统一格式避免冲突,gitlens定位bug引入时间,path intellisense配合jsconfig路径别名生效。

面试官问“你用过哪些 VSCode 插件”,其实是在考什么
不是让你背插件名,而是考察你是否真正在日常开发中建立过效率闭环:有没有主动识别重复劳动、有没有对代码质量有基本敏感度、有没有协作意识(比如格式统一、提交规范)。答错的典型是只列名字不讲场景,比如“我装了 ESLint”,却不说明它怎么帮你发现 console.log 漏删、怎么和 prettier 配合避免团队格式冲突。
ESLint + Prettier 协同配置为什么总出问题
这是高频踩坑点。两者定位不同:ESLint 检查逻辑和风格(如变量未使用、== 误用),Prettier 只管格式(缩进、引号、换行)。冲突常发生在:
-
eslint-config-prettier没装或没启用,导致 ESLint 规则和 Prettier 格式化互相打架 -
"editor.formatOnSave": true开了,但默认 formatter 没设成esbenp.prettier-vscode,结果保存时格式化失效 -
.eslintrc.js里写了"semi": "off",但.prettierrc没配"semi": false,保存后分号又冒出来
实操建议:项目根目录放 .prettierrc 和 .eslintrc.js,在 settings.json 中明确指定 "editor.defaultFormatter": "esbenp.prettier-vscode",并确保 eslint 插件启用 eslint.format.enable。
为什么 GitLens 是前端面试里的“加分项”
它暴露的是你是否习惯从代码变更上下文理解业务。面试官可能追问:“你用 GitLens 查过什么?” 正确回答不是“看谁改的”,而是:
- 定位某段异常逻辑的引入时间,结合 commit message 理解当时的业务意图
- 快速对比两个分支的同一文件差异,确认重构是否遗漏了某处调用
- 右键某行选 “Blame Annotated” 查看历史修改链,判断某个魔法数字是不是临时 hack
注意:不要只说“我装了”,要带出具体动作。比如“上个项目有个状态同步 bug,我用 GitLens 发现是上周某次合并漏掉了 useEffect 的依赖数组更新”。
Path Intellisense 和 Auto Rename Tag 这类“小插件”为什么值得提
它们反映的是你对开发细节的掌控力。比如:
-
Path Intellisense能避免手敲路径出错,尤其在 monorepo 里跨包引用时,import { foo } from '../../../utils'容易少写一个../; -
Auto Rename Tag修改<div class="card"></div>为<section class="card"></section>时,自动同步闭合标签,防止 DOM 结构错乱; - 如果项目用了别名(如
@/components),得确认插件是否支持jsconfig.json或tsconfig.json里的compilerOptions.paths配置。
真正容易被忽略的是:这些插件不是装完就生效。比如 Path Intellisense 在 TypeScript 项目里,必须配合 jsconfig.json 的 "baseUrl" 和 "paths" 才能正确解析别名路径——这点很多人根本没配,却还说“插件没用”。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











