1. 项目概述：为什么音频元数据处理不是“改个文件名”那么简单

你有没有遇到过这样的场景：在整理几百首本地音乐时，播放器里显示的时长全是00:00，或者导出的AAC文件在手机上点开就报“无法读取时长”；又或者你在写一个播客管理工具，用户上传MP3后，前端进度条根本动不了——不是代码没写完，而是音频文件压根没提供可被解析的持续时间字段。这背后不是播放器坏了，而是你手里的音频文件，它的“身份证信息”（也就是元数据）要么缺失、要么损坏、要么格式不兼容。而“获取且设置MP3、AAC文件播放时长、文件大小等信息”，表面看是读两个字段、写两个值，实则横跨容器封装、编码标准、帧结构解析、字节对齐、ID3/AAC ADTS头校验、跨平台时间精度差异等六大技术断层。我做过三个不同规模的音频处理项目：某高校语音实验室的声学标注系统、某播客平台的自动化转码流水线、某车载音响厂商的离线音频包校验工具——所有项目上线前都卡在同一个环节：如何让一段二进制音频，在任意设备、任意播放器、任意操作系统下，稳定、准确、可复现地返回“4分28秒”这个数字，并且能把它“写回去”而不破坏文件可播放性。这不是调用一个getDuration()就能解决的事。它要求你真正理解MP3的MPEG-1 Layer III帧结构中每帧1152个采样点与采样率的数学关系，明白AAC的ADTS头里frame_length字段为何不能直接累加（因为存在填充字节和变长帧），清楚ID3v2.4的TLEN帧和TDRC帧在不同播放器中的兼容优先级，甚至要预判iOS系统对mp4a封装中moov原子内tkhd和mdhd时间戳的解析偏好。本文不讲API调用，只讲你打开十六进制编辑器后，看到的那一串字节到底在说什么；不堆砌库名，只告诉你为什么选mutagen而不是pydub来改ID3，为什么ffmpeg -i输出的时长有时比ffprobe多0.02秒，以及——当你手动计算出的总时长和播放器显示差3帧时，该去检查哪7个字节。

2. 核心原理拆解：MP3与AAC的“时长”根本不是同一个东西

2.1 MP3的时长：从帧数到秒的三重转换

MP3文件没有全局“时长”字段。它的时长是推算出来的，依赖三个关键参数：采样率（Sample Rate）、每帧采样数（Samples per Frame）、总帧数（Frame Count）。MPEG-1 Layer III标准规定，每帧固定包含1152个采样点。所以理论时长 = （总帧数 × 1152） ÷ 采样率。但现实远比公式复杂：

• 采样率不等于文件头声明值：MP3文件头（Sync Word + MPEG Audio Header）中sample_rate_index字段指向一个预设表（如44100Hz → index=0），但某些编码器会伪造该字段，或使用非标采样率（如32000Hz）。此时若盲目套用公式，误差可达±15%。
• 帧边界识别是最大陷阱：MP3帧以0xFFE（12位同步字）开头，但音频数据中也可能出现0xFFE——这是合法的PCM数据。真正的帧起始必须满足：0xFFE后紧跟有效bitrate_index和sample_rate_index，且后续字节符合MPEG帧长度表。我曾处理一批由某国产录音笔生成的MP3，其静音段大量插入0xFFE00000作为填充，导致自动帧计数器误判为237个无效帧，总时长虚高1分42秒。
• VBR（可变比特率）的致命干扰：CBR（恒定比特率）下，每帧字节数固定，总帧数 = 文件大小 ÷ 每帧字节数。但VBR下，每帧字节数动态变化，必须逐帧解析Header才能累加。更麻烦的是，VBR文件常含Xing/VBRI标签——它们存储了预计算的总帧数和VBR缩放因子，但该标签可能损坏、缺失，或与实际帧流冲突。某次调试中，ffprobe读取Xing标签得3分12秒，而逐帧解析得3分09秒，最终发现Xing标签末尾被用户用Windows记事本另存为UTF-8时，意外写入了BOM头（0xEFBBBF），导致解析器偏移3字节，读错后续所有字段。

提示：不要信任任何“快速扫描”工具返回的MP3时长。生产环境必须启用--scan模式（如ffprobe -v quiet -show_entries format=duration -of default=nw=1 input.mp3），它强制逐帧解析而非依赖标签。

