前置条件
你当前使用的版本
2.25.0
描述一下此特性
目前附件库的设计还是有点混乱，把文件对象管理和存储策略杂糅在一起。
一方面，它会为每一个上传的附件建立一个文件对象，会建立自己的分层目录，另一方面，它又想用内部文件对象管理外部存储策略的文件。但实际上，它对内部文件对象又抽象的不够彻底，例如对外暴露的文件链接是外部存储策略的直链，而不是用于重定向的固定链接，这其实失去了抽象的意义。
所以，我觉得它的设计应该走两条路。
第一，如果附件链接设计为静态资源的链接和外部存储的直链。那就将其他存储策略作为临时挂载，和附件管理同层级，让外部存储策略自己维护文件目录、资源的上传、链接的有效性等等。不必额外在附件管理里去添加文件对象进行管理。
第二，如果附件链接设计为固定的站内重定向链接。那就有必要维护一套虚拟的文件管理目录，其下所有文件对象都有一个固定的站内虚拟文件链接，并关联映射一个真实存储策略的文件直链，本地存储只是作为存储策略的一种形式。至于固定链接和真实链接的映射关系处理，交给不同存储策略插件去处理。
附加信息
No response
前置条件
你当前使用的版本
2.25.0
描述一下此特性
目前附件库的设计还是有点混乱，把文件对象管理和存储策略杂糅在一起。
一方面，它会为每一个上传的附件建立一个文件对象，会建立自己的分层目录，另一方面，它又想用内部文件对象管理外部存储策略的文件。但实际上，它对内部文件对象又抽象的不够彻底，例如对外暴露的文件链接是外部存储策略的直链，而不是用于重定向的固定链接，这其实失去了抽象的意义。
所以，我觉得它的设计应该走两条路。
第一，如果附件链接设计为静态资源的链接和外部存储的直链。那就将其他存储策略作为临时挂载，和附件管理同层级，让外部存储策略自己维护文件目录、资源的上传、链接的有效性等等。不必额外在附件管理里去添加文件对象进行管理。
第二，如果附件链接设计为固定的站内重定向链接。那就有必要维护一套虚拟的文件管理目录，其下所有文件对象都有一个固定的站内虚拟文件链接，并关联映射一个真实存储策略的文件直链，本地存储只是作为存储策略的一种形式。至于固定链接和真实链接的映射关系处理，交给不同存储策略插件去处理。
附加信息
No response