ESLint 与 eslint-config-prettier 协同可统一团队 JS 风格，关键在于用 eslint-config-prettier 关闭 ESLint 中与 Prettier 冲突的格式规则（如 semi、quotes），并确保其 extends 配置置于最后；团队共用且提交 .eslintrc.js 和 .prettierrc，启用 formatOnSave 而非 formatOnType，并统一 printWidth 等基础参数。
ESLint + eslint-config-prettier 统一代码规范
团队里每个人写 JS 的风格不一致，console.log 到处飞、分号用不用全凭心情、箭头函数参数括号写不写——这些不是“个人习惯”，是协作时的隐性冲突点。ESLint 能强制统一，但关键在配置方式。
- 必须用
eslint-config-prettier关闭所有与 Prettier 冲突的格式类规则（比如semi、quotes），否则保存时 ESLint 自动 fix 和 Prettier 格式化会互相打架 -
extends顺序很重要：Prettier 的 config 必须放在最后，例如['airbnb', 'prettier']，否则前面的规则会覆盖掉它 - 团队共用同一份
.eslintrc.js，且提交进 Git；不要只靠本地 settings.json 配置，否则新人拉代码后 lint 报错一堆却不知为何
Prettier 保存即格式化，但得关掉 auto-fix on type
很多人开 editor.formatOnType，结果敲个 if 就自动补全加换行缩进，打断思路。真正该开的是 editor.formatOnSave，配合 ESLint 的 --fix 在 commit 前跑一次更稳妥。
-
prettier.semi: false和prettier.singleQuote: true这类基础项必须写进项目根目录的.prettierrc，而不是只存在 VSCode 设置里 - 如果项目用了 TypeScript，确保
prettier.plugins包含prettier-plugin-tslint或@trivago/prettier-plugin-sort-imports（按需），否则 import 排序不会生效 - 注意
prettier.printWidth设为 80 或 100？团队得提前对齐——过宽导致 diff 冗长，过窄又强迫拆行，建议 100 是当前主流平衡点
GitLens 显式暴露协作上下文
光看代码不知道谁改的、为什么改、是不是临时注释没删——GitLens 把这些信息直接贴在行尾或侧边栏，比翻 Git log 快十倍。
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 启用
gitlens.codeLens.enabled后，每行代码右侧显示最近一次修改的作者和时间；鼠标悬停能看到完整 commit message -
gitlens.hovers.enabled打开后，在变量/函数名上悬停就能看到它的首次引入 commit 和后续变更历史 - 别忽略
gitlens.advanced.messages，设为false可关闭烦人的右下角提示，专注代码本身
Auto Import 降低 TS 模块导入门槛
TypeScript 项目里，手写 import { useState } from 'react' 不难，但每次都要查路径、拼文件名、记默认导出还是命名导出——容易出错，也拖慢节奏。
立即学习“前端免费学习笔记（深入）”；
- 插件默认只对
.ts和.tsx生效，如果项目有.d.ts类型声明文件，需手动加到auto-import.fileExtensions配置中 - 遇到
Cannot find module 'xxx'却能正常运行？大概率是node_modules没被索引，检查auto-import.exclude是否误删了node_modules - 它不处理相对路径别名（如
@/components），这类映射必须由jsconfig.json或tsconfig.json的compilerOptions.paths定义好，插件才认得
.prettierrc 的仓库，靠个人 settings.json 拉起来，永远无法保证新成员写出的代码和其他人一样。 