2.2 AAC的时长：ADTS头、ADIF头与MP4封装的三重迷宫

AAC比MP3更混乱。它有三种主流封装格式：ADTS（.aac）、ADIF（已淘汰）、MP4（.m4a/.mp4）。它们的时长来源完全不同：

• ADTS（最常见于独立.aac文件）：每个AAC帧以7字节ADTS头开头。关键字段是frame_length（13位），表示本帧总字节数（含ADTS头）。理论上，总时长 = Σ(每帧采样数) ÷ 采样率。但问题在于：AAC每帧采样数不是固定的1024吗？错。LC-AAC（主流）每帧1024采样，但HE-AAC v1/v2引入SBR（频谱带复制）和PS（参数立体声），实际有效采样数需结合profile和sampling_frequency_index查表。更隐蔽的是protection_absent位——若为0，帧头后还有2字节CRC校验，frame_length已包含它；若为1，则无CRC，frame_length就是纯音频数据长度。忽略此位会导致帧边界错位，后续所有解析全盘崩溃。

• MP4封装（.m4a）：这才是现代设备的首选。时长信息藏在moov原子的mdhd（Media Header）和tkhd（Track Header）中。mdhd提供timescale（时间刻度，如44100）和duration（以timescale为单位的总时长），tkhd提供duration（以movie timescale为单位）。二者必须一致，否则iOS播放器会优先采用tkhd，而Android可能采用mdhd。某次交付中，客户提供的.m4a文件mdhd.duration=189200（timescale=44100 → 4.29秒），但tkhd.duration=189200（timescale=600 → 315.3秒），结果在iPhone上播放正常，在安卓车机上直接卡死——因为车机固件解析tkhd时，将600倍的时间刻度误认为44100，导致时长溢出。

• ADIF（已淘汰但仍有遗留）：整个文件只有一个头，包含length字段声明总字节数。但该字段是32位无符号整数，最大值4GB。当文件超4GB时，部分老解析器会截断为0，返回时长0秒。这不是理论风险——某广播电台的原始录音存档就批量出现此问题。

2.3 “文件大小”为何不能直接用os.path.getsize()？

这看似最简单，却是线上事故高发区。原因有三：

• 文件系统缓存延迟：在Linux下，stat()系统调用返回的st_size可能滞后于实际写入。某次用Pythonshutil.copy()复制大音频文件后立即读取大小，返回值比ls -l少12KB。根源是ext4的延迟分配（delayed allocation），copy()返回时数据仍在page cache，未刷入磁盘。解决方案必须加os.fsync()或pathlib.Path(file).touch()触发刷新。
• 稀疏文件（Sparse File）陷阱：某些转码工具（如ffmpeg -f mp4 -c copy）在处理含空轨道的MP4时，会创建稀疏文件——ls -l显示100MB，但du -h仅占2MB。os.path.getsize()返回逻辑大小（100MB），而真实I/O成本是2MB。若你的服务按“文件大小”计费，这会造成严重资损。
• NTFS备用数据流（ADS）干扰：Windows下，文件可能附带ADS（如file.mp3:Zone.Identifier），getsize()返回主数据流大小，但某些播放器读取时会尝试加载ADS，导致IO异常。需用os.stat()的st_file_attributes字段检测FILE_ATTRIBUTE_HIDDEN | FILE_ATTRIBUTE_SYSTEM组合。

3. 实操方案设计：为什么不用FFmpeg命令行，而选Python+Mutagen+FFprobe组合

3.1 工具链选型的硬核权衡

面对“获取且设置”双重需求，业界常见方案有三类：纯命令行（FFmpeg/FFprobe）、纯Python库（Mutagen/Pydub）、混合方案。我的选择是FFprobe + Mutagen + 少量自定义Cython解析器，理由如下：

• FFmpeg命令行的不可控性：ffmpeg -i file.mp3 2>&1 | grep "Duration"依赖文本解析，正则易失效（如不同版本输出格式微调：“Duration: 00:04:28.12, start: 0.000000, bitrate: 128 kb/s” vs “ Duration: 00:04:28.12, start: 0.000000, bitrate: 128 kb/s”）。更致命的是，ffmpeg -i在遇到损坏帧时默认跳过并继续，导致时长偏短。虽可用-v error降级，但错误日志格式不统一，难以结构化捕获。某次处理10万文件，因FFmpeg版本从4.2升至5.0，Duration字段位置从第3行变为第4行，导致23%的文件时长解析失败。

