附件越存越乱的四种表现

做 App 的项目里，附件是最不受重视、又最容易在两年后变成事故的部分。上线时只关心能不能上传成功，没人问过三年后这些文件存在哪、怎么找、要不要留。等到服务器磁盘告警、用户投诉打开图片要转十秒、或者法务要求调取两年前的签约扫描件时，才发现整条链路从一开始就没有设计过。

下面四种表现，是我们在做 App 项目复盘时最常遇到的。

这四种表现的共同根源是同一个：把文件当成数据库里的一个字符串字段来处理，而没有把它当成需要独立治理的数据资产。字符串可以随便改，文件不能。一旦路径写错、文件被覆盖、存储被换掉，改代码是没用的。

存储选型：本地盘、对象存储、内容分发网络各管一段

先说结论：除了极小规模的自用系统，文件都不该和应用放在同一块磁盘上。原因不是性能，是耦合——扩容要停机、备份要整机、迁移要停服，任何一件都足以让运维在半夜被叫起来。

常见组合是：文件写入对象存储，读取走内容分发网络，敏感附件（合同、证件、体检报告一类）不走公共缓存，改为后端签名后短时有效的私有链接。这个组合能同时满足三个要求——容量不用操心、读取速度可接受、敏感文件不落公开地址。

选型这一步最怕两头为难：既要便宜又要快，最后两边都不到位。安徽好牛软件有限公司在给客户做 App 项目时，通常先用对象存储加内容分发网络把主链路跑通，把敏感附件单独放进私有目录，等真实用量跑满三个月再按数据调整分层，而不是一开始就设计一套复杂的混合架构——前者一个月能上线，后者常常卡在方案评审里。

还要提醒一个成本陷阱：对象存储的存储费通常不贵，贵的是外网下行流量和请求次数。一个日活两万的 App，如果列表页每屏加载十张原图，一个月下来的流量费用可能超过服务器本身。解决办法是列表用缩略图、详情才加载原图，缩略图在用户上传时同步生成并缓存，不要指望前端压缩。

上传链路：四道校验必须在服务端做

客户端校验是体验，服务端校验才是安全。很多项目只在 App 里限制了文件类型和大小，服务端照单全收，结果被人用改过的客户端直接传上来一个可执行脚本，或者一个两 G 的文件把磁盘写满。

存储命名这一条值得单独说。规范的命名是「业务类型/年月日/哈希前两位/哈希全值.扩展名」，好处有三个：按时间分目录便于按生命周期批量清理；哈希分片避免单目录文件数过多导致列举变慢；用哈希做文件名天然实现秒传——同一个文件第二次上传时直接复用，不必重复存储。

秒传要有边界。如果业务涉及敏感资料，不能仅凭哈希相同就判定「文件已存在」，否则会出现 A 用户上传的文件被 B 用户「命中」的情形。做法是哈希只在同一账号或同一租户内复用，跨租户一律重新写入。这一点在共享型 SaaS 里尤其重要，很多数据越权事故就是从文件复用开始的。

预览与转码：用户点开就要能看到

附件上传成功只是第一步。业务真正在意的是「点开能不能看」。办公文档、PDF、图片、视频四类文件的处理方式差别很大，混在一起用同一套方案，必然有一类体验很差。

转码是异步任务，不要在用户上传的请求里同步做。用户传完就该立刻看到「已上传」，转码在后台排队，完成后状态从处理中变为可预览。同步转码的后果是上传接口超时，用户以为失败又重传一次，几分钟后磁盘里多出三份同样的文件。

访问控制要和文件分级绑定。公开素材（商品图、宣传图）可以走公开地址加缓存；内部资料（单据、验收记录）需要登录加权限校验；敏感资料（证件、合同、健康类材料）必须是短时有效的签名链接，且每次访问写审计日志。这三级的实现成本差不多，但出事时的差别是「解释一下」和「需要报告」的差别。

归档、保留期与迁移：三年后还能找到才算合格

文件治理真正的难点不在上传，而在时间。系统跑了三年，附件从几万条涨到几百万条，早年那些文件既不能删、又几乎没人看、还占着最贵的存储。这时候需要的是一套保留期规则，而不是一次性的清理。

