文件不是"上传成功就完事"
一套交易平台里的文件有五类：商品图、资质证照、合同与报价单、资金凭证、售后照片。它们的共同点是必须能追溯：谁传的、什么时候传的、被哪些业务引用、删除会不会让业务数据变成孤儿。
所以文件中心的设计目标不是"能传"，而是"能管"。
一、登记表与存储分离
文件本体存在本地磁盘或对象存储，数据库里只存一条登记记录：文件路径、MD5、大小、类型、分类、上传人、上传时间。
这样做有三个直接收益：
- 去重：同一张图重复上传，MD5 相同即可复用，不重复占用存储；
- 换存储不搬数据：从本地切到对象存储时，只需改驱动配置与新文件的写入路径；
- 可审计：谁能看到哪个文件、什么时候删的，都在登记表里。
存储驱动、三类扩展名白名单（图片/文档/视频）与各自的体积上限，统一放在「网站配置 → 上传设置」里，改上限不需要发版。
二、类型白名单要"即时生效"
一个真实的问题：管理员在设置里加了 md 扩展名，上传仍提示不支持。原因是上传校验读的是缓存里的旧配置。
处理方式是校验时直接取当前配置，不做长缓存；配置保存后立即生效。这个细节看着小，实际会影响运营对后台的信任——"我改了配置但系统没反应"是最容易引发返工的那类 bug。
三、在线预览：能看就不下载
后台的文件列表支持直接预览：图片按原图比例完整显示，文档支持 md / txt / csv / docx / xlsx / xls / pptx。预览的价值是减少下载与本地打开，尤其在客服与财务场景：核对凭证不必先落盘。
预览要处理两件事：
- PPTX 这类版式复杂的格式，转图后容易出现版面错位，需要按容器宽高比约束，而不是交给浏览器自由缩放；
- 大文件不做全量读取，预览走独立的流式输出接口，避免一次性把几十 MB 塞进内存。
四、大文件失败的四个层级
上传 500MB 文件失败时，报错往往表现为"跨域错误"或"网络错误"，实际原因可能在四个层级：
| 层级 | 配置项 | 症状 |
|---|---|---|
| PHP | upload_max_filesize / post_max_size | 超限时 POST 被丢弃，前端只看到网络错误 |
| Web 服务器 | client_max_body_size（Nginx）/ Apache 限制 | 返回 413 |
| 应用 | 上传设置里的单文件上限 | 返回明确的"文件过大" |
| 前端 | 请求超时与中断 | 大文件长时间无响应被浏览器掐断 |
治理方式是四层同时对齐：应用层上限不得高于 PHP 与 Web 服务器的上限，前端按分片或延长超时处理。只改其中一层，问题会以另一种面貌重现。
五、删除必须两段式
直接物理删除是最危险的做法。这套系统用回收站：
- 删除只做软删除，物理文件保留；
- 恢复即把标记改回；
- 彻底删除前先做引用校验：检查是否被商品、订单、合同等业务引用，被引用则拒绝并提示引用位置。
引用校验是防"删了图导致商品详情空白"的唯一有效手段。文件中心可以不知道业务细节，但必须提供"这个文件还被谁用着"的查询能力。
小结
文件中心的复杂度不在上传，而在上限、类型、预览、删除这四件事的一致性。把配置集中、校验即时、删除两段式做对，后面接入商品、合同、凭证都只是复用。