• Pydub的精度妥协：Pydub底层调用FFmpeg，但为简化API，其AudioSegment.duration_seconds强制使用-v quiet并解析stdout，丢失了FFmpeg的详细错误上下文。且它对AAC的ADTS帧解析不完整——当protection_absent=0时，Pydub的_detect_aac_frame函数会把2字节CRC当作音频数据，导致后续帧偏移。我们实测一批HE-AAC v2文件，Pydub返回时长比真实值短0.8秒。

• Mutagen的元数据统治力：Mutagen是目前唯一深度支持ID3v2.2/v2.3/v2.4、APEv2、MP4 atoms、FLAC Vorbis Comments的Python库。它不解析音频帧，专注元数据读写，稳定性极高。关键优势在于：它允许你安全地修改TLEN（总时长）、TSSE（编码器）、TDRC（录制日期）等字段，且自动处理ID3头重写、padding填充、UTF-16 BOM插入等细节。例如，设置TLEN时，Mutagen会：

  1. 定位ID3v2.4头（通常在文件开头）
  2. 查找现有TLEN帧，若不存在则新建
  3. 将整数时长（秒）转为字符串，按ID3规范编码（UTF-16BE + BOM）
  4. 计算新帧长度，调整ID3头中size字段（需同步更新）
  5. 若新ID3头比旧的大，自动在ID3后插入padding；若小，则收缩padding 这种原子级操作，是手写struct.pack()无法企及的安全性。

3.2 获取时长的四步黄金流程（兼顾精度与性能）

以下代码是经过20万+文件验证的生产级流程，核心思想：先用FFprobe快速获取，再用Mutagen校验，最后对VBR/ADTS文件启用逐帧解析兜底。

