昨天烧录机器，测试对方更新的一个库： 开始正确。后来莫名其妙崩溃。反复烧了几次，都错误。复制了老版本的库，正常。再改回新版本，崩溃。 　　于是把整个打包目录给了对方，他一对比，发现文件不对： 于是 用MD5测试虚拟机中的新版本，有差异。从WINDOWS复制ZIP，再解压，MD5正确。重启虚拟机，再复制，正确。

刚入职不久，突然线上夺命连环call，系统进不去啦！一查报错，谁tm把数据库的写权限关了？ 赶紧修改用户权限，上线，没问题了，长吁一口气。 如果你这么操作的，那你就翻车了！ 这次bug的真正原因是，该项是读写分离数据库，对方运维启动 写数据库失败，系统写入操作自动切换到 读数据库了，而读数据库没有写权限反而才是正确的！ 最后系统在读数据库写了一批数据，这时写数据库启动，把读数据库的数据同步

有经验的卖家都清楚一条listing的好坏将直接影响着产品的排名和权重，对于产品的销量和转化更是起着至关重要的作用。 　　最近，船长BI正好看到有卖家反映因修改listing导致销量暴跌的情况。据该卖家表示，自己有两条listing，没有开广告，每天都能稳定出个几单。但是，接下来的一波操作，卖家把原本自然稳定出单的listing给彻底整“死”了。 从该卖家反映的问题来看，促使其修改listin

昨天作死把用labelImg标记生成的xml格式文件批量改了名字，然后到了解析这些文件的时候，给我报了这些错： 也就是我原来用的名称是没有0开头的，比如我原来的名称是621.jpg，改了之后是0621.jpg。 结果我搞了半天愣是没想到哪里有问题，欲哭无泪。 当天晚上躺在床上还在思考是不是因为我把名字改了，然后到了第二天。 第二天早上，我忽然想起来可以打开xml文件查看里面的内容，于是果断