limaofeng

@9fan 无法在继续下去了。

"系统内文件接口太多" 我看到过很多系统，都只有一个文件上传接口（下载也只有一个）

"怎么区分临时表中文件与表单的绑定关系"，为什么会有这个问题。业务表单 file1 = 后端上传文件后生成的 FileId 。 还需要如何区分。（如果你还是不懂，那会不会是自己太菜，或者单纯只是理解与表达有些障碍）

"还有另一个问题是，项目是部署在乙方自建服务器中的，有可能会有拦截，比如请求大小，文件的校验，这个也是未知的"，这个是另一个问题，混在一起会成为解决问题的噪音。

如果你已经在维护一座屎山了，请不要尝试任何所谓的"高效的方案"，抄袭前任的方案，多问前辈。别想搞个大新闻，不然你就会成为最大的新闻。

@seedhk 他描述的临时文件，应该不是存放在系统临时文件夹中的文件。不然就唧唧

@9fan 文件上传接口要纯粹，就只上传单个文件，并返回 ID 。

所以你还是回到了 #7 的方案
如果你想清理过期文件。可以用一张表记录已经上传的文件： 比如 ID ， 状态， 上传时间， 文件实际路径。

再业务表单里面。为文件进行一次确认操作（就是修改其状态）

然后用个定时任务，定期查询 文件记录表中的 状态。如果超过一定时间未处理的文件。 你就可以删除它。

这是你要的效果吗？

@9fan 一个请求附带 N 多文件，而不是单独上传后的文件 ID 。那这个表单到 controller 一定比 只携带文件 ID 的请求慢。这个没法解决。
如果文件单独上传。在客户填写表单时，文件已经上传了。而且为了容错。可以支持多个文件同时上传，端点续传等功能。
但如果非要和业务表单同时上传文件。这个表单就是所有文件要传输的大小。你网络好，文件大的不是很过分，也没啥问题。


所以你的问题，更本就不是你能解决的。你无法改变方案。

"文件个数是不确定的" ? 这个影响吗？ 真正影响速度慢的是文件大小以及网络。 "文件个数是不确定的" 只影响你后端如何处理这个表单中的文件 key 按什么规则匹配到业务场景

@wxb2dyj 真相了
@9fan 这有啥好纠结的，这么被动，领导设计，你无法撼动，而又没有能力说服领导采纳你的方案（前提你得有），那还有啥好商量的，领导咋说你咋干不就成了。不懂问领导，即使再沙壁的方案，也是正道

很多路由器，自带 DNS Server 。 开启就可以用了。这应该不是最简单的吗？

这和原生家庭有毛线关系，我还以为被虐待了。那个年代过来的普通农村家庭大部分都经历过。当时物资匮乏，长大自我补偿。就是当年父母想大方，可能也不允许，有比穿新衣服更重要的事情。而现在已经成年，而且认识到自己的问题，不去解决。还意图归咎于 "原生家庭受的伤"。不要为自己的虚荣找借口，虚荣可以吞下任何东西。就算你父母当年给你所想，你依然会要更多。天天穿奢侈品没什么，自己赚钱自己花，只要自己开心。但你这个 "内心那种伤痕依然无法愈合"，花钱使人快乐，不快乐应该是钱不够花吧。那确实很难治愈。而且痛苦，我现在也痛苦。但我不会归因为原生家庭受的伤

3.1 GHz 四核 Intel Core i7 确实废，打开 XCode CPU 就爆了

@leohuangsulei "JPA 方法名就是查询的真的无法接受" 我用的不是这种方式。
```
List<Employee> employees = this.employeeDao.findAll(PropertyFilter.newFilter().equal("links.type", dingtalk).equal("links.linkId", id));
```
自己封装了一个查询对象，最终转换为 Specification 查询。