@limaofeng 上行 200M 不是 300M 搞错了

@idragonet 上海移动转网联通，168 月租直接将到 50 ，外加 1000 下行 300 上行 宽度，还加 4 张副卡。

@KATTEN 不用销户，合约本来就可以违约。399 套餐才用不久，看合约怎么签的。如果才开始用，违约金应该也不多。

家里放个 Snell 代理，然后配置 IP-CIDR, 192.168.5.0/24, Home, no-resolve

我觉得比 WireGuard 简单。其实用 WireGuard 组网。都可以不必用 Surge 了。

既然用 Surge Snell 代理更简单。可以将 Snell Server 作为 docker 运行

打客服电话

先不带主观偏见的、去试试。试过后如果还是习惯用 windows 就继续用。后面也就没这方面顾虑了。 别人云亦云，亲自试过，才知道自己适合什么

@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 查询。

用 hibernate 必须要 hql 吗？ 我就觉得 jpa 比 mybatis 方便。普通查询之类更本用不上 sql ， 统计要写 sql 的时候也没 hql 啥事。如果还把 hibernate = 代码里面写 hql ，就是不了解 hibernate

还有这样的事情，前些天刚要了个动态公网 IP 。 不知道会不会什么时候收回

有公网 IP 组网就很方便了。 家宽联通动态公网 IP 可以直接要

单独部署不是也会有你说的问题。去拔掉电源，这时更新不也是有问题。

1. 应该考虑的是应用服务器与数据服务器是否应该分离
2. 数据库是否应该高可用，集群部署

docker 只是落地手段，k8s 不还是挂 docker 。 难道 k8s 是为了搭建开发环境的。
不用 docker 和 k8s 这些问题你也要面对。 工具直接简化解决问题的方式