修改文件哈希的原理
典型的加密哈希包括：MD5、SHA-1/256 等，加密哈希函数设计的核心特点是"雪崩效应" - 输入的任何微小变化都会导致输出的巨大变化。这意味着即使只修改一个字节，整个哈希值都会完全不同。举个例子，你写了2000字的文档，保存到word文件，你只要改变其中一个字符，比如加一个空格，那么这个文件的md5就彻底改变了，因此“改变文件哈希”的本质是改变文件内容本身，而非文件名一类的外部属性。这种特性使得文件级哈希修改相对容易实现。
不同系统与格式对“元数据”的归属不同：若元数据嵌入在文件数据中（如 JPEG/视频容器内标签），改变它会改变哈希；若元数据存于文件系统外部数据流或属性中，改变它不影响按文件内容计算的哈希，这解释了“改文件名不变哈希、改内嵌元数据会变”的常见现象。
视频平台转码与“识别是否改过哈希”
用户再视频平台在上传视频后，平台会对这个视频进行：
接收原始文件
格式检查和验证
转码处理（格式转换、分辨率调整、压缩）
关键帧提取
多层哈希计算
这是一套“解复用→解码→处理→重编码→复用”的转码流水线，以产出多码率/多分辨率自适应播放的多版本，这个过程本身就会改变文件字节序列与任何上传前的加密哈希。
文件哈希层面：平台在转码过程中会重新生成文件，原始的文件哈希会自然改变。因此，用户预先修改的文件哈希在转码后已无意义。所以平台不会去识别，你这个文件是否修改过md5等，因为没有任何意义！
去重/版权检测环节并不依赖上传者的文件哈希，而是由平台在解码后的内容上计算自有的“音视频指纹/感知哈希”，并与数据库中的参考指纹比对；例如 YouTube 的 Content ID 会对上传内容进行“指纹化”并与权利人提供的参考进行匹配。
因此平台并非“识别哈希被改过”，而是“忽略上传哈希、重算内容指纹并匹配”，这使得单纯通过修改文件字节或容器元数据来改变 MD5/SHA 并不能绕过基于内容的检测。
