不小心写了个BUG，成功让项目组几个人都换了台新电脑

背景： 项目组接一个老项目，做二次开发工作。

 

起因：客户经常收到服务器的监控告警，磁盘将在不久被写满。

开始，我们自己去手动清理程序日志，但是磁盘还是越来越大；

后来，又去排查有没有其他文件占用磁盘，于是发现，程序中操作临时文件，在操作后都没删除掉

结果：最后写了定时任务，每天夜里来删除这些临时文件。

影响：再后来，就有小伙伴发现自己的D盘文件都没了，像是被格式化一样，莫名D盘就没了。因为电脑有点老了，就开始怀疑自己电脑出问题了，于是几个人陆陆续续都新买了电脑。可是后来，接着又发生了几次，实在诡异，表示新接的项目有毒，也就过去了。

终于：有一天夜里，一个新买电脑的同事，D盘又没了。并在项目组里抱怨，新电脑不行，要去找售后。这时，抱着很想帮她找到原因的心态，于是脑子不断的回想，项目中那些操作文件的逻辑，会不会是删除文件，不小心删掉了D盘，最后忽然一激灵，想起来了，之前那个定时任务就是 夜里这个时间点执行。回头一看，卧槽，果然，文件的路径写的是： D：/ ，最后的最后终于破案了。

回溯一下整个过程：

就是原来老项目挖好坑：首先设置临时文件目录：通过配置文件配置成：D：/xx，项目运行时会在同目录下生成 D：/ 文件夹，用于存放、操作临时文件， 如下图（还有一个目录直接是 D：/）：

 再来就是，临时文件放在这里，一直不删除，对于每天几十G的临时文件，服务器磁盘哪能受得住。然后，处理人直接去拿配置文件中地址，其实就是去 new File("D:/") 递归删除（真是一个文件不给剩啊！），简单粗暴了。

然后每天夜里 凌晨整点 执行定时任务。处理人自己电脑测试几天没问题，后来发版就上正式环境了，也生效了，服务器不会被监控告警了。

整个事件吊诡的地方在于：处理人用的是 MacBook做开发，服务器是Linux，自测试没问题，服务上也没问题。而其他人使用的是 windows 的，使用windows 也没问题，巧合的在于，他们晚上下班回家不关程序，自己本机 Idea 依然在跑程序，于是凌晨整点触发、删除；而老程序的临时文件地址不知道哪位神人 设置成 D：/ 这种坑死人目录。结果第二天回来 一看，D盘没了，没了，没了，怎么就没了，什么迹象都没有，没有痕迹，查看D属性，最后修改时间：凌晨整点，其他看不到了。

说到这里，对于每一个程序员来说，自己写的代码都要负责，真的不能随便写写的。如果是定时删除服务器项目文件、数据库数据、还是这种删除本机上文件，不管是恶意的还是出于疏忽，都是一种伤害。