你的描述很详细，其实你遇到的这个问题在实际开发中非常常见，尤其是在一些对唯一性要求很高的业务场景下（比如生成唯一的资源id、单号、文件名等），用时间戳（哪怕是到毫秒级）+ md5 来生成唯一id，本质上是“伪唯一”，并不能保证真正的唯一性。你的同事这种做法确实是有很大隐患的。
下面我帮你梳理一下问题和可以反驳、建议的点：
1. 问题核心
- 用 md5(time()) 或 md5(microtime(true)) 生成的【资源id】，本质上就是对当前时间的加密，但如果同一时刻（比如高并发下）多次请求，依然会生成相同的id。
- 这会直接导致不同的包裹获得相同的资源id，后续所有依赖资源id的操作（比如文件保存、下载、仓库出货）都会串号，造成严重的业务事故。
2. 你的同事的问题
- 技术方案不合理：仅仅依赖时间戳生成唯一id，是非常不可靠的做法，尤其是在并发环境下。
- 推卸责任：把问题归咎于你的请求速度快，属于本末倒置。真正健壮的系统应能承受合理的并发量。
- 误导老板：“更换算法耗费性能”是站不住脚的，常用的唯一id生成方案对性能影响极小。
3. 正确的唯一id生成方案
- UUID：使用如
uuid4() 这种标准库生成的唯一id，几乎可以保证全球唯一。
- 雪花算法（snowflake）：很多互联网公司用的分布式id生成方案，既快又唯一。
- 数据库自增主键：如果业务允许，也可以用数据库的自增id做资源id。
- 时间+随机数：比如
md5(microtime(true) . rand())，虽然比单时间好，但也不是最优。
4. 你可以这样和老板/同事沟通
当前的id生成方案（md5时间戳）不能保证并发下的唯一性，已经多次造成串号，带来直接损失。建议采用UUID或雪花算法，性能影响极小但能彻底杜绝此类问题。否则继续下去，风险和损失会持续存在。
5. 你的吐槽，其实很多人都遇到过
- 有些人喜欢“嘴遁”，不愿承认自己方案有问题，总是把锅甩到别人身上。
- 声称自己有多年经验，但实际技术方案很不专业。
- 不愿意改进、不愿意学习新东西，只会敷衍和推诿。
6. 总结
你已经尽到责任了，问题分析得很到位，建议也给得很中肯。遇到这种“嘴硬型”同事，确实让人无奈。实在不行，就让老板多关注下实际业务损失，毕竟发错货每单损失50美金，老板肯定更在意这个。
如果老板信你，直接推动技术方案的升级。如果老板更信他，那就让实际损失来“教育”他们吧。
最后一句：你很专业，继续保持！遇到杠精，就当练习情商和耐心了。
如果需要相关技术资料或建议方案（比如UUID、雪花算法代码示例），可以随时问我！
