tree命令是唯一可信的项目结构导出方式，因其直接读取磁盘、不依赖vscode配置，在pnpm workspace、lerna或符号链接场景下准确可靠；windows 10 1809+自带，macos需brew安装，linux多预装；推荐配合-i和-l参数过滤与限深，并用脚本固化命令以确保一致性。
tree 命令是唯一值得信任的导出方式
插件生成的结构图不可信，尤其在含 pnpm workspace、Lerna 或符号链接的项目中，常漏目录、缩进错乱、把 dist/ 当隐藏文件跳过——因为它们依赖 VSCode 的 files.exclude 配置，而那本不是定义“项目结构”的标准。
tree 直接读磁盘，不经过编辑器抽象层，输出就是真实文件系统快照。Windows 10 1809+ 自带；macOS 需 brew install tree；Linux 多数预装，Debian/Ubuntu 缺失时跑 sudo apt install tree。
- 执行前务必确认当前终端工作目录是项目根目录：
pwd看一眼，别靠右键“在终端中打开”就默认安全 - 常用过滤：加
-I "node_modules|.git|.DS_Store"排除干扰项 - 限制深度防爆炸：用
tree -L 4控制最多显示 4 层 - 输出为纯文本可直接粘贴进 README 或文档，不带 Markdown 链接、无缩进污染
别用插件导出用于 CI 或交接的结构图
像 Project Tree 或 File Tree Generator 这类插件，会在 README.md 里写入带链接的 Markdown 树，但链接指向的是 VSCode 内部 URI（如 file:///.../src/index.ts），粘到飞书、Notion 或 GitHub PR 里就失效；更麻烦的是，它们对 symlink 和 hard link 的处理不一致，导致 workspace 子包路径显示为绝对路径或直接消失。
- 插件默认不递归扫描未打开的子文件夹，而
tree无此限制 - 某些插件会把
.d.ts文件当“类型声明”忽略，但实际它属于交付产物，该出现在结构图里 - 如果必须用插件，导出后一定要比对
tree -L 3输出，逐行核对关键目录是否存在
一键脚本比记参数更可靠
每次敲 tree -I "node_modules|.git" -L 4 > structure.txt 容易漏参数、拼错路径。存个脚本，以后双击或 alias 就行。
macOS/Linux：gen-tree.sh
#!/bin/bash tree -I "node_modules|.git|.DS_Store|dist|build" -L 4 -o structure.txt
Windows PowerShell：gen-tree.ps1
tree /F /A /I "node_modules,.git,.DS_Store,dist,build" | Out-File -Encoding UTF8 structure.txt
- 脚本里硬编码过滤项，避免每次手动输错分隔符（
tree用|，PowerShell 用,） -
-o或Out-File直接落地为文件，省去复制粘贴环节 - 加
-L 4是经验阈值：再深就失去概览意义，反而难读
结构图不是越全越好，而是要匹配用途
给新人看的架构图，重点在顶层模块划分（src/、packages/、scripts/）；给 CI 流水线用的结构清单，可能需要包含 dist/ 和 types/——这些不该被默认过滤掉。
- 别盲目加
-I把所有“看起来不重要”的目录都扔掉 - 导出前想清楚：这图谁看？解决什么问题？是否要体现构建产物？
- 同一项目可维护多个脚本变体，比如
gen-tree-dev.sh（含node_modules）和gen-tree-doc.sh（只留业务代码）
真正容易被忽略的，是工作目录和用途匹配——不是工具选错，而是没想清“这个结构图到底要回答什么问题”。
