这是一个创建于 162 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近遇到个事想和大家分享一下。 我们业务最近出了一个 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 是那种反驳性型人格，而且比较自大那种，我快待不下去了
 |
1
foufoufm 2025 年 8 月 8 日  10
为什么是你待不下去而不是他待不下去？
求教 |
 |
4
Mithril 2025 年 8 月 8 日 26
哈希算法是给你“验证”用的，不是拿来做“唯一标识”用的。因为它存在碰撞的可能。
简而言之，哈希值一样，不代表原始值就一样。而哈希值不同，则肯定原始值不同。 这就是为什么科班教学很重要。 你这个需求就应该使用 uuid ，你用 SHA1 也避免不了碰撞。 |
 |
6
InfiniteMirage 2025 年 8 月 8 日
@honkew 这种让老板知道问题在他那里不就好了，把问题越搞越大，老是出问题，然后你向主动请缨，接过去改，改完之后没有任何问题就成你功劳了，就显得那个同事不行，让老板记住
 |
 |
7
wogogoing PRO md5(microtime(true))
PHP 吗？ |
 |
8
honkew OP @InfiniteMirage 服务器在他那里，即便是我要过来改了，我怕他后面又动手脚
|
 |
10
sparklee 2025 年 8 月 8 日
不能再加上自增 id 吗
|
 |
11
changnet 2025 年 8 月 8 日 1
有什么奇怪的，只要你接触的人多，你就会发现，有些人做一辈子也没长进。我见过多了。
像这种情况，你直接说是谁谁谁的问题，你自己不要再去解决这个问题，让上级去接触那个人。 |
 |
12
coderluan 2025 年 8 月 8 日 1
职场所有同事的问题都是领导的问题，看楼主描述你们是老板不懂技术每两个程序员的小公司，建议尽快早寻出路，你那同事就是一直呆在这种公司才变成现在这样的。
|
 |
13
BeforeTooLate 2025 年 8 月 8 日
@honkew 如果 php 直接 bin2hex(random_bytes(16)) 不就行了，这样下去估计他要 这样做了，哈哈哈。md5(microtime(true) ) . mt_rand(1, 999999))
|
|
14
honkew OP 1
@BeforeTooLate 不知道为什么他对时间情有独钟啊，崩溃
|
 |
15
mosfet 2025 年 8 月 8 日
外部可以直接调用这个接口，不用做验证？
先甩锅，再准备跑路吧 小作坊也没这么草台啊 |
 |
16
bfdh 2025 年 8 月 8 日
意思是把 pdf 存临时文件再发给请求端，然后又重名了？不应该是直接发给客户端吗，为啥还要存临时文件？就算要存临时文件，不做重名检查吗？
|
 |
17
la2la 2025 年 8 月 8 日
工作久了也就无所谓了
这种情况直接给老板说明白，跟自己没有关系的问题，你应该是看戏的心态，跟你有啥关系啊 |
 |
18
msaionyc 2025 年 8 月 8 日
对这个同事来说，这件事性质已经不是 bug 不 bug 了，尤其是到了老板面前还争执过，你不要直接和他对话了，找他领导或者跟老板说吧。
|
 |
19
Greendays 2025 年 8 月 8 日
这完全是他的问题啊，解释清楚就行了。接口返回错误和你有什么关系呢？你也没得办法的啊。
|
 |
21
rabbbit 2025 年 8 月 8 日
不要当老板和他的传话筒，想办法让老板直接去找他。这样你就轻松了
|
|
22
honkew OP @la2la 只要仓库那边发错了就找到我这边，我还有其它工作要做，被这种问题天天烦。
老板也指挥不动他，老板长期不在国内。只能让我改想让我“兼容”一下 |
 |
23
MuSeCanYang 2025 年 8 月 8 日 1
用 UUID 为啥会不安全啊？ 完全没理解他的脑回路是啥。
|
|
24
rabbbit 2025 年 8 月 8 日
不要给他建议，让他自己解决吧。看样子他也不领你情
|
 |
25
ooTwToo 2025 年 8 月 8 日
他连 AI 都不用的吗？
|
 |
26
Vindroid 2025 年 8 月 8 日
责任已经分清了，会上讨论过，你也给出了方案，你就不要那么在乎了，后续问题全部转给他就行了
|
 |
28
lixining 2025 年 8 月 8 日
啊我觉得 md5 （ time()）又快又好啊。。。难道我是你同事？
|
 |
