Project Tree类插件仅导出文件树快照，不校验结构合理性；ESLint+import规则和Volar+TS类型系统才是保障目录严谨性的核心手段。
Project Tree 插件生成结构但不校验合理性
Project Tree 这类插件（如 project-tree、file-tree-generator）只负责“快照式”导出当前文件树，它不会判断 src/utils 里混着组件、src/components 下藏着 API 请求逻辑这类结构性问题。导出结果看起来整齐，但可能掩盖真实的设计退化。
常见错误现象：README.md 里结构漂亮，但实际 import 路径混乱，比如 import { api } from '@/utils/api' 和 import LoginButton from '@/components/LoginButton.vue' 都在 src/utils 里——插件照常输出，毫无预警。
- 它不检查路径语义是否与目录名匹配（
hooks/目录下放了非 hook 的工具函数） - 不识别重复职责（
services/和api/同时存在且功能重叠） - 对 TypeScript 的
paths别名无感知，无法验证别名是否覆盖了实际目录结构
ESLint + import rules 是结构守门员
真正让目录结构“严谨”的不是生成工具，而是持续拦截不合理引用的规则。比如启用 import/no-relative-parent-imports 可禁止从 src/features/dashboard 里写 import ... from '../../../utils'；import/no-unresolved 会立刻报错当 import { auth } from '@/auth' 对应的 @/auth 别名未在 tsconfig.json 中配置。
关键参数差异：
-
"import/no-restricted-paths"：可硬性限制某目录不得被特定路径 import，例如禁止src/pages直接 importsrc/store -
"import/no-cycle"：检测跨目录循环依赖，比如A → B → A，这是结构松散的典型信号 - 配合
eslint-plugin-import的order规则，还能强制 import 顺序按路径层级分组（先标准库，再别名，最后相对路径）
Volar + TypeScript 类型系统才是结构事实来源
VSCode 里点进一个 defineProps 或 useQuery，跳转到的定义位置，就是当前结构被类型系统“承认”的路径。如果 src/composables/useAuth.ts 被正确识别，但 src/hooks/useAuth.ts 报红“Cannot find module”，说明你的目录命名和 tsconfig.paths 不一致——这才是结构不严谨的第一手证据。
容易踩的坑：
- 改了目录名但没同步更新
tsconfig.json的compilerOptions.paths，Volar 就会失效 - 用了
@/别名却没配jsconfig.json或tsconfig.json，ESLint 和 Volar 都无法解析 - Vue 单文件中
<script setup lang="ts"></script>内部 import 路径正确，但<template></template>里的v-if="loading"引用的loading来自未声明的响应式变量——这虽是逻辑错误，但暴露了组件内部结构与外部约定脱节
重构目录时必须手动验证三件事
自动工具能帮你建目录，但不能替你决定“这个工具函数该放在哪里”。真要调整结构，以下三点漏掉任一，都会引发构建失败或运行时异常：
- 全局搜索
import.*from.*old-path，逐条确认迁移必要性，而不是批量替换——有些 import 是故意跨域耦合的 - 运行
npm run build和npm run lint，重点看Cannot find module和import/no-unused-path报错 - 检查 CI 流水线配置，比如 Jest 的
modulePaths、Cypress 的supportFile路径、Docker 构建上下文是否仍包含旧目录
最易被忽略的是：重构后忘记更新 .vscode/settings.json 里的 files.exclude，导致旧路径残留文件仍在编辑器里可编辑，团队成员误改又引入不一致。
