1. 为什么偏偏是第25天

码农圈里一直有个不成文的说法：一件事如果能坚持21天，就会形成习惯。但真正动手做过长期打卡的人都知道，第21天往往只是错觉。真正难熬的是第25天，因为新鲜感已经散尽，习惯还没完全固化，手头的项目也恰好进入"改bug比写代码多"的枯燥阶段。2026年1月21日，我手上的 某图像处理Demo 正好走到了Day 25。

这个项目本身不复杂，一句话就能说清楚：做一个批量图片整理工具，解决照片越攒越多、重复图删不干净、模糊图舍不得扔的问题。核心就三个模块：图片哈希去重、清晰度评估、自动分类归档。听起来像是随手就能写完的小工具，但真正往深了做，才发现每个模块都能挖出一堆坑。第25天这个节点，我刚好在跟哈希去重模块的性能较劲，顺便把前24天积累的烂账清了一遍。

这篇文章不只是记录某一天的开发流水账，我想把Day 25前后踩过的坑、做过的取舍、验证过的方案完整梳理出来。如果你的手头也有类似"看着简单、做起来琐碎"的小工具，或者你也在坚持某种长期技术打卡，这篇应该能帮上一些忙。

2. 项目思路的演进：从能用到好用

2.1 最初的设计：以为一天就能写完

最开始的想法很天真：把所有图片统一缩放到8x8像素，算平均值，生成一个64位的感知哈希值，再用汉明距离做两两对比。距离小于5就判定为重复图片。这套逻辑在概念上完全说得通，很多开源的图片去重工具也都是这么干的。但实际跑起来就发现问题了：当图片数量从100张涨到5000张的时候，两两对比的时间复杂度是O(n²)，算力直接爆炸。

那时候我还是用单线程跑的，5000张图片两两比较意味着大约1250万次汉明距离计算。每次计算本身不慢，也就几十纳秒，但加上哈希生成、文件IO、结果写入，整体跑完花了将近40分钟。用户真要处理2万张照片，等待时间会拉到几个小时，完全不可接受。

2.2 第25天的主要矛盾：性能与准确率的平衡

Day 25这天要解决的，就是让去重模块在保持准确率的前提下，把处理时间压缩到一个用户能接受的范围内。我给自己定了两个硬性指标：

• 处理2万张图片的总耗时控制在10分钟以内
• 重复图片识别的误判率不高于2%

10分钟这个指标并不是拍脑袋定的。参考了市面上一款主流照片整理软件在同类任务上的表现，人家2万张图片大概用时8分半。如果我的工具跑到15分钟往上，就完全没有竞争力了。误判率2%则是出于实用考虑——宁可漏掉一些重复图，也不能把火车票截图误判成风景照然后给用户删了，一旦误删就再也没有挽回余地。

要实现这两个指标，光靠算法微调是不够的，必须从数据结构和调度方式两个维度同时动手。

2.3 三个关键决策：分桶、感知哈希进阶、多线程

我在Day 24晚上理了一遍思路，最终锁定了三个改造方向。

第一个方向是引入分桶索引。与其做全量两两对比，不如先按图片尺寸和文件大小粗筛一遍，尺寸差异超过30%的图基本不可能是重复图（因为感知哈希对缩放是敏感的，虽然有一定容错，但跨度太大的缩放会改变太多像素细节）。这样对比池能被压缩到原来的20%到40%。

第二个方向是把感知哈希从8x8升级到16x16。8x8哈希只能用64位数据表达图片特征，对真实场景里的常见干扰——比如加了个水印、微调了亮度、轻微旋转——特别敏感。16x16哈希有256位信息量，虽然计算量翻了好几倍，但经过一个前置的粗筛阶段之后，真正需要做精对比的图片数量可能只有几千张，256位计算的额外成本完全摊销得起。

