各位大佬公司 OSS 文件存储是怎么做的？

两个方案：
1. 架个中间 node 层，把根据文件名获取 url 的逻辑封装在这一层，返回给前端的数据就是完整的 url，前端就可以避免来回请求，浪费性能和降低用户体验。具体哪些桶走照片桶，哪些桶走文件桶，这些都可以在 node 中间层里做配置化。这个设计对于 UI 前端，把 OSS 的细节都屏蔽了。
2. 不敏感的图片、文件，直接 CDN 化。首先配置 OSS 的 CDN 功能。另外约定每个桶的上传规则，同类型的桶尽量规则一致。使用时前端根据规则直接拼接出 URL，拼接过程可以封装成组件或 util 函数。

问题是数据库没存桶名吧，这类文件会非常多，建议还是存 es 里。只能把图片的桶合并成一个，然后存包含桶的完整路径。如果不整成完整的路径，只能按方案二了。

oss 确实复杂，可以看部署 csi 存储的例子 https://drive.google.com/file/d/19T_15PUuXiMXlN71lkVbtdWBlOIajxt_/view

我觉得给到前端的地址得是完整的 url，从一开始返回的时候就应该返回完整的 url 而不是文件名。数据库存什么数据是后端的自由，但是给出去的数据得是完整的，除非有特殊的理由。
所以，如果没有专门做 BFF 的话，你们还是把地址拼好了返回出去吧。
最后。。。我一直没看懂楼主两个方案是啥意思。。。

为啥要这么设计呢？听上去前端增加了很多无用的请求（应该不是为了反爬吧？因为你最后还是能拿到图片 url 的）

1 、前端请求服务器（通用接口），获取 Token 以及文件 URL 路径信息，此 Token 用于调用 OSS 云存储 SDK 传入，Token 一般是 Base64 编码后的一长串字符串，SDK 上传至 OSS 云服务器，OSS 云服务器负责校验 Token 以及解析 Token，并根据元信息（业务后端生成 Token 时指定的桶、文件名称）把文件放到指定的位置。这个 Token 类似 JWT 这种结构，里面包含了元信息以及签名。
2 、SDK 上传完毕后，提交表单把 URL 路径信息提交至业务服务器，业务服务器直接保存 URL 路径。
3 、读取的时候，只需要 URL 路径，后端就可以拼接域名+路径得到完整的访问路径，如果是私有的则需要加上访问 Token，那么后端只需要提供一个根据 URL 路径得到访问链接的通用接口即可，前端就可以调用这个接口批量转换解析。

将上传和解析链接独立出来，成为一个通用的接口，业务使用上就可以直接保存 URL 路径，而不必重复上传或解析的工作，前端也可以根据这两个通用的接口得到自己想要的数据。

在调用生成 Token 这个接口上面，可以自定义参数，比如使用场景、文件类型限制等等，方便与 OSS 进行集成，接口在获取这些信息以后就可以生成对应的 Token 以及准备上传文件的 URL 路径，或其他前端需要在上传阶段需要得到的信息。
如果需要区分不同的桶，则可以在保存的 URL 路径上增加特定的前缀，这样解析服务就可以知道这个 URL 路径到底是哪一个桶的，不过不推荐这样做，不同的业务应该使用各自不同范围的服务，而不是一个大统一的跨项目的通用接口。

至于为什么不在业务数据直接返回的时候直接拼接，这取决于前端的需要，其实前端可以合并请求一次性获取。另外就是如果在后端进行拼接，那么每一个接口都需要知道域名等信息，我的建议是不要把业务数据的 URL 路径当做是一个路径或者链接，而应该把它当做一种特定格式标识符，标识符是需要被二次解析的。想象一下如果返回的数据中不仅要包含 URL，还要包含文件名以及大小上传时间等，跟业务数据的耦合性就比较大。或者这一步至少通过一个过滤器来完成，通过注解（ Java ）的方式来统一处理，否则会有大量重复枯燥的代码。

参考业界成熟方案呗，比如 S3，数据库里就是只存 file key