离谱！某公司员工自掏网费上班。。

刚看到个贴子，说某公司员工居然还要自掏腰包交网费上班，属实离谱

我觉得这事吧，不是网费贵不贵的问题，而是底线的问题。作为程序员，干活靠的是网络，配套环境都不提供，那你让我拿键盘打电报吗？

有网友说什么“小公司就这样”，但凡你听过CDN、看过监控、跑过CI/CD流程，你就知道连个稳定网络都舍不得的老板，多半也不会舍得技术栈升级和员工成长。

当然，也有人觉得花点网费不值一提，我不否认，但你今天掏网费，明天是不是就要自带服务器了？这不是钱的问题，是尊重的问题，是基本工作条件的问题。【备注:文末可领最新资料】

昨天晚上在楼下便利店等人，手里拿着个烧烤串儿，一边刷着LeetCode，结果刷到这道“俄罗斯套娃信封问题”——卧槽这个题我印象特别深，以前面试还真被问过 😓，那会儿是凌晨两点多在群里被人拉去远程面试，一上来就给我扔这道……

说白了，这题核心就是让你找最多能套几层信封，听着挺抽象，但其实不就是二维版本的最长递增子序列嘛，讲得简单点，就跟小时候咱们玩那种塑料的圆形套圈差不多，一圈比一圈大，不能一样大也不能一样小，全靠能不能套进去。

当时我一开始死脑筋上来就想暴力解，O(n²) 双重for循环那种，写着写着感觉不对劲，数据量一大就不行，后来换了个思路 —— 先排序。对对对，关键点是排序，信封你得有个套的顺序嘛。那咋排呢？

Arrays.sort(envelopes, (a, b) -> {
if (a[0] == b[0]) {
return b[1] - a[1]; // 宽度相同，高度降序排
    } else {
return a[0] - b[0]; // 否则宽度升序排
    }
});

你可能一脸懵，凭啥高度要降序？这个是有坑的，要是宽度相等又按高度升序排，那两个宽度一样的信封就容易被误判为可以套，结果套成俄罗斯梦了都……高度降序排就是为了排除这种干扰。

然后你就可以愉快地套用“最长递增子序列”算法了，注意只在高度上做LIS。也就是只考虑能不能高度一层一层上去，宽度因为已经排好序了。

List<Integer> dp = new ArrayList<>();
for (int[] envelope : envelopes) {
int height = envelope[1];
int idx = Collections.binarySearch(dp, height);
if (idx < 0) idx = -(idx + 1);
if (idx == dp.size()) {
        dp.add(height);
    } else {
        dp.set(idx, height);
    }
}
return dp.size();

其实看代码感觉还行对吧，但你真让一些刚学完基础算法的同学做，大概率要懵逼的，我身边那谁...小李前阵子为了搞明白这个题，打印了十几页输出调试信息，结果还是把 Collections.binarySearch 用错方向了 🙄

还有一次我在面试候选人的时候，哥们儿写了一堆排序逻辑但没考虑相同宽度怎么处理，结果他的LIS直接错位了，查了老半天才发现“我去，我把宽度当高度处理了” 😂

而且这题还有个奇妙的点，Java里的binarySearch那个插入点是个负数转正的方式 ( -(插入位置) - 1 )，这个写法属实是毒瘤，一不注意就写错位置了，所以后来我干脆自己封装了个lower_bound函数，写得更清晰一点。

对了，有人问说能不能直接拿TreeMap搞？我之前也试过，写起来倒是优雅了点，但跑起来性能没啥优势，反而代码逻辑还绕了一点点，就怕出bug不好查。

总之这个题啊，你得记住两个坑点：

1. 排序的逻辑，宽升高降
2. LIS做的是高度，不是全二维比较

不然你真的套不起来，俄罗斯那边都惊动了 🤯

我说了这么多，突然想起来...我那会儿做完还特地写了个小工具类，用来做二维排序，结果刚上线就被组里说“用Guava不香吗？”我...算了不说了，都是泪。💔

对了你们晚上有空不？搞完这个信封题，咱约把烧烤继续吃完，顺便给你们讲讲我踩的另一个坑，那个 Java Optional 怎么用着用着就空指针了，绝了。