import subprocess import json import mutagen from mutagen.id3 import ID3, TLEN from mutagen.mp4 import MP4, MP4Info from mutagen.aac import AAC def get_audio_duration(filepath: str) -> float: """ 获取音频文件精确时长（秒），支持MP3/AAC（ADTS/MP4） 返回值：float，精度到毫秒级 """ # 步骤1：FFprobe快速获取（95%文件在此完成） try: result = subprocess.run( [ 'ffprobe', '-v', 'quiet', '-show_entries', 'format=duration', '-of', 'json', filepath ], capture_output=True, timeout=30 ) if result.returncode == 0: data = json.loads(result.stdout) duration = float(data['format']['duration']) if duration > 0: return round(duration, 3) # 保留3位小数 except (subprocess.TimeoutExpired, json.JSONDecodeError, ValueError): pass # 步骤2：Mutagen元数据校验（针对ID3/TLEN或MP4/mdhd） try: audio = mutagen.File(filepath) if audio is None: raise ValueError("Mutagen无法识别文件格式") # MP3：检查ID3v2的TLEN帧 if isinstance(audio, mutagen.mp3.MP3): id3 = ID3(filepath, load_id3v1=False) if 'TLEN' in id3: return float(id3['TLEN'].text[0]) # MP4：检查mdhd原子 elif isinstance(audio, MP4): info = audio.info if hasattr(info, 'length') and info.length > 0: return round(info.length, 3) # AAC（ADTS）：Mutagen不支持ADTS时长，跳过 elif isinstance(audio, AAC): pass except Exception as e: pass # 步骤3：逐帧解析兜底（仅对VBR MP3和ADTS AAC启用） try: if filepath.lower().endswith('.mp3'): return _parse_mp3_vbr_duration(filepath) elif filepath.lower().endswith('.aac'): return _parse_aac_adts_duration(filepath) except Exception as e: pass # 步骤4：终极保底——用文件大小和平均码率估算（仅用于告警） try: size = os.path.getsize(filepath) # 假设平均码率128kbps（16KB/s） estimated = size / 16384 if estimated > 300: # 超5分钟才启用估算 return round(estimated, 3) except OSError: pass raise RuntimeError(f"无法解析文件时长: {filepath}") def _parse_mp3_vbr_duration(filepath: str) -> float: """VBR MP3逐帧解析时长""" with open(filepath, 'rb') as f: # 跳过ID3v2头（若存在） header = f.read(10) if header.startswith(b'ID3'): # 解析ID3v2头长度 size_bytes = header[6:10] id3_size = (size_bytes[0] << 21) | (size_bytes[1] << 14) | (size_bytes[2] << 7) | size_bytes[3] f.seek(id3_size + 10) frame_count = 0 total_samples = 0 while True: sync = f.read(2) if len(sync) < 2: break # 检查同步字0xFFE if sync[0] == 0xFF and (sync[1] & 0xE0) == 0xE0: # 读取完整帧头（4字节） header_data = sync + f.read(2) if len(header_data) < 4: break # 解析采样率索引（bits 11-12 of byte 2） sample_rate_idx = (header_data[2] >> 2) & 0x03 sample_rates = [44100, 48000, 32000, 0] if sample_rate_idx >= len(sample_rates) or sample_rates[sample_rate_idx] == 0: continue # 解析每帧采样数（MPEG-1固定1152） samples_per_frame = 1152 # 计算本帧长度（查表或解析） bitrate_idx = (header_data[2] >> 4) & 0x0F # 简化：此处应查MPEG帧长表，生产环境需完整实现 frame_length = 1024 # 占位，实际需根据bitrate_idx和sample_rate_idx计算 f.seek(f.tell() - 2) # 回退，让循环读取下一帧 frame_count += 1 total_samples += samples_per_frame if frame_count == 0: raise ValueError("未找到有效MP3帧") return round(total_samples / 44100.0, 3) # 默认44100Hz def _parse_aac_adts_duration(filepath: str) -> float: """ADTS AAC逐帧解析时长""" with open(filepath, 'rb') as f: total_samples = 0 frame_count = 0 while True: header = f.read(7) if len(header) < 7: break # 检查ADTS同步字0xFFF if header[0] == 0xFF and header[1] == 0xF1: # 解析采样率索引（bits 2-5 of byte 2） sampling_freq_idx = (header[2] >> 2) & 0x0F sampling_rates = [96000, 88200, 64000, 48000, 44100, 32000, 24000, 22050, 16000, 12000, 11025, 8000, 7350, 0, 0, 0] if sampling_freq_idx >= len(sampling_rates) or sampling_rates[sampling_freq_idx] == 0: continue # 解析帧长度（bits 0-12 of byte 3&4） frame_length = ((header[3] & 0x03) << 11) | (header[4] << 3) | (header[5] >> 5) # 检查protection_absent位（bit 3 of byte 2） protection_absent = (header[2] >> 3) & 0x01 if protection_absent == 0: frame_length -= 2 # 减去CRC长度 # LC-AAC每帧1024采样 total_samples += 1024 frame_count += 1 # 跳过本帧数据 f.seek(f.tell() + frame_length - 7) if frame_count == 0: raise ValueError("未找到有效ADTS帧") return round(total_samples / 44100.0, 3)

注意：上述_parse_mp3_vbr_duration和_parse_aac_adts_duration是精简版，生产环境需补充完整的MPEG帧长表查询、ADTS CRC校验、错误帧跳过逻辑。重点在于流程设计——FFprobe快但不可信，Mutagen稳但不覆盖ADTS，逐帧解析慢但绝对精准，三者按优先级串联，确保99.99%的文件在100ms内返回，0.01%的疑难文件在2s内返回。

3.3 设置时长的元数据写入实战

“设置时长”本质是向文件写入元数据，而非修改音频流。核心原则：只写元数据，不动音频帧。以下是针对三大格式的实操要点：

MP3：ID3v2.4的TLEN帧写入

def set_mp3_duration(filepath: str, duration_seconds: int): """为MP3文件写入TLEN帧（总时长，单位：秒）""" try: # 加载ID3，强制使用v2.4 id3 = ID3(filepath, v2_version=4) except mutagen.id3.ID3NoHeaderError: # 无ID3头，新建 id3 = ID3() # 创建TLEN帧，值为字符串格式的秒数 tlen_frame = TLEN(encoding=3, text=str(int(duration_seconds))) id3.add(tlen_frame) # 关键：保存时指定v2_version=4，且删除旧ID3v1（避免冲突） id3.save(filepath, v2_version=4, v1=0) # 验证写入 verify_id3 = ID3(filepath) assert 'TLEN' in verify_id3, "TLEN写入失败" print(f"MP3时长已设为 {duration_seconds} 秒") # 实测心得：iOS Music App会读取TLEN，但Android MediaPlayer优先读取文件头计算值。 # 因此，设置TLEN后，务必用FFprobe重新验证显示时长是否同步。

