谢谢，有被 1#笑到

说难听点，这个 app 实现出来属于那种上限不高但下限极低的类型，做的人要骂，用的人不会用第二次

超低下限：
1. 快递盒子上的取件码必须至少要对着拍照侧，才能做图像识别，否则虚空识别取件码？
这一点上就能让产品经理被骂得狗血淋头，因为这需要放快递的小哥、整理快递的菜鸟驿站老板、取快递的用户的通力配合，每次放 /整理 /拿快递都要保证所有碰到的快递盒的取件码不错位不至于消失于镜头。而且那种两侧均可取放的超市货架式快递架怕不是要贴两个取件码？你问下现在出取件码的机器支持这么出不？

2. 做取件码图像识别的小组肯定要三天两头骂街，而且最后的结果还不理想
现在光是直接摆检测台子上进行近距离单一对象的图像识别，就有不小的概率会失败，你要让做图像识别的人去精准识别用户拍出来的千奇百怪、百分之五十几率严重欠曝 /过曝 /逆光 /暗光、距离不够广角来凑的高度畸变的照片，而且每个取件码可能还因为占画幅太小+手抖而模糊不清？

3. 用户要么退远要么举高，费劲半天连拍十次，7 次里识别失败，3 次里出来三个结果，但没一个是他的，最后还是靠自己肉眼搜索出来

上限不高：
因为摆放的本来就很整齐，用户自己就快速一眼找到了，压根用不到这个 app

@moonkiller #3 更进一步，本来地球一百年后屁事没有，这一撞的🦋效应把整个小行星带全拉下来了🐶

@manasheep #24 我也知道它肯定有充电保护
但它和（以前的）笔记本比，在供电线路上应该还是两种东西
我记得之前看到过哪位大佬的科普，手机、掌机这些便携式设备，其供电线路是以电池为主体，电都是先充到电池里，然后再供给给后续电路使用，不可能不装电池单插跟充电线就让你使用，部分特殊手机以及飞线直接供电的除外
而笔记本，至少据我所知以前可以自由更换电池的笔记本，电池只是一个可选项，它们是可以直接插上电源就能供电使用的，插电使用时，电流可绕过电池直达后续电路，除非电池要充电，才会匀出来一部分给到电池充电

也就是，本质上允不允许直接供电的问题
而这个问题的不同结果，在 win 掌机上可能有非常大的差异，因为手机的功耗比 win 掌机要小得多得多，如果 win 掌机是走电池再供电，则对电池的损耗会大得惊人，特别是在玩 3a 那种 cpu 得上 15w 、25w ，整机功耗上 40w 的情况

话说这类掌机可以插着电一直玩吗？会不会玩不到一个月电池报废鼓包炸机器的？

感谢又有 OP 来劝退 PDD 下单

以下仅针对 5.7 之前的版本，之后的版本不确定

mysql 自定义变量的执行顺序是这样的，飘忽不定（可能按行可能按列，甚至还可能行列交叉赋值），不知道有谁能有确切的文档描述它的执行顺序 /执行规则
所以在不确定赋值顺序的情况下，在多个列里重复使用自定义变量是个危险的“未定义”行为

楼上+1 ，都外接了，为什么要选择 2.5 的妖魔鬼怪

@plko345 #4 你可以先试着把数据库的内存压榨到 99%，最简单的加缓存，只要是业务上提升出色且因为效果好还有提升需求，那就加，否则真没必要
linux 上跑着，除非卡硬盘 IO 或者你还跑了其他重要占内存的服务，否则还真没其他影响，不会有什么卡顿的

每次谈到学习，评论都一片祥和，真是人间美景（。

看完又想到了 linus 的名言

以 pgsql 为例，每行数据 hash 一下加上主键（单一主键或者联合主键都行）后再比较最好
如果下面的 sql 一次跑不出来，先分别生成两张表然后用那两张新表去做最后的 join 比对

with t1 as(
select f.primary_key,
md5(CAST((f.*) AS text)) as hash
from foo1 f
)
, t2 as(
select f.primary_key,
md5(CAST((f.*) AS text)) as hash
from foo2 f
)
select t1.primary_key
from t1 join t2 using (primary_key)
where t1.hash = t2.hash

@plko345 #1 70%算什么高，抠门公司可以直接给你压榨到 99%（。
不过除非你数据库因为缓存不够大日常卡在硬盘 IO ，否则真没必要