最近项目老是出现一堆莫名其妙的问题，包括但不限于：
拖动文件弹安全警告（这些文件可能对你的计算机有害）、安装器报错、exe 打不开 等等；
排查了一个下午，整整一个下午！！！
谁能想到这全是DSH的锅啊？QAQ
蓝色大肥鱼查到的资料是：
DSH 的设计意图是：降低沙箱内子进程的完整性级别，再用能力 SID 限制写权限，从而让沙箱能够拦截写入。它选择把工作区目录本身标为 Low，作为“向下写”的隔离手段。
但这里有一个明显的疏漏：工作区就是你自己的项目目录。DSH 把用户自己的生产目录当成了沙箱内部。于是：
目录被标成 Low，Windows 便把它视为“不可信位置”，拖动文件时弹警告；
目录被加上 deny，子目录拒绝 FullControl 打开，安装器类程序失败；
去DSH 的仓库翻了 discussion，至少能找到四份报告：
九月底的 #7709：低完整性标签也在影响用户自己的启动，悄悄破坏工具链
十月初的 #9314：工作区里编译的 exe 以低完整性运行，所有写入失败
十月中旬的 #9559：标签没传到已有子目录，导致子目录写入被拒
十月十九号的 #10270：用下载文件夹当工作区，NSIS 安装器直接报错
而官方的回应是——这是有意设计。
原话大意是：工作区的权限修改是常驻的，是跨会话的复用缓存，所以 dispose() 的时候故意不撤销。理由是：如果撤销了，下次还得把整棵树重新递归一遍。
但维护者也承认了一个问题，我觉得这句话是整件事的关键：
“真正没有想清楚的是影响范围。这个缓存的前提是‘这个目录是这个用户的工作区’，但它的效果活过了这个前提，并且作用到了无关的文件上。”