MP4（.m4a）：修改mdhd原子

def set_mp4_duration(filepath: str, duration_seconds: float): """为MP4文件修改mdhd原子中的duration""" try: audio = MP4(filepath) except mutagen.mp4.MP4StreamInfoError: raise ValueError("非有效MP4文件") # 获取当前timescale（通常为44100或48000） if 'mdhd' not in audio: raise ValueError("MP4文件缺少mdhd原子") mdhd = audio['mdhd'][0] # mdhd.duration是以timescale为单位的整数 timescale = mdhd[1] # mdhd[1]是timescale字段 new_duration = int(duration_seconds * timescale) # Mutagen不直接支持修改mdhd，需用bytes操作 # 方案：用mp4box或ffmpeg重写moov（推荐，更安全） subprocess.run([ 'ffmpeg', '-i', filepath, '-c', 'copy', '-movflags', '+use_metadata_tags', '-metadata', f'duration={duration_seconds}', '-y', f'{filepath}.tmp' ], check=True) os.replace(f'{filepath}.tmp', filepath) # 关键警告：直接修改MP4二进制极其危险！mdhd位于moov原子内，其位置和长度由文件结构决定。 # 生产环境强烈建议用ffmpeg重写moov，而非手动字节操作。

AAC（ADTS）：无标准元数据，只能写入注释

ADTS格式本身不支持元数据。唯一可行方案是写入ID3v2头（即使文件是.aac后缀），或转换为MP4封装。后者更可靠：

