VSCode插件推荐：提升开发效率的10个必备神器

VSCode插件推荐：提升开发效率的10个必备神器

别再把插件栏塞得满满当当了，然后转头抱怨“怎么装了这么多还是没效率”。真相是，每天真能帮你省下五分钟以上的，往往就那么几个。关键在于，它们得能精准解决你手头的具体问题。

Path Intellisense 补全别名路径却失效

你是不是也遇到过这种情况：明明配置了路径别名 @/components/Button，但敲下 @/ 后，编辑器却一片寂静，毫无提示？先别急着怀疑插件，问题很可能出在配置的读取环节。

• 首先，确认你的 jsconfig.json 或 tsconfig.json 文件确实躺在项目根目录里。里面的 baseUrl 值必须严格设置为 "."，写成 "./" 或者留空都可能让它“找不到北”。
• 其次，paths 配置项的 key 必须使用通配符格式，比如 "@/*"。如果只写了 "@" 或 "@/"，路径匹配就会失败。
• 修改完配置文件后，有个关键动作不能忘：执行 Developer: Reload Window 命令。仅仅重启编辑器或者重新打开文件，有时并不足以让新配置生效。
• 额外提一句，如果你用的是 Vite + Vue 技术栈，可能还需要在设置里加上 "volar.ignoreProjectWarning": true，以防 Volar 插件在某些情况下干扰路径解析。

Volar 替换 Vetur 后类型提示仍丢失

升级到 Volar 后，defineProps 的泛型推导一片空白，ref 的 .value 没有类型提示，computed 的返回值被标红——这些迹象通常表明，Vetur 的“幽灵”还在后台徘徊，或者 Volar 并未成功接管语言服务。

• 第一步，请务必手动卸载 Vetur 插件。VS Code 不会自动禁用那些已经停止维护的插件，它们可能仍在后台运行。
• 接着，看一眼编辑器右下角的状态栏。点击那个显示 TypeScript 或 Vue 版本的小标识，确认当前的语言模式是 Vue (Volar)，而不是旧的 Vue (Vetur)。
• 如果项目里存在 shims-vue.d.ts 这类类型声明文件，检查一下它是否手动引入了旧版的 Vue 类型声明。这种操作会与 Volar 的类型合并机制产生冲突。
• 当遇到 Cannot find name 'defineProps' 这类错误时，优先去检查 tsconfig.json 中的 compilerOptions.types 数组，确保包含了 "vue"。

Prettier 和 ESLint 保存后代码反复“打架”

按一次保存，代码里的单引号变成了双引号；再按一次，又变了回来。这种来回“拉锯战”，其实是 Prettier 和 ESLint 在争夺代码格式的控制权。

• 治本的方法是，在 .eslintrc.js 配置文件的 extends 数组末尾，加上 "eslint-config-prettier"。这个配置包的作用，就是显式关闭 ESLint 中所有与代码格式（如缩进、引号）相关的规则，把排版工作完全交给 Prettier。
• 在 VS Code 的设置里，明确指定默认的格式化工具："editor.defaultFormatter": "esbenp.prettier-vscode"。
• 同时，禁用 ESLint 的自动格式化能力，只让它负责代码质量检查："eslint.format.enable": false。
• 最后，注意团队协作。.prettierrc 里的配置不应与团队规范背道而驰。比如团队约定使用分号，而你个人配置了 "semi": false，这无异于埋下了一个协作的“地雷”。

Reactjs code snippets 缩写总被原生片段覆盖

兴致勃勃地敲下 us 然后按下 Tab，满心期待出现 useState 片段，结果跳出来的却是古老的 "use strict"。这不是插件失灵，而是 VS Code 默认把内置的代码片段放在了更高的优先级。

• 解决思路很直接：在设置中搜索 editor.snippetSuggestions，将其值改为 top。这样，自定义的代码片段就会优先出现在建议列表的顶部。
• 另一个更彻底的策略是“绕道而行”：进入插件的设置，修改默认的触发缩写。例如，把 us 改成 rus（代表 react useState），把 ue 改成 rua（代表 react useEffect），从而完全避开原生片段的关键词。
• 此外，可以考虑关闭插件自带的 “Auto Import” 功能。这个功能有时会“热心过头”，在不合适的文件里自动添加 import 语句，尤其在 TypeScript 项目中，如果类型尚未导出，就会直接导致报错。

说到底，插件的价值不在于数量，而在于精准。评判一个插件该不该留，不妨问自己一个问题：“昨天我遇到的那个具体卡点，如果没装它，我需要多花几分钟、多点击几次鼠标、多修改几处代码才能解决？” 别盲目相信安装量，相信你自己最真实的开发体验。