project manager插件仅维护绝对路径书签列表，不自动保存项目，首次使用须手动执行“save project”命令并命名，且只读取projects.json记录、不监听当前打开文件夹。
VSCode 本身不自动管理工程目录结构，所有“自动化”都依赖插件或脚本配合，且每种方案解决的问题边界很明确——别指望一个插件搞定全部。
Project Manager 插件只记路径，不感知当前打开的文件夹
它不会因为你打开了 /home/user/my-app 就自动把它加进项目列表。你必须手动执行 Project Manager: Save Project（Ctrl+Shift+P 输入后回车），并给项目起名。
- 名字里别用空格、
/、:、\，否则后续用code命令行打开时可能失败 - 路径必须填 VSCode 界面左下角显示的真实路径：WSL 项目要写成
\wsl$\Ubuntu\home\user\my-app，不是/home/user/my-app - 同名项目会被并列列出，切换时仅靠路径末尾区分——界面上都叫
client，但实际可能是~/git/client和~/git/client-feat/auth
Markdown All in One 的 TOC 功能只处理单个 .md 文件内的标题
它不扫描整个工程目录生成树状索引，只是解析当前 Markdown 文件里的 # 到 ######，生成跳转链接目录。
- 光标放在想插入的位置，执行
Markdown: Create Table of Contents即可 - H1–H6 全部纳入，但普通段落、代码块、列表项不会被识别为目录项
- 修改标题后需重新执行命令，插件默认不自动刷新（没开
markdown.extension.toc.autoUpdate的话） - 生成的锚点是基于标题文本自动生成的，中文标题会转成小写 + 连字符，比如
## 安装步骤→#安装步骤，不是#安装-步骤
tree 命令或 find 脚本能生成工程级目录树，但得手动触发
这类方案不依赖插件，而是靠终端命令输出结构化文本，适合放进 package.json 脚本或 CI 流程中。
- 常用命令：
find . -type d -not -path "./node_modules/*" -not -path "./.git/*" | sed 's/[^\/]*\//|__/g' | sed 's/|__//' - Windows 上
tree命令更友好，但默认包含node_modules，要用tree /f /a | findstr /v "node_modules"过滤 - 如果写进
scripts，注意路径分隔符：macOS/Linux 用/，Windows 用\或双/ - 生成结果是纯文本，不能点击跳转，但可复制进 README.md 或 DOCS_TREE.md 作为静态参考
多根工作区（.code-workspace）和 Project Manager 混用会出问题
Project Manager 记录的是路径字符串，而 .code-workspace 是一个 JSON 配置文件。两者机制不同，强行混用容易导致路径错乱或设置不生效。
- 用 Project Manager 打开一个 .code-workspace 文件，它存的是该文件的绝对路径，不是里面
folders列表里的项目路径 - 切换过去后仍是多根模式，
.vscode/settings.json不会被加载——只有单文件夹模式才认这个 - 想让设置生效，要么把项目单独保存为独立工程（不套在工作区里），要么把配置写进 .code-workspace 的
settings字段 - 手改
projects.json时若误删或错写rootPath，可能导致工作区打不开，且无错误提示
真正麻烦的不是怎么生成目录，而是搞清每个工具的作用域：Project Manager 管路径跳转，Markdown All in One 管单文件内导航，tree 命令管静态结构快照，而 .code-workspace 管跨项目配置——它们互不替代，也互不兼容。选错边界，就会反复踩坑。
