目录树怎么生成:把缩进清单变成 README 里的 ASCII 文件树

打开一个陌生的开源仓库,我习惯先翻 README 顶部那棵目录树。它把整个项目的骨架摆在眼前,哪个文件夹放路由、哪个放工具函数,一眼就清楚,比读三段散文管用得多。问题是,这棵树该怎么画出来。手敲方框字符是个折磨:对齐稍微差一格,整棵树就歪了;后面加一个文件夹,又得把下面所有竖线重新对一遍。

这篇讲清楚目录树的符号到底是什么意思,它和 unix 的 tree 命令差在哪,以及怎么用一份缩进清单稳稳生成出来。

树形符号 ├── 和 └── 各管什么

一棵目录树读起来像图,而不像一堆缩进的行,靠的就是三个符号在配合:

├── 是 T 形分支,用在下面还有同级条目的那一项上,表示这一组还没完。
└── 是 L 形拐角,用在一组里的最后一个条目上,画出来就等于给这条分支收尾。
│ 是竖线,只要某一层后面还有同级条目,它就在左边一直往下画;一旦拐角出现,竖线就换成空白。

记住一条:看到 └── 就知道这一组到此为止,看到 ├── 就知道后面还有兄弟。这一对正是 tree 命令输出的样子,也是手画最容易错的地方。

和 unix tree 命令比,差在哪

tree 命令直接扫你磁盘上真实存在的目录,输出准确,但它有几个场景顶不上:你想画一个还没建出来的结构,tree 没东西可扫;你在沙箱或一台没装 tree 的机器上;你手里只有别人文件管理器的一张截图。这些时候,你需要的是把脑子里或纸面上的结构敲成清单,直接得到同样形状的树。

目录树生成器走的就是这条路:输入一份缩进清单,输出和 tree 命令一致的分支与竖线引导。区别在于它的输入是你写的结构,而不是磁盘现状,所以规划阶段和文档阶段都能用。

缩进决定层级

规则很简单:每多一级缩进,就在树里深一层。用两个空格的设置时,不缩进是根,缩进两格是子级,缩进四格是孙级,往下类推。文件夹行末尾加一个斜杠,工具就知道它是目录。有下级条目的行会被自动当成文件夹,哪怕你忘了加斜杠,几何关系也不会乱。

最常踩的坑是在同一份清单里混用缩进单位:有的行两个空格,有的行一个 Tab,而工具设的是空格,某个子级就会落到错误的深度。选定一种单位,把工具设成一致,整份清单保持统一。

一个真实例子

假设我要给一个小项目写 README,结构清单这么写(缩进两格):

my-app/
  src/
    index.ts
    utils/
      format.ts
  README.md

生成出来的 ASCII 目录树是这样:

my-app/
├── src/
│   ├── index.ts
│   └── utils/
│       └── format.ts
└── README.md

注意 src/ 用 ├──,因为它下面还有同级的 README.md;README.md 是最后一项,所以用 └──。src/ 这一组里 index.ts 还有兄弟用 ├──,utils/ 是组内最后一个用 └──,而它左边那根 │ 一直画到 index.ts 这一行,到 utils/ 收尾就停了。把这段贴进 README 的代码块(三个反引号围起来),GitHub 就以等宽字体渲染成树形。

我自己的用法

我给项目补 README 时,几乎不再手敲方框字符。先把目录写成缩进清单,边写边看树形实时更新,顺手把层级调顺;改完直接复制贴进文档。最省心的是后期维护:加了一个文件夹,我只改清单里一行,重新生成,整棵树的竖线和拐角自动重排,不用我一格一格去对齐。以前手画时改一次错一次的毛病,从此没了。

Unicode 还是 ASCII

默认的 Unicode 连接符更干净,GitHub、多数编辑器和现代终端都渲染得很好。但有些地方会把方框字符显示成问号或方框:老终端、纯文本邮件管道、某些日志查看器。这种情况把连接符切到 ASCII,用竖线加短横做分支、反引号加短横做最后一条分支,形状到哪儿都读得出来。哪种在目标处显示正常就复制哪种。

写完目录树,如果还要给项目补一份 .gitignore,可以顺手用 gitignore 生成器配齐忽略规则,两样一起放进仓库根目录,新人 clone 下来就能照着结构上手。

Made by Toolora · Updated 2026-06-13