第三个方向是多线程。现代CPU不管笔记本还是台式机，起步就是8核，有些甚至到16核。单线程跑哈希和比对比是纯粹的资源浪费。Python里有现成的concurrent.futures，Java里也有并行流和CompletableFuture，关键在于怎么把任务拆得均匀、避免线程切换的额外开销。

三个方向看似独立，实际是一条链路：先分桶缩小范围，再用高位数感知哈希保证精度，最后用多线程榨干硬件性能。单靠任何一个方向都达不到10分钟的目标，组合起来才行。

3. 核心模块的具体实现细节

3.1 感知哈希的升级与参数选择

感知哈希的原理是通过缩小尺寸、灰度化、计算DCT低频分量、取中位数二值化这几个步骤，把一张图片压缩成一个固定长度的指纹。8x8方案之所以误判率高，是因为信息量实在太小了——64个比特位，意味着全世界的图片理论上只有2^64种分类结果，听起来很多，但对高频相似的真实图片库而言，碰撞概率并不低。16x16方案的256位把分类空间扩到了2^256，碰撞风险直接降到可以忽略的量级。

具体计算过程我贴一段核心代码：

def phash(img, hash_size=16): # 1. 缩放到固定尺寸，忽略原始分辨率的影响 img = img.resize((hash_size, hash_size), Image.LANCZOS) # 2. 转灰度，去掉颜色干扰 img = img.convert('L') pixels = np.asarray(img, dtype=np.float32) # 3. DCT变换，提取低频信息（这块用scipy的二维DCT） dct = fftpack.dct(fftpack.dct(pixels, axis=0), axis=1) # 4. 只保留左上角8x8的低频系数 low_freq = dct[:8, :8] # 5. 用中位数做二值化，取0或1 med = np.median(low_freq) return (low_freq > med).flatten()

关键细节不在代码本身，而在第4步。输入尺寸从8x8提到16x16后，DCT矩阵变成了16x16，但最后取低频分量仍然只取8x8。为什么？因为高频部分恰恰是容易被压缩、加水印、微调亮度所干扰的区域，DCT左上角集中了图片真正的结构信息，右下角则是各种噪声。如果直接把16x16的矩阵全部二值化，得到的结果反而对干扰更敏感。这一点我一开始没想明白，盲目把全部256位都参与了对比，结果误判率反而上升了，后来才意识到低频分量才是感知哈希的精华所在。

3.2 分桶粗筛的思路与阈值选择

分桶策略不是随便按一个维度切分，而是结合了图像尺寸和文件大小两重条件。基本判断是：图像分辨率相差1.3倍以上时，即使内容完全相同，感知哈希也大概率会对不上，因为缩放过程中的像素插值方式会显著改变局部细节。这就等于天然给了一个剪枝条件。

具体实现时我用了一个多层桶：

def bucket_key(image): # 计算面积对数，按0.3为步长分桶 area = image.width * image.height return (int(math.log2(area)) // 3, int(round(math.log2(image.size_bytes))) )

这里用对数而不是线性值，是因为图像面积跨越了好几个数量级，线性切分会导致小尺寸图片全部挤进同一个桶，失去了区分度。每个桶内的图片数量被限制在几百张以内，两两对比的计算量降到可控范围。

粗筛的召回率大概能维持在95%左右。换句话说，100组真正的重复图片里，大约有5组会因为分桶条件太严被漏掉。这是个可以接受的代价，因为分桶漏检至少不会误删，只是少清理了几张重复图。如果追求更高的召回率，可以把桶的步长从0.3放宽到0.5，代价是各桶内图片数增多，计算量像滚雪球一样暴涨。

3.3 并发调度的三个坑

多线程改造这一块，如果只是简单地把任务丢进ThreadPoolExecutor，很容易踩到三个隐坑。

第一个坑是Python的GIL。如果是纯CPU密集型的哈希计算，开线程并不能利用多核——GIL保证同一时刻只有一个线程在跑Python字节码。解决办法有两个：要么用multiprocessing开进程池，要么把核心计算放到C扩展里。我对哈希模块做了一点重构，把DCT计算和汉明距离计算移到了NumPy的向量化操作中，利用NumPy底层释放GIL，这样线程池才有实际加速效果。用了一个简单的测试验证：4线程模式下，CPU占用能到280%到320%，说明多核确实被调动起来了。

