在 HX 开发的云服务项目中，可能存在多个云函数/云对象用到相同的代码模块。
如果这些模块来自于公共仓库的开源代码，那很简单，但如果是自己写的代码，在项目开发过程中随时还要修改，
那可能就需要在多个云函数/云对象中复制粘贴了，不仅繁琐，而且很可能出错。
解决的办法就是创建一个单独的目录用来存放这种本地公共代码模块，把公共代码模块放置在这个目录中，
然后在它们原本应该出现的地方用mklink 创建 JUNCTION 指向这里，那么只要在一处发生修改，
其它处也会随着变动，从而避免了手工维护的代码复制。
比如下面这种典型的目录结构：
<project root>
├── uniCloud-aliyun
│ ├── cloudfunctions
│ │ ├── co-1
│ │ │ ├── utils [JUNCTION]
│ │ │ │ └── ...
│ │ │ └── index.obj.js
│ │ └── co-2
│ │ ├── utils [JUNCTION]
│ │ │ └── ...
│ │ └── index.obj.js
│ ...
│
└── local-shared
└── utils [JUNCTION TARGET]
└── ...
在上述目录结构下，创建两个 JUNCTION 的方法是在 co-1 和 co-2 目录下分别执行下面的命令：
mklink /J utils ..\..\..\local-shared\utils
需注意的是，在把源代码提交到 git 仓库的时候，local-shared 目录下的 utils 目录不需要提交，
而要把每个云函数/云对象目录下的 JUNCTION 形式的 utils 目录都提交到 git，就像它们是那里的真实目录一样。
这样虽然在源代码仓库里面有重复的内容，但好处是别人在 checkout 代码之后会得到一个完整的项目目录，
而不用再去手工创建 JUNCTION。
当然如果他们也需要对项目做进一步开发，他们可以自己用同样的方法，把这些重复的目录搬到 local-shared
目录下，再手工创建 JUNCTION。
另外还有一点需要注意，如果 utils 模块依赖于另外一个本地模块，比如 const other = require('../other-util')，
那么这个 other-util 模块也需要放置在 local-shared 目录下，并创建 JUNCTION，否则在 HX 里面
【运行-本地云对象】时会报错，因为它用相对路径加载被依赖模块时是以当前文件的真实位置开始算的。
不过，既然 utils 本身是一个公共模块，那它依赖的模块本来也就应该是一个公共模块，所以一起搬到 local-shared
目录下本来也是顺理成章的事了。