29
coderzhangsan 2025 年 8 月 8 日
不牵扯你，就不要管；如果牵扯到你，就把问题反馈领导，说明原因，剩下让领导处理，固执的人没办法通过沟通解决的。
最后，md5(microtime(true))这种方式生成随机数，最简单的方式加个随机数就可以大幅降低重名的概率，md5(microtime(true).mt_rand(10000000, 99999999))，都 25 年了，ai 都普及了，甚至直接去谷歌随便一搜索就有大把解决方案，我不相信这哥们蠢成这个样子，我猜测大概率是工作上，你让他不爽了。 |
 |
30
sojourner 2025 年 8 月 8 日
让老板知道是哪里出了问题，然后你给出解决方案。如果对方不改或不按给定的方案修改，你跟老板说清楚后剩下的和你无关。再次出问题，老板问的时候将问题产生的原因再次说清楚、给出解决方案，对方不改、或不按给定的方案解决，你报给老板，剩下的和你无关。你没有决定权的时候，让老板决定。我之前也总觉得很多人煞笔，现在我想清楚了，如果别人不煞笔，怎么能显出我的牛逼？
|
 |
31
Foxkeh 2025 年 8 月 8 日
建议服务端用雪花算法生成，杂凑和随机的都没法保证绝对不碰撞
|
 |
33
frankkly 2025 年 8 月 8 日
不是，直接怼他啊，别给他留面子啊
|
 |
34
Subfire 2025 年 8 月 8 日
这个唯一 id 是服务器要保证的, 你这又没 bug 干啥老找你? bug 单转给服务器就行了
|
 |
35
angeni 2025 年 8 月 8 日
你这个层级解决不了就找能解决的，你是打工的又不是和公司生死存亡的死士。该和稀泥就和
|
 |
36
ATKLLL 2025 年 8 月 8 日
是雪花算法性能不够高 还是 UUID 不够多 非得用这种乱七八糟的 ID
|
 |
37
fkdtz 2025 年 8 月 8 日
讲理已经不行了，甩锅就行了。
这个场景需要绝对唯一 ID ，建议记录详尽日志， 出问题直接给老板，说他返回的 ID 不一致，所以导致发错货，  |
 |
38
garlics 2025 年 8 月 8 日
你让他改雪花算法 uuid 啥的，他肯定不愿意。让他改成 date("YmdHisv") . mt_rand(1000000, 9999999) . mt_rand(10000000, 99999999) 吧，低并发的情况下肯定不会出现问题。
|
 |
39
R1 2025 年 8 月 8 日
这个一般用雪花数吧，MD5 主要用来校验吧
|
 |
40
pointerman 2025 年 8 月 8 日
|
 |
41
javalaw2010 2025 年 8 月 8 日
先解决问题，他坚持不处理你就先看看能不能给他擦个屁股，自己加一个锁阻止并发，然后再跟他 battle 。不然公司黄了大家都没饭吃。
|
 |
42
chairuosen 2025 年 8 月 8 日
三包法规定，同一零部件修三次还不好，可以退车
|
 |
43
jasonyang9 2025 年 8 月 8 日 via Android
不管他用什么算法如何实现，必须满足唯一 id 的需求，无论 qps 是多少
|
 |
44
irisdev 2025 年 8 月 8 日 via Android
？用运单号不安全用时间戳就安全了？这什么脑回路，运单表没有主键吗，直接用运单表主键不就行了
|
 |
45
irrigate2554 2025 年 8 月 8 日
绝了，随机 uuid 不比时间 hash 安全么，时间 hash 还可以根据时间猜到
|
 |
46
deplives 2025 年 8 月 8 日
uuid 不就是干这个事儿的吗？
|
 |
48
fengcs 2025 年 8 月 8 日 1
他不改就你改嘛，搞个令牌桶，1 秒处理一个请求
|
 |
49
wangtian2020 2025 年 8 月 8 日
以为时间不会重复的只能说纯蠢，这种写垃圾代码坑人的不少，就是没有基础的编程思维，这种人真适合来写前端，前端这种“对错”少，顶多不好看功能不能用，但不会出“错误”
我和 op 一样是那种爱操心的性格，同事说服不了的话那就没办法了，要么跑路要么忍，反正把话都跟 leader 讲清楚，有解决方法不用就不是你的问题了 说起来，快递站的系统有人手机号末尾和姓和我相同，结果老是发错短信，代码跟这个人写的一样蠢 |
 |
50
jfbcb 2025 年 8 月 8 日
感同身受,工作也遇到了这样的.让他改东西,就说你针对他,这种让老板明白是他的问题.你不要跟他讨论这个问题.如果是 laravel,框架有 uuid 相关的实现函数.远离这种垃圾人.
|
 |
51
FrankAdler 2025 年 8 月 8 日
没问题的，你不应该请求速度这么快
真牛逼啊 |
 |