第二个坑是文件IO的瓶颈。图片读取是IO密集操作，线程开多了反而会因为磁盘寻道冲突而互相拖慢。我的解决办法是分两阶段：先用主线程顺序读图、生成哈希、写入缓存文件，再启动多线程对内存中的哈希列表做对比计算。实测下来，读取阶段占了总耗时的60%左右，但顺序读取比乱序并发读取要快将近1倍。

第三个坑是任务分配不均衡。如果用桶ID作为分组的单元，每个桶的图片数量差异很大，有的桶有800张图，有的桶只有3张，直接按桶分发任务会导致线程闲置。我把所有桶里的图片对全部摊平到任务队列，让线程自己去取，最后用wait主线程同步。这样CPU占用率曲线平稳很多，整体耗时直接少了一截。

4. 实测数据与调优过程记录

4.1 处理 2 万张图片的真实耗时统计

我把一套包含2万张真实图片的目录作为测试集，来源是某开源图片数据集，混合了风景、人物、截图、表情包，大小从几十KB到十几MB不等。测试环境是某品牌台式机，CPU为8核16线程，内存16GB，硬盘是SATA固态。

第一轮跑原始单线程版本，结果惨不忍睹，2万张图耗时39分47秒。其中哈希计算占了大概14分钟，两两对比占了24分钟，其余时间花在IO上。第二轮加上分桶粗筛，对比阶段直接降到6分钟左右。第三轮把感知哈希位数从64提到256，哈希计算涨了约3分钟，但对比阶段的精度提升让桶内需要精算的图片对减少了很多。第四轮上了线程池，整体耗时最终落在8分12秒。

最后一轮的数据说明，IO和计算的重叠设计起作用了。哈希计算阶段虽然还是顺序读图，但利用多线程并行做DCT，整体时间压到了5分钟以内。

4.2 准确率验证：用 200 组人工标注图片做测试

耗时达标还不算完，准确率必须用人工标注数据来验证。我从测试集中随机抽了200组"疑似重复"图片对，人工标注出真正的重复图有153组，剩余47组是相似但不同的图（比如同一场景不同角度、同一张图不同滤镜）。用最终版工具跑完，结果如下：

• 153组真实重复图中，识别出重复的有151组，召回率98.7%
• 47组相似但不同的图片中，被误判为重复的有3组，误判率约6.4%

误判率超出我之前设定的2%目标。我追踪了一下这3个误判案例，发现它们都有共同特点：背景是大面积的纯色或渐变（蓝天、白墙之类），DCT低频分量的差异被大幅压缩，导致感知哈希高度相似。这种情况在风景照片里其实很常见，两座完全不同的山分别配上大面积蓝天背景，就很容易被误判为重复。

解决办法是加一道面积惩罚项：在比较图片时，统计两张图中显著不同的区域占整张图的比例，如果比例超过某个阈值，即便哈希距离小于5，也判定为不重复。具体实现用的是像素级别差分加形态学膨胀，这部分复杂度比较高，我后来又迭代了两个晚上才把误判率压回到1.8%左右。

4.3 用户体验层面的微调

性能和准确率都搞定了之后，Day 25下午我还顺手做了一批交互层面的调整。最受用的是给重复图片分组预览的界面加了"组内缩略图"和"文件大小对比"两个面板。单纯告诉用户"这两张图重复"是不够的，用户需要快速判断保留哪张。缩略图按分辨率降序排列，默认勾选保留最大分辨率的那张，用户可以一键确认，也可以手动切换。

另一个微调是处理结果报告。原来只给一行"共删除重复图片37张"，现在改成生成一份CSV报告，列出每一组重复图片的文件路径、文件大小、哈希距离和操作结果。用户如果删错了，能顺着报告找回原始路径。我在实际投给某公司测试的时候，发现这个CSV报告反而成了他们最看重的功能，因为他们需要跟客户核对清理明细。

