必须跳过 Echo 默认 multipart 解析，直接读取 c.Request().Body 原始字节流；用 mime/multipart 手动解析 boundary 并提取加密字段，避免文件被提前解密或明文处理。
上传前必须绕过 Echo 默认的 multipart 解析
Echo 框架的 c.MultipartForm() 会自动把文件读进内存或临时磁盘，但这个过程不支持拦截原始字节流——你没法在解密前拿到加密后的二进制数据。一旦走默认流程，文件就被当作明文处理了，后续再加密只是“马后炮”，对传输中保护毫无意义。
正确做法是跳过 MultipartForm()，直接从 c.Request().Body 读取原始请求体，手动解析 boundary、提取加密文件字段。你需要用 mime/multipart 包配合 io.MultiReader 或 bytes.NewReader 控制流走向。
- 务必设置
c.Request().ParseMultipartForm(32 （如需读取其他表单字段），但不要调用 <code>c.MultipartForm() - 用
multipart.NewReader(c.Request().Body, boundary)逐 part 解析，只对目标file字段的Part.Body做流式解密 - 避免一次性
io.ReadAll()整个 body，否则大文件会爆内存
解密逻辑必须在内存中完成，不能依赖临时文件
如果你把加密文件先写到磁盘再解密，就等于把密文落盘了一次——这违反私有文件“不落地”的基本安全前提。攻击者只要能访问服务器临时目录（比如通过 SSRF 或容器逃逸），就能拿到未解密的原始数据。
所有解密操作必须基于 io.Reader 和 io.Writer 构建管道：加密文件流 → AES/GCM 解密器 → 内存 buffer 或直通存储服务（如 OSS/MinIO）。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 推荐用
crypto/aes+crypto/cipher.NewGCM，带认证的加密模式防篡改 - 密钥不能硬编码，建议从环境变量或 KMS 获取，用
os.Getenv("ENCRYPT_KEY")读取后做一次sha256.Sum256衍生主密钥 - IV（初始化向量）必须随文件一起上传，且每次上传唯一；可放在 multipart 的 header（如
X-IV）里传过来
上传到对象存储时别漏掉 Content-MD5 和 SSE-C 头
即使你在服务端解密成功，如果下一步上传到 OSS 或 S3 时用的是明文 HTTP 请求，中间网络节点仍可能截获。更糟的是，有些 SDK（比如早期 aliyun/oss-go-sdk）默认不校验响应完整性，返回 200 就认为成功，其实文件可能被中间人篡改过。
真正安全的上传链路是：客户端加密 → 服务端流式解密 → 服务端再用 SSE-C（Server-Side Encryption with Customer Key）加密上传 → 对象存储端强制校验 Content-MD5。
- OSS 上传需显式设置
x-oss-server-side-encryption-customer-algorithm: AES256和对应密钥头 - 计算上传体的 MD5 必须在解密后、上传前做，用
md5.Sum()算出后再转成 base64 放入Content-MD5header - 别信 SDK 的“自动重试”——SSE-C 密钥不参与签名，重试会导致重复加密，OSS 会拒绝
别让错误日志泄露加密上下文
开发时习惯性把 err.Error() 打进日志，但如果解密失败，错误信息里可能含 IV、密钥长度甚至部分密文片段。线上环境一旦开启 debug 日志，等于把解密参数广播出去。
所有与加密相关的错误都应脱敏：统一返回 "upload failed: invalid payload"，真实错误只记到审计日志（如写入独立的 /var/log/audit/encrypt.log），且权限设为 600。
- 禁止在
echo.HTTPError的Message字段暴露任何加密细节 - 用
log.WithFields()记 audit log 时，iv、key_id、file_size这类字段必须打码（如iv: "****-****-****-abcd"） - 尤其注意 Go 的
fmt.Errorf("decrypt failed: %w", err)会透出底层错误链，要拆开处理
