eslint插件必须启用并配合项目级配置文件（如.eslintrc.js）才能真正发挥作用，仅安装插件无配置则默认规则极简、几乎不报错；需搭配eslint:recommended基础规则及对应框架插件（如plugin:vue/vue3-recommended）、typescript支持（@typescript-eslint/eslint-plugin），并在vs code中启用eslint.enable及source.fixall.eslint自动修复，同时与prettier分工协作——prettier负责格式，eslint专注逻辑与安全规范，并通过eslint-config-prettier禁用eslint中格式相关规则以避免冲突。

ESLint 插件必须启用，否则所谓“高质量”只是自我感觉良好。它不是锦上添花的装饰，而是把潜在错误、不安全模式和风格混乱直接标红在编辑器里——你写完 if (x = 1)，它立刻报 Assignment in conditional expression，而不是等运行时崩溃才暴露问题。

ESLint 要配对项目配置才能真正起作用

单独安装插件没用，它只负责“显示”，不负责“判断”。必须有项目级配置文件（如 .eslintrc.js 或 .eslintrc.cjs）告诉它：哪些规则启用、哪些框架要适配、是否允许 console、要不要检查未使用的变量。

• 没配置文件时，ESLint 默认只跑极简规则集，几乎不报错
• 推荐从 eslint:recommended 基础起步，再叠加 plugin:react/recommended 或 plugin:vue/vue3-recommended
• 若项目用 TypeScript，必须加 @typescript-eslint/eslint-plugin，否则 any 类型、接口定义等全被忽略
• VS Code 设置中需开启 eslint.enable 和 editor.codeActionsOnSave → source.fixAll.eslint，否则保存不自动修复

Prettier 和 ESLint 不是二选一，而是分工协作

很多人以为装了 Prettier 就不用 ESLint，或反过来。其实它们干的是不同事：prettier 只管格式（缩进、换行、引号），eslint 管逻辑与规范（变量作用域、重复定义、危险操作）。强行让 ESLint 去做格式检查，会和团队其他成员的 Prettier 配置冲突，导致每次保存来回打架。

Comprehensive Three.js 3D graphics reference

详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。

下载

• 必须安装 eslint-config-prettier 关闭 ESLint 中所有和格式相关的规则
• VS Code 的 editor.defaultFormatter 设为 esbenp.prettier-vscode，而非 ESLint 插件
• 关键配置项 prettier.semi、prettier.singleQuote 必须和团队 .prettierrc 文件一致，否则 PR 会被 CI 拒绝
• 不要勾选 “Format on save” 同时启用两个插件的自动格式化，只留 Prettier 执行这一步

JavaScript (ES6) code snippets 是最被低估的效率杠杆

不是“写得快”才叫高效，而是“少打错、少查文档、少打断思路”才算。比如输入 clg + Tab，自动生成 console.log(); 并把光标停在括号内；输入 imr + Tab，生成 import React from 'react'; —— 这些不是炫技，是把大脑从记忆语法细节中解放出来，专注逻辑本身。

• 确认插件启用后，在 JS/TS 文件中输入前缀（如 af 对应箭头函数）能触发提示
• React 开发者务必检查插件是否支持 JSX 片段（如 rfc 生成函数组件）
• 避免和 TabNine 或 Copilot 的补全重叠：关闭这些 AI 工具对 snippet 类型的干扰（设 tabnine.experimentalAutoImports 为 false）
• 别依赖片段掩盖基础薄弱：知道 clg 是什么很好，但更要清楚 console.table() 或 debugger 在什么场景下更合适

真正卡住质量提升的，往往不是缺功能，而是配置没对齐、规则没落地、习惯没固化。一个没配 .eslintrc 的 ESLint，和没装它没区别；一个没关掉 ESLint 格式规则的 Prettier，只会制造保存时的无限循环。工具链越成熟，越要抠细节。