看这个
用法：vue-cli-service build [options] [entry|pattern]
选项：
–mode 指定环境模式 (默认值：production)
–dest 指定输出目录 (默认值：dist)
–modern 面向现代浏览器带自动回退地构建应用
–target app | lib | wc | wc-async (默认值：app)
–name 库或 Web Components 模式下的名字 (默认值：package.json 中的 “name” 字段或入口文件名)
–no-clean 在构建项目之前不清除目标目录
你大概用了 –dest 但是没看到 –no-clean，cli 的默认不指定就算了，一定不会出问题，但是指定目录就一定要是空目录，不然不会有 –no-clean 这样的参数，不能怪官方啊
vue-cli 的文档上有写 https://cli.vuejs.org/zh/config/#outputdir
至于误删除的文件，可以找一些误删除恢复工具尝试恢复。
我不用 vue 不知道内情，不过 react-create-app 的输出目录默认是项目目录的 build （能不能改不知道），每次 build 都会自动清空输出目录（毕竟输出目录是要发布到服务器的，过期文件当然不要了）
要是我写的 node 代码也会直接干掉你给的目录里面的全部文件，别问为什么，程序逻辑的常规操作
outputDir
Type: string
Default: ‘dist’
当运行 vue-cli-service build 时生成的生产环境构建文件的目录。注意目标目录在构建之前会被清除 (构建时传入 –no-clean 可关闭该行为)。
===
默认的设置在当前目录./dist 下这么合理的设置瞎改，还不看文档地瞎改，这怪谁呢？
然后 H 被清空~
不明白就用默认设置~ 修改设置前请看文档
难道清空之前还得提示你输出目录里的文件是不是要清空？
这不合理，正常情况下输出目录里的文件当然要清空，都过期了
前端对 build 这个概念根本理解不到位，就跟其他所有概念一样。
你见过 build 其他正经项目对时候，一个 make，特么整个项目目录没了的吗
build 和 clean 本来就是应该分开的两个过程，混为一谈就是混为一谈了，搞错了就是搞错了。
弄清楚之后改正就完了，哪那么多原因 jjyy 的
上面很多人都说文档有写、说 LZ 的问题之类的，这就是典型的不提别人着想，觉得某个领域才知道的特定知识是所有人共识了
为什么游戏（尤其主机游戏）在保存存档的时候都会提示“请勿关闭电源”，因为有经验的玩家知道关闭电源可能损坏存档，但是对于这方面不懂的人尤其是轻度游戏玩家来说，根本没人告诉他存档的时候关闭电源会损坏存档这事，这种玩家间的常识超出了他们的知识储备范围
还是那句话不要把特定领域的常识当成全人类共通的认识。这么想的人往往做出的产品，在用户体验方面也是非常糟糕的。
这可能是过于依赖语法糖的弊端吧。如果你自己配置过 gulp 或者 webpack，就会明白执行打包操作之前清空目标目录是很常见的操作。当然 vue-cli 的这个设计也确实不太好，你可以在 vue 的 github 官方仓库发布一个 issue，要求改进一下。
逗死我了真是夏虫不与语冰。
解决 CDN 缓存问题的方案又不只加后缀这一种，html 里加参数是不是也行啊？
加后缀的好处不就是不影响旧版本的使用，可以并存吗，
但问题来了，你 build 目录随时删，能测出多版本并存的实际行为吗？
每次删目录 => 因为每次产生的文件名不一样 => 因为需要不同版本文件共存 => 每次删除目录不保留之前版本？
前端肤浅浮躁成这样还说不得了？ 起码自己好好梳理一下吧
不怪 vue 吧，vue 毕竟是库，面向的是开发，不是面向小白的软件，本质上你自己要对自己敲下的每一个命令会发生什么有一定概念，并承担相应的责任。
你的期冀可能是 vue-cli 在即将清空目录时给一个提示， 并要求输入 yes，除非带上 -force 之类的参数。我个人认为有点强人所难。
直接删目录不就是一个鲁莽懒散么，简单处理能用就行了。
这还没遇到把输出目录指到父级的，我删我自己？
上面也有其他人科普了，就是真正需要 build 的那种 c 系项目，很多是没有专门输出目录的，输出的东西就和源码放一起，从来见不到删目录这种行径，想要清理专门有一个 clean 过程，正好就是 build 的逆过程。正经 build 正经 clean 。
生成文件名带哈希后缀咋了，妨碍 clean 过程吗妨碍覆盖吗只能删目录吗？
一个正则匹配不就都解决了吗？
CDN 问题可以有一百种方式解决，可是当你专注于前端时你能做的就不多，拿你的例子来说，http 里可以加参数，可是你 build 出来的东西不一定由你来 host，懂？简单点，也别讨论哪种方法最好了，你给我找几个 js 文件名不含 hash 或者版本号的站点看看吧？
正确的 flow 是：每次产生新的文件=>本地开发时避免磁盘冗余每次删旧文件=>部署到生产时可以保留新版和旧版以便回归。
>> 你 build 目录随时删，能测出多版本并存的实际行为吗？
你这句话也是蛮无知和搞笑的，版本实际上应该由 git tag 管理，我切个 tag 再 build 可不就能测对应的版本了吗？为啥我需要把所有版本和中间修改生成的文件保存在我本地的 build 目录呢？
我也完全同意直接删目录不可取，更好的做法是删除前提示，或者缓存前几次的文件。
嘴洗干净再学人回帖好吗？
要不你自己打开几大站看一下 html? 引用的 js 都带着哈希呢？ google 的 html 能不能堵上你的嘴？
还有小伙子，你瞅啥不一定非得回答瞅你咋地啊。
一是某个英伟达驱动官方安装脚本中，把 rm -rf /usr/bin/nvida/… 写成了 rm -rf /usr /bin/nvida/…
也就是多了一个空格，导致了很多人数据丢失
二是在很多 Linux 发行版，当你执行 rm -rf / 命令时，会提示你使用 –no-preserve-root 参数进行确认，但部分发行版不会检查。
我觉得主犯的错误与一类似，这是一个又蠢又可怜的错误。我们希望软件的开发者可以像二一样多一个检查，但是也不能苛责他们将其视为义务，因为开源许可证已经明确了免责条款。
加后缀不是为了多版本共存，是因为把指纹或者说版本号放在 url 的 querystring 里其实不是最完美的方案，存在一定风险（有些浏览器认为 querystring 变化后资源可以复用；持续集成发布中遇到资源引用更新但实际内容没来得及更新时 CDN 会用新 URL 缓存旧资源，而你不可能每次发布都刷一遍 CDN 缓存； 。。。），而目前公认的方案是放在 filename 里。所以 rebuild 需要清空上次内容，而最简单的 clean 就是清空整个目录。
@avastms 总喜欢和其他 C 系的项目比，但是这里的比较是不对等的。前端的这些 CLI build 产生的 output 目录是 release-ready 的，你 copy 这个目录然后拿个 nginx 托管一下就能跑的，这是这些工具的意义。make 一下直接就地生成二进制能直接目录打包分发给客户么？你要做 installer 或者 zip 打包你的软件，是不是提前要保证目标目录是干净的？你不希望你的 installer.exe 一释放你的学习资料跑出来了吧，你的 Assembly 过程不希望最终的 package 混进奇怪的东西吧。 所以说这个和传统的 clean 是有差别的。