简单文件信息的弊端
文件上传和业务提交分开的架构中，如何标记有效文件和无效文件，指：“已上传，但未绑定到业务”，例如著名的 “微博图床”插件 就是利用这一特性吸血新浪微博导致储存被滥用
仅储存文件url储存方案分析
- 如果文件名从url中获取，必须再增加一层uuid/md5的文件夹路径，不然就会重名替换了
- 如果文件类型从url后缀获取，也可以，但是对 url 稍微有点限制
- 要求url必须能反向查找到文件系统上的文件，否则没法凭url删除文件
- 只能从业务找到文件，无法从文件找到业务
- uri中的路径必须和文件系统的路径对应，如果出现路径字符不兼容就会有问题（例如windows和linux的文件名中的特殊字符支持不同）
- 一个文件绑定到A业务，如果A业务将文件URL传递给B业务，如何给文件继续添加绑定
完整的文件信息储存方案
文件信息files：
- 上传者ID uid
- 文件url url
- 储存 disk？
- 路径 dir
- 文件名 name
- 文件大小 size
- 是否图片 type?
文件业务关联表file_map:
- file_id
- bussiness_id
- bussiness_type
- timestamps
这样的结构的优势：
- 可以清理无关联的孤儿文件, 例如上传完文件但是未绑定到业务，或者根本就是滥用储存者上传的文件
- 可以防止超权限引用，例如一个用户能看到另一个用户的图片，然后复制了他的url来上传到自己的业务，用仅储存url方案，我们没办法禁止这种行为，但是用完整方案，就可以限定只可以为自己的业务绑定自己uid的文件
- 可以知道哪个用户在哪个业务上传的文件量，可以后置的防止储存滥用
- 可以在上传组件结合文件库组件来避免重复上传同一个文件，这对较多大文件上传的业务很有用
- 在需要删除文件时，清楚的知道影响了哪个业务的哪个数据，能避免不清楚影响范围而不敢删除任何一个文件的情况，即使不删除，只是将文件转移到备份型储存以节省成本也是很有用的
- 在需要删除业务的时候，可以删除业务关联的文件
这种方案不仅在于从各方面节省成本，更在于 不使信息丢失 ，例如文件本身的信息，例如文件名，上传者ID，和文件与业务的关联关系，两个文件是否是同一个文件的关系等