@jobs0 #9
这个扩展只是其中之一，你如果没有 css 问题，那就只能逐个扩展排查了，反正站长也不可能公开 token 算法
v2ex 是依靠 cookies token 的，影响 cookies，以及浏览器指纹的扩展都可能

我在反馈节点写了一帖，发现是外部 css 引起问题（持续两年多，最近才搞清楚），你参考一下
https://www.v2ex.com/t/760297

@3country #9
你还是去问清楚详细需求吧，一般大周期（季、半年、年）的统计都是专门做报告的，实时的统计更多用于监测“异常”和分析变化趋向，年报数据每几分钟变一次是很奇怪的 —— 报告不可信
至于用什么，那不是我擅长的

@3country #4
年度统计不需要实时吧？截至到一个时间的统计，然后存统计结果

简历不写就行了，就算签了合同（试用期？），对方应该也没帮你缴纳一分钱社保等等吧
背调出来就说到职发现对方给的岗位不对，不知道是不是他们搞错了

简历不是详历

老实交代，到底你俩中谁是阿里的？

A 可以问 B，“离婚的话，咱俩谁不努力？”
B 可以问 A，“要不是我答应嫁给你，你跟谁说你努力了？”
🐶

你就缺根筋，主观话题跟老婆讨论个啥？你要让她“认识到自己错了”？

至今也没认识几个，不关心就不上心
跟分不清香奈儿和 channel 一样，🐶

你可以把机箱风扇都拆了再比较一下

还是一句老话说得好：直到官方肯定才能信
官方否定也不能信

撒盐是驱鬼辟邪的一种操作

补充：你这样重复 yield 这个字典，里面还有 open，这样不是打开一万次（每文件一次），而是打开一万次的阶乘！！

前置重点：看下面第四点

我做过类似的，不过不是 base64，而是 CRC32，应该比 base64 耗时，8K 张图片
建议：
1. base64 移出 os.walk，同时也建议 os.scandir 替换 walk，递归只 yield 返回路径就好了
2. 多进程可以尝试换成 Pool+Pool.imap()，注意要用 close()，参考手册，Pool.close 要在 Pool.join 前面，同时限制线程数量
3. 小问题，扩展名列表只有小写，你确保一万多文件扩展名都没有大写字母么？不小心会漏掉文件的
4. 最后是严重的逻辑错误，img_to_base64 里面的 r 是个字典，你最后 return 一次就够了，怎么是不停 yield 这个字典呢？我觉得这是最大问题

我以前考虑是遍历的同时处理文件，还是遍历了路径再处理文件，后来我看到遍历树是递归+yield，就不纠结了
递归里面处理文件，处理文件 yield 结果，这两个都不是好想法，肯定有说不清的问题（因为 python 是调用系统 API 打开文件的），所以直接就用递归 yield 路径，然后再考虑其他方式优化文件处理

@liprais #2 说的是关键点
不要在 with open 里面 yield
yield 相当于生成器，数据是集中处理的，不是逐个处理，这就造成打开太多
简单说就是全部 yield 的数据 都 获取后集中才处理，这时每个 open 都没有 close

女一是我喜欢的演员，🌹