@qiumaoyuan 没有分歧，我只是想回复你一下，然后分享一些关于这件事情的一些想法，前面两段内容是我的一些看法。后面两段也算是具体回复一下关于这个帖子的一些解决思路。

先不考虑是否长连接，如果你用 HTTP 来做，那么当你在发起请求之后，网络断开了，此时你是处于未知状态的。保存有可能成功，也有可能失败。

你可以在发起请求的时候创建一个唯一的 ID，这样服务器就可以支持幂等操作，你可以随意重新尝试 N 次，但是服务器只会处理一次。这样当你丢失连接以后，你可以随意再次发起一次请求，只有当你明确收到服务器的响应说这个请求已经处理完的时候，此时你再删除本地的文件。

@qiumaoyuan 规范的最终目的是服务于团队的，也就意味着想要提升整个团队的工作效率，就像代码是给人看的而不是给机器看的。进一步落地的方案可能是统一命名风格、禁用某些特性。时代在进步，同样我们使用的数据库或者其他中间件也在不断的改进和优化，但是很多方案却止步不前。开放学习和进步的团队文化是至关重要的，在我看来，现在很多的规范都已经过时了，也许在那个时候确实是有理由这样做，但是发展到现在就有点像用明朝的剑斩清朝的官。

反映出来的现象就是，由于很多人学习了这些早期项目的编码实践，后来又被其他人给继承，我不知道他们有没有仔细想过这些细节，但是科学的方法是进一步测试，得出实实在在的证据表明这些实践是否仍然有效。试图发现和总结出现这些现象的原因是另一个问题。

回到主题，对于楼主这个问题，我认为不在于 IN 本身是否好坏，而在于你的业务场景是否适合使用 IN，在 OLTP 场景，响应时间是至关重要的，同时也要保证数据的一致性和完整性，解决思路就是在时间和空间之间取得一个平衡。

对于下单来说，大多数系统需要保证操作及时响应，这也就意味着你不能进行太多耗时的操作（大部分时间花在了 IO 上），但是对于查询来讲，实时性也许就不那么强，或许可以通过异步的方式产生派生数据（即根据订单数据生成另一份数据），这一部分数据可以专门优化为方便查询的结构。当然是否采取这种方法取决于楼主业务的实际使用场景以及我方才这些假设是否成立。

好吧，又是一个没有贴出具体 [数据库以及版本] 的问题。

使用 IN 语句在新版本的 MySQL 中是没问题的，加好索引就行，唯一的问题就是如果 IN 太多的值，可能会导致数据包超过 max_allowed_packet 设定的值。

如果你的心里存在怀疑，那么最好的办法应该在自己的数据库上好好测试一下，看看是否真的存在性能问题。如果你想我们帮你测试，那么至少要列出数据库以及它的版本，更详细的可以列举到数据量、索引是否建立、硬件环境等信息。

我觉得现在很多关于数据库的使用说法有点偏中医理论了，这不能用那不能用，很多时候这些问题都是出现在特定数据库的特定版本。人云亦云，迷信上个世纪的偏方和奇技淫巧，殊不知那些东西早就已经发生了变化。

目前用的 LV273HUPR，可以直接一根 C 口线连接 mbp 充电并拓展显示屏，还有 USB 接口，价格也不错。

这里的问题就是把一些原本更适合放在 Header 中的参数放到了 URL 上。

如果楼主确实需要一种解决方案，我个人的做法可能就是写一个 Filter，然后对 Request 进行包装（ HttpServletRequestWrapper ）并重写 getRequestURI()方法，相当于 rewrite，把这些 URL 路径参数转移到一个 ThreadLocal 上（或者 Header，总之让它存到另一个地方），然后就可以比较干净的来写 Controller 了。

查到了文档，楼主可以参考一下： https://kotlinlang.org/docs/whatsnew11.html#sealed-and-data-classes

没有用过 kotlin，不过看似这个东西在语言层面有点类似于 C/C++的结构体？那么正确的做法应该使用组合而不是继承吧。

如果确实有继承的需求，那么为何不直接用 class 呢？子类行为可以复用 /改写父类行为，实现多态的效果，这才是使用继承的主要原因吧。因为最终还是跑在 JVM 上，个人猜测这里不允许继承可能是因为 equals 或者 hashcode 可能会出现问题？

目前我自己用的是意利的深度烘焙咖啡粉，然后咖啡机用的 STARESSO 三代，清洗方便，做出来的浓缩油脂十足，香气逼人，我一般直接喝浓缩或者兑点开水喝美式，夏天可以直接加冰块。

端对端加密意味着服务端压根不知道你存的什么东西，跟我本地加密然后上传 Github 是一样的吧。

取决于是读多还是写多，另外跟数据量也有关系，假如说按照最坏的情况，修改序列会导致上 W 条的记录被修改，那么单独维护一张表存储序列是一个不错的方案，里面的内容是一个字符串，用分隔符组装 ID 列表，这样在变更序列的时候仅需要修改这一条数据（一对多，这里序列表 ID 就是主表的 ID，比如歌单 ID，评论文章 ID，小说 ID 等等）。

不过在读取的时候可能会遇到条件过滤+分页的问题，还是取决于场景，可以在更新序列表后异步的更新表数据（ order ），此时数据表上的 order 字段只是一个冗余，在修改过后可能会遇到延迟的情况，在关键的地方还是要从序列表当中取出正确的排序，不过大多数情况下是可以接受的。

客户端的 TCP/IP 端口一般是系统临时分配的。如果手机系统厂商为了节省带宽费用，在自家的设备系统上开设端口，然后设备之间打洞穿透内网建立连接，搞 P2P 网络的可行性还是存在的。

做得隐秘一点的话，可以是动态的，反正手机与系统厂商之间总会建立一个连接用于服务目的。

一开始我们用汇编，后来出现了 C 语言，移除了特定架构的 CPU 指令，换平台时只要再编译一次就行了，把硬件 /系统相关的东西交给编译器来完成，C 语言不需要学习吗？

到后来人们开始使用 Java，一次编译全平台运行，Java 不需要学习吗？

下一次发生变革可能会有一个系统来替代编程语言，不需要写代码，但是这个系统不需要学习吗？

不管做到哪种程度，灵活性越高则学习成本越高，学习它本身就是一种职业技能相关的了，如果能够普及到九年义务教育，那也仅仅只能教大家如何使用，但创造性是无法直接教授的，就像学语文一样，你识字但不一定能写诗，到时候可能会说，人人都是程序员，只是使用的工具不一样。

不是没有遇到过这种，但我始终觉得这是迷惑行为，都留了 U 盘可以拷东西了，代码也不见得会多么安全。
还有那种不让联网的，我估计是在造火箭。
时代不同了，现在都是开源的世界，代码并不值钱，数据才是最值钱的。
“信任，但要验证”，与其严防死守，不如制定一种安全策略，管理好访问权限。