vscode不自动修复javascript命名冲突，仅通过插件辅助发现、定位与重构；因模块解析依赖运行时环境，编辑器无法判断同名导出的优先级，需开发者手动决策。
VSCode 本身不解决 JavaScript 命名冲突，插件也不“自动修复”命名冲突——它们只帮你发现、定位、规避或重构，真正决策必须由你做。
为什么命名冲突不会被自动修复
JavaScript 的命名冲突（比如两个 utils.js 都导出 formatDate，而你在同一作用域里同时 import）是运行时/模块解析层面的问题，不是语法错误。VSCode 插件看不到模块加载顺序、打包配置或动态 require 行为，所以无法判断“哪个 formatDate 该被用”。它只能告诉你：“这里有两个同名符号，你得自己选。”
- 编辑器能检测到的，仅限静态可分析场景：同文件内重复声明
const formatDate、同作用域重定义变量、类型声明冲突（如多个declare module 'xxx'定义同名接口） - 跨文件导入冲突（如 A.ts 和 B.ts 都
import { formatDate } from './utils'，但路径解析实际指向不同文件）——这取决于 tsconfig、别名、打包工具，VSCode 语言服务可能给出错误提示，也可能完全沉默 - ESLint 或 TypeScript 的
no-shadow、no-redeclare规则只管局部作用域，对模块级命名碰撞无感
哪些插件能帮你暴露命名问题
关键不是“解决”，而是让冲突显性化、可操作：
-
ESLint+eslint-plugin-import：启用import/no-duplicates检查同一模块多次 import；用import/named确保导入名存在且未被覆盖 -
TypeScript语言服务（内置）：当两个declare module定义同名interface，会报TS2300: Duplicate identifier；同名type在合并声明中若成员冲突也会报错 -
Auto Import（by Microsoft）：在 import 补全时，如果发现多个同名导出来自不同路径，会列出所有选项并标注来源文件，避免你盲目选错 -
npm intellisense：输入import { ... } from '时，提前显示包内导出结构，减少因包版本差异导致的命名误用
重命名时如何避免引入新冲突
VSCode 内置的 rename symbol（F2）是主力工具，但容易踩坑：
- 默认只重命名当前文件内的引用——如果你用的是全局
var或污染全局的 UMD 包，它根本找不到其他地方 - 跨文件重命名依赖 TypeScript 的项目配置（
tsconfig.json中"composite": false或正确设置"include"），否则跳转和重命名范围失效 - 遇到
export * from './x'时，F2 不会穿透到源文件重命名，需手动检查导出链 - React 组件名变更后，JSX 标签不会自动更新——这是设计使然，因为 JSX 是运行时解析，编辑器无法 100% 确定是否该改
真正有效的预防动作
插件只是辅助，根子在工程规范：
- 用
export default+ 唯一命名（如export default formatDateV2）替代具名导出，从源头减少碰撞概率 - 在
tsconfig.json中启用"noUnusedLocals": true和"noUnusedParameters": true，让未使用变量/参数提前暴露冗余命名 - 项目级 ESLint 配置加入
no-restricted-exports，禁止导出util、helper这类泛名 - 团队约定模块前缀：如
dateFormat、stringNormalize而非笼统的format、normalize
命名冲突从来不是编辑器能一键清零的问题。它背后是模块设计、团队约定和类型约束的综合结果。插件的作用，是把模糊的“好像哪里不对”变成明确的报错、高亮或补全选项——剩下的，得你来拍板。
