最近遇到个事想和大家分享一下。 我们业务最近出了一个 bug。我这边通过同事的接口获取快递面单 pdf 具体流程是 [包裹号] -> [资源 ID ] -> [快递面单 pdf ]。也就是说： 拿着包裹号请求接口，拿到资源 ID 再用资源 ID 请求下载地址，获取 PDF。然后发现奇怪的事情，包裹 A 和 包裹 B 获取到的快递面单串了，下载下来是一样的单号 资源 ID res_id 是 32 位数，相同一秒获取到的 pdf 就是一样的，猜测是采用 md5(time()) 这种方式命名文件。

然后和 同事 A 反馈了该问题，同事 A 反应已经修复 接下来一段时间还是出现这种问题会导致仓库发错货，老板问我咋回事，我又去查日志发现同一时间 res_id 还是会一样的，这次精度有所提升不是秒了，大概精确到后面两位的样子，然后和老板说了一下，是因为资源 id 还是一样的 这里他还改了一下运单文件在他服务器上的保存的命名方式，这个改动压根解决不了这个问题 然后同事 A 说他已经改了，没问题的，你不应该请求速度这么快 我直接整个大无语。

然后开会 我说建议使用 sha1(运单号) 的方式生产资源 id ，或者使用 UUID ，还没有说完直接反驳 说不安全巴拉巴拉，不安全可以 accessToken 验证啊，外部访问不到不就可以了 然后又说改算法耗费服务器性能巴拉巴拉的，老板又好声好气的让他想办法改一下 最后他改了，改成 md5(microtime(true))。

然后今天又又又出现这个 bug 了，老板又跑过来问我，我已经要疯了 这个问题前前后后几个月都没有弄好，同事 A 是那种反驳性型人格，而且比较自大那种，我快待不下去了。