52
zhouxiaoxiao 2025 年 8 月 8 日
你做个记录，每次下载下来的 ID 都记录下来，出现重复 就直接报错；把错误的问题来源直接指出来； 因为出问题的环节在你这里，而你又依赖他的接口； 所以直接报错，报出原因；
|
 |
55
elevioux 2025 年 8 月 8 日 1
直接组个随机字符串也比 md5(一堆东西)好啊。我也是写 php 的，有些人确实“十年如一日”，技术不见长进的。
|
 |
56
xz410236056 2025 年 8 月 8 日 1
年级越大的开发越这样，拒绝学习，拒绝接受新事物，死不认错。
|
 |
57
Felldeadbird 2025 年 8 月 8 日
工作久了，菱角没了。换成我的话，不是我的问题我不去修复，也不给建议了。对方什么时候修复，我这边什么时候就正常工作。
|
|
58
xz410236056 2025 年 8 月 8 日
@lixining 明明有标准 API 为啥不用自己弄不标准的算法啊
|
|
59
xz410236056 2025 年 8 月 8 日
@Felldeadbird 你没遇到垃圾领导，我们厂（也可能就我们组这样），找到你了那你就是你倒霉甭管谁的责任你都得负责推，作为客户端/前端 那肯定先找你啊，客服、用户又不懂，就是无赖。
|
 |
61
min 2025 年 8 月 8 日
你做一个预防性动作，发现重复就前台把单拦住，不让发出去即可
|
 |
62
bitmin 2025 年 8 月 8 日
这是你领导的问题你急啥急，这就不是你的问题，你和领导说清楚，出事也是你领导被骂
能解决的自己解决，解决不了的告知领导，让领导解决，自己不要放在心上 你是打工人，你不是老板 |
 |
63
IamUNICODE 2025 年 8 月 8 日
为什么用时间生成这种奇奇怪怪的随机数 id 啊，自增，uuid 是不香么
|
 |
64
zgzhang 2025 年 8 月 8 日
这种人就是又菜又犟，努力学习离开这种垃圾地方，去大厂遇到这样的垃圾的概率非常低，你们老板缺乏基本的技术判断力，所以这么捣糨糊
|
 |
65
wenjie83 2025 年 8 月 8 日
碰到过类似的情况,也是请求过快导致的对面接口异常,反馈给对方连个回应都没有,没把法只能手动增加请求间隔
|
 |
66
duzhuo 2025 年 8 月 8 日
听起来是很严重的事故了
|
 |
67
patrickpu 2025 年 8 月 8 日
论物种的多样性
|
 |
68
moreant 2025 年 8 月 8 日
没有鉴权不用自增和时间戳可以理解，但是反正都是随机的，为什么不用 UUID ?
|
 |
69
Sfilata 2025 年 8 月 8 日
下次遇到这种问题直接让老板找他，他怎么改也直接让老板解释。你又拍不了板，在这儿当传话筒纯纯内耗。
|
 |
70
sagaxu 2025 年 8 月 8 日
他这么喜欢时间戳，可以用 uniqid("", true) 啊，虽然还是基于时间戳，但重复率比他写的低的多
|
 |
71
evan1 PRO 自己在前端写个队列，请求先入队，队列里每个请求发起之前等待 1s🤡
|
 |
73
zhhqiang 2025 年 8 月 8 日 via Android
毫秒级也是有机会重复的。数据库可以加个唯一 key 直接报错
|
 |
76
TORYOI 2025 年 8 月 8 日
time 肯定是不行的，日后有并发怎么办
|
 |
77
asmoker 2025 年 8 月 8 日 1
我说不结晶呢，原来是老鬼搞得~
|
 |
78
super452 2025 年 8 月 8 日
不是你的问题你慌啥，同事无法沟通直接找 leader 就行了
|
 |
79
issakchill 2025 年 8 月 8 日
求他问问 ai 吧...
|
 |
80
imnpc 2025 年 8 月 8 日
大概用的低版本的 PHP ，估计连 composer 都不支持，要不然多的是各种包能解决这个问题 ,最简单的参见 #13 就可以了
|
 |
81
lifeintools 2025 年 8 月 8 日
@evan1 你简直是个天才
|
 |
82
ben1iu 2025 年 8 月 8 日 1
这和工作十几年没关系 这可能是不到一年的经验 重复用了 十几年 实际有效经验一年都没有吧
 |
 |
83
DinnyXu 2025 年 8 月 8 日
我给你一个思路：首先你已经知道问题的根本原因了，你就要去做大量的验证，大量的测试和复现，因为大家都是干程序的，数据是不会骗人的，你也不用在那生气，也不用为这点小事烦心，为什么我说是小事，因为这些还远没有到勾心斗角的地步，一般这种狂的人你必须要用实际数据来说话，因为我以前也遇到过，我说他错了，他就是不信，我做了一些大量的数据反复验证，反复比对结果，一次给他整服气，以后好生给我说话
|
 |
