直接用 os.Stat 比对文件大小和修改时间不可靠，因 NFS、云存储、容器卷等场景下 ModTime() 易不一致，且仅比大小无法区分不同内容；应流式计算 SHA256 哈希比对。
为什么直接用 os.Stat 比对文件大小和修改时间不可靠
很多开发者第一反应是读两个文件的 os.Stat 结果，比对 Size() 和 ModTime() —— 这在本地开发环境可能“看起来正常”，但上线后常出问题。因为 NFS、某些云存储挂载、容器卷或 Git 仓库中软链接/子模块会导致 ModTime() 不一致，甚至同一份内容在不同节点上 ModTime() 差几毫秒就判定为不一致；而仅靠大小更危险：不同内容完全可能大小相同。
真正安全的做法是计算内容哈希。Gin 本身不处理文件哈希，你需要自己流式读取并用 crypto/sha256 或 crypto/md5（仅限内部可信场景）生成摘要。
- 始终用
io.Copy+hash.Hash流式计算，避免把整个文件加载进内存 - 不要用
md5.Sum([]byte(fileContent))—— 这会把文件全读进内存，大文件直接 OOM - 若需兼容性，优先选
sha256；md5仅当旧系统要求且传输链路可信时才用
如何在 Gin 路由中接收两个文件路径并安全比对
Gin 不允许直接通过 URL 传绝对路径（如 /compare?left=/tmp/a.txt&right=/home/user/b.txt），否则有路径遍历风险。必须限制根目录，并用相对路径 + 白名单校验。
推荐做法：前端只传文件名（如 a.txt、b.txt），后端拼接预设的可信目录（如 /var/data/uploads/），再做 filepath.Clean 和前缀校验。
立即学习“go语言免费学习笔记（深入）”；
- 用
filepath.Join(baseDir, filename)拼路径，绝不用字符串拼接 - 调用
filepath.Clean(path)后，检查结果是否仍以baseDir开头，防止../../../etc/passwd绕过 - Gin 中用
c.Query("left")和c.Query("right")获取参数，加非空校验 - 返回结构体建议含
equal bool、reason string（如"file not found"或"hash mismatch"）
如何避免 http: request body too large 错误却仍支持大文件
这个错误其实和“文件比对”无关——你根本没读请求体。它通常是因为误把文件上传接口和比对接口混用，或 Gin 默认的 MaxMultipartMemory 被意外触发。
比对接口应是 GET（查两个已有文件），不是 POST 上传。如果误写成 c.FormFile 或启用了 multipart 解析，Gin 就会尝试解析 body，导致报错。
- 确认路由是
GET /api/v1/compare，不是POST - 删除所有
c.FormFile、c.MultipartForm相关代码 - 若真要支持上传后立即比对，拆成两步：先
POST /upload存文件并返回 ID，再GET /compare?id1=abc&id2=def - 必要时全局调大限制：
gin.SetMode(gin.ReleaseMode); r.MaxMultipartMemory = 8 ，但比对接口不需要
实际比对逻辑里最容易漏掉的三个检查点
哈希计算只是中间一环。生产环境出问题，90% 出现在边界条件没兜住。
- 文件权限：用
os.Open前先os.Stat，检查err == nil且info.Mode().IsRegular()，排除目录、设备文件、符号链接 - 读取中断：
io.Copy可能因磁盘 IO、权限变化中途返回io.ErrUnexpectedEOF或其他 error，必须显式判断并返回具体错误信息 - 编码一致性：如果比对的是文本文件且业务关心内容语义（比如忽略空白行），哈希就不够了——此时该用
diff工具或专用库，而不是硬套哈希方案
哈希比对只解决“二进制内容是否完全一致”这一个问题。一旦需求变成“逻辑等价”或“忽略注释”，就得换思路。别让一个 sha256.Sum 调用掩盖了真正的语义差异。