5. 高频问题与排查经验实录

5.1 内存占用爆满的两个真实场景

第一版多线程代码跑了一半，我瞄了一眼任务管理器，内存占用居然到了11GB。后来定位到两个原因：一是读取图片时用的是PIL的Image.open，没有及时关闭文件句柄，导致图片对象一直驻留在内存中；二是哈希列表和桶索引都使用了Python原生对象，每个键值对的内存开销远大于C数组。

修复方案是：读完像素数据后立刻调用img.close()，并把哈希结果转成NumPy的uint64数组。图片对象是典型的临时数据，用完之后必须马上释放，拖到GC自动回收会积压大量垃圾。这个改动之后，2万张图片的内存峰值稳定在1.2GB左右，16GB的旧机器也跑得动。

5.2 哈希碰撞导致误判的边界情形

感知哈希毕竟不是密码学哈希，它的设计目标就是"相似图片得到相似指纹"，所以碰撞不仅在理论上存在，在实际测试中也一定会碰到。我遇到的最典型案例是一张纯黑色图片和一张纯白色图片，按感知哈希计算，它们的DCT中位数都落在边界附近，二值化结果几乎一样，哈希距离直接小于5。

这类边界情况很难用哈希本身解决，只能靠额外的规则兜底。我的处理方式是对颜色直方图做一次简单统计，若两张图的颜色方差都特别低（即都接近纯色），直接跳过感知哈希比对，降低它们的重复判定优先级。实际效果不错，纯色图片之间的误判率降到了0。当然，纯色图片在真实目录中占比极低，这样做不影响整体召回率。

5.3 文件名后缀迷惑性：两种格式其实是同一张图

日常场景里，图片格式混乱是常态。同一张照片可能存在.png和.jpg两个副本，PNG的尺寸、大小和JPG完全不同，粗筛分桶的时候很容易被分到不同桶里，导致完全跳过对比。针对这个问题，我在读取文件时强制执行统一解码：无论后缀是什么，都按实际文件头解析，然后统一转成RGB格式再做哈希。这样能保证格式不同但内容完全一致的图片出现在同一桶内，不会漏检。

5.4 从日志里能看出什么

整个改造过程，我坚持给每个阶段打日志。日志不是用来排错的——至少主要不是——而是用来观察处理画像。比如"查询:图片hash 000021f, 146 bytes from index"这种级别的一条条细节，能帮我判断哪个步骤的等待时间异常。遇到某个文件特别耗时，日志会显示它在解码阶段卡了10秒，这种信息能精确定位到某张损坏图片或超大分辨率图片。用一句话概括，日志最大的作用是让你知道"卡顿是偶发的还是必现的"。

6. 给同样在做打卡或小工具的人一些建议

写到最后，分享一点个人体会。Day 25这个节点，最让我受益的一个习惯是把每天的工作拆成"完成、进行中、卡住"三类记录下来。完成的事让人有成就感，进行中的事能逼着第二天接着干，卡住的事则值得花时间深挖。这个做法前半程可能看不出效果，到三个星期之后回头看，整个项目的脉络清清楚楚，哪天在解决什么问题、踩了什么坑，一目了然。团队协作的时候，直接丢给别人一份这样的记录比临时讲给你听要省力太多。

另外，大多数"小工具"项目真正消耗时间的不是功能实现，而是边界情况和性能调优。如果你也在做类似的东西，我的经验是：早一点引入真实测试数据，早一点打磨并发和IO，别等到功能都写完了再回头优化，那时候改动的牵涉面会大得多。

Day 25远不算终点。这个图像整理工具后续的扩展方向已经基本清晰：接入智能相册分类、增加面向移动端的Web服务、还有依据EXIF时间自动归档。不过那些都是后面的事，现在先把第25天的进度完整地记下来，它本身就是自己最好的复盘材料。