应优先用hash_file('sha256', $path)计算哈希并用hash_equals()恒定时间比较；需先校验返回值是否为字符串，避免false误判；预存哈希须源自可信环境且独立分发。
hash_file('sha256', $path) 必须返回字符串才可比对
调用 hash_file('sha256', $path) 后，若返回 false，说明文件不存在、不可读、路径含非法字符（如未转义的空格或中文）、或受 SELinux/AppArmor 限制。此时直接拿 === 比较会误判为“哈希不一致”，实际是校验根本没跑起来。
务必先检查返回值：
- 用
is_string($hash)确认结果类型，不是false或null - 对两个文件都做同样判断，任一失败都不能进入比对逻辑
- Windows 下路径含中文时，建议先
realpath($path)再传入，避免编码歧义 - CLI 模式下可加
error_log("hash failed for {$path}: " . error_get_last()['message'] ?? 'unknown');快速定位问题
预存哈希必须可信且未被污染
你比对的不是“当前文件 vs 当前哈希”，而是“当前文件 vs 原始可信哈希”。如果预存的哈希本身来自已被篡改的环境（比如从同一台可能被入侵的服务器上读取的 .sha256 文件），整个校验就失去意义。
安全做法包括：
立即学习“PHP免费学习笔记（深入）”；
- 哈希值应在可信环境（如离线机器、CI 构建阶段）生成，并通过独立信道分发（如签名后的配置中心、Git tag 注释）
- 避免把哈希和文件放在同一目录下，尤其不要用
file_put_contents($file . '.sha256', $hash)自动追加——攻击者可同步覆盖 - 若存数据库，字段类型用
CHAR(64)固长，防止前端注入空格或控制字符干扰比较
必须用 hash_equals() 而非 === 进行最终比对
虽然 === 在多数情况下能正确判断字符串相等，但它不防时序攻击：攻击者可通过反复测量响应时间，推测出哈希值的前缀字符。生产环境涉及权限校验、密钥文件、配置文件完整性验证时，这点不能妥协。
hash_equals() 是 PHP 内置的恒定时间比较函数，它强制遍历全部字符，无论是否提前发现差异：
- 两个参数都必须是字符串；若任一是
false，需提前处理，否则hash_equals()会警告并返回false - 预存哈希若从数据库读出，确认没带换行、BOM 或不可见 Unicode 字符（可用
trim($stored_hash, "\x00..\x1F\x7F") === $stored_hash粗筛） - 不要自己实现“逐字节循环 + usleep()”来模拟恒定时间——PHP 底层已优化，自己写反而更慢且易出错
大文件校验要绕开 Web 请求超时
单个 hash_file('sha256', $path) 对 500MB 文件在普通 Web 环境中大概率触发 max_execution_time（默认 30 秒），导致脚本中断、返回空或 false，但错误日志未必明显。
真正可行的方案只有两个：
- 校验任务改用 CLI 模式执行：
php /path/to/verify.php --file=/var/www/config.php，彻底规避超时和输出缓冲限制 - 若必须走 Web 接口，先用轻量检查（如
filesize()是否突变 +filemtime()是否异常更新）做快速过滤，仅对可疑文件异步投递到队列（如 Redis + Worker）后台计算哈希 - 切勿在 Web 中调用
set_time_limit(0)—— 它无法解决内存溢出，且会让请求长期挂起，压垮 FPM 进程池
哈希校验链条最脆弱的一环，往往不在算法本身，而在哈希怎么来的、存在哪、谁读的、什么时候读的——这几个环节漏一个，sha256 再强也白搭。
