*场景：互联网 / 后端开发，自建服务运维。*

## 起因

有段时间我在整理聊天里收到的截图——设备面板、报错日志、配置页，都是写文章要用的素材。习惯是"先用着，回头再存"。直到有一天我想找回一张图，翻遍聊天记录，发现它没了。

我这才注意到一个事实：**聊天软件里打开或发送过的图片，会在本机临时目录落一份文件，过一阵子目录会被自动清空。** 尤其是清理了聊天记录之后，那些临时文件说没就没。我把"缓存"当成了"存档"，这是个危险的误会——缓存是软件顺手放的，它随时有权清掉，而且不会问你。等你想起来要的时候，它大概率已经不在了。

所以正确姿势不是"回头存"，而是"收到即落地"。把临时目录当成一个"随时会消失的输入源"——它给了我图，但不保证图会一直在，我得在它消失之前把图拿走。这个心态转变，是写这个脚本之前最重要的一步。

## 第一回合：定位临时目录

我先摸清图片到底落在哪。实测下来，它们分散在两类路径里，按年月和哈希分子目录：

| 临时目录特征 | 说明 |
|---|---|
| `.../business/InputTemp/<年-月>/<哈希>/` | 接收类图片的落点 |
| `.../temp/RWTemp/<年-月>/<哈希>/` | 另一类临时图片的落点 |

目录名里那一长串是哈希，没有规律，文件名本身看不出内容。也就是说，想从这里面捞图，不能靠名字，只能靠"时间 + 尺寸"来挑。这也决定了后面脚本的过滤逻辑必须建立在这两个信号上，而不能指望从文件名读出任何语义。

## 第二回合：写脚本，收到即抢救

思路很直接：定时扫描这些临时目录，把**新出现**的图片复制到我的工作目录留存，并且带去重。

```python
import os, shutil

def sweep(src_dirs, dst, seen, cutoff):
    for d in src_dirs:
        for root, _, files in os.walk(d):
            for f in files:
                if not f.lower().endswith((".png", ".jpg", ".jpeg", ".webp")):
                    continue
                p = os.path.join(root, f)
                key = (f, os.path.getsize(p))        # 文件名+大小 粗去重
                if key in seen:
                    continue
                seen.add(key)
                if os.path.getmtime(p) < cutoff:      # 只抢救近期出现的
                    continue
                shutil.copy(p, os.path.join(dst, f))
```

粗去重用"文件名 + 大小"够用，但哈希命名的文件经常同名不同内容，或者同内容不同名。更稳的做法是上内容哈希，按字节算指纹，这样无论名字怎么变都能识别是不是同一张图：

```python
import hashlib

def file_hash(p):
    h = hashlib.md5()
    with open(p, "rb") as fp:
        for chunk in iter(lambda: fp.read(8192), b""):
            h.update(chunk)
    return h.hexdigest()
```

真正的麻烦在后面——**同一天的目录里混着大量无关图片**，得靠时间和尺寸反复过滤，否则工作目录会被塞满废图，反而更难找。我特意把扫描做成增量式：每次只处理 cutoff 之后的新文件，不重复扫全量，既快又不会把已抢救的再捞一遍。

## 踩到的坑

**坑一：文件名无规律。** 全是哈希命名，没法靠肉眼挑。最后只能依赖修改时间（刚收到/刚生成的排在最前面）和内容尺寸（截图通常偏大）来筛。

**坑二：无关图片极多。** 临时目录不是为我一个人服务的，里面混着表情包、缩略图、各种缓存。过滤条件设松了会捞一堆垃圾，设紧了又怕漏掉真图，反复调了几轮阈值才稳住。

**坑三：去重要趁早。** 如果等目录被清了一部分再去重，同一张图的多个副本可能只留了损坏的那份。所以"收到即抢救"比"攒一波再处理"靠谱，落地优先于整理。

## 结果

一次例行扫描，从临时目录里抢救出 8 张待用截图，其中几张在聊天记录之外已经找不到原件了。要不是脚本提前落地，这几张就跟着缓存一起没了，后面写稿都得缺图。

## 三条经验

**第一，"看到图先存下来"。** 依赖聊天软件的缓存不可靠，重要素材要第一时间落到自己能控制的工作目录，别等"回头再说"。

**第二，临时缓存要当不可靠存储。** 自动化里凡是读这类目录，都要假设"它随时会消失"，流程上优先复制、再处理。把它当成一次性水源，而不是仓库，很多"图怎么没了"的困惑会自然消失。

**第三，去重和过滤是配套动作。** 没有去重的抢救会把垃圾越积越多，没有过滤的目录又挑不出真图，两者一起上才稳。落到日常习惯上，就是任何从聊天软件流出的素材，先过一遍这个脚本再谈别的，别等它进缓存被清了才想起来找。

---

*本文记录的是实际调试过程，所有命令行输出和错误信息都来自真实测试。*

#WorkBuddy #AI办公![md25-1-临时目录落点定位.png](https://developer.qcloudimg.com/http-save/yehe-12646891/37c1dbb4987fa982ef7b995d16974a61.png)![md25-2-收到即抢救sweep.png](https://developer.qcloudimg.com/http-save/yehe-12646891/4f9e9aca0798437fdc974e5d469d014a.png)![md25-3-抢救结果过滤取舍.png](https://developer.qcloudimg.com/http-save/yehe-12646891/093871db00b1e5b3c0e579ecc60e3597.png)

有段时间我在整理聊天里收到的截图——设备面板、报错日志、配置页，都是写文章要用的素材。习惯是"先用着，回头再存"。直到有一天我想找回一张图，翻遍聊天记录，发现它没了。

微信图片临时目录会自动清理：我写了个"收到即抢救"的脚本

编程语言

运维

后端

2026上云采购 | AI焕新·智启新局

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

微信图片临时目录会自动清理：我写了个"收到即抢救"的脚本-腾讯云开发者社区-腾讯云

微信图片临时目录会自动清理：我写了个"收到即抢救"的脚本

微信图片临时目录会自动清理：我写了个"收到即抢救"的脚本

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