eslint + typescript 插件是保障 js 代码可扩展性的核心，因可扩展性本质是“未来改起来不崩”，eslint 能检测 no-unused-vars、no-shadow、max-params 等影响重构与演化的规则，而 prettier 仅处理格式；必须启用 plugin:@typescript-eslint/recommended 或 plugin:vue/vue3-recommended 才能正确检查泛型、defineprops 等；no-explicit-any 和 explicit-function-return-type 应保留以约束类型粒度；export * 导出需配 no-restricted-exports 防模块边界模糊；volar 必须配合 tsconfig.json 中 "types": ["volar"] 启用，否则类型推导失效；混用 .js/.ts 时需开启 "javascript.implicitprojectconfig.checkjs": true；vscode 需禁用内置 ts 插件避免与 volar 冲突；auto import 应关闭以维护模块契约，手动导入确保路径可控；可扩展性常崩于未约束的 any、无类型 props 或长函数，需主动关闭“看似方便实则放水”的默认行为。
ESLint + TypeScript 支持插件是提升 JS 代码可扩展性的核心组合，单靠格式化工具（如 Prettier）无法解决接口设计、类型演化、模块拆分等可扩展性问题。
为什么 ESLint 比 Prettier 更关键
可扩展性本质是“未来改起来不崩”，不是“看起来整齐”。Prettier 只管 const a = 1 还是 const a=1；而 ESLint 能揪出：no-unused-vars（冗余变量阻碍重构）、no-shadow（作用域污染导致后续扩展会错乱）、max-params（参数过多暗示函数职责过重，难以横向拆分）。
- 必须启用
plugin:@typescript-eslint/recommended或plugin:vue/vue3-recommended，否则对泛型、组合式 API、defineProps 类型的检查基本失效 - 禁用
no-console等宽松规则可以，但no-explicit-any、explicit-function-return-type建议保留——它们直接约束类型声明粒度，影响后续新增字段或返回值时的兼容性 - 项目里若用
export * from './xxx'大量聚合导出，要配no-restricted-exports规则，防止模块边界模糊，后期无法按需拆包
Volar / TypeScript Server 插件对 Vue/TS 项目的实际影响
在 Vue 3 + TS 项目中，Volar 不只是补全更好看，它让 defineProps 和 defineEmits 的类型能被真正推导。没有它，props.foo 的类型在子组件里可能是 any，一旦你加个新 prop，调用方根本不知道要不要改，这就是可扩展性断层。
- Volar 必须配合
"types": ["volar"]写入tsconfig.json的compilerOptions，否则 TS Server 仍走旧路径，类型检查形同虚设 - 如果项目混用
.js和.ts，Volar 默认只处理.vue，需额外配置"javascript.implicitProjectConfig.checkJs": true，否则/** @type {Foo} */注释类型不会被校验 - VSCode 设置里禁用内置 TS 插件（
typescript-language-features），否则和 Volar 冲突，导致跳转失败或类型提示消失
Auto Import 类插件的隐藏风险
自动导入看着省事，但会悄悄破坏模块契约。比如 vueuse/core 的 useStorage 被自动引入后，如果某天你想把它抽成独立 hook，就得全局搜索所有 useStorage 调用点——因为没显式声明来源，根本没法批量替换。
- 推荐关闭
editor.autoImports，改用Ctrl+Space手动触发，确保每次 import 都经过人工确认路径和命名 - Vue 项目中慎用
vue.components.autoImport，它可能把Button.vue导入成import Button from '@/components/Button.vue'，但团队约定应统一走components全局注册，这种导入反而埋下维护隐患 - 如果真要用自动导入，至少配
"javascript.suggest.autoImports": false和"typescript.suggest.autoImports": false，把控制权交还给开发者
可扩展性最常崩在“没人意识到要约束”的地方：一个没类型定义的 props、一次没检查的 any[] 返回值、一段没拆分的长函数。插件不是银弹，但选对组合并关掉那些“看似方便实则放水”的默认行为，才能让代码真正撑得住迭代。
