多端联调项目有一个很常见的问题：代码不一定只在一个目录里。
你可能同时在处理这些内容：
- 主应用代码
- iPad 或平板端代码
- 文档仓库
- Android 集成工程
- 自动化测试目录
- 临时调试工程
这些目录往往分散在不同位置。短期看还能记住，时间一长，终端、编辑器、脚本和构建命令都开始依赖路径记忆，开发效率就会明显下降。
这时候我觉得 Junction 特别有价值。它不是用来替代 Git 或构建工具的，而是用来先把本地工作区整理顺。
1. Junction 解决的不是“文件怎么改”，而是“目录怎么组织”
在 Windows 里，Junction 可以理解成一种目录映射。
你在一个位置看到的是一个目录入口，但它实际指向另一个真实目录。这样做的意义是：你不用复制项目，也不用迁移真实目录，就能重新组织本地工作区结构。
对于多端联调项目，这一点特别实用。
因为多端协作最怕的不是工具多，而是目录乱。一旦真实代码、集成工程、文档、调试目录散落在不同地方，后面无论是切终端、开编辑器、跑脚本、改工作区，都会越来越依赖“记住路径”。
而 Junction 的优势在于，你可以保留原始目录不动，再在统一工作区下建立一层清晰入口。
2. 为什么它特别适合多端联调
单一项目里，路径问题的影响还不算太明显；但到了多端联调场景，这个问题会迅速放大。
因为你通常不是只开一个目录，而是会同时接触几类内容：
- 前端页面代码
- 原生集成代码
- 接口调试或服务端脚本
- 自动化测试脚本
- 配套文档
如果这些内容原本分布在不同磁盘、不同目录，日常协作就会出现几个典型问题：
- 终端默认路径不统一，命令容易跑错位置。
- VS Code 工作区里的目录顺序和真实关系不直观。
- 脚本里写相对路径时，维护成本变高。
- 新成员接手时，很难快速理解本地目录布局。
而用 Junction 做一层整理之后，本地工作区会更像一个完整项目空间，而不是若干分散目录的临时拼接。
3. 这个命令就够用了
如果只是做目录映射，我更推荐直接用 PowerShell 的方式：
New-Item -ItemType Junction `
-Path "D:\workspace\app" `
-Target "D:\projects\app"
这条命令的含义很直接：
Path是你想创建出来的工作区入口目录Target是真实目录
创建完成后，你访问的是 Path，实际操作的仍然是 Target 那份真实文件。
也就是说，这不是复制，也不是额外生成一份项目，而是在当前工作区里补了一个目录入口。
4. 它比“复制目录”更适合长期使用
很多人第一次遇到这个需求，会先想到复制一份目录。
这在临时救急时没问题，但长期维护几乎一定会出问题。原因很简单：
- 两份目录容易逐渐不一致
- 很难判断自己当前改的是哪一份
- 重复占空间
- 编辑器、脚本、Git 路径都可能混乱
而 Junction 的本质是“入口变了，真实目录没变”。
所以它更适合多端联调这种长期场景。你需要的是统一入口，而不是重复内容。
5. 它对开发工作流最直接的提升是什么
我觉得它最大的价值不是“省一个命令”，而是让工作区边界更清楚。
对于多端联调项目，这会直接带来几个好处：
5.1 更容易整理统一工作区
你可以把原本分散的目录，用统一命名方式映射到同一个工作区根目录下。
这样多端项目在视觉上就是一组相关目录，而不是到处散落的路径。
5.2 更适合 VS Code 多根工作区
当多个目录都挂到同一个工作区根路径下后，VS Code 里的 folders 配置会更清晰，资源管理器和搜索结果也更直观。
5.3 更利于脚本和终端协作
多端联调经常要在不同目录切换命令。
如果所有入口都统一在一个工作区下，命令路径、脚本路径和终端习惯都会更稳定。
5.4 更容易交接和复现
本地目录一旦有统一结构，新成员或者换机器时，理解成本会明显下降。
很多时候，效率提升并不来自命令本身，而来自目录组织终于可预期。
6. 使用时要注意什么
有几点最好提前明确：
6.1 你改的仍然是同一份真实文件
Junction 不是副本。
你在入口目录里改文件，本质上就是在改真实目录。
6.2 删除时先确认删的是入口还是目标
这类目录映射最怕误删路径。
如果只是删 Junction 入口，通常问题不大；但如果把目标目录当成入口删掉，后果就完全不一样。
6.3 它不会替代 Git、worktree 或构建工具
Junction 解决的是目录组织问题。
如果你要做多分支并行开发，还是应该用 git worktree；如果要做环境切换，还是应该靠环境管理工具。它更像是工作区层面的补充。
7. 在 VS Code 里怎么改工作区目录
如果你已经通过 Junction 整理好了本地目录，下一步通常就是把 VS Code 的工作区也切过去。
方式一：重新打开新的目录
- 打开
File - 选择
Open Folder... - 选择新的 Junction 入口目录
这样 VS Code 的当前工作区就会切到新的目录入口。
方式二：修改 .code-workspace
如果你使用的是多根工作区，更推荐直接改 .code-workspace 文件中的 folders：
{
"folders": [
{ "path": "app" },
{ "path": "docs" },
{ "path": "android" }
]
}
把其中原来指向旧目录的位置，改成新的工作区入口目录即可。
改完后：
- 保存
.code-workspace - 重新打开这个工作区文件
这样资源管理器、终端默认路径和全局搜索范围都会切到新的目录结构。
8. 最后一句总结
如果你做的是多端联调项目，Junction 最有价值的地方，不是它本身有多复杂，而是它能在不复制项目、不移动真实目录的前提下，把本地工作区重新整理成更适合协作和联调的结构。
对这类项目来说，路径清晰本身就是效率。
