只因把https改成http，带宽减少了70%

刚刷到个帖子，说有人把网址里的 https 改成 http，结果带宽直接少了 70% 。

我觉得这事吧，说白了就是“图省事，结果掉坑里”。

但换个角度想，其实背后反映的是对技术细节的忽视。网络环境早就不同了，https 不光是安全问题，还牵涉到性能优化和浏览器优先级。你少一个字母，看似没差，其实就是拿着旧钥匙硬开新门，注定卡住。

我的看法是，技术栈的细节就像管道里的阀门，拧错一个方向，水流立马缩水。不是系统矫情，而是规则已经更新，你不跟上就得交学费。与其吐槽，不如当成提醒：细节决定成败，尤其在互联网时代。【备注:文末可领最新资料】

面试题：面试中被录取的候选人

昨天晚上十一点多在公司楼下吹风，手机震一下，小李问我：哥，那个“被录取的候选人”到底怎么判啊，我总写成暴力。嗯…这个题其实特别像 HR 挑人：每个人有两项名次，比如“笔试排名”和“面试排名”，公司只会录取那些不被别人两项都更好的人。换句话说，如果存在另一个人笔试更靠前、面试也更靠前，你就被“支配”了，肯定挂。

别上来就双重循环比大小，$O(n^2)$ 面试官会摇头的。这个问题有个非常顺手的贪心：先按一项排序（随便选一项，比如笔试名次升序），然后扫一遍，维护“目前见过的面试最好名次”。为什么可行？因为排好序后，任何后来的人笔试只会更差或相等，要想不被前面的人压住，就必须在面试上更好（数值更小）。所以我们只要看他是否把当前“面试最优”进一步刷新即可。能刷新就录，不行就淘汰。整件事一遍过，干净利落。

from typing import List, Tuple

defcount_hired(candidates: List[Tuple[int, int]]) -> int:
"""
    candidates: 列表里的每个元素是 (paper_rank, interview_rank)，名次越小越好
    返回能被录取的人数
    """
# 1) 按笔试名次升序，名次相同可再按面试名次升序（不必须，但稳定一点）
    candidates.sort(key=lambda x: (x[0], x[1]))

    hired = 0
    best_interview = float('inf')  # 当前为止见过的面试最好名次（数值越小越好）

for paper, interview in candidates:
if interview < best_interview:
            hired += 1
            best_interview = interview
# 否则说明面试不如前面某人且笔试也不占优 -> 被支配，无法录取

return hired

# 小测一下
if __name__ == "__main__":
# 例子1：5个人
    people = [(1, 4), (4, 3), (2, 5), (3, 6), (5, 1)]
    print(count_hired(people))  # 期望 3

# 例子2：有并列名次也没关系
    people2 = [(1, 2), (1, 3), (2, 1), (3, 3)]
    print(count_hired(people2))  # 期望 2

你看，逻辑就两步：排序 + 单遍扫描。每当遇到更好的“面试名次”，他就能逃过“被支配”的命运，数量 +1。

整体复杂度 $O(n \log n)$（排序占主），空间 $O(1)$（就记一个最优面试名次）。坑在哪？两个小点： 第一，名次数值是“越小越好”，别写反了；第二，排序时同笔试名次的，按面试名次再排一下更稳妥，虽然即使不排也不会影响正确性（因为相同笔试时，只有面试更好的人有机会刷新）。

按笔试升序后，前缀里笔试都不差于你；只有当你的面试名次严格优于前缀最优面试，才能

要是指标从两项变成三项呢？这题就变味儿了，二维的这种“支配关系”可以靠排序 + 一维扫描解决；三维起步就要用更复杂的数据结构（如树状数组/线段树）或转化技巧了，面试里通常考二维这一版。行了，我得去热牛奶了，明早还得早起赶需求…