序列化配置造成的。但这个一般都是特意这样配置的。别问原因，问就是 JS 不能支持 64 位整型数值的锅。

chmod 775 filename

不要做无意义的事情，15 楼的方法可以很好的解决 OP 你的这个问题。

无论是学习还是转行，Java 都是一门好语言。

已经有无数人说过无数次：没有做好血本无归的准备，就不要指望通过加密币交易来发家致富。

OP 你总结这么多条，归根结底不如一条管用：在投资领域，要清楚地知道收益和风险是什么，并及时停止冒险。
是的，任何投资行为都是冒险。所谓风险可控，只是亏得起的另一种说法而已。

在国企为啥不躺平呢？不管上面打压不打压，就不能一推二拖三不会？明确放出信号，给多少钱干多少活。

微服务肯定比巨石要容易维护，但你这个问题和微服务没关系。异步方法就用异步的交互方式好了，至于把他们都硬捏到一块么？譬如你举的这几个例子，都可以前端轮询的方式去查结果啊。

反正我导出 Excel 就是这样处理，服务端导出后上传文件到 OSS ，然后把文件的 url 写到数据库里面。前端查到 url ，就显示下载按钮。你看，这不是很简单？

@loveaeen 数据分布不均匀的话，查列表先表 1 再表 2 不好么？

做个 IP 白名单，只允许 80/443 不限制来源，其他端口都只允许白名单 IP 能访问。

分表规则必须要解决一个问题：你需要知道在哪个表查询目标数据。

一般都能在 50 米以内，少数车在 50 多点，基本没有超过 60 米的。

备刹车当然有意义，但要讲清楚什么情况下需要备刹车。很多人认为只要松开油门就需要把脚放在刹车上，这个我不认为是备刹车，这个认知毫无道理。

真正的备刹车，应该是通过观察，预判有可能需要刹车的时候，才松开油门并把脚放到刹车上，时刻准备踩刹车。如果仅仅是停止加速或者需要降低一些车速的话，完全没必要在松油门的时候把脚挪到刹车上。

OP 的观点+我的观点=不正常的人+不正经的车。嗯……

OP 你的问题是查询条件没有索引，所以直接按条件查速度慢。然而商品是有分类的，店铺也绑定了有限的分类，因为分类 ID 有索引，所以你用分类 ID 作为查询条件之一，就能很有效率。
你方案 2 是先查出店铺的分类 ID ，然后循环用分类 ID 查询数据。这两步其实可以写成 1 个 SQL 语句，就是把方案 2 的查询店铺分类 id 语句作为子查询，join 到方案 1 的查询语句里面就行。

先查店铺绑定的分类 ID ，然后查商品 join 这个子查询。

@xuanbg 如果深度优先进行递归的话，只要能生成一棵高度等于集合 1 数字个数的树，你就已经找到解了。

解题思路是这样的：
先将集合 1 排序，从最小的数字开始凑。能凑出来的就是一棵树的根。
然后每个根开始用剩下的数凑第二大的数，每个能凑出来的组合就是这个根下的第二层子节点。
以此类推，凑下一个数，所有的组合形成下一层子节点。
从如果凑的过程中遇到凑不出来的，那么这棵树就可以删掉了。

综上所述，树的高度等于集合 1 的数字个数，树的数量取决于能凑出几个组合。

首先，你这个数字只能用一次，所以不是全组合。这样组合数其实非常少。而且大于集合 1 里面的数字的组合可以直接排除，那组合数就更少了。
OP 你的逻辑肯定没有优化好，我估计递归深度应该不会超过集合 2 的个数的平方。