VSCode插件通过配置固化编码习惯：Prettier需开启formatOnSave并配合.prettierrc；ESLint须启用eslint.validate支持vue等语言；Auto Rename Tag和Path Intellisense需手动配置activationOnLanguage和jsconfig.json以支持Vue/JSX及~别名。
VSCode 本身不“生成”编码习惯，但能通过插件把已有习惯固化、执行、约束和反馈——真正起作用的不是插件本身，而是你配置它的方式和坚持使用的节奏。
Clang-Format / Prettier 怎么让格式习惯自动生效
它们不是教你怎么写代码，而是把你选好的规则（比如 IndentWidth 设为 4、UseTab 设为 false）变成每次保存时的强制动作。
- 必须在设置里开启
"editor.formatOnSave": true，否则只按快捷键Shift+Alt+F才触发，容易忘 - 不同语言要指定默认 formatter：比如 Python 项目里，
python.defaultInterpreterPath和python.formatting.provider都得指向black或autopep8，否则Ctrl+Shift+I按了也无效 - 如果项目根目录有
.prettierrc或.clang-format，插件会优先读这些文件，而不是 VS Code 全局设置——这是多人协作时最常踩的坑：本地看着正常，CI 上却报格式错误
ESLint + Error Lens 如何暴露“隐性坏习惯”
比如你习惯写 if (x = 1) 而不是 if (x === 1)，ESLint 会在行尾标出 Assignment instead of comparison，Error Lens 把它直接贴在代码右边，不用切到终端看 log。
-
eslint.enable必须为 true，且项目里要有package.json中声明devDependencies含eslint，否则插件只是个摆设 - 规则太松（比如只开
eslint:recommended）会漏掉很多风格问题；太严（比如全开airbnb规则）又容易让新手抵触——建议从eslint-config-standard开始，再逐步加no-console、no-unused-vars这类硬性项 - 别忽略
eslint.validate配置：默认可能只校验javascript，但如果你写vue单文件组件，得手动加上vue，否则<script>块里的 JS 不会被检查
Auto Rename Tag 和 Path Intellisense 怎么减少“手误型”习惯
这类插件不改逻辑，但直接拦截高频低级错误：改了 HTML 开标签却忘了同步闭标签，或者拼错 ../utils/helper.js 路径。
-
Auto Rename Tag默认只对html、xml生效，想支持vue或jsx，得在设置里加"auto-rename-tag.activationOnLanguage": ["html", "vue", "javascriptreact"] -
Path Intellisense对import语句识别很准，但对require('./xxx')或动态import()支持弱——遇到路径补全失效，先确认是不是用了非标准写法 - 这两个插件都依赖文件系统实时扫描，大项目首次启用会卡顿几秒，不是坏了，是正在建立索引
真正难的不是装插件，而是让它们在所有项目里行为一致：全局设置管不住子目录下的 .editorconfig，团队里有人用 Prettier 有人用 Black，Git 提交记录就会夹杂大量格式变更。习惯一旦被工具固化，就很难靠意志力回退——所以第一套规则定下来时，就得想清楚它能不能跨项目、跨人、跨年长期有效。
