extensions.json是唯一可靠方式，需置于.vscode/extensions.json，含"recommendations"字段及标准publisher.name格式插件id，仅首次打开工作区时触发推荐横幅。
怎么让团队成员打开项目就自动启用统一插件集
VS Code 本身不强制同步插件，但可通过 .vscode/extensions.json 文件声明推荐插件，触发编辑器弹窗提示安装。这不是“自动安装”，而是标准化引导——关键在于把插件列表当作项目配置的一部分来维护。
常见错误是只在 README 里写“请安装 XXX 插件”，结果新人漏装 eslint 导致提交大量格式错误，或没装 vetur 就直接改 .vue 文件，语法高亮和类型检查全失效。
- 在项目根目录新建
.vscode/extensions.json，内容示例：
{
"recommendations": [
"esbenp.prettier-vscode",
"octref.vetur",
"dbaeumer.vscode-eslint",
"formulahendry.auto-rename-tag"
]
}
- 确保该文件被纳入 Git 提交（不要加进
.gitignore） - 团队需约定：新成员首次打开工作区后，点击弹出的 “Install Recommended Extensions” 按钮，而非跳过
- 注意：
extensions.json不会覆盖用户已禁用的插件，也不会重装已卸载插件——它只起提示作用
为什么 ESLint + Prettier 组合总在保存时冲突
典型现象是：保存后代码被 prettier 格式化了，但紧接着 eslint 又标红一堆“Expected indentation of X spaces”，或者 eslint --fix 把引号改回双引号，而 prettier 又强行改成单引号。
根本原因是两者规则重叠且未对齐。Prettier 负责格式（空格、换行、引号），ESLint 负责逻辑与风格（变量命名、无用表达式、no-console）。它们不该互相覆盖。
- 必须安装
eslint-config-prettier并在.eslintrc.js的extends中靠后引入，它会关闭所有与 Prettier 冲突的 ESLint 格式类规则 - VS Code 设置中只启用一个格式化器：
"editor.defaultFormatter": "esbenp.prettier-vscode"，并关闭eslint的自动修复（即不设editor.codeActionsOnSave中的source.fixAll.eslint） - 真正生效的流程是：保存 → Prettier 格式化 → ESLint 仅做静态检查（报错/警告），不参与格式操作
Live Server 和 Debugger for Chrome 怎么避免端口/路径踩坑
新人常遇到：点 Go Live 启动了 http://127.0.0.1:5500，但 launch.json 里配的是 "url": "http://localhost:3000"，断点完全不命中；或者 webRoot 指向 ${workspaceFolder}/src，实际构建产物在 dist/ 下，源码映射失败。
-
Live Server是纯静态服务，适合纯 HTML/CSS/JS 原生开发；Vue/React 项目应优先用框架 CLI 自带的 dev server（如npm run serve），它自带 HMR 和 Source Map -
Debugger for Chrome的webRoot必须指向**源码所在目录**（不是dist），否则断点无法关联到原始 .vue 或 .tsx 文件 - 若用 Vite 或 Vue CLI，
launch.json中应配"url": "http://localhost:5173"（Vite 默认端口）或"url": "http://localhost:8080"（Vue CLI），且确认服务已手动启动 - 多个服务共存时，用
liveServer.settings.port在settings.json中显式指定端口，避免和后端或 mock 服务冲突
GitLens 和 Live Share 在协作中容易被低估的细节
GitLens 显示某行作者和上次修改时间看似简单，但若项目没规范 commit message（比如全写 “fix bug”），这些信息就失去意义；Live Share 共享会话时，如果共享方本地没装 vetur 或 eslint，对方看到的代码就是纯文本——没有语法校验、没有组件属性提示，协作效率直接打半折。
- GitLens 依赖高质量的 Git 历史，建议团队统一使用 Conventional Commits 规范（
feat:、fix:、chore:），否则 blame 信息无法支撑有效追溯 - Live Share 默认不共享插件，但可勾选 “Share extensions” 选项——不过要注意：被邀请方仍需自行安装对应插件才能获得完整功能，共享只是“通知+跳转安装页”
- 更实际的做法是：把
extensions.json和.editorconfig一起纳入项目，再配合团队文档说明“协作前必做三件事”：拉取最新代码、安装推荐插件、运行npm install
协作生态不是装一堆插件就成，而是让每个插件的行为边界清晰、触发条件明确、失败反馈可查。最常被忽略的，其实是人对工具链一致性的预期管理——比如谁负责更新 extensions.json？插件版本要不要锁死？这些问题比技术本身更影响长期协作质量。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
