感谢，已经把有关调用钉钉服务拆分了，直接放在有外网的机子上，直接远程调用，不代理了，已经给钉钉提工单了，没用

当前请求 http 由于被安全前置拦截状态码返回 473 ，最后请求这个接口的页面就会返回 "xxx 473 xxx",其中 xxx 是前端自己拼接的

补充接口请求的响应渲染：
http://1.117.77.5/response_view.jpg

补充接口请求的响应
http://1.117.77.5/response.png

组合无疑比继承更加优雅，相对于 java

不建议使用 docker swarm ，除非你是 linux 专家，我就用过，对外访问时网络时快时慢，后期全换成 jar 启动，网络比较平均比用 docker swarm 网络快

insert into article_views(url, views)
values (#{url}, #{views})
on duplicate key update views = views + #{views} 类似这种吗

@wellerman 这个也可以的，与增加临时上传接口本质差不多，你这个更加注重文件上传接口统一成一个的，对前端更加友好

@Belmode 希望你不会不会遇到，算球，只是针对技术解决方案，不对领导与别人作出评价。
@limaofeng 还是应该学习这位老哥的 #13 心态。保命要紧。再贴一波：这有啥好纠结的，这么被动，领导设计，你无法撼动，而又没有能力说服领导采纳你的方案（前提你得有），那还有啥好商量的，领导咋说你咋干不就成了。不懂问领导，即使再沙壁的方案，也是正道

@limaofeng "怎么区分临时表中文件与表单的绑定关系"，为什么会有这个问题。业务表单 file1 = 后端上传文件后生成的 FileId ： 针对这个，我想的是多个表单怎么找到自己表单的临时文件 key ，不好意思是我想叉了，我当时想的记住这个表单，下次可以重用并且适时间内表单内文件是存在的，当前这个表单是知道的没问题，但是当他关闭这个表单后，又想重新提交的情况下，其实这种情况是不需要解决的，只需要定时清理无用的临时文件即可

@zpf124 这个还是最好，谢谢了，下次一定描述尽量准确一点。不用记数据库，返回 url,前端就算离开这个表单，最终也是被延后几小时后删除，前端也能正确提交，唯一需要修改的是要不就在提交表单的业务接口去拉文件然后自己调用文件上传，因为是微服务，要么让其提供一个通知临时文件变永久文件的接口，文件 key 还是不变

@seedhk 应该不可能，应该只有状态为已使用的才会被清理
@limaofeng 是的，有问题是，如果有多人在提交表单，怎么区分临时表中文件与表单的绑定关系的，如果按照 #20 所说中的第 1 方案让前端生成一个唯一表单 id 来与临时文件表中进行绑定，我觉得可行，但是怎么保证前端生成的一定是唯一的呢，如果交由后端生成，那什么时候该生成什么时候应该返回这个表单 id 呢。还有这个方案还是没有 @zpf124 的 2 方案好，简单好维护且高效，不知意下如何。其实 @zpf124 说的是的，他主要是考虑文件打包的功能，其实系统中文件如果这样设计，那么文件上传在微服务调用会区分多个接口调用，而且对应的下载接口数量也同等，前端已经在报怨了，说系统内文件接口太多，已经不知道调用哪个了，可能是接口设计抽象能力不够吧。还有另一个问题是，项目是部署在乙方自建服务器中的，有可能会有拦截，比如请求大小，文件的校验，这个也是未知的

@limaofeng 可否先让后端业务这边单独写个文件暂存的功能返回文件 key ，其实不走文件服务，后续在提交表单时只传与这个表单对应的 key ，这里头可否有问题，比如怎么知道是这个表单的文件 key ，而不是别的表单的文件 key ，后期当前表单提交后，找出临时文件 key 的文件去调用文件服务去上传，最后再删除这个临时表的文件 key 及临时文件。其中的问题应该怎么解决，是不是增加了复杂性了

@xiangyuecn 你真懂，我们都这么觉得的，小伙子，有无好的方案呀，贡献一波，一看你就是大佬，好让我来喷一下领导，虽然我一直赞同文件服务不管业务，只管上传，以及中间增加过滤规则拦截规则之类的

@zpf124 文件个数是不确定的

感觉这下子应该说清楚了，下次还是应该直接上 demo

目前是 POST http://localhost/project/create (@ModelAttribute ProjectCreateRequest request)

request {
field1,
field2,
field3,
......
// 领导立项文件
List<FileDto> file1;
// 领导会议纪要
List<FileDto> file2;
// 其余补充文件
List<FileDto> file3;
}

类似这样的，由于文件太多，且这种会慢，有没有更好的方法

@unclema 是的，目前就是每个类型的文件对应一个字段这样做的。主流方案大家都赞同，由于领导个人影响力太强，我们无法更改，前端一直骂娘，一个文件上传调 6 个接口，我们没办法决定

@cheng6563 multipart/form-data 是可以上传多个文件，但是文件无法进行业务上的区分。
@vagusss 如果单独做，那这种临时文件需要单独去开发，去做存储。还要考虑后期定时删除废文件
我的意思能否有优雅的设计方案