vscode本身不提供自动优化开发目录结构的能力，“插件一键整理src目录”不可信，因其按名称或后缀机械归类，会破坏import路径、tsconfig paths配置、volar类型跳转及eslint规则，导致编译失败或运行时错误；真正可控的方式是用volar+eslint+prettier组合“防乱”而非“整理”，重大结构调整必须手动操作并全程验证。
VSCode 本身不提供“自动优化开发目录结构”的能力，所谓“插件一键整理 src 目录”是危险幻觉——它大概率直接破坏 import 路径、tsconfig.json 的 paths 配置、Volar 类型跳转和 ESLint 规则，导致项目编译失败或运行时 Cannot find module。
为什么“自动重排 src 目录”的插件不可信
这类插件（如某些标榜“Smart Folder Organizer”或“Auto-Structurer”的扩展）通常只按文件名、后缀或字母顺序归类，完全无视业务语义：
- 把
src/features/dashboard/api.ts和src/features/dashboard/store.ts拆到不同目录，defineStore就找不到配套的useDashboardApi - 将
shared/utils移动后，所有import { debounce } from "@/utils"全部报红，paths别名失效 -
ESLint的import/no-relative-packages规则会因路径变更突然触发大量警告，掩盖真实问题 - CI 流水线中
jest的collectCoverageFrom或Dockerfile的COPY ./src不再匹配新结构，覆盖率统计归零或构建失败
真正可控的目录维护方式：用工具守住边界
不靠“整理”，靠“防乱”。以下三者组合才是生产环境可用的底线：
-
Volar：在.vue文件中实时校验defineProps类型与import路径是否一致，路径错一个字符就标红 -
ESLint+eslint-plugin-import：启用import/no-cycle和import/no-unresolved，阻止跨功能模块的随意引用 -
Prettier：统一单文件内<script></script>/<template></template>/<style></style>的顺序与空行，让“视觉结构”稳定可预期
在 .vscode/settings.json 中配好："editor.codeActionsOnSave": { "source.fixAll.eslint": true }，保存即修复格式与基础引用问题。
真要重构目录时，必须手动+验证
比如从分层结构（src/components/、src/hooks/）转向功能切片（src/auth/、src/profile/），流程不能跳步：
- 先在
tsconfig.json的compilerOptions.paths中新增别名，例如："@auth/*": ["src/auth/*"] - 用 VSCode 全局搜索
import.*from.*"@/components，逐条判断是否属于auth域，而不是无差别替换 - 改完立刻跑
npm run build和npm run lint；任何Cannot find module或import/no-unused-path错误必须当场解决 - 更新
.code-workspace的files.exclude，把旧路径如"**/src/components/**"加入排除，防止误编辑残留文件
最易被忽略的是 CI 配置——lint 脚本里的 --ext .ts,.tsx,.vue 路径、测试覆盖率收集的 src/**/*.{ts,vue} glob、Docker 构建上下文中的 COPY 指令，全部要同步调整。
