手把手拆解照片视频智能分类：日期、分辨率与文件大小

简介在数字资产管理中面对成千上万的照片与视频高效归类是整理素材的关键。智能分类软件通常基于元数据如EXIF时间戳与文件属性构建多维分类体系。其中按日期、分辨率及文件大小分类是最常用且实用的策略日期利用拍摄时间作为天然时间轴提供年、年月、年月日三种粒度分辨率通过解析图片像素与视频画面尺寸区分高清与低清文件大小则按字节阈值识别大文件便于存储优化。理解这些原理后无论是摄影师还是普通用户都能借助工具快速管理海量文件甚至自行编写脚本实现自动化归档。本文以实操角度拆解这三类分类方法的实现细节与避坑指南助你建立高效的照片视频整理流程。手把手拆解照片视频智能分类软件里的按日期分类、分辨率分类和文件大小分类手机也好、相机也好拍了一两年之后存储卡里的照片和视频数量基本都会奔着几千上万条去。真正让人崩溃的还不是多而是乱DCIM目录下按月份生成的文件夹、微信保存图片的独立目录、屏幕截图和相机原图混在一起、视频横竖屏交错……这时候你才会意识到一款好用的照片视频智能分类软件最重要的反而不是什么花哨的滤镜而是它能不能在最短时间内把文件扔进正确的格子里。可能不少朋友已经用过一些自动整理工具分类方式通常围绕三个维度展开按日期、按分辨率、按文件大小。这套组合逻辑很接地气也几乎覆盖了日常整理的全部高频需求。标题里提到的按年、年月、年月日三种精度正是日期分类的核心设计而分辨率分类和文件大小分类则是解决找图和清空间这两类痛点的利器。这篇文章我会把每个功能的定位、实现思路、实操流程和踩坑经验都梳理一遍希望能帮你自己动手搭一个顺手的分拣系统。我最初接触这类工具是因为有一次要给客户出一套摄影作品的归档目录需要把三年里横跨多台设备拍摄的照片统一整理当时网上现成的软件试了好几个要么是按文件夹手动拖拽要么分类精度太粗完全没法用。后来干脆自己写脚本配合工具来做反而把分类逻辑理解得特别透彻。现在回头看这类软件其实没多玄乎核心就是读元数据 → 算属性 → 归类移动三步。1. 内容整体设计与思路拆解1.1 三个分类维度到底分别解决什么问题先说按日期分类。照片和视频最大的特点是有时间属性拍摄时间是人回忆的锚点。不管你是要整理家庭相册还是给做内容创作的人整理素材库按日期归档都是最不容易出错、最符合直觉的方式。三种精度本质上是归档粒度的选择按年适合长期归档比如2023年的照片2024年的视频一般用于把几万张照片先做粗分或者对大目录做冷热分层。按年月适合月度复盘或工作素材整理比如不少自由摄影师按月建项目文件夹2024-06一目了然兼顾查找效率和文件数量平衡。按年月日适合强事件驱动的场景比如活动跟拍、亲子记录、旅行素材一天一个文件夹单日文件量往往几百张起按日拆分非常合理。按分辨率分类则解决的是找质量和挑素材的问题。很多人的相册里既有相机原片又有网络保存的缩略图、手机截图这类低分辨率图片混杂在一起非常糟心。通过分辨率把超清、高清、普通、低清分开至少能让你在导出或上传时快速锁定目标。按文件大小分类更多服务于存储管理。视频动辄几百MB甚至几个GB照片则从几百KB到几十MB不等。用大小维度可以快速找出占地方的大块头和毫无保留价值的小图片尤其是电脑空间告急时这个维度比任何其他维度都直接。1.2 为什么多数产品把日期作为第一级分类总结我自己测试多款软件和自写脚本的经验一个合理的多维度分类策略通常会把日期作为第一级目录分辨率或文件大小作为第二级。原因是日期是互斥且完备的。任何一张照片视频都一定有一个可推算的时间哪怕只精确到某一天但并非所有文件都能准确读到分辨率或拍摄参数而且分辨率分类档位是人为定义的不如日期那样天然确定。举个例子假设你按分辨率 → 日期的顺序分类那么超清文件夹下每天都会有大量子目录而某些冷门分辨率档位可能一年都新增不了几行时间一长目录会变得既散又难预测。反过来如果先按年/月/日归档再在月目录下按分辨率拆子目录浏览体验会舒服得多规律也更强。当然这种嵌套结构对低配置设备不友好一层层文件夹的路径也会更长。所以很多工具干脆提供扁平化模式日期和分辨率同时体现在文件名前缀里比如20240615_1920x1080_IMG_001.jpg。我个人在大量文件场景下更推荐这种扁平方案因为操作系统处理海量小文件的瓶颈往往在目录项数量上扁平化能显著减少目录层级移动和扫描都快不少。1.3 工具的三重判断逻辑一个成熟的分类器内部本质是对每个文件执行三次判断判断时间维度读取EXIF拍摄时间读不到再用文件修改时间、创建时间取其中最合理的一个。判断分辨率图片读取像素宽高视频读取画面宽高注意要处理旋转元数据否则竖屏视频可能被误判成横幅。判断大小直接用字节数除以1024或1024的平方得到KB或MB再匹配预设区间。这三步看似简单但每一步都有不少细节尤其是视频远没有图片那么听话。接下来逐个拆解。2. 核心细节解析与实操要点2.1 日期分类的元数据读写策略日期是分类的根基所以先认真聊它。绝大多数数码照片在拍摄时会写入EXIF信息里面包含了DateTimeOriginal原始拍摄时间、CreateDate、ModifyDate等字段。很多图片管理软件在界面里显示拍摄日期其实读的就是这些字段。我在多次批量整理中总结出来的时间优先级是EXIF DateTimeOriginal拍摄时间最贴近事实优先使用文件系统的修改时间mtime适合旧照片、从社交平台下载、经过压缩或转码丢失EXIF的文件文件系统的创建时间ctime这个在Windows上比较可用但Linux上表示的是inode变更时间不能直接用。需要特别小心的是时区问题。相机设置里如果时区不对拍出来的EXIF时间可能和本地时间差了好几个小时其他设备的截图、录屏等也不一定带时区标识。我的建议是不要在处理过程中临时改时区而是给每个时间字段统一加上一个时区偏移参数比如固定按UTC8解释这样即使个别文件时间不准至少全库偏移一致不至于同一事件的照片被拆到两个日期。还有一个常见坑手机拍摄的照片经过微信、QQ发送后EXIF会被大幅剥离只保留文件修改时间。这种情况下按日期分类就得依赖mtime可一旦文件被拷贝过mtime可能变成拷贝时间而不是拍摄时间。我在一次整理旧手机相册时就吃过亏几千张照片全部变成了同一天的修改时间最后只能靠文件名里的时间戳和相册目录名交叉验证才勉强救回来。所以如果条件允许尽量在原始文件刚导入时就做预处理把EXIF时间先固化下来。2.2 三种日期精度对应的目录结构设计三种精度不只是多几级目录的区别背后是文件数量和查找习惯的权衡。下面是我实际用的目录设计精度目录结构示例适合场景文件量参考按年./归档/2024/多年全景归档一年几千到几万按年月./归档/2024/2024-06/月度复盘、素材整理一个月几百到几千按年月日./归档/2024/2024-06/2024-06-15/活动跟拍、日记式归档一天几十到几百注意年月这种结构实际上月份目录也可以写成2024-06或者06。如果年份目录已经存在子目录里再写一次完整2024-06会显得冗余我建议子目录只保留06-06月这类简洁表达避免重复信息让路径过长。Windows的路径长度上限是260个字符如果文件名本身又很长比如一些相机命名规则目录层级太多会直接导致复制、移动失败这一点在编排工具逻辑时必须考虑。在实现三种精度切换时我的做法是写一个通用的build_date_path(base_dir, timestamp, precision)函数内部按精度判断拼接几层。不要用一堆if/else直接写死字符串连接否则后期加一个精度等级会很痛苦。函数化之后用户只需要传一个精度参数所有文件的分拣路径就跟着变了非常方便测试。2.3 分辨率分类的读取逻辑图片分辨率读取相对容易。用Python的PIL.Image.open读取(width, height)或者直接解析JPEG文件头里的SOF标记都不难。但视频分辨率就不一样了。视频文件我通常用ffprobe读取流信息可以拿到视频流编码、宽高、旋转角度、帧率等。这里最关键的是旋转角度。很多手机拍的竖屏视频其内部编码宽度和高度其实是反的比如编码为1920x1080但带一个rotate90的元数据播放器会自动转正但粗暴读取分辨率时你会把它判成横屏。所以读取视频分辨率时一定要检查side_data_list或tags里的rotate字段如果有90或270宽高要互换才能得到真实展示分辨率。分辨率档位如何划分不同人使用场景不同但一个大类划分可以参考下面的方案档位建议宽度参考典型来源低清宽 1280截图、网络旧图、早期手机高清1280 ≤ 宽 1920手机普通拍摄超清/2K1920 ≤ 宽 3840相机、最新手机拍摄4K及以上宽 ≥ 3840专业设备、高码率视频注意我建议按宽而不是面积来划分因为宽高比不同面积并不总能线性代表清晰度感知。比如一个3840x2160的16:9视频和一个2160x3840的9:16竖屏视频宽度都在高清线以上但面积不一样如果按面积来定义4K竖屏文件会被错误分到更低的档位不符合用户预期。2.4 文件大小分类的阈值设置大小分类最核心的不是技术而是阈值设计。我见过不少工具把阈值写死比如小于1MB、1-10MB、10-100MB、大于100MB看起来很合理但实际用于照片和视频混合目录时几乎没法看。因为照片和视频体积分布差异巨大。一张手机照片2-6MB一段4K视频动辄1-2GB混在一起按固定档位分类所有视频会被丢进同一个大于100MB的桶里等于没分。所以一个合格的分类器应该提供按文件类型分别配置阈值的能力或者至少提供图片档位和视频档位两套预设。我常用的视频档位如下小于10MB短视频、表情包、录屏片段10-100MB普通画质短片段、微信保存视频100MB-1GB主流相机/手机拍摄的高清片段大于1GB长时间录制、4K高码率素材图片档位则用另一套小于100KB缩略图、图标、低质量WebP100KB-1MB老照片、微信压缩图、截图1-10MB手机/相机常规原图大于10MB高分辨率RAW、全景图、连拍原图在实际处理中文件大小不非要换算成MB再判断直接拿字节数比较更快。我见过有人每次都size os.path.getsize(path) / 1024 / 1024转成MB然后再比较这个转换本身没问题但在几万文件批量扫描时多一次除法和浮点运算总体耗时也会明显拉高。更高效的写法是字节数size直接和阈值乘出来的常量比较例如10 * 1024 * 1024。3. 实操过程与核心环节实现3.1 准备阶段需要哪些工具和依赖如果你只是偶尔整理一次可以借助现成的图形化工具比如Adobe Bridge、Lightroom、PhotoMove等但它们的批量定制能力总有一些限制。如果你想完整复刻标题里按日期、分辨率、文件大小多维度分类的能力我建议直接写一个小脚本只依赖三个基础组件Python 3.8解释环境Pillow读取图片分辨率ffprobe随FFmpeg一起安装读取视频元数据exifread 或 Pillow的Image._getexif读取EXIF拍摄时间安装命令很简短pip install pillow exifreadFFmpeg需要一个单独安装步骤Windows用户到官网下载安装包后把bin目录加入系统PATHmacOS用户可以用Homebrewbrew install ffmpegLinux用户用各自的包管理器安装ffmpeg即可比如sudo apt install ffmpeg安装好之后先用ffprobe -version验证一下环境。注意如果你的照片视频目录里包含大量HEIC、RAW等特殊格式Pillow不一定能直接读取这时需要额外装pillow-heif或者rawpy不然分辨率读取会失败。我在第一次跑脚本时就没注意这个导致一整个目录的iPhone HEIC照片全部无法被识别。3.2 核心代码读取日期、分辨率、大小的三个基础函数下面是我平时用作工具原型的核心代码你可以在自己机器上跑也可以照着改成自己的类。import os import shutil import subprocess import re from datetime import datetime from PIL import Image import exifread # 时间偏移单位小时根据实际情况调整 TIMEZONE_OFFSET_HOURS 8 def get_exif_datetime(path): 优先读取EXIF中的拍摄时间返回datetime对象或None try: with open(path, rb) as f: tags exifread.process_file(f, detailsFalse) date_str str(tags.get(EXIF DateTimeOriginal) or tags.get(Image DateTime) or tags.get(EXIF CreateDate)) if date_str and None not in date_str: # 格式通常为 2024:06:15 10:30:00 dt datetime.strptime(date_str.strip(), %Y:%m:%d %H:%M:%S) # 注意时区偏移默认按UTC8解释 dt dt.replace(yeardt.year) # 可在此处做时区校正 return dt except Exception: pass return None def get_file_time(path): 获取文件的合理时间优先EXIF其次修改时间 exif_dt get_exif_datetime(path) if exif_dt: return exif_dt mtime os.path.getmtime(path) return datetime.fromtimestamp(mtime) def get_image_size(path): 读取图片分辨率返回(宽, 高) try: with Image.open(path) as img: return img.size except Exception: return None def get_video_size(path): 读取视频分辨率用ffprobe并处理旋转元数据 cmd [ ffprobe, -v, error, -select_streams, v:0, -show_entries, streamwidth,height:stream_tagsrotate, -of, json, path ] try: result subprocess.run(cmd, capture_outputTrue, textTrue, timeout30) import json data json.loads(result.stdout) stream data[streams][0] w int(stream[width]) h int(stream[height]) rotate int(stream.get(tags, {}).get(rotate, 0)) if rotate in (90, 270): w, h h, w return (w, h) except Exception: return None def get_file_size(path): 获取文件字节大小 return os.path.getsize(path)这段代码里我刻意把时间偏移处理留了一个注释位置。因为在不同项目中你的照片来源和时区情况完全不同直接硬编码绝对不是一个好选择。更稳的做法是把时区偏移作为一个全局参数或者从相机型号、拍摄位置信息里推算但那样复杂度过高一般场景用不到。exifread和Pillow的EXIF解析有细微差异Pillow 的_getexif()返回的键是整数需要查表才能知道哪个是拍摄时间而exifread返回的键是字符串比如EXIF DateTimeOriginal直观很多。所以我这里选择了exifread它在处理部分老设备生成的异常时间字符串时也更宽容。3.3 核心代码按三种日期精度构建目标路径日期路径构建是整个工具的核心枢纽。下面这个函数我建议直接抄进你自己的脚本里def build_date_path(base_dir, dt, precisionymd): 按精度拼接日期目录precision可选 year / month / day year dt.year month dt.month day dt.day if precision year: return os.path.join(base_dir, str(year)) elif precision month: return os.path.join(base_dir, str(year), f{year}-{month:02d}) elif precision day: return os.path.join(base_dir, str(year), f{year}-{month:02d}, f{year}-{month:02d}-{day:02d}) else: raise ValueError(f未知精度: {precision})关于月份目录命名我坚持用2024-06这种帶年份的格式而不是06。原因有两个第一当你用文件管理器浏览时2024下面跟着2024-06、2024-07排序可靠且自动第二如果某个月份目录需要单独拷贝出来文件名自带年份不会丢失上下文。有人可能会觉得这样重复冗余但从可读性和实用性来看这点冗余完全值得。为了防止移动文件时发生目录嵌套错误我还会在移动前统一创建目录def ensure_dir(path): os.makedirs(path, exist_okTrue)注意一定用exist_okTrue否则并发或重复处理时很容易抛异常。如果你打算多线程加速处理这个标志位几乎是必须的。3.4 核心代码分类执行器与冲突处理将所有基础模块拼起来就是一个最基本的分类执行器。我这里给一个支持日期-分辨率两级分类的版本文件大小分类也可以类似扩展。IMAGE_EXTS {.jpg, .jpeg, .png, .bmp, .tiff, .webp, .heic} VIDEO_EXTS {.mp4, .mov, .avi, .mkv, .m4v, .wmv} def classify_file(src_path, base_dir, date_precisionday, sort_by_resolutionTrue, dry_runTrue): 分类单个文件dry_runTrue时只打印移动计划 ext os.path.splitext(src_path)[1].lower() is_image ext in IMAGE_EXTS is_video ext in VIDEO_EXTS if not is_image and not is_video: return # 1. 获取日期路径 dt get_file_time(src_path) date_dir build_date_path(base_dir, dt, precisiondate_precision) # 2. 获取二级分类目录 sub_dir if sort_by_resolution: if is_image: size get_image_size(src_path) else: size get_video_size(src_path) if size: w, h size if w 3840: level 4K以上 elif w 1920: level 超清 elif w 1280: level 高清 else: level 低清 sub_dir level target_dir os.path.join(date_dir, sub_dir) if sub_dir else date_dir ensure_dir(target_dir) target_path os.path.join(target_dir, os.path.basename(src_path)) if os.path.exists(target_path): # 解决冲突加时间戳后缀 name, ext2 os.path.splitext(os.path.basename(src_path)) new_name f{name}_{dt.strftime(%H%M%S)}{ext2} target_path os.path.join(target_dir, new_name) if dry_run: print(f[计划] {src_path} - {target_path}) else: shutil.move(src_path, target_path) print(f[移动] {src_path} - {target_path})这段代码特意把dry_run参数放在最前面默认只是打印计划。我强烈建议任何批量移动工具都保留这个安全开关因为几秒内把上万张照片移动错位再想找回来非常痛苦。我第一次拿真实目录做测试时就因为没加预览一个错误的分类参数直接让三千多张照片全部堆到了一个文件夹里后来不得不靠文件名后缀一个个筛回来花了整整一个下午。3.5 执行整理从预览到正式交付的完整流程在实际项目中我会按照下面的流程来操作每一步都不跳过全盘扫描先遍历整个源目录统计文件总数、图片数、视频数、总大小。这步的目的是确认没有意外的隐藏目录或临时文件混入。抽样验证元数据随机抽10-20个文件打印它们的EXIF时间、分辨率、大小人工核对是否符合预期。尤其要注意不同设备、不同来源的文件元数据是否完整。小规模试运行复制一个子目录比如最近一个月的文件作为测试集加上dry_runTrue跑一遍查看输出路径分布是否合理。正式执行确认无误后去掉dry_runTrue正式移动。如果文件数特别多可以考虑分批次执行比如先按年份范围划分一次处理一年。交叉校验处理完后再扫描一遍目标目录验证文件总数是否与源目录一致。这一步对拍过大量素材的人尤其重要因为移动过程中如果遭遇断电或磁盘空间不足很容易悄悄丢文件。4. 常见问题与排查技巧实录4.1 EXIF时间读不到怎么办这是最频繁出现的问题。旧照片、网图、部分录屏文件没有EXIF时间或者EXIF字段被压缩软件清空了。这种情况下我们必须退一步用文件修改时间来兜底。但有一个隐患如果你曾经用某些工具优化过文件或者从网盘下载时东拉西扯修改时间可能被更新成下载时间。我给这类问题配置了一个三级回退策略DateTimeOriginalmtime文件名里的日期模式比如IMG_20240615_103000.jpg、2024-06-15 10.30.00.png这类常见命名规则用正则提取。def parse_date_from_filename(filename): 尝试从文件名提取日期失败返回None patterns [ r(\d{4})[-_]?(\d{2})[-_]?(\d{2})[-_]?(\d{2})[-_]?(\d{2})[-_]?(\d{2}), r(\d{4})[-_]?(\d{2})[-_]?(\d{2}), ] for pat in patterns: m re.search(pat, filename) if m: nums [int(x) for x in m.groups()] if len(nums) 6: return datetime(*nums[:]) else: return datetime(*nums) return None这个函数放进去之后回退逻辑可以升级为EXIF → 修改时间 → 文件名解析。我实测下来这个组合可以解决95%以上的日期缺失问题剩下的要么是文件名完全无意义要么修改时间也不可信就只能放到一个未识别目录里人工处理了。4.2 视频分辨率读不到或读取错误处理视频时ffprobe读取失败通常有三个原因文件编码异常ffprobe无法解析流信息。文件扩展名和实际编码不一致比如.avi实际里面是MP4格式。权限问题程序没有读取文件内容的权限。排查方法很简单先手动执行一下ffprobe命令看具体输出什么。如果是编码异常可以加-analyzeduration参数提高解析时间如果是扩展名问题建议直接忽略扩展名用ffprobe探测到的真实编码判断。某些老旧的mts/m2ts文件它们的流信息和普通mp4不同但ffprobe一般也能正确读出来只是字段名略有差异需要自行检查。还有一个容易被忽略的点部分视频文件里面有多个视频流比如主片和预览流并存。如果-select_streams v:0选中了预览流那么读到的分辨率就会偏小。如果你发现某类视频的分类结果所有文件都变成了低清大概率就是这个原因。改动方法是在ffprobe命令里加-select_streams v:0后再加一个条件只选codec_typevideo且codec_name不是mjpeg的流因为有些封装格式会把缩略图也作为一个视频流存进去。ffprobe -v error -select_streams v:0 -show_entries streamwidth,height:stream_tagsrotate -of json input.mp4如果确认存在多条视频流可以用-show_streams查看所有流的索引再决定选第几个。4.3 移动文件时路径过长或目录权限问题Windows 如果按年-月-日 分辨率多层建目录再加上较长文件名很容易触达260字符上限。我在Windows上跑批量整理时就遇到过一次一个文件名为DJI_20240615_Travel_Beijing_Summer_Holiday_4K_Original_Clip_001.mp4目标路径已经接近250字符shutil.move直接抛OSError。解决思路有三个在Windows上启用长路径支持组策略或注册表打开LongPathsEnabled在脚本里对文件重命名缩短文件名减少目录层级比如日期精度不要选年月日或者分辨率子目录用HD/UHD之类的短名称。我在正式执行方案中用的就是第三种把分辨率子目录从4K以上/超清/高清/低清缩短为4K/FHD/HD/SD。这样既保持了可读性又解决了路径长度问题。下表给出两个命名方案的对比方案示例路径优点全中文归档/2024/2024-06/2024-06-15/超清/可读性好简短英文archive/2024/06-15/UHD/路径短兼容性好4.4 处理重复文件防止整理后多份拷贝分类整理过程中难免会遇到同一个文件被从多个来源分别拷贝进同一个目录的情况。比如手机备份了一遍电脑又备份了一遍。如果脚本不去重分拣之后同一张照片会出现在两个日期文件夹里因为它们的修改时间可能不同导致被分到不同日期。最简单有效的做法是比较文件内容哈希MD5或SHA-1在扫描阶段建立哈希索引。注意对几万个文件整体计算哈希可能耗时较长但可以用文件大小 文件名 前1KB哈希做快速预筛只有预筛命中才计算全量哈希这样能节省大量时间。def quick_hash(path): 快速预筛哈希读前1KB with open(path, rb) as f: return hashlib.md5(f.read(1024)).hexdigest()预筛相同后再计算完整MD5确认如果确认重复按你想要的策略处理要么只保留一份要么移到重复文件目录里等待人工确认。千万不要自动删除因为文件名相同的两个文件可能内容完全不同。4.5 误分类的后悔药移动前建立清单和软链接整理这种大规模操作最怕的就是做错了想反悔但已经找不回原样。除了我前面提到的dry_run另一个特别实用的技巧是正式移动后不要删空原目录而是在原目录创建指向新位置的符号链接Windows上叫快捷方式Linux/macOS上是symlink。def move_with_symlink(src, target): shutil.move(src, target) try: os.symlink(target, src) except Exception: pass创建软链接有几个好处第一源目录依然保留完整的目录结构你可以通过文件管理器一眼看到这些文件去了哪里第二环境变量或脚本如果还在引用旧路径不会被立即打破第三当你确认整理结果无误后再统一删掉空目录和软链接非常干净。不过要注意os.symlink在Windows上默认需要管理员权限或者启用开发者模式。普通用户模式下可能会抛权限错误遇到这种情况直接不用软链接也行反正最核心的还是备份和预览机制。5. 专项进阶工具选型与周边配套5.1 用现成软件还是自己写脚本很多人会问市面上现成的照片视频分类软件那么多为什么还要自己写脚本我的看法是两者各有适用场景。如果你只有几千张照片要求不高用现成工具其实更省事。比如Adobe Bridge主要是摄影师做素材管理它的基于EXIF日期自动分类和元数据过滤功能很成熟。Lightroom更多是目录式管理不太适合物理归档但筛选和批量重命名很强。PhotoMove专门按EXIF日期归档的小工具简单直接。DigiKam开源功能全面日期分类、标签分类都有支持数据库管理。不过一旦你面对的是十万级别的文件或者需要与自己的命名规范、业务目录结构深度整合现成工具往往会卡在两点上一是它们的分类规则固定不容易改二是处理效率不一定高界面操作还需要大量人工点击。自己写脚本至少你可以精确控制文件路径、文件名格式、阈值档位、时区策略还能复用同一套脚本做增量整理。5.2 如何把脚本封装成分类工具如果你不想每次整理都打开终端跑脚本可以把核心代码封装成一个简单的命令行工具或者用tkinter/PySide写一个最小GUI。我常用的做法是把classify_file和目录遍历逻辑打包成一个类暴露几个参数参数说明默认值source_dir源目录路径必填output_dir整理后根目录必填date_precisionyear/month/daydaysort_by_resolution是否启用分辨率分类Truesort_by_size是否启用大小分类Falsedry_run预览模式Truetimezone_offset时区偏移小时数8封装的好处是以后新增按拍摄设备分类按宽高比分类等维度时只需要加一个分支函数不需要动主流程。如果你的文件量很大还可以给遍历加多线程但要注意FFmpeg进程本身已经比较消耗资源多线程同时跑多个ffprobe可能会拖垮CPU所以我一般用ThreadPoolExecutor(max_workers4)控制并发数。5.3 和NAS、网盘自动同步配合一旦分类脚本稳定下来你就可以考虑把它纳入日常自动流程。比如群晖NAS上设置定时任务每周日凌晨自动扫描某个上传目录把新文件按日期和分辨率分类后移动到归档目录或者在自己电脑上用cronmacOS/Linux和任务计划程序Windows写个定时脚本每天处理一次。这里面需要额外注意增量处理的逻辑每次扫描只处理那些在整理目录之外的新文件。最简单的方案是记录上一次处理的时间点只处理修改时间晚于该时间点的文件更严谨的方案是把已经处理过的文件路径列表保存在一个processed.lst里。我用过的方案是后者因为它还能用来做重复检测和异常回溯。如果与网盘同步比如OneDrive或Dropbox所在的目录建议额外加一个同步冲突检测手机在本地编辑时可能会生成同步占位文件或冲突副本不要把这类文件也一起归档。判断方法很简单文件名里通常带冲突字样或设备名遇到这类文件直接跳过等人工确认。6. 一张速查表常见问题与解决方案为了让实际排查更快我把自己碰过的问题整理成下面这张速查表基本覆盖了多数人在整理照片视频时会遇到的坑现象可能原因解决方案部分照片时间相差几小时时区设置问题统一按UTC8解释EXIF或增加时区偏移参数某些文件没有日期分类结果EXIF丢失、文件名无规律用mtime兜底文件名含日期则正则提取竖屏视频被判成横屏未处理旋转元数据读取rotate字段并交换宽高视频分辨率偏小选到了预览流用-select_streams v:0筛选码流检查是否存在多视频流所有视频都堆在100MB大小阈值未区分图片/视频为图片和视频配置独立档位移动时报路径过长错误Windows长路径限制缩短目录层级或启用LongPathsEnabled移动后照片重复同一文件被多设备备份快速哈希预筛再算完整MD5去重扫描速度太慢大目录里频繁IO先做一次目录清单缓存或提高并发数特殊格式RAW、HEIC读不出来依赖库不支持装rawpy、pillow-heif或用ffprobe兜底这张表不完全但绝对能覆盖80%的日常问题。7. 踩坑日记一次真实的大规模整理复盘前面讲了不少原理和代码最后我想分享一次真实的大规模整理经历帮大家把这些经验串起来。那是我帮一个做旅行内容的朋友整理素材目录里一共约7万张照片、5000条视频分散在3块硬盘、6个顶层目录中。朋友的原始诉求很简单我想按日期找到某次旅行的素材顺便把占空间的大视频挑出来单独放。我当时的规划是第一级按年归档第二级按年月第三级按分辨率大视频按大小单独抽出。脚本跑完后第一天只整理了约2万张照片速度大概每秒8个文件主要瓶颈是exifread解析。后来发现很多照片根本没有EXIF修改时间也乱成了一锅粥——朋友用各种App同步过导致同一个拍摄时间点的文件被分散到好几个日期目录里。我后来靠文件名里的IMG_20240316_xxxxxx格式救了回来把parse_date_from_filename的优先级提到mtime之前重新执行了一遍才把照片对回正确日期。这次经历让我彻底明白所谓智能分类很多时候拼的不是算法多牛而是对现实世界混乱程度的容忍度和回退策略的完善程度。还有一次我在处理视频时发现所有MOV文件的分辨率都变成了0x0排查半天发现是ffprobe在读取某台旧相机的MOV文件时因缺少-analyzeduration参数导致流信息解析超时。加上参数后一切正常。这种问题看起来小但在几万文件批量处理时一个看似无关紧要的报错可能让整个流程中断所以脚本里一定要对单文件异常做try/except捕获不能让一个坏文件拖垮全局。8. 最后再分享两个小技巧第一个是归档时不要随意改文件名。除非你的文件命名本身没有意义否则保留原始文件名对追溯很有帮助。很多整理软件默认会按日期分辨率重命名比如20240615_1920x1080_IMG_001.jpg名字里确实带了更多信息但一旦你改了想再回到原始文件的命名规律就难了。我通常只移动不重命名除非有明确的去重或冲突需求。第二个是在分类完成之后随手生成一份索引文件。不管是用脚本扫描目录还是简单地把所有文件路径和大小写进一个CSV都会让后续检索轻松很多。索引里至少包含文件名、路径、大小、拍摄时间、分辨率、分类时间。这样即使某天归档目录层级变了你还能靠索引恢复映射关系。照片视频整理这件事说难不难说简单也不简单。难在现实数据太乱简单在只要你把元数据读取、时间回退、路径设计这几个核心逻辑想透了剩下就是套一个循环跑文件。希望这篇文章能把你的整理工具从能用推到好用下次面对海量素材时至少心里有底。本文还有配套的精品资源点击获取