def convert_aac_to_m4a_with_duration(aac_path: str, duration_seconds: float): """将ADTS AAC转为MP4并嵌入时长""" m4a_path = aac_path.replace('.aac', '.m4a') subprocess.run([ 'ffmpeg', '-i', aac_path, '-c:a', 'copy', # 无损复制音频流 '-movflags', '+use_metadata_tags', '-metadata', f'duration={duration_seconds}', '-y', m4a_path ], check=True) return m4a_path # 实测：某车载系统只认MP4封装的AAC，且要求mdhd.duration精确到整数。 # 因此，duration_seconds必须四舍五入到最近的整数秒，否则系统解析失败。

4. 常见问题与避坑指南：那些让你加班到凌晨的“小问题”

4.1 问题速查表：症状、原因、解决方案

4.2 独家避坑技巧：来自血泪教训

• 技巧1：永远用ffprobe -v quiet -show_format -show_streams代替ffmpeg -i
ffmpeg -i是交互式命令，会输出彩色ANSI转义符，当重定向到Pythonsubprocess时，这些字符会污染JSON解析。而ffprobe专为机器解析设计，-v quiet关闭所有日志，-show_format确保返回duration字段。某次线上故障，就是因为ffmpeg -i在stderr输出了[mp3 @ 0x7f8b1c00a800] Estimating duration from bitrate, this may be inaccurate.，而Python错误地将此行当作duration值。

• 技巧2：MP3的ID3v2头必须紧贴文件开头
  某些工具（如Adobe Audition）导出MP3时，会在ID3v2头前插入4字节0x00000000作为padding。Mutagen读取时会跳过这4字节，但写入时仍从文件开头写，导致新ID3v2头与旧padding重叠，文件损坏。解决方案：用xxd -r手动删除前4字节，或用eyeD3 --remove-v1 --remove-v2 file.mp3清理后再写入。

• 技巧3：AAC的protection_absent位是玄学开关
  在ADTS头中，protection_absent（bit 3 of byte 2）为0表示有CRC校验，为1表示无。但某些编码器（如FAAC）会将其设为0，却不在帧后写CRC。此时，若解析器严格按protection_absent=0读取2字节CRC，就会把下一帧的前2字节当作CRC，导致帧错位。实测有效方案：先按protection_absent=1解析，若解码失败（如FFT报错），再重试protection_absent=0。这需要音频解码库支持，但至少避免了硬性失败。

• 技巧4：Windows下路径长度超260字符导致os.path.getsize()失败
  Python默认受Windows MAX_PATH限制。解决方案：在路径前加\\\\?\\前缀，如os.path.getsize(r'\\\\?\\C:\\very\\long\\path\\file.mp3')。某次处理网络共享盘上的音频库，因路径含中文和长文件名，20%的文件getsize()抛OSError: [WinError 206]，加前缀后100%通过。

• 技巧5：时长精度不是越高越好
  播放器对时长的显示精度有限。iOS Music显示到0.01秒，Android MediaPlayer显示到0.1秒，网页Audio API只返回整数秒。因此，round(duration, 3)是过度设计。生产环境统一用int(duration)或round(duration, 1)，既减少浮点误差，又避免播放器解析异常。我们曾将时长设为4.283秒，结果某款蓝牙耳机固件因无法解析小数点后三位，直接拒绝播放。

5. 性能优化与批量处理：如何在一分钟内处理1000个文件

5.1 并发策略：线程池 vs 进程池的生死抉择

音频解析是I/O密集型任务（读文件、解析字节），而非CPU密集型。因此，必须用ThreadPoolExecutor，绝不能用ProcessPoolExecutor。原因：

• 进程启动开销巨大：每个FFprobe进程启动需加载FFmpeg二进制（约15MB）、初始化编解码器、分配内存。启动1000个进程，仅fork开销就超2GB内存，且上下文切换导致CPU利用率暴跌。
• 线程共享内存：ThreadPoolExecutor中，所有线程共享Python解释器和已加载的库（如Mutagen），启动零开销。实测对比：
  • ThreadPoolExecutor(max_workers=8)：1000个MP3（平均5MB）耗时58秒，内存占用峰值120MB
  • ProcessPoolExecutor(max_workers=8)：同样任务耗时213秒，内存占用峰值3.2GB

from concurrent.futures import ThreadPoolExecutor, as_completed import time def batch_process_files(file_list: list, max_workers: int = 8): """批量处理音频文件时长""" results = {} start_time = time.time() with ThreadPoolExecutor(max_workers=max_workers) as executor: # 提交所有任务 future_to_file = { executor.submit(get_audio_duration, f): f for f in file_list } # 收集结果 for future in as_completed(future_to_file): filepath = future_to_file[future] try: duration = future.result() results[filepath] = duration except Exception as e: results[filepath] = f"ERROR: {str(e)}" end_time = time.time() print(f"处理{len(file_list)}个文件，总耗时{end_time - start_time:.2f}秒") return results # 实测：在8核16GB服务器上，max_workers=8是最优解。 # 超过8，I/O等待增加；低于4，并发不足。需根据磁盘类型调整： # NVMe SSD：max_workers=12；SATA HDD：max_workers=4。

5.2 内存优化：避免大文件一次性加载

Mutagen默认将整个文件读入内存。对于1GB的AAC文件，这会直接OOM。解决方案：

• 对大文件禁用Mutagen，直连FFprobe
  添加文件大小判断：if os.path.getsize(filepath) > 100 * 1024 * 1024: # 100MB，则跳过Mutagen步骤，仅用FFprobe。

• 使用mutagen.File(filepath, easy=False)的懒加载模式
  easy=True（默认）会尝试解析所有元数据，包括封面图片（可能达数MB）。easy=False仅解析基础结构，内存占用降低70%。

• 对MP4文件，用mutagen.mp4.MP4Info替代MP4
MP4(filepath)加载整个文件，MP4Info(filepath)仅解析moov原子，速度提升5倍，内存占用降至1/20。

def safe_get_mp4_info(filepath: str) -> dict: """安全获取MP4基本信息，避免OOM""" try: # 仅解析moov原子，不加载音频数据 info = mutagen.mp4.MP4Info(filepath) return { 'duration': info.length, 'bitrate': info.bitrate, 'codec': info.codec } except Exception as e: # 回退到FFprobe return json.loads(subprocess.run([ 'ffprobe', '-v', 'quiet', '-show_entries', 'format=duration,bit_rate', '-of', 'json', filepath ], capture_output=True).stdout)['format']

5.3 缓存机制：让重复文件“秒出结果”

在媒体库管理中，同一首歌可能有多个副本（不同目录、不同命名）。为避免重复解析，实现LRU缓存：

from functools import lru_cache import hashlib @lru_cache(maxsize=1000) def _get_file_hash(filepath: str) -> str: """获取文件SHA256哈希（仅读取前1MB和后1MB）""" hash_sha256 = hashlib.sha256() file_size = os.path.getsize(filepath) with open(filepath, "rb") as f: # 读取开头1MB hash_sha256.update(f.read(min(1024*1024, file_size))) if file_size > 2