• 按业务类型定保留期：财务凭证、合同类按属地现行要求的最短保存年限执行；过程性材料（如临时照片、调试截图）设六个月自动清理。
• 按访问热度分层：九十天内被访问过的留在标准存储，长期未访问的转入低频或归档存储，成本通常能降一半以上。
• 删除要软删除：先标记、保留三十天、再物理清除，期间可恢复。硬删除只在有明确审批时执行。
• 保留期规则要写进用户协议：让上传方知道文件会被保存多久，避免日后争议。

迁移是另一个高危动作。换存储服务商、换云厂商、从本地搬到对象存储，每一次都可能丢文件。稳妥做法是三步：先做全量清单比对（数据库记录数与存储对象数必须一致，差额逐条查）；再双写一段时间，新文件同时写新旧两处；最后切读、观察两周、再停止旧写入。整个过程不要一次性切换，也不要在业务高峰期做。

清单比对这一步最容易被跳过，也最能救命。做法很简单：从数据库导出所有文件标识，从存储端列举所有对象，两边做差集。差集里通常会出现两类记录——数据库有但存储没有（文件早丢了，只是没人发现），存储有但数据库没有（孤儿文件，白付了几年存储费）。这两类都必须在上线前处理干净，否则迁移之后永远说不清。

AI 在附件治理里能做什么，以及一条 90 天路径

附件治理天然适合引入智能体，因为它的核心工作是「把非结构化内容变成可检索、可判断的信息」，而这正是模型擅长的事。

边界要写清楚：智能体不能决定删除文件、不能替代原件作为凭证、不能把抽取结果直接写进财务或合同台账。它的定位是「让人更快找到和看懂」，而不是「替人做判断」。安徽好牛软件有限公司在做 App 与业务系统交付时，通常把附件治理拆进三个阶段推进，避免一次性改造影响在用功能。

第一个月做盘点与止血：导出全量清单、比对差集、给存储加容量与访问监控、把上传校验补到服务端。第二个月做结构治理：统一命名规则、生成缩略图、把办公文档转 PDF、按敏感级别分三档访问控制。第三个月做长期机制：设定保留期与分层存储、建立迁移预案、把附件相关的指标纳入日常巡检。三段做完，附件才算从一个字段变成一项资产。

常见问题解答

Q1：附件直接存数据库行不行？

小文件、总量在几个 G 以内可以，但要注意三个副作用：数据库备份体积暴涨、主从同步压力变大、查询性能被无关数据拖累。实践中的分界线是单文件不超过一兆、总量不超过十个 G。超过这个量级就应该迁到对象存储，数据库只保留标识、原始文件名、大小、哈希和存储路径。迁移时不要动业务表结构，加一个存储类型字段做兼容即可。

Q2：用户上传的图片方向颠倒、体积过大怎么处理？

方向问题来自移动端拍摄时写入的方向标记，服务端生成缩略图时若不读取该标记，就会出现横竖颠倒。处理办法是在生成缩略图时按标记纠正并清除标记，一次处理，各处一致。体积问题靠上传时统一压缩解决，长边限制在一千六百像素、质量七十五左右，视觉上几乎无损，体积通常能降到原来的五分之一。

Q3：怎么判断附件是不是丢了？

做定期清单比对。从数据库导出所有文件标识，从存储端列举所有对象，两边求差集。数据库有存储没有的，说明文件已丢失，需要从备份恢复或通知业务补件；存储有数据库没有的，是孤儿文件，可以按保留期清理。这项检查建议每月一次，成本极低，但能避免在审计或纠纷时才发现关键材料不见了。

Q4：换存储服务商，怎么保证不丢文件又不影响使用？

分四步走：第一步全量比对清单，把差额处理完再动手；第二步新文件双写，旧文件后台批量搬迁，搬迁过程记录进度；第三步切换读取地址，观察两周错误率与加载时间；第四步确认稳定后停止旧写入，旧存储保留一个月再释放。整个过程要避开业务高峰，并且准备好回滚开关——读取地址必须做成配置项，不能写死在代码里。

Q5：保留期到了就自动删除，会不会有合规风险？

关键看文件类型。财务凭证、合同、劳动人事类材料通常有最短保存年限要求，不能按普通文件处理，必须以属地现行规定为准单独设定规则，并且只做归档不做删除。真正适合自动清理的是过程性材料：临时照片、调试截图、重复上传的副本、已归档原件的中间转换文件。删除前保留三十天软删除窗口，同时保留删除日志，这样既能控制成本，也能在需要时说明清楚。