84
xloger 2025 年 8 月 8 日
@MuSeCanYang doge 我不会的东西就是不安全的
|
 |
85
doyel 2025 年 8 月 8 日
照例说按以前服务器的并发能力，我直接经常 Timestamp 直接拼串用，只要再接个业务 id 或者其他什么标识，同一个业务 ID 被毫秒级请求到的可能性已经接近于 0 了
当然用 uuid 也可以，但是对于输出来说，之前的方法有先天的优势，文件名排序 |
 |
87
unco020511 2025 年 8 月 8 日
uuid 即可
|
 |
89
zhaoyihuaer 2025 年 8 月 8 日
知道问题在他那 还找你 这才是问题 [老板又好声好气的让他想办法改一下 最后他改了] 难道是小舅子？
|
 |
90
way2create 2025 年 8 月 8 日
按你说的这么离谱，这感觉已经不是单纯的技术能力问题了，纯属人脑子态度有问题，退一万步就算这个人初次使用的时候不会不懂没考虑到不在乎，那出问题但凡是个正常人也很快能修复。
虽然不是说什么都要用 uuid ，但也要考虑使用场景的，这 md5(time())明显不符合这种使用场景，而且重复了还会导致这样的后果是更逆天，太迷惑了 |
|
91
DinnyXu 2025 年 8 月 8 日
@tianzhiya 他说了没问题，那为什么老板还要找啊，2 边人对质一下，当面给他戳穿，如果他还要说没问题，那就在老板面前说清楚，如果再出现问题，就喊老板找他
|
|
92
DinnyXu 2025 年 8 月 8 日
@tianzhiya 对付无赖的人，拿出数据验证只是第一步，让更多人知道他是无赖，会打击他嚣张的心理，次数多了以后他的置信度就会降低，后面也不敢再过于狂妄
|
 |
93
Dora112233 2025 年 8 月 8 日
又菜又犟
|
 |
94
JKeita 2025 年 8 月 8 日
让你老板把他开了呗，还能怎么办，都造成公司损失了还不开
|
 |
95
ryd994 2025 年 8 月 8 日 via Android
他在重新发明 UUID 。然后试图用伪•snowflake 算法来实现 UUID 。
这个场景用 UUID 没毛病。性能不是问题，你们一天也就这么点快递，远没有到 UUID 会碰撞的量。也没有单调递增的要求（何况 hash 时间戳也没有单调递增） 说完技术问题，再说行政问题。你没必要和他争。他的代码他负责没毛病。你要铁证如山摆在老板面前，而且留下书面证据，保证他的锅扣在他自己头上。剩下的就是你老板的问题了。公司不是你开的，有什么业务损失是公司的事，公司怪罪下来是你老板的事。反正没你什么事。你做好给你分配的事情就好了。 |
|
96
Greendays 2025 年 8 月 8 日
话说这种情况直接拿包裹号来做资源 ID 不就可以了？包裹号不会重复的吧？
|
 |
97
sampeng 2025 年 8 月 8 日
尊重他人命运 放下助人情节。。你们相信这是一个工作 n 年人都没意识到的问题？？？
最多说 1 次，第二次爱改不改，又不是我写的代码。老板问就是代码不是我写的，问题没出我这。除非我是 leader 或者项目负责人，那是另一回事。 |
 |
98
Geon97 2025 年 8 月 8 日
老板知道是他负责的不是你负责的，也给他建议了，不听就随便吧 反正和你没关系
|
|
99
ryd994 2025 年 8 月 8 日 via Android 1
@honkew #14 时间戳比随机数省性能。对超高性能的系统来说，用时间戳没毛病。但是他这是邯郸学步，因为：
1. 我上面说过了，你们这点并发度还没到需要这个的程度。 2. 高性能时间戳也不是用 clock time 。读 clock time 同样非常耗性能，因为 syscall 至少需要一次上下文切换。高性能时间戳用的是 CPU 内部计数器 TSC 。这是一个从开机开始计算的单调递增数字，和现实时刻没有对应关系，只保证时长正确。 3. md5 的性能开销就更加没边了，和伪随机数比还指不定哪个快一点。random 函数用的是系统默认随机数源，拿到的是参杂真随机熵的伪随机数。对于外部系统来说足够安全了。而且现代 CPU 还自带熵源，也会被掺杂进去。总的来说是足够随机了。 真随机源也有，但是除了密码学应用，一般的情况不需要。 |
Select Language