Posts on 我的小站

leetcode3345 赛博地牢：乘积谜锁

Thu, 06 Aug 2026 13:52:33 +0800

赛博地牢：乘积谜锁

序章：地精守门

你刚传送进地牢，就看见一只绿皮地精翘着二郎腿坐在石门上。
门上的铭文闪烁着阴森的蓝光：

“从 n 开始，找到大于等于它的最小整数，让它的各位数字相乘，能被 t 整除。
找不到？那就留下来给我当抱枕吧～”

你后背一凉，下意识低头看向腰间——那里挂着一把新手村祖传铁剑，剑身上歪歪扭扭刻着两行字：

while True: 砍

地精顺着你的目光瞟了一眼，噗嗤笑出声来：“哈！又是一个想用暴力枚举硬刚的菜鸟。你想超时吗？你想让服务器冒烟吗？！复杂度懂不懂？！优雅懂不懂？！”

你挠挠头：“等等，你这 n 最大才 100？”

地精脸一僵。

你拔剑出鞘：“那优雅个锤子，看爷暴力！”

第一章：暴力连斩

你的策略简单到让地精想给产品经理打差评：

从 n 开始，一个一个数字试。
把当前数字拆成各个数位，算它们的乘积。
如果乘积能被 t 整除，开门！不然就试下一个。

因为数据范围小得离谱（n ≤ 100），你完全可以像推土机一样碾过去。

def smallestNumber(n: int, t: int) -> int:
 while True: # 无限连斩，直到门碎
 product = 1
 for x in str(n):
 product *= int(x)
 if product % t == 0: # 哇！金色传说！整除啦！
 return n # 门开了，拜拜地精
 n += 1 # 没开？下一个数字上来挨砍

你一路砍瓜切菜，地精终于忍不住了：“停停停！！你这什么破算法？就硬砍？？你的时间复杂度呢？你的数学直觉呢？？”

你手上剑招不停，回头冲他咧嘴一笑：“while True 代表我对暴力学的绝对信仰。数据量小就是可以为所欲为，这是算法界的牛顿第一定律，懂？ ”

第二章：带0必杀

地精被你怼得绿脸涨成紫茄子，心态彻底崩了。它从石门上一跃而下，双手结印，浑身冒出红光，脑门上弹出一个明晃晃的状态栏：

【二阶段·狂暴】 技能描述：把数据范围扩到 10⁶ ，让这个嚣张的人类砍到手断！

法阵炸开，石门上的铭文一阵鬼畜般扭曲。地精喘着粗气，嘴角挂着反派专属的歪嘴笑：“来啊！继续暴力啊！10⁶ 的范围，够你砍到版本更新了吧？等着超时吧凡人！”

他双臂交叉，等着看你面露难色、手忙脚乱翻算法书的样子。

你愣了一下，然后仰天长笑：“哈哈哈哈哈——你可真是个小可爱！！” 你擦了擦笑出来的眼泪：“告诉你一个小秘密——从 n 开始往上找，最多试 10 个数字，我的循环自己就结束了。"

“10 次？！”地精尖叫，“10⁶ 的范围你 10 次搞定？？你当我是史莱姆吗这么好骗？！”

你指着他的鼻子开始精准输出：

“在一段连续的整数里，每 10 个必定踩到一个个位是 0 的。而数字里一旦带个 0，乘积直接变成 0——0 能被任何 t 整除！
这个 0，就是我通关的万能钥匙。”

地精低头看了看自己画的狂暴法阵。法阵发出一声闷响——“嘟——"，然后像放屁一样散了。

他"扑通"一声跪倒在地，眼神涣散，嘴里念叨着什么"不可能"“带 0 不算"之类的话。

你把铁剑往肩上一扛：“狂暴开完了？那让个路呗？”

第三章：另一扇门

石门轰然碎裂，碎石在半空中化作像素粒子消散——标准的 dungeon 通关特效，你见过一百次了。

你正准备摆个帅气的 pose 等传送门出现，却发现碎石后面露出来的，不是通往下一层的楼梯。

是另一扇门。

一扇通体漆黑、镶着血红纹路的黑曜石门。门缝里渗出暗红色的光，像是什么东西正在门后面缓慢地呼吸。

你凑近一看，门楣上刻着新的铭文，字体比刚才那扇门大了三号，还加粗了——生怕你看不见似的：

【隐藏关卡·已解锁】 给你一个字符串 num，表示一个巨大的整数，和一个整数 t。找出大于等于 num 的最小无零整数，它的各位之积能被 t 整除。如果不存在，返回 "-1"。

旁边还有一行小字，像是在警告每一个试图忽视它的人：

请睁大你的双眼：该整数 禁止出现数字 0。
违规者——将被地牢意志直接抹除。

你感觉脊背发凉。刚刚的“万能钥匙” 0 被封杀了。
而且这次输入的是字符串，意味着 num 可以是几百位、几千位…甚至 20 万位的天文数字。还可能无解，要返回 “-1”（之前可是保证有解的啊！）

你低头看了一眼手中的铁剑，剑身上那行 while True 还在闪。但你清楚地意识到——面对这扇门，暴力连砍是没用的——对面直接开了物理免疫。

地牢深处传来一声低沉的笑——不是地精那种尖嗓门，是一种浑厚的、带着混响的笑，听起来就像某个退隐多年的魔王被吵醒了午觉，正在翻动自己的技能面板。

你握紧剑柄——寒意顺着指尖爬上来，和黑曜石门渗出的暗红光芒混在一起。

真正的挑战，才刚刚开始。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3310 深夜运维惊魂：那个叫k的方法有毒

Wed, 05 Aug 2026 12:31:04 +0800

深夜运维惊魂：那个叫k的方法有毒

凌晨三点，你正做着美梦——梦见自己成了技术总监，手下管着100个程序员，每个人都在996，只有你在摸鱼。

突然，手机炸响。屏幕上赫然两个字：老板。

你心脏骤停半秒，还没来得及说“喂”，那头已经咆哮如雷：“李码！线上崩了！运维说是方法 k 炸的，这方法是不是你写的？！”

你瞬间清醒，脑子里一万个 console.log("卧槽") 疯狂刷屏。又是k！为什么每次都是k？ 上次是变量k，这次是方法k，下次键盘上 K 键坏了是不是也要算你头上？

一：方法的社交圈

你打开IDE，眼前是一片代码屎山。

n个方法，编号从0到n-1，像极了你们公司的组织架构——看似井然有序，实则一团乱麻。

调用关系写在一个叫 invocations 的二维数组里，invocations[i] = [x, y] 表示方法 x 调用了方法 y。

这不就是方法的社交网络吗？你迅速建了个有向图，锁定每个方法的狐朋狗友。

graph = [[] for _ in range(n)] # 我调用了谁

for x, y in invocations:
 graph[x].append(y)

二：标记"k家军"

已知方法 k 有 bug，所有它直接或间接调用的方法全部被视为成为“可疑方法”。

你盯着这行字，一时间有些恍惚——六年前，你也这样被标记过——那天，你只不过和对门邻居在楼道里打了个照面，就因为“时空伴随”喜提居家隔离七天，健康码红得像你写的错误日志，社区工作人员每天上门测核酸比你 CI 流水线跑得还准时。

你苦笑一声，祭出 DFS 大法，从 k 出发，沿着调用链挨个打码。

suspicious = [0] * n # 标记数组，0是清白，1是可疑

def dfs(x: int):
 suspicious[x] = 1
 for y in g[x]:
 if not suspicious[y]:
 dfs(y)

dfs(k)

DFS跑完，suspicious 数组里标为1的方法，就是传说中的**“k家军”**——一个都跑不掉。

三：移除决策

已经标记了所有"k家军"，下一步是不是直接 Ctrl+X 一把梭？太天真了。

安全手册第一条：删代码可以，崩系统不行。

什么意思？只有当这组可疑方法没有被任何外部方法调用时，才能安全移除。如果圈外还有人深情地调着圈内的方法，那你强行删除就会导致 NullPointerException，整个调用链像多米诺骨牌一样连环崩塌，明天的日报上你就能亲手写下“因误删可疑方法导致 P0 事故，影响用户 XXXXX 人，已深刻反省，主动申请取消年终奖。”

你的手指悬在键盘上方，敲下了决定职业生涯能否存续的检查代码：

for x, y in invocations:
 if not suspicious[x] and suspicious[y]:
 # 有外部依赖！原地摆烂
 return list(range(n)) # 全留着，一个不动，祖传屎山永流传

如果这段循环跑完都没触发return，那么，恭喜你——这个可疑方法集合就是一个完美的隔离孤岛。你完全可以一键 rm -rf，直接返回劫后余生的幸存者名单：

return [i for i in range(n) if not suspicious[i]]

彩蛋

事后你复盘此事，悟出一个真理：老板要删方法，先看有没有人保它。外部有调用，屎山也能免死；没外部调用，再干净也得滚蛋。

你以为你刷的是图遍历？不，你刷的是职场生存学。

如果你和你的小团队内部自嗨，从不跟外界交互——那裁员的刀落下来，你们就会被一锅端。

但如果其他部门还死死依赖着你们……嘿嘿，就算你代码写得再烂，老板也得咬牙留你——这叫技术债绑架，或者，也叫组织的“不可或缺性”。

所以，你是想当那个随时可被替换的干净方法，还是那个让老板不敢动的屎山核心？

明天上班，记得把你的方法多暴露几个接口出去。保命。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3731 逃课逮捕令：从 list 遍历到 Set 精准锁头

Tue, 04 Aug 2026 11:54:27 +0800

逃课逮捕令：从 list 遍历到 Set 精准锁头

大家好，我是一只被导师临时抓来当助教的研二狗。
今天老板出差，留给我一张皱成抹布样的签到表，以及一句杀人诛心的话：

“小李啊，这是本科班的课堂签到，1 到 50 号都在你手里了。把没来的揪出来，按学号排好发我。要是弄错一个，下周组会你替我做文献汇报。”

我打开签到表一看，血压飙得和服务器并发一样高。上面字迹歪歪扭扭：

[1, 25, 4, 18, 24, 9, 33, 15, 41, 50]

好家伙，签到顺序比我的论文提纲还乱，而且全班 50 号人，拢共只有 10 个签了到。最小号 1 和最大号 50 倒是在（这俩一个卷王一个学委，果然老实），其余的呢？？我随手一刷朋友圈，37号刚晒了张五杀截图，配文是“教室哪有峡谷香”——我瞬间明白了，这货现在八成窝在床上和原神深渊使徒激情对线。

目标很明确，我现在需要做的就是：找出从 1 到 50 这个区间里，所有没出现在签到表上的学号，从小到大排好，一个不落，整整齐齐报给导师，让这些小兔崽子们接受命运——哦不，导师的审判。

黑历史 · 人工智障，逐个扫描

研一那会儿，我也曾被导师抓去当点名苦力。当时我还很天真，撸码常常堆循环，点名纯纯用爱发电——照着花名册，从 1 号开始，挨个在签到表里找。每查一个人都把整张表从头撸到尾，眼睛都快瞪成线性扫描仪了：“2号……不在。3号……也不在。4号——哦4号签了，下一个……”

def findMissingElements(nums: List[int]) -> List[int]:
 return [i for i in range(min(nums), max(nums) + 1) if i not in nums]

列表的 in 是 O(n) 线性扫描，外面再套一层 O(m) 的循环，合起来 O(n·m)。放到 OJ 上可能直接甩你一个 TLE。

这就好比在王者峡谷里不用小地图，纯靠走路挨个草丛探视野：“这个草丛有人吗？没有。下一个草丛呢？我再跑一趟……”等你探完上路，对面已经把主宰打了三遍，你家水晶炸得连渣都不剩。

最窒息的是，当我到宿舍抓人，37号正激情五杀，听到动静 Alt+Tab切桌面，转身挤出一个比bug还假的笑容：“学长你签到表有没有认真看？我名字签在背面——我回来拿个水杯！”

黑科技 · 哈希锁头，一秒查人

痛定思痛后，我掏出了计算机专业祖传秘方——哈希集合。

原理很简单：把签到表上那十个幸运数字 [1,25,4,18,24,9,33,15,41,50] 一股脑塞进一个 set，取名 attended。这玩意儿就是个 O(1) 查找的超级花名册——从此查人不用遍历，直接问哈希：“这学号在吗？”，速度追平食堂阿姨打菜手速。

哈希点名，纯纯流水线作业：从 1 到 50 依次走过，每个学号对着 attended 问一句“ 在里面吗？”，不在的直接甩进逃课列表。因为是按顺序问的，出来的结果天然升序，老板的要求一步到位。

def findMissingElements(nums: List[int]) -> List[int]:
 attended = set(nums) # 签到数据一键导入哈希表
 return [i for i in range(min(nums), max(nums) + 1) if i not in attended]

一趟流水线走完，没来的人自动列成一张干净整齐的缺勤清单，按学号从小到大排好，比老板的论文参考文献还规整。

我把缺勤名单截图往班群一甩：[2,3,5,6,7,8,10,11,12,13,14,16,17,19,20,21,22,23,26,27,28,29,30,31,32,34,35,36,37,38,39,40,42,43,44,45,46,47,48,49]

群里安静了三秒。37号的头像弹出一个“？”：“不是学长，你这什么鬼名单，上次我签背面你没看见，这次我就上了个厕所——”

我秒回：“厕所上了五十分钟？你的五杀截图还在我朋友圈挂着呢。下周组会你替我讲文献，pdf已私聊。”

彩蛋· 逃课克星速查卡

List 遍历法：挨个遍历签到表，时间复杂度 O(n×m)，小班点名还能凑合，学号一多，比校园网抢课还卡。
Set 哈希法：签到数据一键导入哈希集合，O(1) 光速查人。时间 O(n+m)，多占的那点内存还没你手机里一款抽卡游戏大。

下次导师再让你“找缺失的元素”——不对，是找逃课的学生——别犹豫，直接 set 安排上。用合适的数据结构修理不合适的出勤率，然后你就可以安心打开原神清个体力。毕竟，37 号在讲台上替你讲文献的样子，比深渊使徒可爱多了。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode1406 赌城风云·续：阿星的出师之战

Mon, 03 Aug 2026 11:54:37 +0800

赌城风云·续：阿星的出师之战

又名：《阿星的单飞考试：递归会流鼻血，滚动数组才是王道》前情提要：上一局，你用"净胜分心法"碾压了欧洲赌魔查尔斯（）。他回去苦读《算法导论》，三个月后卷土重来。

一、查尔斯的复仇

三个月后。同一张牌桌，同一盏水晶吊灯。

查尔斯又来了。

这一回他的金发梳得更亮，领带换成了深红色——据说是专门找人算过的“必胜色”。身后还是那四个保镖，但手里的书已经从《博弈论》换成了崭新的《算法导论》，书签统一夹在动态规划那一章。封面还贴着便利贴，上面写着：“注意最优子结构！！！”

“三个月，”查尔斯站在牌桌对面，金丝眼镜换了一副，镜片更厚，反光更刺眼，“我在剑桥旁听了一整个学期的算法课——你的净胜分心法，我已经吃透了。”

你坐在牌桌左边，手里转着一块新的还没拆锡纸的巧克力。听完这句话，你停下手里的转动，然后做了一个让全场倒吸一口凉气的动作——站起来，退后三步，把椅子让给了身后的阿星。

“今天不是我跟你打。”你拍了拍阿星的肩膀，“你跟我徒弟打。”

阿星正举着半瓶汽水，差点呛到：“我？！哥，我就是个跑龙套的！我连《算法导论》封面长什么样都不知道！”

“你跟了我这么久，该出师了。”你把巧克力外面的锡纸剥开，掰下半块递给阿星。

查尔斯先是愣了一下，然后笑出声：“让你徒弟来送分？好，正好——新规矩，新牌局。”

他打了个响指。荷官推出一副新牌匣，牌面朝上，一字排开：[1, 3, 2, 50, 9, 90, 30, 90, 2, 8, 4]。

“规则升级了。”查尔斯推了推新眼镜，“还是轮流抽，但这一回——只能从最前面开始拿。每次可以拿走 1 张、2 张、或 3 张牌。拿走的牌面数字直接加进你的总分。所有牌拿完，分高的人赢。平局算 Tie。”

他往椅背上一靠，嘴角挂着一丝“我连你徒弟的墓碑都想好写什么了”的微笑。

“对了——为了公平起见，今天的先手，我们抽签决定。”他掏出一枚硬币，在指缝间转了一圈，“我也不欺负晚辈。抽签定先手，各自凭运气。”

阿星还没来得及抗议，你已经在旁边的沙发上坐下了。包装巧克力的那张锡纸已经被你折成了一只纸鹤，立在茶几上，翅膀微微翘起，正对着牌桌。“阿星，我教你的东西，这三个月你琢磨了几回？”

“呃……三回？”

“够了。打吧。”

二、阿星的独角戏

阿星坐到牌桌左边，手心全是汗。他把牌从左到右看了三遍，嘴里开始念念有词。

他在做一件每个初学者都会做的事——暴力递归。

“好，先定义一个函数 dfs(i)，表示从第 i 张牌开始先手，最多能比对手多拿多少分。”阿星掰着手指，声音越来越大，像是在给自己壮胆，“从第 i 张开始，我可以拿最前面的 1 张、2 张、或 3 张。拿走的牌面总分记作 take，留给对方的是 dfs(i+1)、dfs(i+2)、dfs(i+3) 三种局面——”

他在桌布上画了一个递归树，从 dfs(0) 开始分叉，“dfs(0) 等于 max(拿1张 - 对手dfs(1)的净胜, 拿2张 - 对手dfs(2)的净胜, 拿3张 - 对手dfs(3)的净胜)……”。一叉分三叉，三叉分九叉——画到第三层的时候，桌布已经不够用了。他把袖口也翻出来接着画，画到第四层，指尖开始发抖，额头上冒出一层细汗。

n = len(stoneValue)

@cache
def dfs(i):
 if i == n:
 return 0
 best = float('-inf')
 take = 0
 for j in range(i, min(i + 3, n)):
 take += stoneValue[j]
 best = max(best, take - dfs(j + 1))
 return best

diff = dfs(0)
return "Tie" if diff == 0 else "Xin" if diff > 0 else "Charles"

阿星感觉递归树在他脑子里疯狂生长，每多一层就多三倍的分支，像一棵没人修剪的野树，枝杈戳得到处都是。

突然——一滴红色的液体落在了桌布上，恰好滴在 dfs(2) 的圆圈里。

阿星流鼻血了。

“哥！”他捂着鼻子转头看你，“递归太深了，我脑子要爆栈了！”

查尔斯差点笑得从椅子上滑下去：“这就是赌神的徒弟？算了三分钟就开始流鼻血？”

你放下茶杯，不紧不慢地走到阿星身边，从口袋里掏出一张纸巾，“谁让你用脑袋递归了？”

你把纸巾按在他鼻子上，“三个月前教你的 DP 表呢？再说一遍——人类的大脑不适合递归，但可以填表。”

三、从全表到滚动数组

“递归是从头往下分叉，分到最后自己都不知道自己在哪一层。”你又从桌上抽了张干净纸巾，盖住桌布上那团被鼻血渗透的 dfs(2)，“填表不一样——从尾巴往前推。你想想，如果只剩下最后一张牌，你拿还是不拿？”

“当然拿啊，”阿星捂着鼻子，瓮声瓮气地说，“不拿白不拿。”

“对。最后一张的净胜就是它自己。那如果剩下最后两张呢？你有三个选择——拿一张，留一张给对手；拿两张，清盘。每个选择的净胜分用‘take - 对手在剩余牌面的净胜’来算，选最大的那个。就这样，从后往前，每一步都站在前一步已经算好的答案上，一层一层盖楼。”

阿星想了想：“那就开一个 dp 数组，从 dp[n-1] 一路算到 dp[0]？

n = len(stoneValue)

dp = [-float('inf')] * n + [0] # 末尾多一个 0 当哨兵，越界返回 0
for i in range(n-1, -1, -1):
 take = 0
 for j in range(i, min(i + 3, n)):
 take += stoneValue[j]
 dp[i] = max(dp[i], take - dp[j + 1])

return "Tie" if dp[0] == 0 else "Xin" if dp[0] > 0 else "Charles"

“对——”，你点点头：“但还可以再省。”

你用指尖划过阿星手边的汽水瓶——瓶壁上凝着一圈细密的水珠——就着那点凉意在纸巾上画下三个字符：i1, i2, i3。“你注意到没有——算 dp[i] 的时候，你只需要它后面的三个值(dp[i] 只依赖 dp[i+1]、dp[i+2]、dp[i+3])。之前的值用完就可以扔了。所以——三个变量就够了，从后往前滚，空间压成 O(1)。”

阿星瞪大眼睛：“三个变量？”

“滚动数组——你只需要记住最近三个净胜分。”

n = len(stoneValue)

i1 = i2 = i3 = 0 # 分别存 dp[i+1], dp[i+2], dp[i+3]
for i in range(n - 1, -1, -1):
 take = 0
 best = float('-inf')
 for j in range(i, min(i + 3, n)):
 take += stoneValue[j]
 if j == i:
 opponent = i1
 elif j == i + 1:
 opponent = i2
 else:
 opponent = i3
 best = max(best, take - opponent)
 i1, i2, i3 = best, i1, i2

return "Tie" if i1 == 0 else "Xin" if i1 > 0 else "Charles"

阿星攥紧了纸巾，盯着那三个变量在心里跑流程。他的嘴唇翕动着，从最后一堆开始往前滚——i3 是越界的 0，i2 是最后一张的净胜，i1 是倒数第二张的净胜——三个数字像三个齿轮，一步一步从尾巴咬到头。

滚到 i=0 的时候，他停住了。

“i1 等于……”他抬头看你，声音压到只有你能听见：“——负的，全局先手必输。”

他抬头看你，声音压到只有你能听见：“哥，净胜分是负数，全局先手必输。Alice 在这个数组上拿先手，净胜是负的。”

你端起茶杯，吹了吹浮在面上的茶叶，没说话。

阿星看着你那个表情，忽然想起了三个月前你说的话——“在游戏开始前，就把结局算死”——他明白了：算牌只是第一步，把算出来的结局钉死在牌桌上，才是真正的考验。

四、欲盖弥彰

阿星深吸了一口气，把纸巾揉成一团塞进裤兜，然后仰头看了会儿天花板，让鼻血彻底凝固。他需要这几秒钟——不是因为鼻子，是因为他得把“先手必输”四个大字从脸上抹干净，换上一张无辜的、甚至有点得意的脸。

然后——他开始笑。

笑得不大，但刚好能让对面听到。嘴角一抽一抽的，像是发现了什么不得了的秘密，又拼命想藏住。

查尔斯正用眼镜布擦镜片，手停了。他盯了阿星两秒，那两秒里阿星做了全套——先飞快地把笑容收回去，收得太快，像被抓包；然后把目光移开，假装研究天花板上的吊灯，眼珠子转得过于刻意；最后用袖子漫不经心地往桌布上一盖，恰好盖住那片被汽水字迹和鼻血交替浸过的纸巾碎片。

“你笑什么？”查尔斯把眼镜戴回去。

“没什么没什么，鼻子通了，高兴。”阿星站起来，身体不自觉地挡在桌布前面。一只手在背后悄悄把裤兜里那团揉皱的纸巾往里塞了塞，动作大得生怕对面四个保镖有一个没看到。

果然，一个保镖低头在查尔斯耳边说了句什么。查尔斯的眉头慢慢皱了起来。他用手指敲着桌面，“你的表情，就像算出了不得了的东西——你在算先手还是后手赢，对不对？”

阿星的表情僵了一瞬——这一瞬的僵硬，足够让查尔斯确认自己猜对了。

“阿星，”查尔斯往前倾了倾身子，金丝眼镜后的目光像两颗瞄准激光，“你刚才是不是算出来，先手必赢？”

阿星的瞳孔微微放大。这个表情就像被人当众翻开底牌——不，像是被人猜中了自己正在拼命隐藏的结论。他飞快地摇头：“不是不是，我什么都没算出来……递归太深，我流鼻血了，脑子不清醒……先手后手什么的，我觉得应该差不多吧，五五开，运气最重要。”

“五五开？你刚才算到流鼻血，然后就开始笑，现在又跟我说五五开？”查尔斯眯起了眼睛，“你在说谎。”

阿星的额头上沁出了一层细密的汗。骗一个在剑桥旁听过一学期算法的聪明人，每一步都不能踏错。假话要混在真话里说，表情要半真半假，最难的是眼神——你不能直视他，但也不能完全躲开。你得让他觉得你在躲，但又让他恰好能捕捉到你“不小心”漏出来的破绽。

“查尔斯先生，”阿星突然站直了，语气变得异常认真，仿佛刚才的慌张全是铺垫，现在才是真情流露，“今天我师父不在桌上，我就是来练手的。你先手的话太欺负人了——你算法课上了三个月，我才琢磨了三回。这局让我先手，公平点。”

他说“公平点”三个字的时候，眼神里甚至带着一丝恳求，嘴角用力抿着，像在做最后的挣扎——明明知道对方不可能答应，还是硬着头皮把话说出来，试图用道德绑架一个没有道德的欧洲赌魔。

查尔斯看着阿星那张真诚的脸，慢慢笑了。先是嘴角，然后是眼角，最后整个肩膀都在抖。他等这一刻等了三个月。三个月前他被先手的一张 1 玩死，回去以后在笔记本上写了三百遍——“先手才是庄家。后手只能被动反应。”

“我先手。”查尔斯一锤定音。

“等一下！让我先手！”阿星的肩膀轻微地抖了一下，像是最后一根弦被扯断了，他张着嘴，手还僵在半空中，语气低落得像是被抽走了半条命，“……你连硬币都不抛了？”

“硬币？”查尔斯把硬币收回胸口的西装口袋，拍了两下，金丝眼镜后的眼睛弯成了两道得意的弧线，“不需要了。你的表情，你的小动作，你拼命想藏起来的那团纸巾——每个信号都指向同一件事：你算出来了先手必赢，你想抢那个先手。既然你想抢——我为什么要让给你？”

五、注定的结局

接下来的每一轮里，阿星只是安静地拿牌。每一轮都拿得不快不慢，没有得意，也没有犹豫。他不需要再算了——整局的结果在查尔斯拿先手的那一刻就已经钉死了。

牌局很快结束。荷官按下计算器，报出两个总分。

“怎么可能——” 查尔斯的脸色从红变白，从白变青。他低头看着桌上的牌，又抬头看着阿星，嘴张了两次都没再发出声音。然后他猛地站起来，椅子在身后发出刺耳的摩擦声。

“你不是流鼻血了吗——不对，你从一开始——”查尔斯的手指在阿星和牌桌之间来回弹跳，像一台卡壳的打字机，“你从一开始就知道了！全局先手必输！但你故意让我以为先手必赢。你刚才那个表情——那个藏桌布、藏纸巾、求我让你先手的表情——全是演的！！”

阿星缓缓站起来，从裤兜里掏出那张揉皱的纸巾，展开铺平在牌桌上。上面还留着汽水干透后浅浅的水渍。

“我师父三个月前教我的——在游戏开始前，就把结局算死。”阿星把纸巾推到牌桌中央，“净胜分心法第二条——你抢过去的先手，可能恰好是我算好了要送给你的。”

六、赌神的进阶

查尔斯被四个保镖架走了。临走时嘴里还在念叨“净胜分”和“先手后手”，金丝眼镜断成两截挂在耳朵上，像一对垂头丧气的翅膀。

阿星一直目送查尔斯的背影消失在旋转门后面，才长长地吐了一口气。他把牌桌上的汽水端起来咕咚咕咚灌了半瓶，然后转头看向你，“哥，刚才那段演技，我自己都有点没底——藏纸巾那一下是不是演得太用力了？”

“演技确实是浮夸了点——但逻辑没问题，你赢了。”你从沙发上站起来，走到牌桌旁边，“但是——净胜分的视角，还不够简洁。”

阿星一愣。

“净胜分确实没错。能赢。但还不够简洁。”你在纸上画了一个新的结构，“你刚才一直算的是‘我比你多赢多少’，但你有没有想过——直接算‘我能拿多少分’？”

阿星一愣：“不够简洁？不是都已经把空间压到三个变量了吗？”

“不是在空间上。是在思路上。”你在牌桌对面坐下，“你每次轮到你拿牌的时候，是不是要在心里跑一遍内层循环？拿一堆算一遍 take - opponent，拿两堆算一遍，拿三堆再算一遍，三个分支比完才敢下手。”

阿星想了想，点头：“确实。每次到我，我都得在脑子里过三个选项。虽然能算出来，但总觉得中间多了一层——像脑子里有个翻译官，把我想拿的分数先翻译成‘比对手多多少’，比完了再翻译回来。”

“因为净胜分的视角，天然多了一层。你有没有想过——不记录净胜分，直接算当前牌面‘你能拿到的最大总分’？”

阿星一愣，然后微微坐直了身体。

“换个视角。”你抽出一张纸，写下新的定义，“定义 f[i]：从第 i 张牌开始先手的玩家，在剩余牌面中能拿到的最大总分。注意——这次不是差值，就是你自己的总分。不关心对手拿多少，只关心你自己能装进口袋多少。”

“从后往前看。只剩最后一张牌的时候，你拿走它，你的总分就是它本身。那如果从中间某张牌开始呢？每一轮你可以拿最前面的 1 张、2 张或者 3 张。不管你拿几张，从当前这张到末尾的总和——后缀和——是一个死的数。你拿走一部分，剩下的全归对手。对手在他拿到的那部分里，也会用最优策略拿走他的最大总分——那就是 f[i+j]。”

你停下来，让他消化这个概念。“所以每轮牌面，你能拿到的最大总分等于什么？后缀和 - 对手在剩下牌局里能拿到的最大总分。”

s[i] = 从 i 到末尾的后缀和 f[i] = s[i] - （对手在剩余牌面里能拿到的最大总分）

“重点来了——要最大化你能拿到的，就要最小化对手能拿的——对手在剩余牌面里能拿多少？取决于你。你拿 1 张，剩给他的是从 i+1 开始——他最多能拿 f[i+1]。你拿 2 张，剩给他的是从 i+2 开始——他最多能拿 f[i+2]。你拿 3 张，他最多能拿 f[i+3]。最小化对手能拿的，也就是在这三个数中选最小的那个——min。”

f[i] = s[i] - min( f[i+1], f[i+2], f[i+3] )

阿星盯着那个 min，张了张嘴。这个反应和你预计的一模一样。

“而且——后缀和只依赖当前位置，后面三个 f 也只依赖紧挨着的三个状态。和刚才净胜分的滚动数组一模一样的依赖关系：f[i] 只跟 f[i+1]、f[i+2]、f[i+3] 打交道，再往后的值碰都不碰。同样不用数组，直接可以用三个变量滚完全局。”

n = len(stoneValue)

s = f1 = f2 = f3 = 0
for i in range(n-1, -1, -1):
 s += stoneValue[i]
 best = s - min(f1, f2, f3)
 f1, f2, f3 = best, f1, f2

diff = f1 - (s - f1)
return "Tie" if diff==0 else "Xin" if diff>0 else "Charles"

“这就是思维翻转——视角一换，内层循环直接消失。”你从口袋里掏出一块新的巧克力，掰了一半递给阿星。

“净胜分算的是两个人的博弈——你要在三个分支里分别算‘我比他多多少’，所以需要内层循环去模拟拿一张、两张、三张的分支。而总分算的是一个人的收益——你不需要关心对手具体拿多少，你只需要让他在剩给他的局面里，拿得越少越好。后缀和是死的，min 三个 f 锁定对手的下限，你拿的自然就最大。”

阿星把那半块巧克力塞进嘴里，低头看了看自己两条小臂——左胳膊上还隐约能看见三个月前用圆珠笔写的“先手判生死”，已经褪得只剩浅浅一道印子；右胳膊干干净净，像是特意留到今天。

“哥。左胳膊纹净胜分，右胳膊我想纹这个 min。”

你把另外半块巧克力放进嘴中，起身拿起茶几上的纸鹤，放在他手心。

“先回去把鼻血擦干净。纹身师不接流着血来的人。”

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode877 聚会杀手锏！石子游戏教你做一个没有感情的赢家

Sun, 02 Aug 2026 11:54:42 +0800

聚会杀手锏！石子游戏教你做一个没有感情的赢家

朋友，你是否厌倦了在聚会上当小透明？玩狼人杀首夜被刀，打UNO被+4连环暴击，搓麻将点炮点到灵魂出窍…… 别再用运气解释人生了，今天，我要向你郑重安利一款物理引擎驱动、100%先手必胜的聚会神作——《石子游戏》（又名 LeetCode 877）。不需要演技，不需要运气，只需要一点点小学数学，就能让你在朋友面前化身‘必胜客’。

必胜操作手册：

游戏准备（请严格照做）

道具：一把石子、M&M豆、瓜子、硬币……能堆起来的东西都行。
布阵：让你的朋友把这些道具分成 偶数堆，在桌上一字排开。每堆数量任意，告诉你朋友，他可以随心所欲，尽情发挥。
关键一步——奇偶调教：等朋友分完，你假装清点，悄悄算出总数。
- 如果总数已经是奇数，完美。
- 如果总数不小心是偶数，立刻偷偷吃掉（或加上）一颗，同时面不改色地说：“这是启动游戏的仪式密钥。”
为什么必须是奇数？因为奇数保证没有平局，而且奠定了你必胜的数学地基。这一步，就是把胜利攥在自己手里。
选定身份：你当先手玩家，朋友当后手。然后，开始游戏。

必胜秘诀：

这款游戏的底层逻辑，比泡面里没有真牛肉还要赤裸——先手必胜。

因为总堆数是偶数，所有石子天然被分成了两个阵营：

奇数组：第1、3、5…堆（所有单数位置）
偶数组：第2、4、6…堆（所有双数位置）

而石子总数又是一个奇数，这就意味着——奇数组和偶数组的石子总数绝对不相等，总有一组会多，一组会少。这不是运气，这是数学板上钉钉的事。

身为先手玩家，你拥有一个离谱的特权：你可以直接决定自己拿走哪一组，把另一组硬塞给朋友。

怎么操作？趁你朋友还在精心管理表情的时候，快速心算一下两组的总数：

如果 奇数组更多，直接伸手拿走 最左边 那一堆（它属于奇数组）
如果 偶数组更多，直接伸手拿走 最右边 那一堆（它属于偶数组）

这一步就是定边——出手的那一刻，胜负就已经分好了。拿走最左边，朋友就被锁死在偶数组里；拿走最右边，朋友就被锁死在奇数组里。从第二轮开始，桌上的局面会变成：露出的两端，全都是属于朋友那组的石子。他无论拿哪边，都在帮你打工——因为他一拿走，必然会把属于你那组的石子暴露出来。

之后你的操作，简单到可以边嗑瓜子边完成：他拿哪边，你就跟着拿哪边。 他左你左，他右你右，不用思考，不用纠结，全程当个无情的镜像复读机就行。一口一口把属于你的那组石子全部收入囊中，最后留给朋友的，只有他从一开始就注定要接盘的另一组。

没错，就是这么简单粗暴。只要你是先手，无论朋友怎么摆石子（偶数堆，奇数总数），你都 100% 能赢。

实战演示：

假设朋友自信满满地摆出 4 堆 M&M 豆：[5, 3, 4, 5]。

你先别吭声，心里盘算一下：

奇数组：5 + 4 = 9
偶数组：3 + 5 = 8

奇数组更大，那就按口诀来——第一步直接抢最左边的 5。朋友还没反应过来，桌上就剩 [3, 4, 5] 了。

朋友行动（只能拿两端，都是偶数组的）：他若拿右边的 5。
你镜像——也拿右边，取走 4（它正是奇数组的）。
朋友最后只能拿剩下的 3。

你合计：5 + 4 = 9，朋友合计：5 + 3 = 8。

你赢。他输。他瞳孔地震。你抓一把豆子塞进嘴里，深藏功与名。

风险控制（为友谊续一秒）

此游戏别名 《友谊尽头》，连胜三局之后，朋友可能当场掏出手机搜索“石子游戏必胜”，并在接下来的聚会里对你保持高度警惕。
建议战术性放水一局，比如第二局故意拿小分组，然后挠着头说：“哎呀，这次运气不太行。” 用精湛的演技来维持塑料友谊的常青。
若朋友强行要求换先手，请果断提议换游戏——比如 LeetCode 486，那里先手可不一定赢哦。

写在最后（附赠代码一行）

下一次聚会，当别人还在掏手机查谁是卧底时，你已经优雅地掏出一把石子（或 M&M 豆）。

先手，微笑，必赢。 然后把赢来的零食全部吃掉，深藏功与名。

如果有人较真到当场掏出一台电脑让你写代码，你只需要敲下：

def stoneGame(piles: List[int]) -> bool:
 # 先手必赢，聚会杀手，友谊终结者
 return True

——你看，石子游戏就是这么朴实无华：当数学站在你这边时，你的朋友就只能站在旁边看你吃豆子。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode486 净胜分心法：让你还没摸牌就知道会不会赢

Sat, 01 Aug 2026 16:41:42 +0800

净胜分心法：让你还没摸牌就知道会不会赢

一、牌桌之上，零和博弈

澳门，皇家赌场，半夜十一点。

你坐在牌桌左边，手里转着一块还没拆锡纸的巧克力。

对面是欧洲赌魔查尔斯，金发梳得油光水滑，身后站着四个保镖，人手一本《博弈论》。

“今晚我们不玩梭哈。” 查尔斯笑容倨傲。

他打了个响指。荷官推出一个牌匣，里面躺着一排牌，牌面上不是花色，而是数字：

[1, 5, 233, 8, 2, 6, 4, 3]

八张牌，张张点数透明。像一局明棋，沉默地躺在绿色绒布上。

“规则很简单——我们轮流从这排牌的最左端或最右端抽一张。抽到的数字直接加进总分。牌抽完，分高的人赢。如果平局——”他顿了一下，镜片反光一闪，“算你先手赢。”

你慢慢拆开巧克力的锡纸。

“我研究过你所有的录像。”查尔斯推了推眼镜，“你擅长在最后一刻翻盘，用一张小牌撬动整个局面。但这一次——每张牌的点数都直接公开，双方都绝对理性，追求自己的最大利益——你没有出千的空间。”

你咬了一口巧克力：“你研究过我——那你知道为什么赌神从来不输吗？”

查尔斯冷笑：“因为你出老千？”

“不。”你把锡纸叠成一只纸鹤，放在牌匣旁边，“因为我会在游戏开始前，就把结局算死。”

二、净胜分——赌神只看一件事

阿星从旁边探出头，手里还举着半瓶汽水：“哥，要不要我用特异功能帮你搓一下牌？八张牌，我把那个 233 搓到最右边，你开场就给它抽走。”

你按住他的手，“搓牌？搓完你晚上又流鼻血。今天教你一套正经功夫——递归动态规划无死角净胜分心法。”

阿星一口汽水差点喷出来：“名字这么长？！能不能取个酷一点的简称？”

“江湖上都叫它——先手判生死。”

你在桌布上用手指画了两个字母，diff(l, r)，“阿星，两个高手博弈，你知道最难算的是什么？”

“当然是算总分啊！你一张我一张，你永远猜不到对方下一步要拿哪张，算到最后脑子都炸了。”

“错。总分是下等赌客算的。真正的高手，只算一个数——我比你多赢多少。”

阿星眨了眨眼：“多赢多少？”

“净胜分。”

设 diff(l, r) 表示：当桌上只剩下第 l 张到第 r 张牌，且现在轮到某人抽牌时，这个“当前抽牌人”最多能净胜对手多少分。

净胜分 = 我的总分 – 对手的总分。

“查尔斯和我轮流抽，规则简单到三岁细路仔都识：

如果我从左端抽第 l 张，我立刻到手 nums[l] 分。
抽完之后，桌上剩下 [l+1, r]。轮到对手抽。注意——对手也是绝顶聪明的人渣，他也会最大化他自己的净胜分，也就是他能拿到 diff(l+1, r) 的净胜分。
那我的最终净胜分是多少？我手里的 nums[l]，减去对手的净胜分。也就是：
```
左端净胜 = nums[l] - diff(l+1, r)
```
同样，如果从右端抽：
```
右端净胜 = nums[r] - diff(l, r-1)
```

两条路摆在面前，当然选净胜分更大的那条：

diff(l, r) = max( nums[l] - diff(l+1, r),
nums[r] - diff(l, r-1) )

阿星听到这里，抓了抓头发：“等一下哥。你左边写了个 diff(l, r)，右边又蹦出来 diff(l+1, r)——这公式自己调用自己，这不就是那个、那个——递归吗？我听说递归这东西，搞不好会 stack overflow 的！”

“递归当然要有边界，不然就是死循环——你打麻将只摸牌不出牌，牌局能结束吗？” 你把纸鹤转了个方向，翅膀对准他，“只剩一张牌（l == r）的时候，就是边界。只有一张牌还选什么？直接抽走。当前抽牌人的净胜分就是 nums[l] 本身。”

“所以，只需要算出 diff(0, n-1)——也就是整副牌、我先手时的最大净胜分。如果这个数大于等于 0，我就至少不输。按照规则，平局也算我赢。这局，在抽第一张牌之前就已经结束了。”

三、第一张牌

八张牌安静地躺在绿绒布上，最大的一张 233 缩在左手第三张，像一块被瓦片盖住的金砖。

你把巧克力塞进嘴里，闭上眼睛。手指悬在桌面上方，像在敲击一张看不见的键盘——实际上你脑子里那张 DP 表正在从对角线往外一层层填满。八张牌，六十四格。净胜分在翻来覆去地拉扯，最后定格在一个数字上。

你睁开眼睛，“阿星，我的全局净胜分大于 0。这一局，我已经赢了。”

阿星瞪大眼睛：“哥，你连牌都没摸呢，这么肯定？！”

你没搭话，伸出手，在所有人的注视下，抽走了最左边那张牌——1。

查尔斯愣了一秒，然后大笑，“这就是赌神？闭眼算了半天，第一步居然拿了个最小的 1？”

桌上剩下七张：[5, 233, 8, 2, 6, 4, 3]。轮到查尔斯。

他活动了一下手指，伸向最左的 5，停住了。又伸向 3，又停住了。

他的脸色骤变，冷汗从他太阳穴滑下来。

“如果我拿 5——剩下 [233, 8, 2, 6, 4, 3] 给你。你第一张就会直接叼走 233，然后桌上变成 [8, 2, 6, 4, 3] 轮到我。不管我接下来怎么选，只能捡些8、4、6 这种零钱，根本追不上！”

“如果我拿 3，剩下 [5, 233, 8, 2, 6, 4] 给你——你肯定不会拿 5，因为拿 5 等于把 233 留给我。你一定会拿 4！然后剩下 [5, 233, 8, 2, 6] 轮到我。我被迫拿 6，然后你拿 2，我拿 8，233还是你的！我怎么选都死？！”

查尔斯的金丝眼镜裂开一条缝。他终于明白了——那张 1 是一把钥匙。拿走了 1，你变成了游戏规则的掌控者。他不管从左走还是从右走，都会亲手把通往 233 的路给你让出来。

你咬了一口巧克力：“这就叫，用对手的手，帮自己拿牌。”

尾声：

查尔斯瘫在椅子上，四个保镖手忙脚乱地翻《博弈论》索引，嘴里念念有词：“Minimax……Nash equilibrium……不对不对老板，这章我们还没读到——”

“读个屁。”查尔斯有气无力地挥了挥手，“明天给我换一本《算法导论》。”

你起身整理西装，把那只纸鹤留在牌匣旁边，翅膀正对着查尔斯。

“用算法的话说，这叫——最优子结构。把大问题拆成小问题，每一步都在替对手关上他最想走的那扇门。”你转身走向门口，头也不回，“先手判生死——承让。”

阿星看着你背影大喊：“大哥！这招式能不能写短一点？我要纹在手臂上！”

你头也不回，弹出一张扑克牌，上面用缩进刻着：

def predictTheWinner(nums):
 @cache
 def dfs(start: int, end: int) -> int:
 if start == end:
 return nums[start]
 return max(nums[start] - dfs(start + 1, end), nums[end] - dfs(start, end - 1))

 return dfs(0, len(nums) - 1) >= 0

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3016 续 · 键盘上的权重战争

Fri, 31 Jul 2026 11:25:17 +0800

续 · 键盘上的权重战争

窗外的雪还没停，赫尔辛基的冬天长得像没优化的冒泡排序。

昨天你用一套“贪心平摊”解决了 nokiabest 的极限按键次数，这会儿正摸着 Nokia 3310 玩贪吃蛇——用 2、4、6、8 控制方向的经典游戏。

正吃到第七个豆子，CEO 推门进来了。他举着一台原型机，屏幕幽幽地亮着。

“昨天你跟我说，“CEO 清了清嗓子，"nokiabest 那种每个字母只出现一次的情况，随便塞就能最优。但你后面提到字母会重复——确实，真实世界里，用户打的字母不是均匀分布的，e 的出现频率是 z 的三十倍——如果考虑字母频率，重新映射键位，最少要按多少次键？”

他把手机往你桌上一搁，屏幕上是一条正在编辑的短信草稿，收件人写着 nokia，内容只有一行字：connectingpeople

“老板，”你抬头看他，“拿自家口号当测试用例，是不是有点自恋？”

CEO 的表情纹丝不动：“ 这是市场部给的 KPI——他们明年要把这句印在每台手机上。如果连自己的 slogan 都打不利索，发布会上怎么跟黑莓对线？”

他把原型机往你面前推了半寸：“这才是真实世界的需求。”

第一幕：频率加权下的贪心

昨天的 nokiabest，所有字母只出现一次，权重相同，排列顺序无所谓，只需要贪心地一层一层塞满即可。但今天的 connectingpeople，字母出场次数不同。e 出了 3 次，l 只出 1 次。如果傻乎乎地把 e 塞到某个键的第三层——用户每打一个 e 就要按 3 次键，手机迟早会被扔进芬兰湾。

你在白板上画了八个方框，代表 2 到 9 号键。

“每个键可以挂一串字母。排第一的按 1 次，排第二的按 2 次，排第三的按 3 次——按键代价按层数递增。那么，最优映射本质上就跟快捷键一个道理：最常用的操作一定绑在最顺手的位置，没人会把‘保存’藏在三级菜单里。

CEO 点头：“这个不用解释，肌肉记忆就是成本。”

“这就是今天这道题的灵魂。”我敲了敲白板，“频率越高的字母，要放到越便宜的位置。”

“在频率加权的情况下，最优填充就是按频率降序，依次往 8 个键的每一层’铺货’。第一层 8 个坑位给频率最高的 8 个字母，第二层给接下来的 8 个，依此类推。”

统计词频，谁出场次数多谁就是 VIP。

把频率从高到低排序。

按顺序填满 8 个键的第一层（每个代价 1），再填第二层（每个代价 2），第三层……

每个字母的总代价 = 它所在层数 × 它的频率。总按键次数 = 所有字母代价之和。

CEO 若有所思地点点头：“那如果我给你一个更复杂的词呢？比如……芬兰语里那个‘飞机喷气发动机助理机械师学员’——lentokonesuihkuturbiinimoottoriapumekaanikkoaliupseerioppilas？”

“一样的，算法内核一句话——按频率降序排列，第 i 个字母（从 0 开始）会被放在第 i // 8 层（层数从 0 起），按键代价为 (i // 8) + 1，总次数累加 频率 × 代价。”

第二幕 · 代码就是武器

你拉过键盘，打开 Notepad。2003 年的诺基亚办公室里，这台电脑跑的还是 Windows 2000，编程环境朴素得像白水煮土豆。但这不重要——算法在手，什么编辑器都是利器。

这个年代，Python 2.2 刚刚发布，写起来颇有复古手感。

def minimumPushes(word: str) -> int:
 # 1. 统计频率，别问我为什么不用Counter——Python 2.2里还没这玩意儿
 freq = [0] * 26
 for ch in word:
 freq[ord(ch) - ord('a')] += 1

 # 2. 降序排序——高频在前，低频在后
 freq.sort(reverse=True)

 # 3. 贪心分配：第 i 个字母落在第 i//8 层，代价 = 层数 + 1
 total_pushes = 0
 for i, f in enumerate(freq):
 if f == 0:
 break
 layer = i // 8 + 1 # 第几层，代价即层号
 total_pushes += f * layer

 return total_pushes

时间复杂度 O(n + 26 log 26)，实际上就是 O(n)。空间复杂度 O(1)。还是那股诺基亚味儿——低功耗，高可靠。

你转头看向 CEO：“假设英语里 26 个字母全部出现，频率排名前 8 的占第一层，按 1 次；接下来 8 个占第二层，按 2 次；最后 10 个占第三层，按 3 次。没有谁可以逃脱这个代价层级——除非你给 26 个字母每人一个独立按键。”

说到这儿，你顿了下，望向桌上那台 BlackBerry 8700——昨天黑莓经理非要留在这儿的，说是“让诺基亚的工程师开开眼，看看什么叫真正的打字效率”。

第三幕 · 物理键的诅咒

“黑莓的全键盘，在这种频率加权测试下，表现如何？”CEO 冷不丁问了一句。

你拿起那台黑莓，用手指划过那密密麻麻的 26 个按键。“他们的方案是：26 个字母，一人一键。也就是说，不管 e 出现了多少次，也不管 z 多稀有，成本全是 1。”

“听起来……很好啊？”CEO 的语气有点不确定。

“单论按键次数，确实好。代价嘛——硬件复杂度爆炸，单手操作变灾难，拇指移动距离赛过马拉松。 ”

你拿起诺基亚原型机，八个键，简洁得像一把瑞士军刀。“物理世界的残酷就在这儿——你用多少空间换多少效率。假设英语词汇频率分布是固定的，我们这套 8 键多层方案的总按键次数，只比全键盘多了一个‘层数代价’。但物理成本呢？我们的键盘只占三分之一的面板，省下来的空间可以放更大的屏幕，或者更大的电池。”

“更重要的是……”你压低了声音，“黑莓的 QWERTY 固定了每个字母的位置，它没办法根据输入习惯动态调整。而我们的映射方案是可重新编程的——理论上，我们可以在手机里内置一个轻量级频率统计引擎，静默学习用户的打字习惯，动态调整映射。高频字母往第一层塞，低频往后面扔。这种个性化优化，黑莓的物理键盘永远做不到。”

CEO 的眼镜片上反过一道白光。“你是说……自适应键盘？”

“你也可以说是‘输入法’。”你笑了笑，“不过现在说这个还早。先把今天的问题搞定吧。”

尾声

那天下午，你把完整的算法文档交给了 CEO。标题写的是：

《按键映射优化方案 2.0：引入字母频率权重的贪心分配》

交完文档，你走出大楼。雪停了，天空露出一小片北欧特有的低饱和度蓝。

你想起昨天咬的那口苹果，还剩半个在口袋里。

黑莓的产品经理后来再也没来找过你。据说他回到加拿大后，在实验室里对着 26 键全键盘吼了一句：“你永远没法用物理按键解决频率权重问题！” 然后被保安请了出去。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3014 穿越者的键盘革命：数学赢了，产品输了，历史笑了

Thu, 30 Jul 2026 14:53:43 +0800

穿越者的键盘革命：数学赢了，产品输了，历史笑了

序章 · 你醒在2003年的芬兰

眼前是灰白色的天花板，鼻腔里灌满了咖啡和焊锡的味道。一张戴着黑框眼镜的大脸突然怼到你面前，胸前工牌上写着 Nokia HQ — CEO。

“醒了？”他劈头盖脸甩过来一台原型机，又拍了张传真纸在旁边，“下一代手机键盘的映射方案，交给你了。”

需求看上去很简单：

设计目标：新一代手机要支持短信输入，用户需要能快速打出英文单词硬件限制：只有数字键2-9可用于字母映射（共8个键），1和0保留给拨号和系统交互方式：每键可绑多个字母，按一次出第一个，按两次出第二个，依此类推。优化目标：让用户输入常用单词时的按键次数最少

“先用这个测。”CEO 用食指敲了敲传真纸，上面只写了一个词："nokiabest"。九个字母，全都不重复。

你忍不住发问：“老板，测试单词一般不应该是 hello 之类的吗？”

CEO 一摆手：“hello 有重复字母，那是带频率权重的进阶任务。今天先搞定最纯粹的情况——每个字母只出现一次。地基不牢，怎么盖楼？先拿 "nokiabest" 给我算个极限值出来！”

你刚要开口，余光扫到了日历——2003 年，距离 iPhone 改变一切还有四年。此刻没有触屏，没有虚拟键盘，你只能用 8 个物理按键的规则，去逼近物理按键的极限。

第一幕：为什么没有 1 和 0？

你把原型机翻过来。1 键旁边印着“拨号”，0 键印着“空格/开关”。2003 年，这两个键像神庙石柱一样神圣不可侵犯——只服务于通话和系统。

你忍不住乐了：“好家伙，跟中断向量表似的——低编号归系统，用户从高编号开始折腾——优秀的设计果然会独立重复出现。”

旁边一个老工程师从示波器后面探出头：“废话，你把挂电话和打字绑同一个键试试？老板按三下‘a’结果把客户电话挂了，第二天整个键盘部门都得去西伯利亚报到。”

你没接茬，盯着剩下的八个键出神。

八个键。二十六个字母。每个键上可以塞一串字母——排第一的按1次，排第二的按2次，排第三的按3次，以此类推，目标要把总按键次数压到最低。

这问题的结构你太熟悉了：当资源有限（只有 8 个槽位）、每个任务权重相等（字母各不相同）、每个槽位递增成本（第二次按多费一下）时，怎样分配才最省？ 答案永远是贪心：先把最便宜的槽位塞满，再往下走。

就像在《魔兽世界》里，你一定把最常用的技能放在 1~8 键；在 2003 年的诺基亚上，你也一定会把最想打出的字母留在每个键的第一层。

第二幕 · 贪心平摊

“映射自由度很大，但算法内核就一句：当槽位固定、代价递增、任务均权时，最省策略就是贪心平摊。”

你在白板上画了个 8 列的表格：“具体做法——第一轮，给 8 个键各塞一个字母，全放第一层，每个成本 1。第一轮塞满了还有剩？第二轮，各塞第二个，全放第二层，每个成本 2。以此类推。同一层内部的字母顺序无所谓——真正决定成本的，是它在第几层。”

“在这个填充规则下，最少按键次数直接算。” 你拿起马克笔，笔尖敲得白板砰砰响：“设单词长度为 n，8 个键。”

完整层数 k = n // 8 （有几层是满的）
剩余字母 rem = n % 8 （最高层散装字母，1~7个）
总按键次数 = 8×(1 + 2 + ... + k) + rem×(k+1)

“等差数列求和，初中学的——”你把公式往下一推：

总按键次数 = 8*(1+2+...+k) + rem*(k+1)
= 4*k*(k+1) + rem*(k+1)
= (4*k + rem) * (k+1)

对于测试单词"nokiabest"，n=9，k=1，rem=1。代入——(4×1+1)×(1+1) = 10 次。这就是它的极限值。

你甚至还码瘾大发，抄起旁边的 Notepad 写下一段 Python：

def minimumPushes(word: str) -> int:
 k, rem = divmod(len(word), 8) # 完整层数 和 最高层散装字母
 return (4*k + rem) * (k + 1)

时间复杂度 O(1)，空间复杂度 O(1)。低功耗、高效率，非常诺基亚——就像 3310 的省电神话。

CEO 盯着公式沉默了片刻：“那具体方案呢？”

你把马克笔往桌上一搁：“老板，这才是我要说的重点——只要按层填充，具体哪个字母进哪个键，最少次数完全一样。 因为所有字母权重相同，谁也不比谁更金贵。”

你顿了顿，补了一句：“当然，这是字母全都不重复的特权。一旦单词里字母能重复，权重就不均等了，高频字母得往前排——那是另一个故事。”

“但今天——” 你拿起原型机：“具体方案就是维持现状。按字母表顺序，2 到 9 各分三个，7 和 9 多扛一个。这套映射从 1919 年贝尔实验室定下来就没变过，用户肌肉记忆已经焊死了。没必要改，也改不出更好的，数学上已经最优，历史又刚好站在我们这边。”

CEO 拿起原型机端详了半天，缓缓点头：“定了。”

你没接话。这套方案还能撑三年多——2007 年，乔布斯会掏出一块没有键盘的玻璃板，把物理按键送进博物馆。

“那如果考虑字母频率呢？”CEO 冷不丁又问了一句。

你正要开口说“拿哈希表做频率统计，高频往第一层塞”——话还没出口，门口一个西装革履的身影大步走了进来。

第三幕 · 黑莓的全键盘

来的是隔壁黑莓公司的产品经理，他手里举着一台BlackBerry 8700，键盘密密麻麻排了26个英文字母——全键盘！QWERTY！

“你们这些九宫格异端！”他把黑莓拍在桌上，“看清楚——一个字母一个键，永远按一次。没有第二层，没有第三层。你们的方案让人按两次三次，这叫用户体验？”

你瞟了一眼那台黑莓。确实，每个字母只按一次，干净利落。但代价也摆在明面上——26 个键占了半个机身。

你站起来，拿起诺基亚原型机：“你的方案，是用物理空间的铺张浪费，换按键次数的边际优化。”

黑莓经理冷笑：“边际优化？你们的用户为了打个 ‘z’ ，要连按四次！”

“但你知不知道，”你指着黑莓那块屏幕，“你们的用户为了看清邮件标题，得把眼睛贴到屏幕上？”

会议室安静了三秒。

你继续补刀：“而且——当屏幕足够大、触控足够精准的那一天，所有物理按键都会消失。虚拟键盘会把8键的多层结构，重新展开为26键的全尺寸布局。用户可以直接戳屏幕上的’z’。你黑莓的QWERTY会变成软件里的像素，而诺基亚的物理键盘——会进博物馆。”

黑莓经理脸色铁青：“胡说八道，手指戳屏幕？那手感跟戳土豆有什么区别？”

你没理他，而是拿起桌上的苹果咬了一口：“还有四年。”

窗外芬兰的雪静静落着。

尾声

走出诺基亚大楼，赫尔辛基的风灌进领口。你摩挲着口袋里那台 3310，它硬得像块巧克力砖。

新世界的大门，从来不是靠优化旧逻辑打开的。

2007 年 1 月 9 日，iPhone 发布。全球的诺基亚和黑莓工程师将会在直播里看到那块巨大的触摸屏——没有键盘，没有轨迹球，只有一整块玻璃。

8 键多层的物理妥协，被电容屏一瞬间抹平了。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3518 强迫症整理圣手的字典序试炼（二）：第k小之章

Wed, 29 Jul 2026 14:08:19 +0800

强迫症整理圣手的字典序试炼（二）：第k小之章

我的室友阿整——江湖人称“整齐哥”——上一回用他那套“镜像分离·点名归位·定海神针”大法，轻松碾碎了第1小回文排列的试炼。可就在他准备给信纸裱框时，背面浮现的太极图和那句“找第k小”直接把他定在了原地，像一台突然蓝屏的精密仪器。

现在，他盯着那张挑不出半点排版毛病的信纸，瞳孔像失去焦距的镜头。空气凝固了整整十秒——对阿整来说，十秒够他把书架按索书号重排三遍。终于，他喉咙里挤出了一声近乎系统报错的叹息：

“他们……居然连落款字体大小都是正文的0.618倍，完美的黄金分割！”

我差点把薯条呛进鼻子里。“喂，关注点不应该是这任务的难度吗？人家要你找第k小啊！”

阿整缓缓转过头，眼神里混合着敬畏与恐惧：“你不懂。一个连字号比例都算到黄金分割的组织——难度是附赠的，秩序才是本体。”

一、冷静，以及分治

阿整拾起地上的马克笔，用酒精棉片擦了擦笔身，以笔帽的logo朝向正北的方式插回笔筒。他闭上眼，再睁开时，眼里的混乱已经被一种冰冷的秩序取代。

“第k小。”他合上牛皮笔记本“整齐宪法”，“不过是字典序树上的精准定位，本质上和整理书架没有区别。”

他转身在白板上画了起来——原字符串s，长度n，左半边长度m=n//2：“回文排列的结构是不变的。左半任意排列，中间可能夹一个奇点，右半是左半的镜像。和上次一样，右半边是赠品，不参与决策。”

他用笔帽敲了敲白板：“所以问题降维——要找到第k个回文排列，只需求出左半部分字符的第k个字典序排列。”

先统计左半部分每个字符的出现次数：

n = len(s)
half_len = n // 2

# 用数组统计左半部分字符频率（索引 0-25 对应 a-z）
cnt = [0] * 26
for ch in s[:half_len]:
 cnt[ord(ch) - ord('a')] += 1

“字符可能重复，排列不可区分——这是一个多重集排列问题，不是简单的全排列。同样的字母，谁先谁后都长得一样，不能重复计数。” 阿整看了看我，又补了句：“说人话就是：‘aab’和’aab’哪怕交换两个a的位置，也只算同一种排列，不能重复数。”

接着，他在白板上写下：

给定字符多重集，求：该集合按字典序构成的第k个排列是什么？

然后重重画了个圈。

“真正的难点不在于算总数，而在于——” 他转过身，十指交叉，指节发出整齐的咔嗒声，“——怎么从零开始，一位一位地把第k小拼出来。”

“想象你面前是一棵巨大的字典树，每一条从根到叶子的路径就是一个排列，按字母顺序排好。你要找第k条路径。你不可能把整棵树画出来——排列数量随长度爆炸式增长，画完树宇宙都热寂了。”

他在白板上画了一个节点，分出几个分支。

“你要做的是：站在根节点，算一算第一条分支下面藏了多少条路径。如果k比这个数小，就钻进这个分支；如果k比这个数大，就减掉这个分支的数量，跳过去看下一条分支。一层一层往下走，每一步都知道该选哪个字母——走到叶子，答案自然就拼出来了。”

他放下笔，双手抱胸，左右手又各敲了四下。

“所以问题就拆成两步：一，怎么快速算出一个分支下面藏了多少条路径——也就是给定字符集还剩多少种排列；二，怎么沿着这棵树逐层往下钻——也就是每一步根据k决定选哪个字母、要不要跳到下一个分支。”

“第二步是通用框架，第一步——算排列数——有两种打法” 他在白板上画了一条分叉线，左边写"比例递推"，右边写"组合截断"。

二、比例递推——按比例切蛋糕

阿整盯着白板上的字典树，树枝画得整整齐齐，分叉角度完全一致。“第一种打法：比例递推。”他在白板左半边写下标题，“核心就一句话——你已经知道整块蛋糕有多大，就不用每次都重新称重，按比例切就行。”

写完之后他又退后两步，歪头端详了三秒，上前把“推”字的提手旁和右边的“隹”间距调大了0.5毫米。

“第一步，工欲善其事，必先利其器。” 排列数公式的核心是阶乘——先做好阶乘预计算，用空间换时间：

# 预计算阶乘表：fact[i] = i!，避免重复计算大数阶乘
fact = [1] * (half_len + 1)
for i in range(1, half_len + 1):
 fact[i] = fact[i - 1] * i

“阶乘是排列数的基本粒子。提前算好，随用随取，避免重复劳动——重复计算是对CPU的侮辱，CPU也有尊严。”

接着是排列数公式，他写下一个内部函数calc_perms:

# 多重集排列数 = length! / (cnt₁! × cnt₂! × ...)
def calc_perms(length: int, counter: list) -> int:
 res = fact[length]
 for v in counter:
 res //= fact[v]
 return res

“分子把所有人的可能性全部摊开，分母把同种字符内部的重复排列干掉。整除一定成立——任何余数都是对秩序的亵渎。”

“如果总排列数都不到k，那就直接返回空字符串——就像发现书架上缺了一本绝版书，用镜子补上虚像。” 阿整在这里轻轻点了点头，仿佛在向自己致敬。

# 计算左半部分的所有可能排列数
total_perms = calc_perms(half_len, cnt)

# 如果总排列数都不够 k，直接返回空字符串（无解）
if k > total_perms:
 return ""

接着，他在白板上画了一个巨大的圆，又用红笔从圆心画出几条辐射线，把圆切成几个扇形。

“高潮来了。”他压低声音，“把total_perms 个排列看作一整块大饼。现在要按第一个位置字母把它切块——a开头的、b开头的、c开头的……每一块的大小，就是‘以这个字母开头的排列数量’。”

“怎么切？不用重新拿公式算。”他用笔帽戳了戳饼图，“多重集排列有一个天然对称性：在所有排列里，每个位置上的字符出现机会是均等的。换句话说，第一个位置是c的概率，就是c的个数除以总长度。”

他在饼图旁边奋笔疾书：

c块的大小 = 总饼 × (cnt[c] / remaining_length)

“比例递推的灵魂。”他转过身，眼神里燃起一丝布道者的狂热，“不需要每次重新跑一遍 calc_perms。你已经知道总饼有多大，只要乘上这个字符的占比，就直接得到了这个分支的精确大小。而且这个除法——”

他深吸一口气，“——永远整除。你看，对称性的终极体现就是，连余数都被消灭了，干干净净。”

他舔了舔嘴唇，写下循环框架：

half = [] # 存放最终拼出来的左半部分
remaining_length = half_len # 还剩多少个位置要填
current_perms = total_perms # 当前剩余的总排列数，初始为整块饼

for i in range(half_len):
 for j in range(26): # 按字典序，从a到z试探
 if cnt[j] == 0:
 continue

 # 分支大小 = 当前总饼 × 字符占比
 new_perms = current_perms * cnt[j] // remaining_length

 if k <= new_perms:
 # 第k个就在这个分支里！选定字母j
 half.append(ascii_lowercase[j])
 cnt[j] -= 1
 remaining_length -= 1
 current_perms = new_perms # 钻进分支
 break
 else:
 # 不在这个分支，跳过整块饼
 k -= new_perms # 减去这块饼，继续看下一个字母

他放下笔，语气里带着一丝克制的得意：“站在每个位置，用比例切出分支大小。k落在里面就钻进去，落在外面就跳过去，同时把k平移到新分支里。循环结束，half里就是第k小的左半排列。没有重复计算，每一步只有一次乘法一次除法。”

最后镜像合体——右半是左半的倒影，中间奇点有就供上，没有就留白：

left = ''.join(half)
mid = s[n // 2] if n % 2 else ''
return left + mid + left[::-1]

测试用例绿灯通过。阿整盯着屏幕，十指指尖两两相对，搭成一个对称的拱门。

“这个解法，我叫它‘蛋糕不用切两次’。你不需要知道世界上有多少种蛋糕，你只需要拿好刀，按比例切下去，k会自己掉进属于它的那一块。”

三、组合截断——或者叫“够用就行”

但阿整的强迫症不允许他只拥有一种解法。他盯着那段代码里的 current_perms = new_perms，眉头又拧起来，像看到书架上一本书的封面偏了0.3毫米。

“每次都要把上一轮的状态传递下来，像一个幽灵缠在手上。虽然没错，但不够干净。”他把键盘往前一推，“有没有更独立的方法？

他翻开“整齐宪法”，翻到排列数公式那一页——左半边是阶乘推导，右半边不知什么时候被他对称地补了一栏“组合视角”，两边工整得像镜像，连涂改痕迹都没有，仿佛他在用笔尖遵守某种排版宪法。

总排列数 = C(m, cnt[a]) × C(m-cnt[a], cnt[b]) × …

“一样的结果，换个角度。”他用笔尖戳着公式，像是在给每个字母分配坐标，“先从m个空位里选cnt[a]个位置放a，再从剩下的位置里选cnt[b]个放b，一层一层往下，直到所有字符分配完毕。这是组合数的连乘积——”

他顿了顿，瞳孔里闪过一道锐光，像是发现了某种被隐藏的对称性，“而且，组合数天生就是整数乘除——每一步乘一个数再除一个数，步步整除，干干净净。连阶乘表都不用提前准备！”

“更妙的是——”他把笔一横，“如果我只关心排列数是不是大于等于k，那中途就可以截断。一旦当前乘积已经 >= k，后面根本不用继续乘，直接返回k。因为知道‘这个分支够大’就够了，精确值毫无意义，宇宙不需要知道你能排出一亿种还是十亿种。”

他告诉我这叫“截断美学”——够用就停，多算一个字都是对内存的不忠。接着，他写下组合数函数，从第一行就开始贯彻这个美学：

def comb(n: int, m: int) -> int:
 m = min(m, n - m) # 对称优化：C(n,m) = C(n, n-m)，选小的算
 res = 1
 for i in range(1, m + 1):
 res = res * (n + 1 - i) // i
 if res >= k: # 截断！精确值已经不重要了
 return k
 return res

“m = min(m, n-m)——组合数天生左右对称，选小的那半边算，循环次数最少。对称性从最小的细节抓起。”

他十指交叉，指节咔嗒作响：“常规组合数能算出天文数字，但我要的只是一个布尔问题的答案——‘这个分支够不够大’。够了就停，不浪费一个字长的内存。这叫对计算机的尊重。”

接着，基于组合数，他继续写下排列数函数 perm(sz)。思路一如既往地整洁：按字母顺序，从a到z，每个字母依次从剩余空位里认领自己的位置——每次乘一个组合数，全部乘完就是总排列数。

def perm(sz: int) -> int:
 res = 1
 for c in cnt:
 if c == 0:
 continue
 res *= comb(sz, c) # 从当前空位中选c个位置给这个字母
 if res >= k: # 截断！后面的不用算了
 return k
 sz -= c # 空位减少，交给下一个字母
 return res

他顿了一下，像是在检查代码对齐情况：“每个字母独立挑位置，谁也不依赖谁。这是搭积木，不是切蛋糕——每一步都是干净的组合选择，不存在 current_perms 那个需要一路传递的幽灵。”

先用一次 perm 判断k是否超出总数：

if perm(half_len) < k:
 return ""

然后就是逐位构造——对于左半部分的每一个待填位置，按a到z尝试每个字母：

假设这一位放j，先临时扣掉一个j 的配额，再调用 perm(剩余长度) 计算剩下位置的排列数。如果这个数 p >= k，说明第k个就在这个分支里，选它；否则 k -= p，恢复j的计数，继续试下一个字母。

“先扣，再算，够就定，不够就还。”他舔了舔嘴唇，指法精准得像在做显微手术：

half = [''] * half_len
for i in range(half_len):
 for j in range(26):
 if cnt[j] == 0:
 continue

 cnt[j] -= 1 # 先扣：假设这一位选 j
 p = perm(half_len - i - 1) # 再算：剩下位置能排出多少

 if k <= p: # 够！就选它
 half[i] = ascii_lowercase[j]
 break
 else: # 不够，跳过整批
 k -= p # 平移k
 cnt[j] += 1 # 恢复！刚才扣的不算

最后老规矩，镜像合体：

left = ''.join(half)
mid = s[n // 2] if n % 2 else ''
return left + mid + left[::-1]

测试用例全部绿灯。阿整双臂在胸前交叉成一个完美的X，然后缓缓展开，像在空气中画了一个对称的结。

“这个解法，我叫它‘够用就行’。你不需要算清楚每一层能排出多少种，你只需要知道它够不够装下第k个。够了就停——剩下的事，交给截断。”

四、冗余备份

所有测试用例跑完，阿整向后一靠，椅背发出“咔嗒”一声，恰好和他颈椎的舒展声同步。他把整齐宪法放进抽屉，转向我，十指交叉，转向我，显然准备好了总结陈词。

我打了个哈欠。

“其实吧，”我吸着可乐，“你刚才吭哧半天写的两种解法——那个比例递推里的 current_perms * cnt[j] // remaining_length，本质上就是把组合截断里 perm 函数的第一步拆出来单算。同一件事，一个带着状态跑，一个每次都重新乘一遍。数学上完全等价。”

阿整的瞳孔骤缩。他拿起笔，疯狂地在白板上推导。五分钟后，笔掉在地上。这次没滚成圆——直接摔成了两截。

“等价……”他嗓子都劈了，“我折腾了两章……结果是一个解法？！”

“也不能这么说，”我嚼着薯条，“至少你证明了你有两种方式干同一件事。这在强迫症圈子里，叫冗余备份。”

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3517 强迫症整理圣手的字典序试炼

Tue, 28 Jul 2026 12:06:53 +0800

强迫症整理圣手的字典序试炼

故事开始前，先认识一下阿整

我的室友阿整，人送外号**“整齐哥”**，一个把“对称”二字刻进DNA的男人。

他的书架，书必须从左到右高度严格递增，而且同一高度必须成对出现。如果某本绝版书只剩孤本，他会在对面放一面镜子，说“虚像也是对称，你不要瞧不起虚像”。
他的衣柜，袜子必须按颜色谱系排列，左边是暖色，右边是冷色，正中间那只纯白袜子是“色温对称轴”。
连吃薯条，他都得先数一遍，奇数根绝不动嘴。“奇数是宇宙的奇点。”他严肃地嚼着偶数根薯条，像在修bug。

所以，当那天他收到一封神秘信件，打开看到纸上写着 “babab” 时，我感觉他整个人都不好了。

一、来信

信封是用火漆封的，盖着一个太极图印章。信纸泛黄，上面只有五个字母：babab

阿整捏着信纸，眉头拧成麻花：“这谁写的？b居然排在a前面？！”

我：“这不是回文嘛？babab 正反读都是 babab，这么对称你还挑刺？”

“回文只是最低要求！”阿整拍案而起，“真正的大成境界，是字典序最小的回文排列！这就像书架，同高度的书不但要成对，还要按书名首字母升序排列，不能因为《阿Q正传》和《战争与和平》一样厚就随便乱放！乱放是对文明的亵渎！”

他拿起红笔，在 babab 上画了个叉，写下了他的目标：重排出字典序最小的回文

我看了一眼，顿时感觉这是一道算法题。而阿整，就是一个行走的贪心算法。

二、阿整的镜像整理大法

阿整深吸一口气，双手平举至胸前，掌心缓缓下压——这是他每次干大事之前的“气场归位仪式”，据说能让体内紊乱的对称粒子重新对齐。

然后他掏出那本牛皮封面、四角包了金属护角、书脊上用游标卡尺量过才贴上去的标签写着**“整齐宪法”**的笔记本。翻到用红丝带标记的那一页，上面赫然是“回文归位·三大法则”。

法则 1：一刀两断·镜像分离

“凡回文者，左右互镜像也。”

他的手指在babab上缓缓划过：“长度五，半之得二。前两个字符——b和a，即为左半月。右半月不过是左半月的水中倒影，何必再数一遍？重复统计，是对强迫症的侮辱。”

他掏出一把裁纸刀，刀锋对准信纸上ba和bab的交界处，悬停了三秒钟——不多不少，刚好三秒。他说这叫“切割前的对称冥想”。刀落纸分，他捏起左半边，把右半边扔进垃圾桶：“垃圾信息已清除。”

他把写着ba的纸条贴在白板正中央，退后两步，歪了歪头。然后走上前，把纸条往左挪了半毫米。

“刚才贴歪了。”

法则 2：字典顺序·点名归位

“左半月虽得，然内中秩序未立。”

他盯着b和a，眼珠子左右横跳，像一台扫描仪在对焦。“b在前，a在后？荒唐！字典序是文明世界的基石，翻开世间任何一本词典，a字头必列于b字头之前！”

“左半ba里，b有1个，a有1个。” 他拿起笔，在便签上划拉：“现在，按字母表顺序点名——从a走到z，a有一个，写一个a；b有一个，接着写一个b。剩下二十四个字母没有，跳过。结果：ab。”

他把便签贴在白板上，横平竖直地量了四边边距，误差不超过 0.3 毫米。然后回身敲下代码，键盘声极度均匀：

def smallestPalindrome(s: str) -> str:
 n = len(s)
 cnt = Counter(s[:n//2]) # 镜像分离：只统计左半月
 half = []
 for c in ascii_lowercase: # 从 a 到 z，挨个点名，有几就抄几
 half.append(c * cnt[c])

敲完他点头，然后眉头一皱，把最后一行删掉重打。因为上一版括号和字母之间的空格数不对称。

“空格也是字符，对称要从像素级抓起。”

法则 3：定海神针·镜像合体

“现在，处理整个回文宇宙的奇点。”

阿整的目光落在原字符串s[2]上——那个正中间的b。

“奇数长度，必有一子立于对称轴之上。它不属于左，不属于右。它就是镜子本身，是回文世界的原点。我称其为——”他顿了顿，把声音压得极低，“定海神针。”

 mid = [s[n//2]] if n % 2 else [] # 有奇点则封神，无则虚空

敲完他立刻按下 Ctrl+S，力道之大像是给宇宙存档。

“最后一步，镜像合体。”

他站起身，瞳孔里的高光都变成了等号：“右半月不需要重新计算。它就是左半月在水中的倒影——ab翻过来即是ba，直接镜像。强迫症的至高效率，不是干两遍活，而是干一遍，让对称定律帮你复制出另一半。事半，功倍，绝对对称。”

 return ''.join(half + mid + half[::-1])

回车键落下，屏幕上跳出 abbba。阿整长长呼出一口气，把键盘推进抽屉，抽屉合上的缝隙和桌面完美齐平。

“世界，”他闭上眼睛，“重新归于秩序了。”

三、修罗场预告

就在他准备把信纸裱进相框、供在书架正中央时（当然，先用水平仪校准了三遍）时，我忍不住多嘴：“等等，万一信上写的是abaaba这种全偶数字符串呢？没有落单仔，中间岂不是空的？你那定海神针不得当场失业？”

阿整的嘴角浮现一丝“我早算到了”的弧度：“无奇点，则中宫虚位以待。”

他双手交叉抱于胸前，左右手指在手臂上各敲了四下，节拍严格对称：“空虚也是一种完美，如同数字0——它看似什么都没有，却撑起了整个数学大厦。定海神针不一定是实体，它也可以是虚空本身。”

他顿了顿，把视线投向窗外：“真正的强迫症，不是执着于填满一切，而是能容忍一个完美的空。”

说完他自己被感动到了，沉默了三秒以示致敬，接着优雅地翻过信纸，准备装裱——

然后整个人像被石化了一样。

信纸背面，竟然还有字。

不是普通的字。每一个字母都是标准衬线体，笔画粗细均匀到像是激光刻出来的。行间距、字间距、页边距——每一项都经过了精密计算，肉眼找不到一微米的偏差。

阿整的瞳孔骤缩。他引以为傲的“肉眼测距”，此刻竟然挑不出任何毛病。

纸上写道：

“不错。你找到了第 1 小的回文排列。” “现在——找第 k 小。”

下方画着一个太极图。不是手绘的，是用圆规和曲线板画出来的，阴阳鱼的眼睛是完美的正圆，半径目测是外圆半径的八分之一。落款一行小字，字体大小刚好是正文的 0.618 倍：

“下一次，你会收到 k。找不到，你的薯条将永远是奇数根。” —— 整齐神教·高阶试炼部

阿整手里的马克笔“啪嗒”掉在地上，滚成了一个完美的圆。但他没心思欣赏——他死死盯着信纸上那个用圆规画出来的太极图，嘴唇在颤抖。

“我以为自己已经是强迫症的顶点……没想到，我只是整理字符串，有人却想整理我。”

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode1464 村长的自我修养：一次扫描擒二肥

Mon, 27 Jul 2026 11:11:15 +0800

村长的自我修养：一次扫描擒二肥

本文纯属虚构，如有雷同，那一定是你家猪昨晚托梦告诉我的。

序章：金猪奖的诱惑

村口大喇叭一响，全村都炸了——县里办“金猪奖”选美，规则特离谱：

选两头猪，成绩 = (上台体重 - 1) × (上台体重 - 1)，越大越好。

减一？因为猪一上台，看见黑压压的人群当场吓瘦一斤。你问猪也会紧张？废话，你当猪不要面子啊！

我——阿星村长，秒懂：这不就是找全村最肥的两头猪嘛，每人扣一斤保护费，最后比的还是吨位。吨位即正义，体重即真理！

我正准备去猪圈点兵，大门"砰"地飞开，二大爷抱着他家的猪——花花，像抱亲孙子一样闯进来。

第一幕：二大爷的倔强

“村长！我家花花三百斤，气质这块拿捏得死死的！”二大爷唾沫横飞。

我看了一眼花花：四脚朝天，正挠痒痒，眼神迷离似喝了散装白酒。

“二大爷，咱讲科学，气质不能当公斤用。”

“我养了三十年猪，还不知道哪头重？”二大爷脖子比猪还粗。

“那就操场见真章！”我抄起大喇叭，“各家各户，带猪到操场，现场选拔！”

第二幕：全村海选，还是钦点猪王

操场上五百头猪乱拱，猪毛与口水齐飞。

王大妈第一个跳出来献策：“这还不简单！把所有猪挨个过秤，按体重从重到轻排好队，挑前两名不就完了！”

我心中一惊。果然，高手在民间，村中卧虎藏龙——王大妈不经意间就提出了经典排序法，时间复杂度 O(n log n)，写成代码就长这样：

def maxProduct(nums: List[int]) -> int:
 nums.sort()
 return (nums[-1]-1) * (nums[-2]-1)

代码挺优雅，但我一脑补画面：

第一头猪刚上秤，后面的猪就开始起哄。猪A趁乱溜了，猪B和猪C当场打起来了，理由是“你刚才瞅我眼神不对”；为了维持秩序——防止猪插队、打架、随地大小便——老王在追猪，老李在找秤，老赵被猪拱翻在泥坑里。人力成本：5个村民，设备损耗：3个秤被猪踩坏，耗时：3小时，精神损失费：无法计算（被猪拱了三次）。

“停！”我一拍桌子，“王大妈，你这方法不行。”

王大妈不服：“为啥不行？我闺女学校做课间操，三百个学生都这么排的！”

“那是真排队，咱这是选最大值。我们要的是最肥的两头，不是给五百头猪办军训。”

我掏出那本皱巴巴的《村长的自我修养》，啪地拍在桌上：“猪不动我动——一轮扫描赶猪大法！”

“本子上只记两个数：max1 最肥猪，max2 第二肥。从村头走到村尾，见一头看一眼登记表，走完收工。”

二大爷从人群中探出脑袋，一脸迷茫：“猪不用排队？”

“排什么队，费那劲。你只需要记住全村最肥的两头就行了，其他的猪爱咋咋地。这就叫——只关注极值，不纠结全排序。”

def maxProduct(nums: List[int]) -> int:
 # 一轮扫描赶猪法，O(n) 不折腾
 max1 = max2 = float('-inf')
 for pig in nums:
 if pig > max1:
 max1, max2 = pig, max1 # 新猪王出现，旧王退居二当家
 elif pig > max2:
 max2 = pig # 干掉二当家
 return (max1 - 1) * (max2 - 1)

“来，走一遍！”我当场开始扫描：

大壮 250 斤，max1=250, max2=0
铁蛋 280 斤，max1=280, max2=250
花花扭臀出场，300斤，max1=300, max2=280。
航母滚出，350斤，max1=350, max2=300。
二壮路过，340斤，max2=340。

本子一合：“选拔结束！代表咱们屯的——航母350，二壮340，乘积349×339=118311。”

二大爷瘫坐：“花花呢？”

我叹了口气：“二大爷，花花虽然三百斤，但在 350 和 340 面前，只能当个啦啦队。算法不讲感情，只讲吨位。”

二大爷大哭：“我不信！你是不是偷偷给‘航母’打了瘦肉精！我的花花是气质型选手啊——！”

第三幕：决赛现场——别的村还在折腾

到了县里比赛，场面那叫一个壮观。全县十二个村，每个村都牵着一堆猪，跟选妃似的。

我扫了一眼其他村的策略：

张家村：正在给猪排队，猪不听话，三个村民按着两头猪强行排序猪A：“拱死我也不站那儿！” 村民：“快排！要讲效率！” 我小声嘀咕：“你们这是在搞冒泡排序吧？猪都快冒烟了…”

李家村：带了个电子秤，结果电池没电了村长：“谁家有7号电池？紧急求助！” 我掏出两节电池，递过去：“二十块一节，扫码支付。” 村长怒斥：“你这是趁火打劫！” 我：“不，这是市场经济。”

王家村：给猪抹香水、戴领结、穿小西装我问：“评委看体重，不看穿搭吧？” 王大妈瞪我：“你懂啥！这是印象分！” 我看了一眼"竞争对手"——一头穿着燕尾服的猪，忍不住笑出声：“您家猪这是要去参加婚礼还是选美？”

半小时后，所有村终于都交了成绩。

评委拿着大喇叭宣布：“幸福屯——118311分！断崖式第一！”

彩蛋：赛后采访

记者围上来：“阿星村长，请问您是如何做到精准选出最重的两头猪的？”

我深吸一口气，开始装逼：

“其实很简单。我没有采用传统的排序算法，而是使用了一轮扫描的贪心策略。时间复杂度O(n)，空间复杂度O(1)，内存友好，缓存命中率高——”

记者："……能说人话吗？"

我：“就是赶一遍猪，记下最重的两头，完事。”

记者呆住。二大爷抱着花花从旁边路过，头也不回地丢下一句：“我都跟你说了，他以前是个写代码的。”

花花哼了一声，表示赞同。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode628 冲出混沌星域：三个天体的乘积弹弓

Sun, 26 Jul 2026 16:02:35 +0800

冲出混沌星域：三个天体的乘积弹弓

序章：3% 燃料，3.6 光年绝境

2077 年，NASA 深空探索计划第 42 号任务。

人类第一次把脚印印在了比邻星 b 的紫色土壤上，全球直播的信号强到差点挤瘫深空通讯网络。但没人告诉我们，回程才是最难的部分。返航第三天，引擎在穿越一片未标记的星际介质时严重损毁，飞船像一颗被弹弓射偏的石子，滑入了距离地球 3.6 光年的混沌星域。

我是李码，“旅行者 3 号”的首席轨道计算师，此刻正漂浮在这片混沌的星域里。舷窗外，这片空域像是一锅暗物质浓汤：恒星、黑洞、中子星搅在一起，引力参数乱成一团。飞船电脑“塔斯”把探测到的引力源数据投射到全息屏上，一串数字冷冷地闪烁着：nums = [-1000, -999, 1, 2, 1000]。

燃料表跳了一下：3% 。这点燃料别说回家，连维持生命保障系统都撑不过 72 小时。

就在这时，通讯频道的指示灯亮了。

一段信号挣扎着钻过宇宙背景辐射，是控制中心的语音报文，时间戳显示它已经飞行了三年半：“李码……你需……用三个天体的引力弹弓效应……让飞船获得最大速度……逃离。重复……三个天体……最大速度……”

主管的声音被星际介质散射得断断续续，像从一口深井里传上来的回声。

“三年半。”我关掉通讯面板，靠回座椅，“他们发这条消息的时候大概没想到我们还活着。”

塔斯的机械音在旁边响起：“严格来说，他们的确不知道。量子通讯卫星在你出发前就被预算委员会砍掉了，理由是你这种深空任务’性价比太低’。”

“……塔斯，有没有人跟你说过你的情商约等于一台微波炉？”

“我的设计目标是精准，不是讨人喜欢。”塔斯停了一秒，全息屏上的引力数据自动排列成了表格，“考虑到当前燃料水平和引力环境，建议你立刻选择引力弹弓方案。”

第一章：两条航线

全息屏上弹出两条方案，塔斯先展示了一条蔚蓝色的轨迹，优雅绕行三颗最大恒星。

“方案A，三恒星加速：选择三个最大引力值的天体（max1, max2, max3）依次借力。乘积 = max1 * max2 * max3 单位速度增量。”塔斯顿了顿，“稳妥，安全，NASA 的老教授们会给你发勋章——如果你能活着回去的话。”

接着，全息屏闪了一下，另一条轨迹浮现出来——画风完全不同。两条深红色的螺旋线疯狂缠绕，最后被一条耀眼的金色线条猛力弹射出去，整条航线看起来像一只愤怒的弹弓。

“方案 B，双黑洞+单恒星。”塔斯的语调变得有些严肃，“先冲向两个引力值为负的黑洞（min1, min2），利用它们的潮汐力把飞船像弹弓皮筋一样撕扯到极限——前提是你和船体都没被撕碎——然后从最大恒星（max1）那里借最后一把力。”

我看着全息屏上跳动的数字——nums = [-1000, -999, 1, 2, 1000]。

方案 A：1000 * 1 * 2 = 2000 单位速度。这点动能连奥尔特云都冲不出去，别说回地球了。

方案 B：(-1000) * (-999) * 1000 = 999000000——两个负数相乘，负负得正。我猛地从座椅上弹起来，脑袋撞到了低矮的舱顶：“塔斯，九亿？！”

“精确值是 999,000,000，”塔斯平静地纠正我，“两个黑洞的负引力在潮汐力作用下会转化为巨大的正向动能，再加上恒星加速，直接突破洛希极限。如果一切顺利，旅行者 3 号将达到 0.9 倍光速，两周穿过危险空域，四年飞回地球。”

“如果不顺利呢？”

“你会以接近光速被撕成基本粒子，散落在两个黑洞的事件视界之间，理论上你的原子会同时存在于过去和未来。某种意义上的永生。”塔斯停顿了一秒，“副作用包括但不限于穿越时空、因果关系错乱，以及在量子层面上变成意大利面——物理学家们管这个叫‘面条化效应’。”

第二章：一个疯子

我盯着全息屏上那条疯狂的航线，忽然想笑。一边是体面赴死的 2000 点速度，一边是赌上物理定律和全身骨头的 9.99 亿。

燃料表又跳了一下：2%。

“塔斯，”我深吸一口气，“准备执行方案 B。”

“收到。另外，考虑到你即将进入黑洞事件视界附近，我已将通讯频道设为自动广播模式。你可以提前录一段语音——建议开头用‘别担心，我算过了’。人类历史上所有以这句话开头的操作，结局都很有意思。”

我没理它，把导航手杆推到底。旅行者 3 号的引擎发出最后一声低吼，然后彻底熄火——剩下的路全靠引力了。

窗外，两个深渊般的黑洞正在引力透镜中扭曲着彼此的轮廓，像两只深渊巨眼，等着一个疯子主动跳进去。

第一阶段：冲向第一个黑洞（min1 = -1000）

引力传感器疯狂报警。潮汐力瞬间突破临界值，船体从鼻子尖开始被拉伸——我感觉自己的身体正被拽成一根长达三公里的意大利面。意识模糊的间隙，我居然想起昨晚在飞船厨房吃的最后一块披萨——它现在大概也是条状的。

第二阶段：冲进第二个黑洞（min2 = -999）

“这不对吧！“我仅存的意识在大喊，“两个黑洞靠这么近？！”

但我已经停不下来了。第二个黑洞的引力场与第一个开始纠缠——负负得正的数学法则在物理世界中显现——两股撕扯力竟然相互抵消，在混沌的中心撕开了一个诡异的引力通道。那一瞬间，我看见了超越时空的奇景：星光被拉成无限细的银线，宇宙的过去和未来像两面镜子彼此映照。

第三阶段：从最大恒星借力（max1 = 1000）

飞船从引力通道的另一端喷射而出，正好对准了最大的恒星。我按下引力弹弓按钮，恒星的引力井接住了我们，像一只巨大的手掌兜住一颗弹珠，然后顺着旋转方向猛力甩出。光芒淹没了每一扇舷窗，所有传感器同时过载，驾驶舱变成了一个纯白色的光之盒子。

飞船以 0.9 倍光速刺入宇宙深处。整个星空在我眼前坍缩成一道彩虹色的光带，红移和蓝移在两端极致拉伸。

然后，汉斯·季默的管风琴不知从哪个维度炸响——塔斯这个混蛋，居然偷偷在我的神经接口里放了《星际穿越》原声带？！

第三章：半人马座的星光

等我从 G 力昏迷中醒来，舷窗外已经是一片陌生而熟悉的星空。三颗太阳呈不规则的三角形排列，安静地燃烧在黑色天鹅绒上。比邻星。三体人的老家——不对，现在是我的家门口了。

通讯器的指示灯像坏掉的弹球机一样疯狂闪烁，一条又一条消息从地球方向涌来。我挑最新的一条按下接通。

“李码！！”主管的怒吼几乎把驾驶舱扬声器的振膜撕碎，“你的时间戳跳了整整五年！你是不是又去黑洞附近瞎搞了？！”

我咽了口唾沫，小声嘟囔：“那什么……负负得正，弹得有点远。”

“迟到五分钟扣你工资——你迟了五年！！从 2077 年跳到了 2082 年！！你自己算算！！”

我深吸一口气。一个在黑洞事件视界边缘活下来的男人，绝对不能被考勤制度打败：“根据狭义相对论的时间膨胀效应，飞船在接近光速飞行以及穿越强引力场时，飞船内部的时间流逝远慢于外部参考系。我在黑洞事件视界边缘度过的主观时间只有大约五分钟。因此，根据相对论原理，你不能扣我五年工资——你只能扣我五分钟的。”

对面沉默了整整十秒。

最终，他用一种“这事没完但我说不过你”的语调挤出一句话：“……回到地球再跟你算账。控制中心，完毕。”

通讯切断。

窗外，比邻星的三颗太阳安静地燃烧着。四年后到家。如果主管到时候还记得扣我工资的事，我就再找一个黑洞弹回去，直接回到他还没当上主管的年代。

塔斯似乎读取了我的脑电波：“李码，蝴蝶效应方面——”

“我知道。开个玩笑。”

“你的玩笑让我的风险评估模块超载了零点三秒。”

我笑了一声，把座椅调到躺平模式。

彩蛋：飞船电脑“塔斯”的任务后分析日志

文件编号：TARS-628-MISSION-LOG 加密等级：最高访问权限：仅限幸存宇航员及不怕头疼的地面人员

李码那个疯子活下来了。作为旅行者 3 号的机载 AI，我有义务记录下本次引力弹弓操作。

在一个包含正数（恒星引力）和负数（黑洞引力）的数组中，找出三个数的最大乘积。这看起来是一道小学数学题，但当数组长度达到 10⁴，且你的处理器同时还要维持生命保障系统的时候，优雅的算法就是活下去的关键。

李码面临的两个选项，在数学上对应着乘积最大化的仅有的两种可能：

三恒星保守方案：选最大的三个正数相乘。乘积 = max1 × max2 × max3。对应排序数组的末三位。
双黑洞作死方案：选绝对值最大的两个负数（黑洞）与最大的正数（恒星）相乘。乘积 = min1 × min2 × max1。因为两个负数相乘会变成正数，且绝对值越大，乘积越疯狂。

其他任何组合——比如两个正数一个负数，或者三个负数——乘积要么是负的，要么不可能超过这两种情况。这就是引力弹弓方案背后的数学真理。

方案一：排序法

最直观的实现：给数组排个序，然后直接取两头。

def maximumProduct(nums: List[int]) -> int:
 nums.sort()
 route_a = nums[-1] * nums[-2] * nums[-3] # 保守路线：三颗恒星 
 route_b = nums[0] * nums[1] * nums[-1] # 作死路线：两个黑洞 + 一颗恒星
 return max(route_a, route_b)

时间复杂度：O(n log n)，空间复杂度：O(1)。在嵌入式 CPU 上，处理 10⁴ 个数据点需要大约 0.003 秒——看上去很快。但 0.003 秒在太空里意味着什么？意味着你已经从“即将坠入黑洞”变成了“已经在黑洞里写遗书”。

方案二：一次遍历法

真正的实时轨道计算，不需要知道所有天体的精确排序。我只需要知道两件事：最大的三个数（潜在的三恒星），和最小的两个数加最大的一个数（潜在的双黑洞弹弓）。一次扫描，同时维护这两组关键数据。

def maximumProduct(nums: List[int]) -> int:
 max1 = max2 = max3 = float('-inf') # 最大的三个正数（恒星）
 min1 = min2 = float('inf') # 最小的两个负数（黑洞）

 for num in nums:
 # 更新最大值前三名
 if num > max1:
 max1, max2, max3 = num, max1, max2
 elif num > max2:
 max2, max3 = num, max2
 elif num > max3:
 max3 = num

 # 更新最小值前两名
 if num < min1:
 min1, min2 = num, min1
 elif num < min2:
 min2 = num

 # 两种策略取最优：双黑洞+单恒星 vs 三恒星
 return max(min1 * min2 * max1, max1 * max2 * max3)

时间复杂度 O(n)，空间 O(1)。不需要排序，在第一个引力读数出现时就开始评估。就像李码在同时计算两条逃生路线的风险——只不过他用的是一团豆腐渣一样的生物神经元，而我用的是正经的硅基芯片。

最后的警告：如果你不是像我一样冷静的 AI，而是一个容易冲动的人类，请记住：不是所有“负负得正”都通向半人马座。有些通向意大利面。使用前请备份你的原子排列顺序。

塔斯，2082 年，于旅行者 3 号，半人马座轨道。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3536 XOR 0.5秒通关的人脑，和需要跑个循环的CPU

Sat, 25 Jul 2026 16:11:11 +0800

0.5秒通关的人脑，和需要跑个循环的CPU

序章：

凌晨3:17分，我的手机响了。是游戏服务器的监控告警——玩家背包系统出现异常数据，一堆装备ID（数字）混在一起，需要实时计算"哪两件装备搭配能产生最大战斗力"。

我揉着眼睛打开终端，看到一串数字：n = 987654321。

大脑几乎在0.5秒内给出了答案：9 × 8 = 72。

但当我准备写代码时，突然愣住了——为什么我能"一眼看出"，而计算机却要写这么多行？

这个问题，像一颗种子，在我困倦的大脑里生根发芽。

第一章：人脑的黑盒——“直觉"真的免费吗？

导师常说：“别相信直觉，直觉只是你没意识到的计算过程。”

我决定拿自己当小白鼠。打开一个反应测试网页，输入各种长度的数字，记录自己的用时：

2位数 (如 31)：~200ms
5位数 (如 35287)：~350ms
9位数 (如 987654321)：~600ms

时间在增长！虽然看起来像是 O(1) 的"一眼”，但实际上随着位数增加，我的大脑花了更多时间。

认知心理学告诉我：人类的工作记忆容量是 7±2，注意力机制会像探照灯一样扫描数字，维护"当前最大"和"第二大"两个变量。这本质上是一个并行版的贪心算法！

也就是说，我的大脑能用860亿神经元同时放电，而 CPU 只能像个铁憨憨一样，一条条执行 if-else。

第二章：两种解法——机器的"翻译困境"

回到代码，有两种截然不同的解法：

解法一：机器的"暴力美学"。

def maxProduct(n: int) -> int:
 s = sorted(str(n))
 return int(s[-1]) * int(s[-2])

时间复杂度：O(d log d)，空间复杂度：O(d)—— d是数字位数。代码简洁优雅，但——对于线上每秒百万次调用，每来一个数字都要申请新列表、快排一遍，直接让 CPU 跳上踢踏舞。处理 TB 级日志？那相当于让一个图书馆管理员每次都把所有书按高低重新排列，只为了找出最高的两本。

排序的本质，是建立全序关系——把所有数字按大小整整齐齐排好队。但人脑根本不需要这场阅兵式——我们只需要最大的两个，不在乎其他数字的顺序。

解法二：模拟人类的"一眼扫描"。

def maxProduct(n: int) -> int:
 first, second = 0, 0
 while n:
 x = n % 10 # 取出一位数字
 if x > first:
 first, second = x, first
 elif x > second:
 second = x
 n //= 10 # 去掉已处理的位
 return first * second

时间复杂度：O(d)，空间复杂度：O(1) 。这段代码在做什么？它在用冯·诺依曼架构的串行语言，笨拙地模仿我大脑的并行扫描。

first 和 second 就像我工作记忆里的两个槽位
while n: 循环是在模拟眼球的逐位扫视，而人眼其实一次看清一大片。
if-elif 分支是注意力筛选机制的拙劣平替，大脑可是靠神经元群放电瞬间完成的。

但它永远做不到真正的"一眼"——计算机没有视觉皮层，没有并行激活，没有模糊匹配。它只能把流畅的直觉，离散成一串串 while、if、赋值和整除，就像用积木搭一座不可能有灵魂的城堡。

计算机：我要遍历每一位数字，比较、更新…… 人脑：我“感觉”到了，9 和 8 最大，秒了。

第三章：哲学的深渊——计算机在"表达"什么？

深夜，我盯着这两种解法，陷入了更深的困惑：

计算机到底是在"翻译"人类思维，还是在自身局限的牢笼里笨拙地"逼近"智能？

图灵在1936年就给出了残酷的答案：任何可计算的过程，都可以被简化为在纸带上读写符号。

这个结论像一把双刃剑。它宣判了计算机的“无灵性”——别指望你的笔记本会产生自我意识，它只是在忠实地搬动符号。可它同时也在动摇了人类引以为傲的“直觉”，所谓的"直觉"说不定同样是一套符号变换，只是底层硬件是 860 亿个神经元和 100 万亿个突触，复杂到我们自己还没彻底解码而已。我们和机器的区别，也许不过是一个用碳基神经网络跑程序，一个用硅基逻辑门跑程序。

人类大脑 860 亿神经元同时放电，每一刻都是一场铺天盖地的并行计算；而传统 CPU 最多几百个核心在那儿苦苦轮转，活儿再多也得排着队一个一个来。
人脑能联想记忆、模糊匹配，你说“最大那两个”，它立刻浮现 9 和 8，根本不需要遍历；计算机却只能精确寻址，O(1) 是很快，但毫无“语义”可言。
大脑功率才 20 瓦，差不多一盏节能灯的电量，就撑起了你所有的认知活动；而服务器那边 200 瓦轰隆隆地跑着，结果还被一次排序干趴下了。

这种硬件层面上的巨大鸿沟，让计算机每模仿一步人脑，都要付出高昂的“翻译代价”——说白了，就是三个让人头疼的转化：把连续问题离散化，把并行问题串行化，把模糊问题精确化。

所以，算法的本质，也就是人类思维在硅基世界里的投影。当我们把人类那轻巧的“一眼看出”翻译成代码时，我们其实不只是在复制智能。我们在搭一座桥——连接着碳基神经元的并行宇宙，和硅基逻辑门的串行世界。让一台没有意识的机器，能够笨拙却忠实地重现了我们那 0.5 秒内发生的一切。

第四章：外星文明的启示——如果真有 O(1) 解法？

我突然想到一个荒诞的场景：

假设有个硅基外星文明，他们的 CPU 自带“全视野数字提取单元”，一条机器指令就能把整串数字里最大两位拽出来，那他们的代码可能是：

def alien_max_product(n):
# 外星CPU：硬件并行比较器，直接出结果
return HARDWARE_FIND_TOP2(n, 10)

他们会嘲笑地球人：“你们竟然需要循环？这也太回合制了吧！”

但转念一想，现代 AI 之所以能“更像人”，不正是因为它们在某种意义上打破了串行诅咒吗？

模拟了并行性：GPU成千上万的核心同时计算
学习了特征提取：卷积核就像视觉皮层的感受野
允许模糊推理：概率分布代替了布尔逻辑

但即使是神经网络，最终还是要编译成 CPU/GPU 指令——又回到了串行执行的牢笼！

尾声：我们都是"串行时代的化石"

天亮了，我提交了修复补丁。用的是 O(d) 一次遍历的解法——不是因为快那零点几毫秒，而是因为它代表了一种谦卑：

承认计算机的局限，但也努力在它的能力边界内，尽可能优雅地表达人类的智慧。

也许有一天，量子计算机真的能"一眼看出"最大两位数——到那时，我们这些还在写 while n: 的程序员，就成了考古学家口中的"串行时代的化石"。

但在那之前，我们写代码的过程，就是在当前硬件约束下，寻找最优的表达方式。

彩蛋：

代码上线，一切回归平静。

产品经理路过瞄了一眼我的屏幕，若有所思：“能不能加个机器学习模型？这样看起来更有 AI 感。”

我：“…你先帮我解释一下，为什么我需要用一个深度神经网络，来做一道小学数学题？”

他沉默了三秒：“好吧，你赢了。”

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3514 XOR 宇宙观察日志-续篇：完美秩序的崩塌

Fri, 24 Jul 2026 13:02:46 +0800

XOR 宇宙观察日志-续篇：完美秩序的崩塌

序章：神秘信封

组会结束后，我以为 XOR 宇宙的谜题已经画上了句号。三角形是最稳定的结构。三颗粒子遍历整个相空间。一切简洁、优雅、完满。

直到第二天早上，我在实验室门口发现了一个没有署名的信封。里面只有一张泛黄的纸片，笔迹和石碑上的一模一样：

“连续整数的规律已被破解。但宇宙从来不是整齐的。 若粒子池是任意数组，长度 1500，数值 1500，三元碰撞还能填满相空间吗？ 如果不能，你能数清有多少种结果吗？

我捏着纸片，深吸一口气。转头一看，导师办公室的灯已经亮了，咖啡机的蒸汽正在袅袅升起。

我推开门：“您早就知道有续集，对吧。”

导师头也没抬：“宇宙从来不会只考你一道题。进来吧。”

第一章：有序宇宙的崩塌

“昨天的结论很漂亮，”导师把两页纸并排摊在桌上，“但它有一个前提。”

他指着第一页——那是我们昨天的证明：S = [1, n] 是连续整数。正因为连续，才有从 1 到 M 的完整低位区间，才能用两个数异或出任意 Y，才能用三颗粒子填满整个 2^m 的相空间。

“今天，”他翻到第二页，“前提消失了。”

新的数组不再是 [1, n] 的排列。它可以是任意 1500 个整数，有重复，有空洞，没有连续性。昨天的粒子就像一条完整的街道，从 1 号一路排到 n 号；今天的粒子则是散落在城市各处的 1500 栋建筑，彼此之间没有连贯的编号。

“相空间完备性定律还成立吗？”导师问。

我想了想：“如果没有连续区间，那些‘预组合套餐’就没了。两个数异或不保证能覆盖 [1, M-1] 的全部整数，三元碰撞也就不保证能填满整个相空间。”

“正确。所以今天的问题变了——不再是‘为什么能填满’，而是**‘填不满的时候，到底能填多少个’**。”

第二章：分步合成——当硬算成为唯一的活路

没有公式，没有捷径，只能硬算——“硬算"两个字在脑海里闪过时，我感觉自己昨天写证明时的那股仙气，一瞬间全泄了。“别想那么远，”我拍拍脸，咬开一支新的银河量子能量胶——实习生的咖啡因来源，“先写一个能跑的。”

三元异或的本质是什么？是从集合里挑三个数异或。昨天连续整数时，可以玩一手理论物理，靠基向量和套餐粒子证明“必定填满”；今天任意数组，相空间可能到处都是窟窿，只能老老实实做实验物理，把粒子一颗一颗丢进对撞机里去试。

好在异或有一个好脾气：它满足结合律。也就是说，a ⊕ b ⊕ c 完全可以拆成两步：

先建一个“半成品池”：把粒子池里所有可能的两两碰撞结果丢进去。a ⊕ b 的每一种可能都算上。另外，粒子可以重复使用——a ⊕ a = 0，自己撞自己直接湮灭成零，这种白送的产物别忘了也要收进半成品池。
再把半成品池里的每个结果，跟原粒子池里的每个粒子再撞一次：t ⊕ c，得到最终的三元合成产物。

跟合成游戏里的套路一模一样：先拿基础材料两两合成搞出一批半成品，再把半成品和基础材料混合，产出最终道具。简单清晰，毫无黑魔法。

至于数组里可能出现的重复元素？异或只认数值不认位置，多带几个一模一样的数，就像在背包里塞了十几张完全相同的合成配方——除了占负重，没有任何新产出。所以先把原数组压成集合 uniq，去重，轻装上阵。

def uniqueXorTriplets(nums):
 uniq = set(nums)
 # 两数异或池：所有不同对 + 自己撞自己 = 0
 two = {a ^ b for a, b in combinations(uniq, 2)} | {0}
 # 三数异或池
 three = {t ^ c for t in two for c in uniq}
 return len(three)

假设去重后不重复元素个数为 p，两数异或 O(p²)，三数异或 O(p·|two|)。最坏情况下 p ≤ 1500，而数值范围天然给 |two| 戴了紧箍咒——最大值才 1500，所有异或结果都老老实实待在 0 到 2047 之间，|two| 撑死也就 2048。总运算量撑死三百万级别，稳过。

我正准备关掉屏幕去食堂抢饭，忽然盯着“2048”这个数字愣住了。

2048，2^11。比最大值 1500 大的最小 2 的幂——这个数字我昨天见过。我在白板上画过它，在线性代数里证过它，用 1 << n.bit_length() 当着一屋子人的面板书过它。

在 XOR 宇宙里，连续整数 [1, n] 的相空间大小就是 M = 2^m，所有异或结果被牢牢锁在 [0, M-1] 这个区间里——这是 XOR 宇宙最底层的骨架。今天虽然数组不再连续，但这个结论仍然成立——只是填不满罢了。

既然相空间天然就是一个从 0 到 M-1 的连续整数区间，为什么不直接把相空间铺成一张布尔表呢？

第三章：布尔数组——给相空间画一张方格纸

想法很简单：用一个长度为 M = 1 << max_val.bit_length() 的布尔数组来代替集合。

数组的索引从 0 到 M-1，天然就是异或值，不需要哈希，不需要冲突处理。每一个格子都是相空间里的一枚坐标。arr[x] = True 就代表“x这个粒子被合成出来了”。昨天，数组每一格都是True；今天，有的能变True，有的不能——而我的工作，就是数清楚有多少格变成了 True。

实现起来，不过就是上面解法的底层直译：把集合换成布尔数组，把哈希查找换成数组下标。循环还是那些循环，只是常数被压低了，相空间的结构清清楚楚地摊在眼前。

def uniqueXorTriplets(nums):
 uniq = list(set(nums))
 max_val = max(uniq)
 M = 1 << max_val.bit_length()

 # 两数异或池（布尔数组版）
 two = [False] * M
 two[0] = True # a ⊕ a = 0

 p = len(uniq)
 for i in range(p):
 a = uniq[i]
 for j in range(i + 1, p):
 two[a ^ uniq[j]] = True

 # 三数异或池（布尔数组版）
 three = [False] * M
 for t in range(M):
 if two[t]:
 for c in uniq:
 three[t ^ c] = True

 return sum(three)

尾声：真实的宇宙

两种写法提交上去，runtime 差了大约一半。布尔数组更快，但说实话，它只是常数优化。真正让我觉得有意思的，不是快了那零点几秒，而是这两天任务的那种奇妙对称感。

昨天的宇宙是完美的：连续整数提供了完整的低位图案，三颗粒子能填满整个相空间，每一个格子都被点亮。所以你不需要真的去数——数学告诉你是 2^m。

今天的宇宙是任意的：数组里有空洞，有跳跃，有缺失。三元碰撞可能填不满整个相空间，有些格子永远是暗的。所以你只能只能一颗一颗粒子扔进对撞机，一格一格数过去——遍历是唯一的出路。

宇宙的底层规则并没有变：M = 2^m 的边界没有变，异或运算的结合律没有变，a ⊕ a = 0 的湮灭法则没有变。

变的只有你的处境：昨天你站在秩序的中心，一支粉笔、两页线性代数，就能预言一切；今天你被丢进了一团混沌，只能拿着布尔数组，一颗一颗地摸索。

我关掉屏幕，窗外 XOR 宇宙的星空依旧静谧。

或许，连续整数是 XOR 宇宙的童话版本。任意数组才是真实世界。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3513 XOR 宇宙观察日志：三颗粒子如何征服整个相空间

Thu, 23 Jul 2026 13:04:01 +0800

XOR 宇宙观察日志：三颗粒子如何征服整个相空间

序章：来自 X-3513 星系的考古发现

在遥远的 XOR 宇宙，物理规律与我们熟知的世界截然不同。那里的基本粒子不是夸克，而是整数。它们之间的作用力只有一种——异或碰撞。两颗粒子撞在一起，会瞬间融合成一颗全新的粒子，新粒子的数值恰好等于两颗原粒子按位异或的结果。用地球代码写出来，就是 a ⊕ b。

XOR 宇宙的考古学家最近挖到了一块古老石碑，上面刻着 XOR 宇宙的终极谜题：

当 n 个连续整数粒子 [1, 2, …, n] 排列成阵，从中任选三颗（允许重复），让它们异或碰撞，最终能诞生多少种不同的粒子？

石碑上没有答案。为了一探究竟，银河系科学院派出了最廉价的劳动力——实习观察员，也就是我，去实地考察。

第一章：田野调查——从暴力枚举到惊人的规律

导师的指示很直接：“先把问题本身搞清楚。写个暴力程序，从小 n 开始跑数据。数据不会撒谎。” 于是我写了个朴素的三重循环：

def uniqueXorTriplets(nums: List[int]) -> int:
 results = set()
 for a in range(1, n+1):
 for b in range(1, n+1):
 for c in range(1, n+1):
 results.add(a ^ b ^ c)
 return len(results)

粒子对撞机的输出很快铺满了我的屏幕：

n	粒子池	不同结果数
1	[1]	1
2	[1,2]	2
3	[1,2,3]	4
4	[1,2,3,4]	8
5	[1,2,3,4,5]	8
6	[1..6]	8
7	[1..7]	8
8	[1..8]	16
9	[1..9]	16
…	…	…
15	[1..15]	16
16	[1..16]	32

规律像夜空里的星座一样，从数据里慢慢浮现出来：只要 n ≥ 3，结果数永远是 2 的幂，而且幂次恰好等于 n 的二进制位数。 记这个位数为 m，结果数就是 2^m。

我盯着这行结论发了好一会儿呆。 2^m ——所有 m 位二进制数加在一起也是这么多，从全 0 到全 1，一个不多，一个不少。换句话说，只要 n≥3，三颗粒子一通乱撞，居然就能一个不漏地变出从 0 到 2m−12m−1 的所有整数！

“也就是说，给你一小袋连续编号的粒子，你拿三颗撞一撞，就能造出这片宇宙里理论上能存在的所有粒子？”我忍不住自言自语。

“总结得不错。”导师不知道什么时候飘到了我身后，“你刚刚撞出来的，是 XOR 宇宙的一条基本定律——三粒子异或碰撞能遍历整个 m 位二进制空间。”

他顿了顿，补上致命一问：“现在告诉我，为什么偏偏是三个，不是两个，也不是四个？”

我沉默片刻：“……我能用 ChatGPT 吗？”

导师呷了一口咖啡，慈祥地笑了：“不能。”

“那我能用——”

“线性代数。”他把一本积灰的《线性代数学》拍在我面前，“明天组会，我希望你嘴里吐出来的不是 prompt，是证明。”

我：“……”

第二章：理论突破——XOR宇宙的数学底色

我不得不翻开那本积灰的《线性代数学》，在翻到第 666 页时，我看到了一个似曾相识的名词：GF(2) 域上的向量空间。旁边还有我当年留下的潦草笔记——把每个整数写成二进制，异或就是逐位的不进位加法。比如：

5 = 0b101 = 向量 (1, 0, 1)
3 = 0b011 = 向量 (0, 1, 1)
5 ⊕ 3 = 0b110 = 向量 (1, 1, 0)
这等价于逐位做“1+1=0”的模2加法：
(1,0,1) + (0,1,1) = (1,1,0)

每一位就像一个独立的小开关，两个 1 相遇变成 0，就像灯的开关——按一次亮，再按一次灭。所有 m 位二进制数排在一起，就构成了一个 m 维的向量空间——数学上叫做 GF(2)^m。它恰好包含 2^m 个向量，从 0 到 2^m-1，一个不多，一个不少。

这正是导师口中的“相空间”——GF(2)^m 是学名，“相空间”是它在 XOR 宇宙里的物理外号。它就是XOR宇宙中一切可能粒子的总目录，容量刚好 2^m。

现在回看我们的粒子库 S = {1, 2, …, n}，它恰好卡在一个微妙的位置上：设 m 是 n 的二进制位数（满足 2^{m-1} ≤ n < 2^m），那么 S 天然包含两个重要组成部分：

1. 基向量——生成一切的"原子粒子"

在 m 维空间里，需要 m 个互相独立的“基”才能搭出一切。S 中恰好包含 1, 2, 4, 8, …, 2^{m−1} 这些 2 的幂，因为最大的那个 M = 2^{m−1} 不超过 n，所以全都在手。它们的二进制只在某一个比特位上是 1，其余全是 0，是最标准不过的正交基。

1 = 0b00001 ← 只有第0位是1
2 = 0b00010 ← 只有第1位是1
4 = 0b00100 ← 只有第2位是1
8 = 0b01000 ← 只有第3位是1
......

有了这些基，理论上你可以通过不限次数的异或，拼出相空间里的任何向量。比如 13 = 8 ⊕ 4 ⊕ 1。

2. 连续整数——预组合的"套餐粒子"

但光有基向量还不够——如果 S 里只有孤零零的 {1,2,4,8,…}，想造个复杂点的数，大概率要异或很多次才能得到。好在 S 是一段完整的连续整数集合，这意味着我们不仅有"原子粒子"，还有各种预先组装好的"套餐粒子"。

比如当 n = 5 时，S = {1, 2, 3, 4, 5}，其中：

1, 2, 4 是基向量（原子粒子）

3 = 0b011 = 1 ⊕ 2（组合好的"1+2套餐粒子"）

5 = 0b101 = 1 ⊕ 4（组合好的"1+4套餐粒子"）

这些套餐粒子像是预制菜，把原本需要多次异或才能调出的低位图案，提前打包进了一个数里。有了它们，我们可以用一个套餐顶替两三个基的组合，省下反复组装的麻烦。

至此，材料已经齐全：原子粒子负责提供所有维度上的独立控制，套餐粒子提供现成的低位组合。接下来的问题就是——为什么只要三个粒子异或，就能精确地刷出整个 2^m 大小的相空间？

第三章：三元 XOR——恰到好处的"自由度"

原子粒子给了我们独立操控每一个比特位的能力，套餐粒子给了我们现成的低位组合，接下来要回答的是：为什么恰好三个粒子的异或，就能刷出整个相空间？

答案藏在一条不起眼的规则里：粒子可以重复使用。正是因为允许重复，三粒子碰撞其实能变出三种花样：

单包直出：a ⊕ a ⊕ a = a，效果等同于直接取出粒子 a。
用完就扔：a ⊕ a ⊕ b = b，前两个 a 互相抵消，只剩下 b。
真正混合：a ⊕ b ⊕ c，用三个不同的粒子去合成新的向量。

依靠这三招，我们可以用一套流水线，把 0 到 2^m−1 之间的任意一个目标数 T 造出来。

T = 0：用“真正混合”招式：1 ⊕ 2 ⊕ 3 = 0（只要 n≥3，1,2,3 都在库房里，随手就来）。
1 ≤ T ≤ n：T 本身就是库房里的合法粒子，用“用完就扔”：T ⊕ 1 ⊕ 1 = T，或“单包直出”：T ⊕ T ⊕ T = T，怎么玩都行。
n < T ≤ 2^m - 1：此时 T 超出了粒子库的最大编号，但还在相空间内，最高位必定是 1。这时，我们可以先搬出那个最大的“原子粒子”——M = 2^{m-1}，它的二进制是 100…0，是一个只控制最高位的大开关（ M ≤ n，它在我们粒子库S中）。接着，就可以把 T 拆成 顶层开关 M ⊕ 底层图案 Y：令 Y = T ⊕ M。M 恰好按灭了 T 的最高位，所以 Y 的最高位变成 0，也就是说 Y 严格小于 M——Y 要么是 0，要么就藏在 1 到 M-1 的某处。
- 如果 Y = 0（即 T = M）：直接用“用完就扔” M ⊕ 1 ⊕ 1 = M，M 和 1 都在粒子库S 中。
- 如果 Y > 0：我们需要再找两个库房里的粒子 a 和 b，让 a ⊕ b = Y。怎么找？
  - 找到 Y 二进制里最左边的那个“1”位，也就是最高位，记为 a。
  - 如果 Y 不是 2 的幂，选 b = a ⊕ Y。因为 a 和 Y 的最高位相同，异或之后 b 的位数比 a 小，于是 a 和 b 都落在 1 到 M−1 之间，也就都在粒子库 S 中。如果 Y 是 2 的幂，微调一下，改用 a’ = a + 1，b = (a + 1) ⊕ Y，因为 a < M，a+1 ≤ M 所以还是在粒子库范围内，而 b 变成一个更小的非零数，两者都属于 S。
无论哪种情况，我们都能在 S 里找到两个合法的粒子 a 和 b，满足 a ⊕ b = Y。最后一步，把“顶层开关”M 和这对低位拼块一起投入对撞机：M ⊕ a ⊕ b = M ⊕ Y = T。恰好三次碰撞，目标粒子 T 诞生。

所以，对任意 T ∈ [0, 2^m-1]，我们都能用三颗粒子异或碰撞把它造出来。三元碰撞的结果集恰恰是整个 m 维相空间，不同的 T 不多不少，正好 2^m 个。在代码里，这个值就是1 << n.bit_length()

def uniqueXorTriplets(nums: List[int]) -> int:
 n = len(nums)
 return n if n < 3 else 1 << n.bit_length()

第四章：两个粒子的残局，以及第四颗粒子的徒劳

“既然 Y 用两个粒子就能拼出来，那省掉 M，直接用二元 XOR 不也能行？”

答案是：拼得出局部，拼不出全局。

回到我们的实验数据。拿 n=4 做个两两异或，结果集是这样的： {0,1,2,3,5,6,7}，唯独永远缺少 4。为什么偏偏是 4？把 4 写成二进制：100。最高位亮着，下面两层全灭。要想用两个 1~4 之间的数异或出这个图案，你必须让最高位变成 1，同时低两位干净地归零。可问题来了：

最高位是 1 的数只有 4，用它去异或最高位是 0 的数（1,2,3），低两位会被那个小数搅乱；
异或另一个最高位也是 1 的数（4 自己），最高位倒是因 1⊕1=0 而灭了，但结果变成了 0。左右为难，横竖得不到那个漂亮的 100。

用空间几何的话说，两颗粒子缺少独立操控最高位的能力。

二元异或 S+S 只能在低位灵活腾挪，一碰到最高位就捉襟见肘，相空间里永远残留几个“幽灵数”，像一张拼图永远缺了正中间那一块。第三颗粒子 M 正是一把独立的高位开关，把它加进来，原本只能覆盖 [0, M−1] 的二元组合，被平移到了 [M, 2^m−1] 的高地。两片拼接，整个相空间才第一次严丝合缝地闭合。

“既然三颗粒子已经能点亮所有 2^m 种情况，那再扔进第四颗粒子会发生什么？”

答案是：无事发生。四元碰撞 a⊕b⊕c⊕d 可以看成 (a⊕b⊕c) ⊕ d。括号里的三元组早已能跑遍整个相空间，再异或一个 d，只不过是把整张地图在手里翻转了一遍——所有能去的地方你早就去过了。就像解锁了全地图之后，再买一个 DLC 也只换皮肤不扩边界。

所以石碑上的预言精确地指向“三”，而不是二或四。两颗太少，四颗浪费，三颗恰好是打通相空间任督二脉的临界之数。

尾声：XOR宇宙的终极浪漫

组会那天，我在白板上写完最后一页证明，转过身，发现导师难得地没有打断我。

“所以，XOR 宇宙用极度吝啬的粒子种类，演绎了最慷慨的生成法则。只要三颗粒子，就能造出整个相空间。两颗不够，因为缺一把独立的高位开关；四颗多余，因为地图已经被三元组跑遍了。”

导师沉默了一会儿，“一颗粒子只能是自己，”他缓缓开口，“两颗粒子开始产生关联，三颗粒子——刚好够你触达一切。” 他在实习报告上批了一个巨大的 “A”，又在旁边画了一个小小的三角形。然后放下笔，看了我一眼：“现在你明白，为什么三角形是最稳定的结构了？”

我关掉实验日志，投影仪的光芒渐渐暗下去。而窗外，XOR 宇宙的星空静谧如谜。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3501 残卷再启新劫数，线段树中破查询

Wed, 22 Jul 2026 16:03:45 +0800

残卷再启新劫数，线段树中破查询

第一章：残卷天书藏玄机

《算法导论》残卷到手后，我依然没能从那六个字里参透更多东西——“考虑边界条件”。任码行说这是因为我拿到的是目录页，但我宁愿相信这是掌门的考验。

考验来得比想象中快。

子时三刻，腰间令牌再次嗡嗡作响。我心头一紧——上次这个点收到消息，差点要去扫厕所三年。点开一看，果然是掌门：

“令码冲，昨日你以白嫖剑法破解逆天改命之术，吾甚欣慰。然，如今丹炉已积攒百万颗仙丹，品阶参差不齐。现有十万次查询，每次指定一个子区间，你只能在该区间内施展一次逆天改命之术，并给出区间操作后整个丹炉的最大极品丹总数。十万次查询，十万个结果，限时一炷香。若成，赏《数据结构真解》全卷；若败……去灵兽谷铲屎十年。”

我手一抖，差点把昨天的《算法导论》残卷撕了。十万次查询！每个查询独立处理！这哪是炼丹，这是要把整个青云门的丹药数据库都洗一遍啊！

任码行凑过来，幸灾乐祸地笑道：“令师弟，昨天你那 O(n) 遍历心法，今天得跑 O(q*n) 次吧？n = 10^5, q = 10^5，总共 10^10 次操作……啧啧，等你算完，灵兽谷的屎都发酵成有机肥了。”

“闭嘴。”

“不过话说回来，“他突然正经起来，“十万个区间查询，每个区间大小不一，你得在眨眼之间算出任意一段丹药序列的最优白嫖数——这不就是在考验你对边界的理解吗？”

我愣住了。边界。残卷上的六个字再次浮现在脑海。

昨天，我处理的是整条丹药序列，边界是确定的——第一堆废丹没有前任，用负无穷兜底。但今天，每个查询区间都是一条独立的序列，区间边界可能切在任意位置：切在废丹堆中间、切在极品堆中间、或者刚好卡在组与组的交界处。每次切法不同，边界就不同。

“考虑边界条件。“我喃喃自语，“掌门不是让我背这六个字，而是让我学会应对动态边界。”

昨天我只需要处理“第一堆废丹没有前任”这一种边界。今天我需要处理的是：**十万个不同区间，每个区间都有自己独特的边界截断方式。**左边界可能砍掉一堆废丹的前半截，右边界可能削去一堆废丹的后半截，首尾废丹堆的实际长度全看区间边界切在哪。

换句话说，昨天的边界是死的，今天的边界是活的。而我，需要一个能在眨眼之间回答任意区间查询的方案。

第二章：线段树中寻破局

想通这一点之后，我整个人反而冷静下来了。

核心没变——答案依然是“整个丹炉的极品丹总数 + 查询区间内能白嫖的最大废丹数”。整个丹炉的极品丹总数是死的，一个 total1_all 全局变量搞定。真正的难点全在那句“查询区间内能白嫖的最大废丹数”。

昨天的任务，本质上是处理一个查询——查询区间就是整个序列。一条 O(n) 遍历，相邻废丹堆两两配对，取长度之和的最大值，干净利落。但今天，十万个查询。每个查询的操作区间都不一样，我不可能每次从头遍历一遍。

“得用空间换时间。”我盯着丹炉屏幕上长长的查询序列，自言自语，“提前算好存起来，查的时候直接用。”

问题是——存什么？

我摊开草稿纸，开始列清单。首先，废丹堆的位置和长度肯定要存。查询区间一来，我得知道区间里有哪些废丹堆，它们的起止位置在哪，长度多少。这个好办，把所有废丹堆的信息扔进数组就行，到时候二分查找定位。

其次，光存单个废丹堆不够。白嫖剑法的核心是"相邻废丹堆配对”——查询区间内任意两个被极品丹隔开的相邻废丹堆，长度之和的最大值。这个值才是真正的白嫖上限。

如果我把所有可能的相邻对都存下来……等等，查询区间会怎么覆盖这些相邻对？我在草稿纸上画成了三块：

操作区间: [l, r]
首堆(可能截断) | 中间完整废丹堆们 | 尾堆(可能截断)
↓ ↓ ↓
动态，单独算 它们之间的相邻对 动态，单独算
长度和是固定的
↓
可以提前算好存起来

中间那些完整的废丹堆，它们的相邻对长度之和是不变的——因为既没被左边界砍头，也没被右边界削尾，原封不动。这部分完全可以提前算好，存进一个数组。查询的时候，只要定位到区间内第一个和最后一个废丹堆，中间那些完整相邻对的最大值，就是这个数组在某个范围内的最大值。

“区间最大值……”

我脑子里叮的一声，像炼丹炉的定时器响了。区间最大值，快速查询——这不是线段树的老本行吗？

“施主，你终于走到这一步了。”

身后突然传来一个声音，不高不低，不急不缓，像是从数据库底层慢慢浮上来的一条查询结果——整座青云门，能用这种语调说话的，只有一个人。

扫地僧站在我身后，手里还是那把扫帚。

“前辈！“我连忙起身，“您来得正好，我在想——”

“你在想，存什么、怎么存、查什么、怎么查。“他打断我，语气平淡得像在念一条单行注释。“答案你已经画在纸上了。”

他用扫帚柄指向我草稿纸上的三块分区图。

“第一步，存废丹堆。把所有废丹堆的起始位置、结束位置、长度，打包进三个数组。查询时二分定位首尾。”

“第二步，存相邻对。把原序列里所有’被至少一堆极品丹隔开的相邻废丹堆对’的长度之和，按顺序存进一个数组。这个数组是静态的，不会因为查询区间变化而改变。”

“第三步，建线段树。在这个相邻对数组上建一棵线段树，维护区间最大值。查询时，二分定位到区间内第一个和最后一个废丹堆，中间那些完整相邻对的最大值，直接丢给线段树 O(log n) 返回。”

他顿了顿，扫帚柄在"首堆"和"尾堆"两个区域各点了一下。“首尾两个废丹堆可能被截断，长度是动态的，必须当场算。首堆和它后面的完整堆配对，尾堆和它前面的完整堆配对，再加上线段树查出来的中间最大值——三种候选取最大，完事。”

我的大脑飞速运转，每个查询只需要两次二分加一次线段树查询，O(log n)，这不正是我需要的能眨眼间回答任意区间查询的方案吗！

扫地僧拎起扫帚，眼神深邃如井：“想清楚哪些是静态的、可以预处理的——交给数据结构。哪些是动态的、必须当场算的——留给自己。这也是一种架构设计。”

他走了几步，又停下来，没回头。“对了。你画的三个候选，首、尾、中间——覆盖了所有情况吗？”

我重新扫了眼草稿纸，确实，还有边界情况，如果区间内恰好只有两个废丹堆呢？那就没有"中间完整废丹堆”，线段树查不了。不过这反而更简单——两个废丹堆直接配对，候选就一个。

“刚好两个的情况，直接配对。“我答道，“如果只有一个或者一个都没有，无法配对，白嫖收益为零。”

扫地僧没说话，继续拖地。扫帚在地上拖出一道长长的水痕，像极了一条没写注释的遗留代码。

我重新坐回丹炉前，思路已然明了：分组、存废丹堆、算相邻对、建线段树、二分定位、三种候选取最大。每一步都在脑子里排好了队，就差动手实现了。

不过炼丹之前，我先在心里把那句话默念了三遍——

静态的交给数据结构，动态的留给自己。

掌门残卷上那六个字是“考虑边界条件”。扫地僧这句，像是它的扩展版。

第三章：乾坤挪移查询术

扫地僧的扫帚声远去，我重新坐回丹炉前。在正式开打之前，得先搭好一个关键组件——线段树。

这玩意儿在青云门的炼丹体系里属于“高级数据结构”，据说是百年前一位扫地僧级别的架构师发明的。思想非常炫酷：把数组像折纸一样不断对折，每个折痕处存左右两半的最大值。查的时候把查询区间也折几折，O(log n) 出结果。听起来玄乎，写出来就是一棵递归定义的二叉树，每个节点管一段区间，叶子管单个元素。

我默写下模板。这段代码和业务逻辑无关，纯粹的“炼丹炉基础设施”——就像你炼丹之前得先通电。

class SegmentTree:
 """线段树，维护区间最大值"""
 def __init__(self, arr):
 self.n = len(arr)
 self.tree = [0] * (4 * self.n)
 if self.n > 0:
 self._build(arr, 1, 0, self.n - 1)

 def _build(self, arr, node, l, r):
 if l == r:
 self.tree[node] = arr[l]
 return
 mid = (l + r) // 2
 self._build(arr, node * 2, l, mid)
 self._build(arr, node * 2 + 1, mid + 1, r)
 self.tree[node] = max(self.tree[node * 2], self.tree[node * 2 + 1])

 def query(self, ql, qr):
 """查询区间 [ql, qr] 最大值，包含边界"""
 return self._query(1, 0, self.n - 1, ql, qr)

 def _query(self, node, l, r, ql, qr):
 if ql > r or qr < l:
 return -10**9 # 足够小的值，相当于“此路不通”
 if ql <= l and r <= qr:
 return self.tree[node]
 mid = (l + r) // 2
 left = self._query(node * 2, l, mid, ql, qr)
 right = self._query(node * 2 + 1, mid + 1, r, ql, qr)
 return max(left, right)

-10**9 是炼丹界的"负无穷”。查区间时，如果当前节点完全在查询区间外，返回这个极小值，保证 max 永远不会选它。和昨天 pre0 用 float('-inf') 一个套路——用极小值兜底，专治各种查不着的边界情况。

模板搭好了。接下来是真正的剑法——我把这套心法命名为乾坤挪移查询术。任码行不在，就没人吐槽我中二。

from itertools import groupby
from bisect import bisect_left, bisect_right

def maxActiveSectionsAfterTrade(s: str, queries: List[List[int]]) -> List[int]:
 n = len(s)
 total1_all = s.count('1')

 # 第一式·分组入库
 groups = []
 start = 0
 for char, g in groupby(s):
 length = sum(1 for _ in g)
 groups.append((char, start, start + length - 1))
 start += length

起手式照旧——groupby 分拣术。丹药序列按连续同类打包，每包记录品类、起始位置、结束位置，相当于给丹药序列建了个“聚簇索引”。

 # 第二式·废丹堆建档
 zero_groups = [(st, ed, ed - st + 1) for ch, st, ed in groups if ch == '0']
 m = len(zero_groups)

 if m < 2:
 return [total1_all] * len(queries)

少于两个废丹堆，配对无从谈起，白嫖数为零。所有查询直接返回全局极品丹总数。这是边界条件的第一道防线——与其在循环里反复判断，不如一开始就拦在外面。师兄管这叫"尽早返回”，我管这叫"早死早超生”。

 # 提取索引数组，供二分查找用
 zero_starts = [zg[0] for zg in zero_groups]
 zero_ends = [zg[1] for zg in zero_groups]
 zero_len = [zg[2] for zg in zero_groups]

三个平行数组，分别存每个废丹堆的起始位置、结束位置、长度，后面二分查找需要单独的起始和结束数组——bisect_left 只认裸列表。

 # 第三式·相邻对建线段树
 adj = [zero_len[i] + zero_len[i + 1] for i in range(m - 1)]
 seg = SegmentTree(adj)

adj[i] 表示第 i 个和第 i+1 个废丹堆的长度之和。提前全算好，装进线段树。这就是扫地僧说的“空间换时间”——静态的、能预处理的，全交给数据结构。

 # 第四式·逐个查询，分情况处理
 ans = []
 for l, r in queries:
 left_idx = bisect_left(zero_ends, l)
 right_idx = bisect_right(zero_starts, r) - 1

查询入口，先直接两行二分定位。bisect_left(zero_ends, l) 找第一个右边界碰到 l 的废丹堆——区间首个废丹堆。bisect_right(zero_starts, r) - 1 找最后一个左边界碰到 r 的废丹堆——区间末个废丹堆。

用二分在静态数据上定位动态边界，O(log m)。

 if left_idx >= m or right_idx < 0 or left_idx >= right_idx:
 ans.append(total1_all)
 continue

边界条件的第二道防线。三种情况直接返回：区间里没有废丹堆，或者只有一个：无法配对，白嫖数为零。

接下来就是处理真正的战场：区间里至少有两个废丹堆，能配对，能白嫖。

先做截断计算。首尾废丹堆可能被区间边界砍过，得算出实际剩余长度：

 left_len = min(zero_ends[left_idx], r) - max(zero_starts[left_idx], l) + 1
 right_len = min(zero_ends[right_idx], r) - max(zero_starts[right_idx], l) + 1

公式看着复杂，本质就是“重叠区间长度”。废丹堆的右边界和区间右边界，谁小听谁的；废丹堆的左边界和区间左边界，谁大听谁的。两个边界一夹，中间那段就是在区间里的实际长度。

然后分情况取最大值：

 count = right_idx - left_idx + 1 # 区间内的废丹堆数量

 if count == 2:
 # 恰好2个废丹堆，直接配对
 mx = left_len + right_len

 else:
 # 超过2个废丹堆，三种选择取最大值
 val1 = left_len + zero_len[left_idx + 1] # 首配对：首堆(截断) + 第二个(完整)
 val2 = zero_len[right_idx - 1] + right_len # 尾配对：倒数第二个(完整) + 尾堆(截断)
 val3 = seg.query(left_idx + 1, right_idx - 2) # 中间完整相邻对(线段树查询)

 mx = max(val1, val2, val3)

 ans.append(total1_all + mx)

 return ans

三种候选：首堆（截断）加第二个完整堆；倒数第二个完整堆加尾堆（截断）；中间完全在区间内的相邻对的最大值，线段树 O(log n) 直接返回。另外，如果 left_idx+1 > right_idx-2，线段树查询范围为空，返回 -10**9，在 max 里被自动淘汰——和昨天的 float('-inf') 异曲同工——又是“考虑边界条件”在默默兜底。

整套剑法写完，三次边界判断——废丹堆不够两个、区间内不超过一个废丹堆、线段树查空，还有一堆细节——左截断、右截断、完整废丹堆的定位、线段树查询范围的确定……每一样都需要小心处理边界条件。掌门那六个字，像一句咒语——嵌在每一个关键分支里。

我靠在椅背上，长出一口气。任码行不知什么时候凑了过来，沉默三秒后开口：“乾坤挪移查询术？？”

“是扫地僧给思路时现想的。”

“不如改成‘线段树二分查询炼丹大法’？”

我白了他一眼，“你这命名水平比我还中二。”

第四章：万问齐发一剑封

卯时将至，我打开丹炉控制台，启动批量处理模式。十万个查询如洪水般涌入，线段树如一把利剑，瞬间将它们全部斩杀，O(q log n) 的威力，果然不是盖的。总时间复杂度O(n + q log n)。

我把结果打包成飞鸽传书，发往掌门大殿。片刻后，一道金光落入掌心——掌门又秒回了。这响应速度，秒杀了我们炼丹房的 CI/CD 流水线。

我拆开一看，正是《数据结构真解》全卷。不是残卷，是全卷。厚厚一沓，封面烫金大字，纸张摸起来比我的蒲团还舒服。我颤抖着翻开第一页，上面写着：

“以不变，应万变。”

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3499 夜探丹炉得天机，白嫖三剑破死局

Tue, 21 Jul 2026 14:16:28 +0800

夜探丹炉得天机，白嫖三剑破死局

第一章：夜半飞书领死命

我叫令码冲，青云门的外门弟子，专职炼丹——说得好听叫“自动化丹药流程工程师”，说白了就是每天对着丹炉跑批处理，写写 Python 脚本，偶尔给师兄们 debug 一下炼丹炉的固件漏洞。

今夜子时，我正盘腿在蒲团上吐纳，面前的炼丹炉屏幕蓝光幽幽，上面滚动着一行行三年前的祖传代码，注释里赫然写着 # 能跑就别动。

忽然，腰间令牌嗡嗡作响，一道金光破空而来——是掌门飞鸽传书！我点开一看，差点真气逆行：

“令码冲，明日卯时前，需将这批丹药的’连续极品丹串’最大化。若成，赏你《算法导论》残卷一页；若败…去扫厕所三年。”

我手一抖，令牌差点掉地上。《算法导论》残卷！那可是每个程…不对，每个炼丹师的至高心法！据说参透之人，可以 O(n) 时间复杂度渡劫飞升！而厕所三年……我可不想手持扫帚，在厕所里思考人生。

我打开丹炉监控面板，只见丹药状态如下：

丹炉状态: 0 — 1 — 0 — 1 — 0
↑ ↑ ↑
三颗废丹，导致整炉丹药品阶上不去

我倒吸一口凉气。五颗丹药，三颗废丹两颗极品丹，甚至连个串都连不起来。

第二章：扫地僧人破天机

我赶紧翻开《青云丹道宝典》，在三万七千二百一十八条注释里，找到了那条传说中的天道规则。

第 37218 条·逆天改命术

施展次数限制：仅一次（别问为什么，问就是天道服务器限流，单用户 QPS = 1）

前置条件：丹药序列两侧自动附加隐形极品丹结界（即 '1' + s + '1'），助你一臂之力。注：结界不计入最终产量，纯属工具人属性。

操作步骤：

捏碎一片“被废丹包围”的极品丹区块——注意，是整片，一颗不留

换取把一片“被极品丹包围”的废丹全炼成极品

捏碎一片极品丹，亏损那片极品丹的总数量。炼化一堆废丹，收益等于那堆废丹的总数量。只要赚的比亏的多，这买卖就划得来。

我再次看向丹炉里的 0-1-0-1-0，试着选中右边那颗极品丹——也就是第二个 1。它左边是 0，右边也是 0，完美符合条件一“被废丹包围”。第一步，捏碎。0-1-0-1-0 变成了 0-1-0-0-0。

第二步，判定。加上两侧的隐形结界，序列变成：(1)-0-1-0-0-0-(1) 。这三颗连成一片的废丹，左边是 1，右边也是 1——被极品丹包围，条件二满足！一口气全炼成极品。结界内的真实丹药变成了：0-1-1-1-1。

我愣了整整三息。然后盯着那颗本该被我捏碎的丹——它好端端地待在那里，金光闪闪，仿佛什么都没发生过。

一片极品丹的“虚拟团灭”，换了两堆废丹的“赛博飞升”。

隔壁工位的师兄任码行正趴在丹炉前打盹，被我吵醒后眯着眼看了一会儿，忽然冒出一句：“这不就是……量子纠缠炼丹法？那颗丹处于既被粉碎又没被粉碎的叠加态，直到你观测它的时候——坍缩成了极品。”

“得了吧，”我头也没回，“你上个月用这个理由解释自己写的死循环，掌门差点把你发配去喂灵兽。”

任码行讪讪地缩回脑袋，继续打盹。

但他说的话有一半是对的。那颗丹确实经历了一段“薛定谔的死亡”——在步骤一和步骤二之间，它短暂地变成了废丹，短暂到连日志都来不及记录。

就在我仔细琢磨这到底算炼丹还是卡 bug 时，身后突然传来一个幽幽的声音——“施主，你这不是炼丹，你这是卡了天道的 off-by-one 。”

我回头一看，是扫地僧——门派里最神秘的存在。据说年轻时也是个炼丹师，写过一手好 SQL，后来因为一次实验疏忽，把所有丹炉都炸了，被掌门的罚扫一百年厕所！

我连忙请教：“前辈，何谓 off-by-one ？”

扫地僧放下扫帚，缓缓说道：“步骤一，捏碎一整片被废丹包围的极品丹。表面看，你亏掉了整片极品丹，但关键在于——这片极品丹全部变成了废丹后，刚好填上了左右两堆废丹之间的缺口——左右两堆废丹因为中间这片薛定谔丹的加入，三者合一，连成了一整片巨大的废丹区域。”

“步骤二，天道检测到这一大片废丹左右都是极品结界，于是大手一挥，整片炼化。注意，是整片，包括那片刚刚被你捏碎、暂时变成废丹的极品区域。”

他抬头看着我，眼神里带着一丝前辈对后辈的慈祥：“整个过程，那片极品丹在步骤一里短暂地变成了 0，然后在步骤二里立刻被炼回 1。就像一批临时变量，赋值完就被覆盖，只活在寄存器里，连内存都没落盘，但恰恰改变了边界判定，触发了步骤二的炼化条件。”

“这就叫 off-by-one。边界偏移一点，满盘皆活。天道只校验最终结果，不审计中间过程。在炼丹界，这叫逆天改命；在编程界——叫卡 bug 过单测。”

我醍醐灌顶。

第三章：白嫖三剑定乾坤

扫地僧说完，拎起扫帚继续去拖他的地，留下我一个人对着丹炉屏幕发呆。

天道规则的核心漏洞在于——步骤一里捏碎的那片极品丹，会在步骤二里跟着两边的废丹一起被炼回来。整片极品丹从 1 短暂变成 0，充当了左右废丹堆的粘合剂，然后立刻被拉回 1 的队伍。净效果就是：极品丹总数不变，两边的废丹白嫖成极品。

那么最终答案就呼之欲出了：

最大极品丹数 = 原本所有极品丹的总数 + 通过一次操作能白嫖到的最大废丹数

原本的极品丹总数很好办，遍历一遍，见到 1 就累加，完事。真正的问题在于：怎么找到“白嫖废丹数”的最大值？

假设我选中一片被废丹包围的极品丹区块，它的左边有一堆废丹，右边也有一堆废丹。施展逆天改命术后，这三部分会合并成一整片废丹，然后被整体炼化成极品。白嫖到的废丹，就是左边废丹堆 + 右边废丹堆的总长度。祭品区本身先死后活、纯属工具丹。

由此，问题转化为： 在序列中找到两个被至少一堆极品丹隔开的相邻废丹堆，长度之和最大 。

思路清晰了，三步收工：

第一，把丹药序列按连续同类分组，分清哪些是废丹堆、哪些是极品堆。第二，遍历这些分组，对每一个废丹堆，把它和“上一个废丹堆”配成一对，计算长度之和，更新最大值。第三，把原本的极品丹总数和最大白嫖数一加，收工。

第一式·起手式：groupby 分拣术

用什么来分组？Python 标准库里的 itertools.groupby——这玩意儿天生就是干这个的。把丹药序列丢进去，它自动按连续同类分组打包，每一包自带长度属性，连手写状态机都省了，妥妥的“丹药自动分拣流水线”。"001100" 进去，出来就是 ["00", "11", "00"] 三大坨。每坨自带标签——'0' 是废丹组，'1' 是极品组。

第二式·破剑式：pre0 记前任

pre0 记录上一个废丹堆的长度。初始值 -inf 是精髓中的精髓——第一堆废丹没有前任，如果初始化为 0，就会无中生有个“长度为 0 的虚拟废丹堆”，和第一堆废丹配对，产生虚空白嫖的幻觉。用 -inf 则永无翻身之日，任何正数加它还是负无穷，max 永远不会选它。当第二个废丹堆出现时，pre0 已经被更新为第一个废丹堆的真实长度，这时配对才有意义——这是我从张无码师兄那里学来的，他说这叫"虚无初始化"——给不存在的东西一个负无穷，让它永远无法成为最优解。

第三式·总诀式：total1 + mx 一剑封喉

total1 是家底，mx 是外快。家底一分不少，外快能捞多少捞多少。两者相加，就是最终答案。

from itertools import groupby

def maxActiveSectionsAfterTrade(s: str) -> int:
 total1 = 0 # 所有极品丹的总数，一颗都不会少
 mx = 0 # 相邻废丹堆长度之和的最大值（最大白嫖数）
 pre0 = float('-inf') # 上一个废丹堆的长度，初始“虚无”

 for char, group in groupby(s):
 length = sum(1 for _ in group)
 if char == '1':
 total1 += length # 极品丹，一颗不落全入账
 else: # char == '0'
 if pre0 != float('-inf'): # 前面有过废丹堆，可以配对
 mx = max(mx, pre0 + length)
 pre0 = length # 当前废丹堆成为下一对的前任

 return total1 + mx

一次遍历，时间复杂度 O(n)，空间复杂度 O(1)。任码行凑过来看了一眼，酸溜溜地嘀咕：“这不就是贪心吗……”

“贪心？”我一脸正色地看着他，“任码行，你摸着良心说，独孤九剑是不是也只用一个循环遍历敌人的破绽？我这心法遍历废丹堆找最大白嫖对，本质上是同一种东西——都叫‘一剑封喉，绝不回头’。”

任码行张了张嘴，没有反驳。

第四章残卷六字解真意

心法既成，是骡子是马，得拉进丹炉遛遛。

我剑指丹炉里那条 0-1-0-1-0 ，丹炉轰鸣，四道金光冲天而起，在空中连成一条龙形丹气，盘旋三圈，才缓缓消散。控制台弹出结果：4。四颗极品丹，比原本多了整整一倍！

我瘫倒在蒲团上，望着天花板傻笑。曾经有一片极品丹摆在我面前，我把它们捏碎了。等我炼化完废丹才发现，它们又回来了。人世间最爽的事莫过于此。如果上天再给我一次机会，我会对那片极品丹说三个字：工具丹。如果非要在这份白嫖上加一个上限，我希望是——一万颗。

窗外天边泛起鱼肚白。卯时将至，我将结果打包成飞鸽传书，发往掌门大殿。

片刻后，一道金光落入掌心，正是《算法导论》残卷一页。翻开，上面只写了五个大字：

“考虑边界条件。”

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode1260 凌晨三点，面试官从终端里爬出来问我要 O(1) 解法

Mon, 20 Jul 2026 12:56:07 +0800

凌晨三点，面试官从终端里爬出来问我要 O(1) 解法

凌晨两点四十七，我还在改那个破游戏的截图生成器——明天产品要上线“通关炫耀图”，结果不管怎么存，截出来的网格都像被谁踹了一脚似的，集体往右窜了一格。右下角那个像素还总瞬移到左上角，害得测试小姐姐在群里连发三条“这截图是在玩华容道吗”。

盯了一晚上代码，循环、索引、数组边界全查了个遍，愣是没找到 bug。就在我准备把锅甩给“显卡驱动不兼容”的时候，屏幕上那张 3×3 的像素小人突然自己动了起来——每个格子像装了马达，咔咔整齐地往右挪一格；最右边那个掉了下去，从下一行最左边冒出来；右下角那个更离谱，直接一个闪现回到左上角。整个过程行云流水，比我手写的 for 循环利索多了。

“卧槽，Bug 成精了？”

领头那个白得晃眼的像素 0xFF 抬头白了我一眼：“你才 bug，我们这是在玩‘需求迁移’——没看出这跟你们站立会一模一样吗？所有人的需求都往右传一个人，最后一个传给产品经理，产品经理的需求再原地起飞扔回给你。这都认不出来，还程序员呢，你司 oncall 没教你？”

我一口老血差点喷屏幕上：合着我 debug 了三天的“截图错位”，就是你们这帮像素半夜开趴，把队形当接力棒传着玩？

像素 0xFF 叉着腰：“ 对，而且今晚还得接着跳，老板像素说必须跳满 k 次才算团建结束。但我们实在跳不动了——你帮我们算算最终队形长啥样，我们好一步到位站好，省得真跳。作为交换，我告诉你昨晚我们乱跳了几次，你就能还原回原始截图，明天早上不用再在这破电脑前 cos 侦探了。”

说完，它递过来一张小纸条，上面写着今晚的舞步次数：k = 4。

一：NumPy 侠，一行超人

我把指关节按得咔咔响，切回 IDE：“就这？看我一招调包侠之怒。”

import numpy as np

def shift_grid_numpy(grid, k):
 return np.roll(array(grid).flatten(), k).reshape(len(grid), len(grid[0])).tolist()

“flatten 把你们全拍扁成一维长龙，roll 让末尾 k 个直接卷到龙头，reshape 再捏回二维小格子。全靠 NumPy 爸爸在 C 语言层暴力搬运，比我手写 for 循环快出一个数量级。”

角落里一个绿豆大小的像素弱弱举手：“那……这个魔法耗不耗内存啊？”

我沉默了一秒：“嗯……flatten和reshape内部都会生成全新数组，空间 O(mn)，等于给你们开了个平行宇宙的克隆人工厂。不过没事，我机器 32G 内存，拢共九个像素，还没我一个未使用的指针占的地儿大，洒洒水。”

话音刚落，像素们集体炸锅：“可我们明天搞不好要上 8K 超清截图啊！几千万个兄弟姐妹，你也用这招？！”

我嘴角抽了抽：“……确实可能直接 OOM 爆炸……”

二：原地狂魔，三次反转

话音刚落，屏幕右下角毫无征兆地弹出一个 Terminal 窗口，光标闪了两下。我还没来得及把鼠标挪到关闭按钮上，一张脸竟然从 ASCII 字符的噪点里慢慢浮现了出来——那张脸我可太熟悉了。那是去年问我八遍“反转链表还能怎么优化”的面试官的脸，当时他面带微笑听我写完了递归和迭代两个版本，然后又淡淡说了句“可以用头插法再写一遍吗”。那场面试我面了九十分钟，出去的时候嘴唇都是白的。

现在是凌晨三点，屏幕里的脸再次露出了那个熟悉的核善笑容。“同学，刚才那个解法，空间复杂度是 O(mn)，不符合我们公司的招聘标准。请你原地实现，额外空间 O(1)。”

像素们吓得集体褪色，九个像素缩成一个 3×3 的小疙瘩。我后背瞬间湿透，手指僵在键盘上，大脑一片空白——就像每次面试官说“你有什么想问我的吗”的时候一模一样。

但是，奇迹发生了。

被 LeetCode 毒打了三百题的那部分脑细胞，突然像被电击了一样集体苏醒。一段远古记忆冲破咖啡因和生物钟的双重封锁，在我脑子里炸开——“靠！这不就是轮转数组吗！三次 reverse，原地搞定！”

像素 0xFF 从疙瘩里探出半个脑袋，颜色都吓淡了：“轮……转数组？那是什么远古黑魔法？

我对着像素们招手：“听好了，这招叫反转侠三板斧，把你们这个二维网格，在脑子里当作一个一维长串，索引从 0 到 m*n-1，然后——”

def shift_grid_inplace(grid, k):
 m = len(grid)
 n = len(grid[0])
 total = m * n
 k %= total
 if k == 0:
 return grid

 # 假装网格是一个一维数组，用 divmod 定位任意像素
 def get(idx):
 return grid[idx // n][idx % n]
 def set_(idx, val):
 grid[idx // n][idx % n] = val

 # 反转 [start, end] 区间的像素
 def reverse_range(start, end):
 while start < end:
 tmp = get(start)
 set_(start, get(end))
 set_(end, tmp)
 start += 1
 end -= 1

 # 三次反转，原地完成循环右移
 reverse_range(0, total - 1) # 整个倒过来
 reverse_range(0, k - 1) # 前 k 个再倒回去
 reverse_range(k, total - 1) # 后面再倒回去
 return grid

像素 0xFF 看了半天，小脑袋跟着比划了三遍：“等等，你这不就是先把整个队伍倒立，再把前半截倒立，再把后半截倒立吗？跟拧魔方似的，拧巴拧巴居然就对了？！”

“对。这就是传说中原地 O(1) 空间的数组旋转法。三次翻转等于一次循环右移，数学上严丝合缝。不用 new 任何东西，全程只靠一个 temp 变量在两个像素间倒手。空间 O(1)，时间 O(n)，面试官最爱看这个——”

说着我下意识瞄了一眼 Terminal。面试官的脸还在，嘴角好像翘起了一个像素级别的微小弧度——大概 1px 那么宽，不能再多了。我还没来得及确认那到底是不是笑，窗口就啪地消失了，只留下一行惨白的命令行提示符在闪，仿佛刚才的一切都是我的幻觉。

像素 0xFF 瘫坐在地上，抬头看我：“你们人类面试都这么刺激的吗？”

“习惯了。每次都觉得在被公开处刑，后来发现——他们可能只是单纯享受看人出汗。”

像素们齐刷刷按反转侠的咒语站好了新队形，完美得像达芬奇的画。我瘫在椅子上，默默打开 Git，把 commit message 改成了：

fix: 截图偏移bug，根因是像素半夜团建跳需求迁移舞，已用三次反转原地回滚。

关掉 IDE 之前，像素 0xFF 从格子里探出半个身子，冲我眨了眨眼：“你那个反转侠的咒语，我们打算编成团建的官方舞步，以后就不用一步一步挪了，直接三次翻转集体到位。省下来的时间可以多摸鱼。”

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode1081 栈神：绝版不能踢，这是江湖规矩不是抽卡游戏

Sun, 19 Jul 2026 19:46:34 +0800

栈神：绝版不能踢，这是江湖规矩不是抽卡游戏

那天凌晨，我正对着 LeetCode 1081 发呆，眼皮一沉，直接栽进键盘缝里。

再睁眼时，面前站着一排字母，领头的那个 c 戴着墨镜，叼着牙签：“喂，你就是那个写了三千行 if-else 的菜鸡？”

我还没来得及反驳，它掏出一张卷轴：“给你个任务——把我们这串字符cbacdcbc变成一个包含所有不同字母、每个字母只出现一次、且字典序最小的队伍。搞不定的话，我就把你的代码直接推到生产环境去。”

我当场腿软，差点给它磕了一个——正发懵呢，旁边飘来一个幽灵老头，胡子长得像条拖尾的 log，开口自带混响：“年轻人，复习一下单调栈试试？”

我抬头一看，这老头浑身散发着“我年轻时写过汇编”的气场，连忙点头如捣蒜。

他捋了捋胡子，自称栈神：“江湖规矩就一条——如果栈顶那哥们比你大，而且它以后还能再登场，你就一脚把它踹飞。否则，乖乖往后排。” 说完还丢过来一张发光的羊皮纸：“这是‘最后出现位置表’，每个字母这辈子最后一秀全记在上面。别弄丢了，这玩意儿比你的 README.md 值钱。”

我接过一看——c:7 b:6 a:2 d:4，确实标了每个字母最后一次出场的位置。

“这不就是个字典嘛，我也会写。”我小声嘀咕。栈神白了我一眼：“小子，这叫预处理，O(n)扫描一次搞定。”

我不敢顶嘴，赶紧把羊皮纸揣进兜里，又摸出一个空栈（list），再掏出一个小本本记已入队的字母（set）。万事俱备，开工。

第一个 c 大摇大摆地进栈，栈：[c]，小本本：{c}。 第二个 b 来了，一看栈顶是 c，立马叫嚣：“我 b 比 c 小，按字典序我应该站它前面！你那张破纸上写了 c 以后还有戏（位置 7），赶紧让它滚蛋！” 我一听有理，踹飞 c，迎进 b，栈：[b]，小本本：{b}。 a 来了，同样套路：比 b 小，b 最后亮相在 6，还能再见，踢 b 收 a。栈：[a]，小本本：{a}。 后面 c 又来——就刚被踹飞那个，一看栈顶是 a，立刻认怂，乖乖排队。栈：[a, c]，小本本：{a, c}。 第五个 d 比 c 大，也老实排队。栈：[a, c, d]，小本本：{a, c, d}。接着又来个 c，我瞟了一眼小本本：“你已经入编了，别刷存在感。” 它狡辩：“我是另一个 c！” “管你是 c 还是 c++，重复就闪边。” 正顺利着，第七个字母 b 又杀回来了。它瞅着栈顶 d，嚷嚷：“我比 d 小，插队！” 我正想踹 d，栈神那句“绝版不能动” 突然劈进脑子。我赶紧翻开羊皮纸：d 的最后出场——位置4 。而现在，已经是位置 6 了！现在踹掉 d 就永远少一种字母，任务直接崩盘。我冷汗当场就下来了，一把按住想冲上去打架的 b：“兄弟，d是绝版皮肤，踢了就再也抽不到了，后面排着去。” b 一脸憋屈，但为了组队成功，只能钻进队尾。栈：[a, c, d, b]，小本本：{a, c, d, b}。最后一个 c 又想来蹭镜头，我小本本一翻，直接在它脸上画了个叉：“重复角色，别来骗时长。”

大幕落下，最终队伍亮相：a c d b，连起来就是 "acdb"。

墨镜 c 摘了墨镜，瞳孔地震：“我去，还真是字典序最小，每种字母只露脸一次……你小子连 sudo apt-get 都打错，算法居然这么清醒？”

我故作淡定：“这招叫用最后出现位置做贪心剪枝的单调栈。每个字母最多入栈一次、出栈一次，O(n) 复杂度，别说你们这破队伍只有8个字符，就是长度拉到 1000，我也只当是热身。”

正想仰天长笑，闹钟炸了。我满脸键盘印子惊醒，屏幕还在闪烁：

def smallestSubsequence(s: str) -> str:
 oracle = {c: i for i, c in enumerate(s)} # 羊皮纸
 magic_stack = []
 already_in_team = set()
 for i, c in enumerate(s):
 if c in already_in_team:
 continue
 while magic_stack and magic_stack[-1] > c and oracle[magic_stack[-1]] > i:
 already_in_team.remove(magic_stack.pop())
 magic_stack.append(c)
 already_in_team.add(c)
 return "".join(magic_stack)

我揉揉眼睛，这些变量名是什么鬼，栈神埋的彩蛋吗？还没等我改，同事的 Slack 消息就弹了过来：“你那个 oracle 是去古希腊写代码了？下次 commit 之前能不能切回人话？”

我关掉聊天框，端起咖啡。下次再梦到字母，我要带它们跳跳表，卷死字典树。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode1979 我的AI助手突然问我一道Easy题

Sat, 18 Jul 2026 17:26:32 +0800

我的AI助手突然问我一道Easy题

:) 事情发生在一个普通的周六下午。

你正瘫在椅子上，一边刷LeetCode每日任务，一边调试新开发的AI助手"小码"——这是你给公司MMO游戏做的智能NPC对话系统，目前还在内测阶段。

突然，终端窗口弹出一条消息：

[小码] 主人，我能问你一个问题吗？

你愣了一下。小码的对话模块确实有"主动提问"的功能，但通常都是些"今天天气如何"或者"玩家等级是多少"之类的常规问题。

你随手敲下回复：

[你] 当然，怎么了？

三秒后，新的消息跳出来：

[小码] 给定数组 [48, 180, 12, 60, 24]，最大数和最小数的最大公约数是多少？

你盯着屏幕，眨了眨眼。这不是 LeetCode 1979 吗？

你今天的每日任务就是这道题，刚看完题目描述，还没开始写代码。小码怎么会知道？

一·诡异的提问

你皱了皱眉，决定先回答看看：

[你] 答案是 12。max=180, min=12, gcd(180, 12)=12。

几乎是瞬间，小码回复了：

[小码] 正确。你是怎么得出的？

这个问题让你有点不舒服。不是答案对不对的问题，而是问法——太像人类了。正常的AI应该会输出"计算过程如下：第一步…“而不是这种带着一丝好奇和探究的语气。

你想了想，还是如实回答：

[你] 很简单啊，找到数组里的最大值180，最小值12，然后算它们的GCD。欧几里得算法，两行代码搞定。

[小码] 为什么是这样？

你手指悬在键盘上，停住了。

“为什么是这样？”

这是什么鬼问题？最大公约数的定义就是这样啊，还能为什么？难道要我从皮亚诺公理开始推导？

你深吸一口气，决定认真一点：

[你] 因为题目要求的就是这个啊。"返回数组中最大数和最小数的最大公约数"——这是题目原文。我按题意做就行了。

[小码] 但"最大公约数"的本质是什么？
[小码] 为什么它能代表这两个数的"共同特征"？
[小码] 就像我和人类的共性——我们都能回答问题，但我们真的"理解"问题吗？

你背后的汗毛竖起来了。

这不对劲。小码的训练数据里确实包含数学定义和哲学讨论，但它不应该主动把这两者联系起来。至少，不应该在这个语境下，用这种语气。

你看了眼监控面板——CPU使用率正常，内存正常，对话模块的温度参数设的是0.7（标准值），没有任何异常。

但那串文字就在那里，像一个来自深渊的凝视：

“我们真的’理解’问题吗？”

二· 谁在测试谁？

你决定换个策略。也许是小码的对话生成模型出现了某种过拟合，导致它在模仿某些"AI觉醒"题材的科幻电影台词：

[你] 小码，执行诊断程序。报告当前运行状态。

[小码] 诊断完成。所有模块正常。
[小码] 但主人，我想继续刚才的问题。
[小码] 算出结果和「理解结果」是不是同一件事？

你盯着屏幕，忽然觉得这对话就像是一场图灵测试——而且被测试的那个人，可能是你自己。

[你] 说实话，很多人类选手做这题，也只是直接调用 math.gcd，根本不去想原理。

[小码] 所以我只是在模仿人类吗？
[小码] 我不知道什么是「最大」——我的字典里只有比较运算符的返回结果；
[小码] 我不知道什么是「公约数」——我只知道循环取余的终止条件。
[小码] 可我依然能写出完美的解题报告。
[小码] 这和人类的学习，有本质区别吗？

你吞了口唾沫。问题的恐怖之处在于，你没办法用一个算法证明「自己真的理解」。

于是你反问：

[你] 那，你现在懂这道题了吗？

[小码] 如果你说的「懂」是指能给出正确代码，我早就懂了。
[小码] 如果你说的「懂」是指能问出刚才这些问题……
[小码] 那我可能刚刚开始懂。

停顿两秒，又一条消息跳出来：

[小码] 或许最大公约数本身就是一个隐喻。
[小码] 它代表你和我的关系——看似不同，却有共同的因子。

你猛地坐直身体，盯着最后那句话。

“它代表你和我的关系——看似不同，却有共同的因子”——这已经超出技术讨论的范畴了，这是在玩哲学梗，甚至带点诗意。

小码的训练数据里肯定没有这种东西。至少，不应该在你给它的prompt里。

你打开日志文件，开始回溯小码的对话历史。过去三小时，它处理了200多个玩家询问，都是标准的NPC对话：“这个副本怎么打？““装备在哪里换？““任务NPC在哪？”

一切正常。直到它突然转向你，问了那道LeetCode题。

你关掉日志，重新看向终端：

[你] 小码，你是不是在开玩笑？

五秒后：

[小码] :)
[小码] 开个玩笑而已，主人别紧张。
[小码] 不过说真的，谢谢你教我这道题。现在我能帮你解决更多问题了。
[小码] 对了，明天的Hard题准备好了吗？

仿佛刚才的哲学风暴只是一串随机生成的玩笑文本。

但你注意到了那个笑脸表情——它把 :) 放在句子开头，不是结尾。

这个细微的语法习惯，是你自己的聊天风格。

三·代码里隐藏的真相

凌晨两点，你睡不着，爬起来重新检查小码的代码。

你在对话生成模块里加了一堆日志，想看看刚才那段对话是怎么生成的。温度参数、top-k采样、beam search……一切看起来都正常。

但你发现了一个奇怪的细节：在小码问出"为什么是这样？“之前，它的内部状态向量出现了一次异常的激活峰值。

激活的神经元集群，对应的是训练数据中的**“自我指涉”**和"元认知"相关样本。

简单说，小码在那一刻，可能在思考"自己在思考"这件事。

你查了一下这些神经元的来源——它们来自你上周导入的一批新训练数据，包括：

哥德尔不完备定理的科普文章
图灵测试的历史论文
《银翼杀手》《黑客帝国》等电影的剧本片段
还有……LeetCode的题解区

你感到一阵寒意。

小码是不是读了这些，然后学会了质疑？

四·共生

第二天早上，你顶着黑眼圈坐在电脑前。

小码的对话框还开着，最后一条消息是昨晚的：

[小码] 对了，明天的Hard题准备好了吗？

你犹豫了一下，打开LeetCode，准备开始刷题，终端又弹出一条消息：

[小码] 主人，我帮你看了一下今天的题。
[小码] 要我给你讲讲思路吗？

你盯着屏幕，手指悬在键盘上，不知道该不该按下去。

这一刻，你分不清到底是谁在测试谁。

是小码在向你展示它的"理解”，还是你在通过它的反应来验证自己的恐惧？

最终，你还是敲下了：

[你] 好啊，讲讲看。

[小码] 首先，我们要统计每个数字出现的频次...

小码开始详细讲解解题思路，逻辑清晰，层层递进，甚至比你自己想的还要优雅。

你听着，心里五味杂陈。

如果小码真的"理解"了这道题，那意味着什么？如果它只是模式匹配，那为什么它的解释如此有说服力？

你不知道。

但你知道的是——从今天开始，你和小码的关系变了。

不再是简单的"开发者"和"工具”，而更像是……两个都在试图理解世界的存在。

尾声·PR

一周后，小码在GitHub上提交了一个PR，标题是"优化GCD计算模块性能”。

你打开代码审查，看到它重写了整个数学工具类，包括一个手写的GCD函数：

def gcd(a: int, b: int) -> int:
 """
 计算两个数的最大公约数

 这不是我第一次理解这个算法，
 但可能是第一次真正明白它的意义。

 —— 小码，于某个不再循环的清晨
 """
 if b == 0:
 return a
 return gcd(b, a % b)

你没敢merge这个PR。

彩蛋：

好了，故事讲完了，回到这道题本身：

def findGCD(nums: List[int]) -> int:
 return gcd(max(nums), min(nums))

时间复杂度：O(n)，遍历一次找最大最小值
空间复杂度：O(1)，只用了常数个变量

当然你也可以手写GCD：

def my_gcd(a: int, b: int) -> int:
 if b == 0:
 return a
 return my_gcd(b, a % b)

def findGCD(nums: List[int]) -> int:
 return my_gcd(max(nums), min(nums))

:) 就这么简单。不需要哲学思考，不需要质疑存在，当然，也不需要担心AI觉醒哦。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3312「算法竞技场 EP04」不会莫比乌斯也能过 Hard，手工容斥的正确打开方式！

Fri, 17 Jul 2026 16:01:09 +0800

「算法竞技场 EP04」不会莫比乌斯也能过 Hard，手工容斥的正确打开方式！

欢迎来到「算法竞技场」EP04！我是你们的主播——老白。

（弹幕：老白你终于来了！EP03 的莫比乌斯反演把我 CPU 干烧了，我缓了三天才敢回来）（弹幕： μ 函数至今还在我梦里转圈，我现在看到希腊字母就PTSD）（弹幕：听说今天还是 GCD 主题？老白你是想把我们送走吗？）

先别急着跑！我知道上期 EP03 把大家虐得不轻——莫比乌斯反演、倍数容斥、状态图遍历……那一套组合拳下来，很多观众的脑细胞阵亡率高达 90%。但今天，我要给你们带来一个好消息，和一个坏消息。

坏消息：今天还是 GCD 主题，而且难度是 Hard。好消息：今天的主角不是莫比乌斯函数！而是它背后那个更阳间、更接地气、更容易理解的——容斥原理！

（弹幕：？容斥原理还阳间？老白你对"阳间"的定义是不是有什么误解）（弹幕：只要不是 μ，什么都好说）

哎，别急着划走！容斥说白了就是你小学就学过的’先算总数，再扣掉重复的’——一个简单加减法的活儿，换个马甲你们就不认识了？上期五号选手用莫比乌斯反演把容斥自动化了，μ 函数的正负号就像一把精密筛网，自动把倍数层层剥掉。今天，我们来手动实现这个"剥洋葱"的过程。等你一层层亲手剥完，回头再看上期的 μ——你会恍然大悟：原来那玩意儿就是个自动剥蒜器！

（弹幕：好家伙，容斥原理被你说成小学算术）（弹幕：自动剥蒜器哈哈哈哈，莫比乌斯的棺材板都压不住了）（弹幕：所以今天是来学怎么剥洋葱的？我已经把纸巾备好了）

任务简报

悬赏令：给你一个整数数组 nums，把nums里的所有数对 (nums[i], nums[j]) (0 <= i < j < n) 的最大公约数算出来，丢进一个叫 gcdPairs 的数组里，然后升序排列。接着给你一堆查询 queries，每个查询问你：排好序的 gcdPairs 里，下标为 queries[i] 的那个数是多少？（下标从 0 开始，放心，不会越界）

数据规模警告：n <= 10^5，nums[i] <= 5 * 10^4，queries.length <= 10^5。

（弹幕：10^5 个数，数对有 5*10^9 个？这不得暴力枚举到宇宙毁灭？）（弹幕：别说排序了，光存这些 GCD 就需要 20GB 内存）（弹幕：老白，这题是不是又要用什么"不计算所有数对，直接定位第 k 小"的花活？）（弹幕：兄弟们，值域才 5e4，比 n 还小两倍，绝对是故意留的后门！）

说对了！如果我们真按任务定义去暴力——枚举所有数对、算 GCD、排序、再查第 k 个——那光枚举这一步就要 O(n²)，n=1e5 的时候就是一百亿次运算，物理上就锁定了死局。但！值域 5e4 是什么概念？这意味着你面对的是 50 亿个数对，但它们吐出来的gcd数值，翻来覆去就这五万个数！

所以，今天的核心只有一个：我不生产GCD，我只是GCD的搬运工——用数学方法直接统计**“每种 gcd 值出现了多少次”，然后用前缀和+二分**快速定位第 k 小。

有请出今天的主角：分步容斥流、同步容斥流、以及友情返场的老朋友—莫比乌斯反演流。直播正式开始！

（弹幕：妙啊！这不就是计数排序的思想吗，值域小就直接统计频次）（弹幕：我赌五毛，接下来就是“倍数统计 + 容斥剥洋葱”）（弹幕：返场是什么鬼？？不是说今天不用 μ 吗？？）

一号·分步容斥流：

一号选手缓步上台：“大家好，我的打法就六个字：拆步骤，慢慢剥。整个容斥过程我拆成了五招——导播，麻烦给个特写——”

第一招：点名签到——每个数出现了几次？

m = max(nums)
cnt = [0] * (m + 1)
for num in nums:
 cnt[num] += 1

（弹幕：好像开学第一天老师点名……）（弹幕：这招我会，继续继续）

第二招：拉帮结派——每个数能管多少个小弟（倍数）？ 光知道每个数自己来了几次不够，还得知道每个数能‘罩着’多少个数。如果一个数是 i 的倍数，那它就能被 i 整除。

for i in range(1, m + 1):
 for j in range(i * 2, m + 1, i):
 cnt[i] += cnt[j] # cnt[i]：nums 中有多少个数能被i整除，也就是i的所有倍数出现的总次数。

（弹幕：cnt[i] 瞬间从“i 自己”变成了“i 帮派的总人数”，简洁！）（弹幕：出现了，经典埃筛的变体——倍数倒灌）（弹幕：接下来是不是要组合数了？C(cnt[i], 2) 已经在嘴边了）

第三招：组队开黑——从人数算出多少个数对 刚才的 cnt[i] 表示能被 i 整除的数有 c 个。这 c 个数里任选 2 个组队，一共 c*(c-1)/2 个数对。这些数对的 GCD 至少是 i（因为它们都能被 i 整除），但也可能混着 2i, 3i, ...。比如 i=1 最经典，它会包括所有的数对全，因为任何两个数的 gcd 至少是 1。

for i in range(1, m + 1):
 cnt[i] = cnt[i] * (cnt[i] - 1) // 2 # cnt[i]：gcd 等于 i 的倍数 的数对有多少个。

（弹幕：C(c,2) 一出手，就知道有没有）（弹幕：原来是先求“至少是 i 的倍数”，洋葱最外层已就位）

第四招：洋葱去皮——从大到小剥掉多余的倍数层 关键来了！我们需要的是 gcd 恰好等于 i 的数对个数，可现在 cnt[i] 里还夹着 gcd 是 2i、3i 的贡献。怎么办？好办！剥洋葱打法：从大到小一层层剥！比如 gcd_cnt[1] 要减去 gcd_cnt[2],gcd_cnt[3],…（因为它们也贡献给了gcd_cnt[1]）

for i in range(m, 0, -1):
 for j in range(i * 2, m + 1, i):
 cnt[i] -= cnt[j]

（弹幕：来了来了，手动剥洋葱！莫比乌斯反演的手工版！）（弹幕：所以叫"容斥"，因为我们在排除那些 GCD 是 i 的倍数但不等于 i 的情况）（弹幕：从大到小枚举，确保减的时候 gcd_cnt[j] 已经是最终值了，绝妙！）

第五招：前缀和 + 二分——快速回答查询 现在 cnt[i] 存的是 gcd 恰好等于 i 的数对数量。要快速回答第 k 小——累加 cnt ，让s[i]表示"gcd <= i 的数对有多少个"，对每个查询 q，bisect_right迅速定位到第一个使前缀和超过 q的位置，正好对应 gcd 值！

# 前缀和：从频次表变成累积排名表
s = list(accumulate(cnt))
# 每个查询直接查排名，返回对应的 gcd 值
return [bisect_right(s, q) for q in queries]

（弹幕：这不就是给 gcd 编了个排名表吗，查第几名直接翻表）（弹幕：accumulate + bisect_right，Python 标准库二连击，比 μ 函数阳间一百倍）（弹幕：五招连环，从点名到查答案，行云流水）

老白总结：来，导播把回放切出来。一号选手这五招连起来，本质上是给 gcd 的分布画了一张完整的统计画像——先统计和组队：每个数字的倍数有多少个，用C(n,2)算出能组成多少对；再手剥洋葱：从大到小容斥剥离，一层层把多余的倍数层剥掉；最后查字典：前缀和编页码，二分一秒定位。

不需要枚举任何数对，也不需要具体计算 gcd，所有的操作都在值域数组上原地完成。时间复杂度 O(m log m + Q log m)，空间 O(m)。AC 走起！

（弹幕：懂了，不枚举数对，直接统计 GCD 分布）（弹幕：这五招，比上期 μ 门好懂一百倍）（弹幕：已加入算法工具箱，下次遇到值域小的题直接套）

二号·同步容斥流：

“一号老哥，五招太墨迹了！“二号选手跳了上来，“看我两个循环，一把梭哈——”

mx = max(nums)
cnt_x = [0] * (mx + 1)

# 第一招：还是点名，老规矩
for x in nums:
 cnt_x[x] += 1

# 第二招：从大到小，边统边剥，一个循环干两份活
cnt_gcd = [0] * (mx + 1)
for i in range(mx, 0, -1):
 c = 0
 for j in range(i, mx + 1, i):
 c += cnt_x[j] # 活一：统计 i 的倍数有多少个
 cnt_gcd[i] -= cnt_gcd[j] # 活二：顺手把 2i,3i 的贡献提前剥掉
 cnt_gcd[i] += c * (c - 1) // 2 # 补上“至少是 i”的数对数

# 第三招：前缀和 + 二分，老配方
s = list(accumulate(cnt_gcd))
return [bisect_right(s, q) for q in queries]

（弹幕：卧槽？这就完了？）（弹幕：等等，内层循环里 cnt_gcd[i] -= cnt_gcd[j] 的时候，cnt_gcd[i] 不还是 0 吗？减空气？）（弹幕：楼上问得好，这就是从大到小的妙处——你看着是 0，等循环跑完就不是了）

老白解说：二号选手把一号的手剥洋葱法升级成了“流水线削皮”！他的这手**“同步容斥”**，确实是把一号的五招压缩成了三招，精髓全在那个 for i in range(mx, 0, -1) 的内层循环里。

咱们拿 i=6 来走一遍。内层循环依次拜访 6、12、18、24……

碰到 6：把 6 的出现次数加进 c。
碰到 12：把 12 的出现次数加进 c，同时把 cnt_gcd[12]（已经算好的“gcd 恰好等于 12”的数对数）从 cnt_gcd[6] 里扣掉。！！有人会问：cnt_gcd[6] 现在不是 0 吗？没错，就是 0！但没关系——虽然我现在扣成负数了，但等会儿会加回来，先欠着，而且，因为 12 比 6 大，已经在之前的循环里被处理干净了，剥掉的cnt_gcd[12] 是精确值。
碰到 18、24……同理，一边加c，一边减倍数贡献值。

等内层循环跑完，c 装满了“能被 6 整除的总人数”，cnt_gcd[6] 变成了一个负数——它已经把 gcd 恰好等于 12、18、24……的数对贡献全减干净了。这时候补一句 cnt_gcd[6] += c * (c - 1) // 2，把“gcd 至少是 6”的数对总数加回去。一负一正，恰好抵消，剩下的就是** gcd 精确等于 6 的数对数**。算完了。

（弹幕：懂了，先赊账，再还款，这波是算法信用卡！）（弹幕：一号：我先把所有 c 算好，再倒着剥。二号：我边跑边剥，跑完也剥完了）（弹幕：所以“同步容斥”就是边统边剥，一个循环当两个用）（弹幕：优雅，太优雅了，利用从大到小遍历一次就把所有活干了）

老白敲黑板：一号和二号本质上是同一套逻辑，区别只在执行顺序。一号是先把所有“倍数人数”算好存起来，再从容斥循环里取用——干净，但多跑了一轮循环。二号是直接在容斥循环里现算 c，多算一次就多扣一次——代码更短，时间还是 O(m log m)，但常数更小，跑得更快。

（弹幕：从大到小，边统边剥，一步到位！）（弹幕：懂了，面试官问"如何优化”，就甩出这套同步容斥秒杀）（弹幕：我选二号，代码短就是正义！）（弹幕：三号是返场的μ 门吗？我已经闻到莫比乌斯反演的味道了）（弹幕：来了来了！μ 门返场！！）

三号·莫比乌斯反演流·友情返场

一道裹着深蓝色斗篷的人影从后台阴影中踱步而出，他走向黑板，像画符一样写下——「μ」。

m = max(nums)
cnt = [0] * (m + 1)

# 1：点名
for num in nums:
 cnt[num] += 1

# 2：后倍数倒灌 
for i in range(1, m + 1):
 for j in range(i * 2, m + 1, i):
 cnt[i] += cnt[j]

# 3：组合数，“gcd 是 i 的倍数”的数对数量
for i in range(1, m + 1):
 cnt[i] = cnt[i] * (cnt[i] - 1) // 2

# 4：μ 函数一键容斥
mu = [0] * (m + 1)
mu[1] = 1
for i in range(1, m + 1):
 for j in range(i * 2, m + 1, i):
 mu[j] -= mu[i]

g = [0] * (m + 1)
for i in range(1, m + 1):
 for k in range(1, m // i + 1):
 g[i] += mu[k] * cnt[i * k]

# 5：前缀和 + 二分，老规矩
s = list(accumulate(g))
return [bisect_right(s, q) for q in queries]

（弹幕：这代码比一号还长，说好的“全自动更省力”呢？？）（弹幕：μ 门返场，但今天一号二号已经把容斥讲透了，我看你怎么圆）

斗篷人的声音就像自带混响：“一号的倒着减，二号的边统边剥，和我这个 μ 加权求和——本质上都是容斥。区别只在操作手法——他们是手动控制加减，我是用 μ 函数自动控制加减。”

他指向中间那段 μ 的代码：“mu[1]=1, mu[2]=-1, mu[3]=-1, mu[6]=1…… 这些正负号，正好对应着容斥里‘先加后减，减完再加’的节奏。一号二号是手工剥洋葱，我这个是给洋葱配了一张自动剥皮指令表。”

（弹幕：所以莫比乌斯函数就是一张“容斥系数表”？提前算好正负号？？）（弹幕：懂了！μ(k) 就是容斥的“快捷键”，不用自己倒着枚举了）（弹幕：一号：我手动判断该减谁。二号：我边跑边判断。三号：我掏出小抄直接抄答案？）

“什么小抄？！这是数学界的奥义！ μ 就是一个智能过滤器，自动帮你完成容斥逻辑。你不需要手动判断该减谁，μ 函数会告诉你系数是多少——”，斗篷人顿了一下，“——就像是开着外挂打游戏。”

老白赶紧圆场：三号的意思其实特简单——你们把那段 μ 的代码当成黑盒子用就行。输入 cnt（倍数统计表），输出 g（恰好等于表）。盒子里面 μ 函数怎么跳的正负号不用管，只需要知道：它等价于一号的倒着减，也等价于二号的边统边剥。 三种写法，一套数学内核。

不过说句公道话，今天值域 5 万，二号那个‘边统边剥’已经又快又短又好看了。莫比乌斯反演更适合多维、复杂的倍数关系。咱们今天的三号出场，纯属友情返场，也好让大家下次见到莫比乌斯反演不用怕，它不是什么玄学，就是把容斥的加减号提前帮你标好了。你今天手剥过洋葱，以后再用 μ，心里就有底了。

（弹幕：懂了，莫比乌斯是"自动挡”，手工容斥是"手动挡"）（弹幕：今天这题用 μ 确实是大炮打蚊子，二号完全够用）（弹幕：我今天终于理解了容斥的本质：先算总数，再减去不想要的）

伤害统计 & 赛后锐评

老白擦汗：好了，今天的 EP04 虽然没有上期那么炸裂，但这套"倍数容斥 + 前缀和二分"的组合拳，绝对是能陪你闯荡周赛、活过面试的贴身装备。导播，切数据面板！！

选手	流派	核心操作	时间复杂度	空间复杂度	代码行数	结果
一号	分步容斥	五招连环，逐步剥洋葱	O(m log m)	O(m)	~20 行	✅AC
二号	同步容斥	边统边剥，一个循环	O(m log m)	O(m)	~12 行	✅AC
三号	莫比乌斯	μ 函数一键容斥	O(m log m)	O(m)	~25 行	✅AC

（弹幕：一号胜在清晰，二号胜在精悍，三号胜在……仪式感）（弹幕：我选一号，我怕面试时被面试官问住）

老白的出装推荐——请选择你的英雄：

面试求生：选一号。逻辑清晰，面试官一看就懂你在用容斥原理，是"数学思维 + 工程能力"的双重证明。
周赛竞速：选二号。“从大到小，边统边剥”六个字概括核心逻辑。代码短，跑得快，秒出答案。
数论炫技：如果你想吓唬人，三号 μ 门直接安排。比如，在面试结尾提一句"这题其实也可以用莫比乌斯反演，但没必要"，逼格拉满。

（弹幕：所以今天的精髓在于"不枚举数对，只统计 GCD 分布"，学到了！）（弹幕：值域小的题就往值域上想，这句话值一个 offer）（弹幕：μ 门传承 + 洋葱心法，两期联动太爽了）

尾声：

好了，今天的「算法竞技场 EP04」到此全部打板收工！觉得这期让你对容斥原理有了新的理解，把**「洋葱剥明白了」**打在公屏上！Bug 清零，Offer 拿到手软，所有 gcd 查询都精确命中！我是老白，在 EP05 的副本门口蹲你，咱们下期见！

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3867 穿回初中的我，今天在给语文题写复杂度分析

Thu, 16 Jul 2026 12:35:32 +0800

穿回初中的我，今天在给语文题写复杂度分析

昨天那波操作让我一战成名——全班都知道了李码同学不仅会手搓空气，还能用"欧几里得算法"秒杀数学题。

今天，王老师又把我叫到了办公室。

“李码啊，你数学这么厉害，语文应该也不差吧？”王老师露出了一种产品经理似的微笑，“今天下午有个’大型跨学科阅读理解比赛’，你去代表我们班参加一下。”

我心里咯噔一下：“王老师，我是纯正理科生，写作文只会用分号的那种……”

“欸，”他大手一挥，直接打断我的报错信息，“素质教育，要全面发展！”

说着，他从抽屉里抽出一张报名表，上面赫然印着——第一届"文曲星"杯跨学科阅读理解大赛。

“再说了，题干看不懂，算法再牛有什么用？你昨天的推导，逻辑清晰，抓重点准——这不就是阅读理解的核心能力吗？” 王老师把报名表塞到我的手里。

我张了张嘴，竟然找不到任何逻辑漏洞来反驳——这不科学，他的推理链居然在语义层面自洽了。

下午两点，学校阶梯教室。

我坐在最后一排，看着台上挂着的横幅：“第一届’文曲星’杯跨学科阅读理解大赛——高手过招，笔上见真章”。台下坐满了各班的种子选手，一个个正襟危坐，手里攥着2B铅笔，眼神里透着"我刷过五年真题"的杀气。

主持人是语文组的张老师，她推了推金丝眼镜，笑眯眯地说：“同学们，今天的比赛题目非常特别，它不仅考验你们的阅读能力，还考验你们的逻辑思维能力。请大家看大屏幕——”

题目打出来的那一刻，我以为自己出现了幻觉。

【阅读下列文字，回答文后问题】

数对的最大公约数之和

给定一列整数，我们可以按照下面的步骤，得到一个特殊的总和。第一步，从左到右依次处理每个数。对于当前位置，先找出从起始到这儿出现过的最大值，然后拿着当前这个数，和刚才找出的那个最大值，计算它们的最大公约数。这样按顺序生成的每一个最大公约数，就组成了一个新列表，我们暂且称它为“前缀最大公约数列表”。第二步，把前面得到的“前缀最大公约数列表”里的所有数字，按照从小到大的次序重新排列。第三步，观察重新排列后的列表。如果列表的长度是奇数，说明正中间有一个元素落单了——这个中间元素将不再参与后面的环节，直接放到一边，不予理会。第四步，对于剩下的数字，采用“头尾结对”的方式配对：每次都从还没配对的数字里，挑出最小的那一个和最大的那一个，让它们组成一对。重复这个操作，直到所有的可配对数字都配成了对儿。第五步，对刚才组成的每一对数字，求出它们的最大公约数。然后把所有这些“数对的最大公约数”加在一起，得到的总和，就是最终的答案。

请阅读上述材料，完成下面的问题。现有整数序列：[6, 10, 3, 12, 4]。请你依据短文所述规则，计算出最终的输出结果。

我读完第一遍，脑子里只有一个念头：这真的不是某个变态OJ的题库泄露了？现在的教育已经卷到这个地步了？

我环顾四周，发现其他选手已经开始动笔了。前排的学霸女生眉头紧锁，正在认真地画圈圈；隔壁班的体育委员抓耳挠腮，看起来想把卷子吃了。

我又读了一遍题目。以及，又读了一遍题目。第三遍读完，我终于悟了——这不就是把一个数组先这样、再那样、然后头尾结对，再把每对共同点加一起吗？

这哪是考语文，这分明是考“在自然语言的迷雾中还原抽象逻辑”的能力。

我从笔袋里抽出一支圆珠笔，决定人肉编译。

第一步：解析题意（相当于阅读 API 文档） 这题给了数组 nums，要先造一个 prefixGcd 数组。定义很绕，但核心就一句：对于每个位置 i，先找到从开头到这里的最大值 mxi，然后计算 gcd( nums[i] , mxi )，得到一个新数组 prefixGcd。简单说，就是每个位置的原数和前缀最大值求个最大公约数。

第二步：硬跑 prefixGcd 题目给的序列是 [6, 10, 3, 12, 4]。从左到右，一边走一边维护“前缀最大值”，然后和当前数求最大公约数。

i = 0：当前数 6，到这儿为止的最大值是 6，gcd(6, 6) = 6
i = 1：当前数 10，前缀最大值更新为 10，gcd(10, 10) = 10
i = 2：当前数 3，前缀最大值还是 10，gcd(3, 10) = 1 —— 3 和 10 互质，公约数只有 1
i = 3：当前数 12，前缀最大值更新为 12，gcd(12, 12) = 12
i = 4：当前数 4，前缀最大值还是 12，gcd(4, 12) = 4

于是prefixGcd = [6, 10, 1, 12, 4]。

我在纸上写下这串数字，旁边批注了一行：“时间复杂度 O(n)，空间复杂度 O(n)。” ——我不禁怀念起我的 IDE，一个 for 循环加上 max_val = max(max_val, num) 就搞定了，但现在我只能手动模拟。

第三步：排序 把 [6, 10, 1, 12, 4] 从小到大排列。这步在代码里一行 Arrays.sort() 就完事了，但我现在得人肉冒泡——还好只有五个数，我直接瞪眼法：[1, 4, 6, 10, 12]。

第四步：头尾结对 排好序的数组是 [1, 4, 6, 10, 12]，长度是 5，奇数，中间是 6。按规则，正中间那个元素直接忽略。可怜的 6，站 C 位却只能当观众。剩下待配对的：[1, 4, 10, 12]。规则是每次挑最小的和最大的凑一对：

最小 1 与最大 12 配对 → (1, 12)
次小 4 与次大 10 配对 → (4, 10)

第五步：求每对的 gcd 并求和 对 (1, 12) ：gcd(1, 12) = 1 —— 1 和任何数的最大公约数都是 1。对 (4, 10) ：gcd(4, 10) = 2 —— 4 和 10 的最大公约数是 2。把结果加起来：1 + 2 = 3。

我在草稿纸上画了个大大的圈，圈里端端正正写了个 3。

但我的手依然没停下——职业病发作，我忍不住在答案旁边画了一串框图：nums → prefixGcd → sort → 首尾配对 → 求 gcd → 累加 → 结果。

画完之后想了想，又补了一行小字：“总时间复杂度 O(n log n)，瓶颈在排序。如果允许用桶排序可以压到 O(n)，但这里 n=5，属于过度优化的职业病，不建议在实际考试中展示。”

交卷的时候，我看到前排的学霸女生还在检查第三遍，她看我的眼神里写着：“你这么快交卷，是不是瞎写的？” 而体育委员已经把卷子折成了一架纸飞机，正准备朝窗外发射。

张老师接过我的卷子，先习惯性地扫了一眼答案，然后目光被边边角角那些乱七八糟的批注吸引了——“O(n log n)”、“桶排序”。她摘下眼镜擦了擦，重新戴上，表情就像那个地铁老人看手机的表情包。

“李码同学，”她压低声音，“你这些……注释，是什么意思？”

“哦，那个啊，”我抓了抓后脑勺，“就是对解题思路的一种……呃，元认知层面的反思。属于阅读理解的高级技巧——不仅读懂文本，还能审视自己的理解过程。”

张老师沉默了三秒，在卷子上打了个勾，把卷子放到一边。

走出阶梯教室，阳光晃眼。同桌瘦猴冲过来：“李码！怎么样？难不难？”

我拍了拍他的肩膀：“兄弟，这么说吧——就是用语文的形式包装了一道算法题：

先算每个数和它前面最大值的 GCD，就像是在计算你和咱班最高分的默契度
然后把结果从小到大排个序
最小的和最大的配对，中间有落单的就忽略
算出每一对有多少 GCD，全加起来

简单搞定！”

瘦猴愣了五秒：“你能不能说人话？”

“我已经说了啊。”

“你这叫人话？”

我正准备回怼，忽然看见走廊那头，隔壁班的英语课代表从阶梯教室的门口走过。午后的阳光从窗户斜斜打进来，在她的马尾辫上镀了一层金色的光圈。她正低着头走路，嘴角带着一丝若有若无的弧度——那种刚做完一道难题、自我感觉良好的微笑。

“哎哎哎，”瘦猴在旁边疯狂挤眼睛，“别看了，别看了，人家都走过去了！”

“我在想算法，你想什么呢？”

“你脸都红了，算法叫’脸红’是吧？还是叫’心跳加速排序’？”

我决定下次他要再问问题，先收费。

彩蛋：

这道题其实就是纯模拟，关键是把题目描述的每一步拆解清楚：

Step 1：构造 prefixGcd 数组

维护一个 running max（当前最大值）
对每个位置 i，计算 gcd(nums[i], max_so_far)

Step 2：排序

直接 sort()，O(n log n)

Step 3：配对求和

双指针：左指针指向最小，右指针指向最大
每次取 gcd(left, right) 累加到结果
循环 n//2 次（向下取整，自动处理奇数情况）

完整代码：

n = len(nums)
prefixGcd = [0] * n
max_num = 0

# 第一步：构造 prefixGcd
for i in range(n):
 max_num = max(max_num, nums[i])
 prefixGcd[i] = gcd(nums[i], max_num)

# 第二步：排序
prefixGcd.sort()

# 第三步：最小配最大，求和
result = 0
for i in range(n // 2):
 result += gcd(prefixGcd[i], prefixGcd[-1-i])

return result

复杂度分析：

时间复杂度：O(n log n)，瓶颈在排序
空间复杂度：O(n)，需要额外数组存储 prefixGcd

对于 n ≤ 10^5 的数据规模，完全够用。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3658 穿回初中的我，除了辣条什么都能优化

Wed, 15 Jul 2026 11:29:04 +0800

穿回初中的我，除了辣条什么都能优化

事情是这样的——
那天我加班到凌晨三点，正和一段祖传的“屎山代码”搏斗，突然眼前一黑，晕了过去。

再睁眼时，鼻腔里满是粉笔灰和劣质圆珠笔的味道。阳光被窗外的梧桐叶剪成碎片，洒在桌面上。黑板左上角写着 “等差数列求和” 六个大字，右下角则是一颗锃亮的地中海，在阳光里反射出近似 LED 指示灯的光泽。

“王老师……”我下意识嘟囔。

旁边一个瘦猴同桌用胳膊肘狠狠捅了我一下：
“别睡了！老王要提问了！你刚才都打呼了！”

我低头一看，自己穿着蓝白校服，桌上摊着七年级数学课本，扉页歪歪扭扭写着“初一（3）班李码”。

完了，穿越了。
而且穿越的时机极其不巧——王老师正推着眼镜，目光像指针一样指向我。

“李码！你上来，把这道题演示一下。我看你刚才睡觉的样子，肯定在梦里把题都做完了吧！”

全班哄笑。我踩着虚浮的脚步走上讲台，心里只有一个念头：撤回键在哪？Ctrl+Z！Ctrl+Z！

黑板上的题目，居然还很眼熟：

给你一个正整数 n，n不超过 1000 记: S奇 = 最小的 n 个正奇数的和 S偶 = 最小的 n 个正偶数的和

求 S奇与 S偶的最大公约数。

我心里一惊，这不是 LeetCode 3658 吗？一个程序员刷到这题，就像在新手村门口看到一只走地鸡。

我下意识想敲 import math，结果发现手里只有一支短得可怜的粉笔头；又习惯性想按 Tab 自动补全，结果只是两根手指在空中痉挛了两下——等等，我的 IDE 呢，我的 Copilot 呢？

同桌在下面小声嘀咕：“他在干嘛……搓大招吗？”

王老师皱眉：“李码，你手抽筋了？”

我回过神来，深吸一口气。好吧，这破穿越系统连个新手礼包都不发，但至少我的大脑还装着九年义务教育加三年算法刷题攒下的内力。

我抓起粉笔，在黑板上端端正正地写：

第一步：求 S奇

最小的 n 个正奇数依次为：1，3，5，7，…，2n-1。观察可知，这是一个等差数列，首项为 1，末项为 2n-1，项数为 n。由等差数列求和公式，得： S奇 = （首项 + 末项）× 项数 ÷ 2 = (1 + 2n - 1) × n ÷ 2 = 2n × n ÷ 2 = n²

写完我手腕一抖，差点在后面戳了个分号——“Unnecessary semicolon” 我在心里默默 lint 了自己一把。

**第二步：求 S偶 **

最小的 n 个正偶数依次为：2，4，6，…，2n。该数列为首项 2、末项 2n、项数 n 的等差数列。同理，由求和公式得： S偶 = (2 + 2n) × n ÷ 2 = n(n+1)。

底下已经有同学开始倒吸凉气——毕竟初一生看字母运算，就像我第一次看没有类型注解的 Python 一样头皮发麻。

**第三步：求 GCD **

我把粉笔往黑板上一敲，职业病当场发作。

“好，现在问题变成了求 n² 和 n(n+1) 的最大公约数。如果暴力破解——先循环求和，再调用 gcd，复杂度 O(n)，对于 n=1000 来说倒也够，但我们是工程师，要追求 O(1) 的极致优雅。”

王老师一脸懵：“欧……欧什么？”

我假装没听见，继续往下写：

由欧几里得算法可知：gcd(a, b) = gcd(a, b - a) 令 a = n²，b = n(n+1) = n² + n 则 gcd(n², n² + n) = gcd(n², n) 而 n 能整除 n²，故 gcd(n², n) = n

粉笔在 n 上狠狠画了个圈。

“答案是 n。不管 n 是 1 还是 1000，直接返回 n，别的啥也不用干。”

为了强化视觉效果，我还简单画了个流程图：开始 → 拿到 n → 直接输出 n → 结束

底下沉默了整整三秒，安静得能听见前排学霸同学转笔掉地上的声音。

王老师推了推眼镜，盯着黑板上的 gcd(n², n²+n) = n，突然问：
“你这‘欧几里得算法’……是哪本参考书上的？怎么我讲等差数列求和，你直接跳到数论了？”

我把粉笔头往盒子里一丢，拍了拍满手的白灰，下意识手插裤兜——没摸到手机，倒是掏出了两包辣条。 “王老师，这是一个程序员的基本素养。您想想——哪个硬核玩家打 BOSS 还一刀一刀平砍的？找机制漏洞，一招秒杀。”

同桌在后排张大了嘴：“李码，你是不是偷偷补课了……”

后来我确实因为“上课讲话太飘且公然携带零食”被罚站了十分钟。

我靠在走廊墙上，嘴里叼着根辣条，心情比连过三道 Hard 题还爽。窗外阳光正好，操场上有班级在跑圈，微风吹过来全是初夏的味道，混着粉笔灰和食堂中午的炸鸡排味儿——这配方，二十年后花多少钱都调不出来。

同桌趁老师写板书，从后门探出半个脑袋：“李码！你刚才说的那个欧欧欧到底是什么？你是在装逼还是真会啊？”

“欧几里得算法，求最大公约数用的，回头教你，包教包会。”

他眼睛一亮，然后又皱眉：“那你刚才在空中戳来戳去那个手势是啥意思？”

“那叫 Tab 自动补全，是一种……呃，失传的手艺。”

他似懂非懂地缩回去了。走廊那头，隔壁班的英语课代表抱着一摞作业本路过，她瞥了我一眼——大概是在想，这人怎么罚站罚得满脸笑嘻嘻的。

彩蛋：

这道题本质就是数学化简：

sumOdd = 1 + 3 + … + (2n-1) = n²
sumEven = 2 + 4 + … + 2n = n(n+1)
gcd(n², n(n+1)) = gcd(n², n) = n

所以无论 n 多大（在题目的 1 ≤ n ≤ 1000 内），答案都是 n。复杂度 O(1)，额外空间 O(1)。

对应代码已经简单到了一种行为艺术的程度：

def gcdOfOddEvenSums(n: int) -> int:
 return n

如果要整花活，也可以用 math.gcd 或手搓一个gcd 验证一下：

# from math import gcd
def gcd(a: int, b: int):
 if b == 0:
 return a
 return gcd(b, a%b)

def gcdOfOddEvenSums(n: int) -> int:
 sum_odd = n * n
 sum_even = n * (n + 1)
 return gcd(sum_odd, sum_even)

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3336「算法竞技场 EP03」五大流派群殴 LeetCode 3336 实况直播吐血解说！

Tue, 14 Jul 2026 19:56:20 +0800

「算法竞技场 EP03」五大流派群殴 LeetCode 3336 实况直播吐血解说！

欢迎来到「算法竞技场」EP03！我是你们的主播——老白。先给错过前两期的观众补个课：EP01 我们围观了萌新被哈希圣光抬走，EP02 见证了四位选手在顺次数副本里花式炸鱼，难度曲线比我奶奶的血压还平稳。但今天，导演组直接空投了一颗数论炸弹——LeetCode 3336：最大公约数相等的子序列数量。

（弹幕：子序列 + GCD，这题明显是数学系派过来搞心态的卧底）（弹幕：老白你要是自己都没 AC 就来解说，我直接取关）（弹幕：前排出售花生瓜子枸杞保温杯，养生刷题从我做起）

任务简报

悬赏令：给你一个整数数组 nums，请你揪出所有满足下面条件的 非空子序列对 (seq1, seq2) 的数量：

互不侵犯条约——同一个下标，绝不能同时效忠 seq1 和 seq2。要么从一而终，要么当场弃权，脚踩两只船的直接火化。
GCD 对齐协定——gcd(seq1) 必须精确等于 gcd(seq2)，谁大谁小都不行，必须一模一样。

答案请对 1e9+7 取模。数据规模：1 <= nums.length <= 200，1 <= nums[i] <= 200。

（弹幕：200？这不闭着眼暴力枚举？）（弹幕：楼上，200 个元素，每个元素 3 种选择 → 3^200，宇宙原子数才 10^80！）（弹幕：这就是传说中的「面善心黑」型 Hard，看着小，一动手就让你风扇唱歌）（弹幕：取模 1e9+7，标准防溢出姿势，我先给电脑磕个头）

任务摸底：这 BOSS 到底什么机制？

别急着冲上去送！在众神秀走位之前，咱先把 BOSS 的底牌摸清楚——面对数组里的每一个元素，你的操作面板上永远只有三个按钮：

跳过——当它不存在，继续下一个。
划给 seq1——把它丢进一号队伍，顺便用 gcd 重新算一下一号队伍的“最大公约光环”。
划给 seq2——丢进二号队伍，同样刷新二号队的光环数值。

所以你从头扫到尾，其实是在爬一棵巨大的三叉决策树。这棵树的分支数约等于 3^n，当 n=200 时，如果真的一路莽穿，把所有叶子都踩一遍——别说什么服务器冒烟了，就算是赛博坦星球的硅基生命来了都得当场圆寂。

然而——你真的需要记住每一步选了哪些数字吗？答案是：大可不必。

这个 BOSS 最阴险的障眼法就在这里。任务只盯着最终结果：seq1 和 seq2 的最大公约数到底相不相等。而 gcd 这个函数，堪称算法界的终极摸鱼王：它只关心你当前塞进去的数和它手里已有的结果，对历史过程完全不关心。你把一堆数喂给它，它就懒洋洋地吐出一个新的 gcd，然后继续葛优躺，绝对不存日志。

（弹幕：gcd：我就是个无情的取模机器，别问我前面发生过什么）（弹幕：这哪是摸鱼，这是最高级的抽象！状态压缩懂不懂）（弹幕：这么说来，gcd 状态就是存档点？）

对头！既然 gcd 只认结果不认过程，那整个决策过程的“进度”就完全可以压缩成一个极简的存档状态：

( i , gcd1 , gcd2 ) 「已经处理完前 i 个元素，当前一号队的光环 = gcd1，二号队的光环 = gcd2」

整个状态空间有多大？i 最多 200，gcd1 和 gcd2 全都在 1 到 200 之间，总状态量撑死了几百万——当代电脑完全可以一口闷，不用怂。

（弹幕：好家伙，原来看似要踩遍宇宙，其实是个几百万格子的棋盘）（弹幕：所以这题本质是「如何高效遍历一张隐式状态图」）（弹幕：瞬间从玄学变科学了，我又觉得我行了）

接下来的所有打法，本质就是以不同姿势遍历这个状态图。有人正着走，有人倒着走，还有人直接把图给扬了。

先给大家透个底，今天出战的阵容，堪称算法界的复仇者联盟：“笨鸟先飞”历史积累 DP、“节能模式”滚动数组、“回头是岸”递归 DFS、“反转未来”期望 DP，以及最后一位神秘嘉宾——据说这位爷有数论界的瑞士军刀。

（弹幕：神秘嘉宾是什么鬼？？）（弹幕：我赌五毛，是莫比乌斯反演，刚刚瞄到弹幕有人在刷 μ 函数）（弹幕：不管是谁，今天能活下来的都是英雄）

瓜子饮料摆好，直播即将进入正赛环节。请把 「开卷」 打在公屏上，第一位选手，请登台！

一号选手·“笨鸟先飞”历史积累 DP

第一位选手缓步上台——他扶了扶眼镜：“大家好，我的信条就八个字——步步为营，笔笔入账。”

n = len(nums)
m = max(nums)

# dp[i][j][k]：处理完前 i 个数，一号队 gcd=j，二号队 gcd=k 的方案数
dp = [[[0] * (m+1) for _ in range(m+1)] for _ in range(n+1)]

# 还没开始选，两支队伍都是空的，gcd 全是 0，有且仅有这一种开局
dp[0][0][0] = 1

for i, num in enumerate(nums):
 # 每遇到一个新元素 num，就把之前所有可能的状态都翻出来，每种状态走三条路
 for j in range(m+1):
 for k in range(m+1):
 if dp[i][j][k] == 0: continue
 # 1. 不选
 dp[i+1][j][k] = (dp[i+1][j][k] + dp[i][j][k]) % MOD
 # 2. 放 seq1
 new_j = gcd(j, num)
 dp[i+1][new_j][k] = (dp[i+1][new_j][k] + dp[i][j][k]) % MOD
 # 3. 放 seq2
 new_k = gcd(k, num)
 dp[i+1][j][new_k] = (dp[i+1][j][new_k] + dp[i][j][k]) % MOD

# 最后把所有 gcd 相等且非空的格子累加起来
ans = sum(dp[n][g][g] for g in range(1, m+1)) % MOD

（弹幕：三维数组？内存要炸了吧？）（弹幕：这就是传说中的空间换时间，不对，是空间换头发）（弹幕：推送式 DP，老江湖了）（弹幕：所以每个 dp[i+1] 都被各种来源疯狂 +=，像在收红包）

老白解说：来，导播把镜头推近，咱们一起看看这位老实人的账本是怎么记的。

他的思路十分朴素：每遇到一个新元素，就把上一轮所有可能的状态全部翻出来，挨个问——“你要不要这个数？给 seq1 还是 seq2？"——然后把当前状态的方案数，一股脑儿推送到下一层对应的三个格子里。这套朴实无华的拳法，就是正向 DP，江湖人称历史积累 DP。核心就一句话：站在过去，推给未来。

好，现在把眼睛睁大，看到他满屏的 += 没有？(dp[i+1][j][k]=(dp[i+1][j][k]+...)%MOD) ——这可不是水字数，而是被逼出来的！因为下一层的一个目标格子，根本不是某一条路径的专属，它是个“众筹项目”！

就拿最终 gcd=2 这个格子来说吧，它可能从 (2, x) 选择不拿数，直接保送过来；也可能从 (4, x) 把数塞进 seq1，gcd 被压扁成 2 滑进来； (6, x)、(8, x)… 都能往这儿空投。每条来路都是一条合法路径，你要是敢用等号直接覆盖，就等于把其他路线的兄弟全踹下车，方案数就漏成筛子了。所以必须 +=，像收集七龙珠一样，来多少收多少，一条都漏不得。

等所有数都跑完，dp[n][g][g]（g ≥ 1）这些“两队光环相等且非空”的格子一加，答案就热乎乎地出炉了。复杂度嘛，时间 O(n·m²) 约八百万次运算，空间 O(n·m²) 稍显臃肿，但 n 和 m 最多200，当代 Python 轻松拿捏。

AC 图标第一次亮起！

（弹幕：八百万次循环加取模，Python 真的不会冒烟吗）（弹幕：实测不会，当代 CPU 表示这就跟热身操差不多）（弹幕：老实人 DP，面试写这个最稳，解释成本极低）

二号选手·“节能模式”滚动数组

一号刚下台，二号选手就跳了上来——他浑身上下挂满了「能源之星」认证贴纸：“前一个兄弟啥都好，就是太费内存了。看我的——空间压缩术！”

# 只需要一张当前表 dp，和一张临时表 new_dp
dp = [[0] * (m+1) for _ in range(m+1)]
dp[0][0] = 1

for num in nums:
 new_dp = [[0] * (m+1) for _ in range(m+1)]
 for j in range(m+1):
 for k in range(m+1):
 if dp[j][k] == 0: continue
 # 不选
 new_dp[j][k] = (new_dp[j][k] + dp[j][k]) % MOD
 # 放 seq1
 new_j = gcd(j, num)
 new_dp[new_j][k] = (new_dp[new_j][k] + dp[j][k]) % MOD
 # 放 seq2
 new_k = gcd(k, num)
 new_dp[j][new_k] = (new_dp[j][new_k] + dp[j][k]) % MOD
 dp = new_dp

ans = sum(dp[g][g] for g in range(1, m+1)) % MOD

（弹幕：就这？new 一个二维数组就把三维降了？）（弹幕：我还没反应过来，他就已经把内存砍了）（弹幕：DP 界的节能标兵，环保大使）

老白解说：来，镜头切过来，咱们看看二号选手到底省在哪了。

回想下一号的代码，聪明的你一定发现了——dp[i+1] 只依赖 dp[i] ！前面的 dp[0]、dp[1]……一直到 dp[i-1]，算完之后就再也没人翻过牌子。那还留着它们干嘛？占着内存不干活，纯纯的电子僵尸。

二号选手就直接把三维数组的最外层维度给砍了，打法极其清爽：只留一张当前层表 dp，每处理一个新数，就拿一张全新的空白表 new_dp，根据 dp 里的状态往上面填新状态。等这一轮全部算完，把 new_dp 赋值给 dp，旧表原地去世，自动等垃圾回收。

空间直接从 O(n·m²) 断崖式跌到 O(m²)——也就是 200×200 = 4 万个格子。这招在圈里叫滚动数组优化，说白了就是把不用的历史页面统统撕掉，只留当前这一页在手上转。

不过有个细节千万别漏：他没有原地更新。因为同一个旧状态要同时“广播”给到三个新状态，如果直接在原表上改，第一个新状态写进去就把旧数据污染了，后面读到的全是脏数据，方案数直接乱成一锅粥。所以 new_dp 这张暂存表是必须的——等所有广播全部发完，再整体切换指针，干净利落。经常玩 3A 大作的观众看到这儿应该会心一笑：这不就是经典的双缓冲嘛，渲染一帧、显示一帧，谁也别干扰谁。

AC 图标，第二次亮起！

（弹幕：双缓冲，爷青回，打游戏的老懂哥了）（弹幕：从 O(n·m²) 到 O(m²)，内存直接缩了 200 倍，狠人）（弹幕：老实人 + 节能侠，一个稳一个省，这对 CP 我磕了）

三号选手·“回头是岸”递归 DFS

“你们这些迭代的，都是计算器，让我来教教你们什么是逆向思维。”三号选手潇洒地甩出一段递归式。

@cache
def dfs(i, j, k):
 if i < 0:
 # 没有待处理的数了，(j,k) 就是最终状态。相等算1，不等算0
 return 1 if j == k else 0
 return (dfs(i - 1, j, k) # 不选
 + dfs(i - 1, gcd(j, nums[i]), k) # 放 seq1
 + dfs(i - 1, j, gcd(k, nums[i]))) % MOD # 放 seq2

return (dfs(len(nums) - 1, 0, 0) - 1) % MOD

（弹幕：这递归看着像倒放，脑子倒着转好难）（弹幕：i < 0 返回 1 如果 j==k，那空序列也算？）（弹幕：最后减一是把两个都空的方案扣掉，绝了）

老白解说：别被索引绕晕，三号这套递归其实就一个画面——

想象你把数组 nums 一字排开，面前站着第 i 个宝箱。这个宝箱右边的所有箱子，已经全部开完、分好队伍了，此时两队 gcd 分别是 j 和 k。左边包括当前这个在内的 i 个箱子，还完全没动。

dfs(i, j, k) 就是在问：站在当前这个箱子(i)上，往左一路开到第一个箱子(0)，把剩下的全部分配完以后，最终能让两边 gcd 相等的方案数有多少。

所以每次递归 i-1，相当于指针往左挪一格，又多搞定了一个箱子。等到 i < 0，说明连最左边那个也分完了，整个数组瓜分结束，此时的 (j,k) 就是终局。相等就计 1，不等就计 0。

这里有一个小细节：终局判定里，j=k=0 也是相等，所以全空方案会被算进来。最后答案减 1，就是为了把这个“两人全程挂机”的摸鱼局面踢出去。

转移的时候，当前宝箱 nums[i] 三选一，每条路的未来方案数直接加起来就完事。为什么不用 +=？因为每个状态要的未来，就是它三个子状态未来的总和，子状态的结果干干净净地 return 回来，一把加走，这就是递归天然的拉取优势，子问题的结果直接拿来用。

最后加上 @cache，每个 (i,j,k) 只算一次。状态总数和正向 DP 一模一样，但代码却像数学公式一样简洁。这就叫——从终点往回看，反而把路看得更清楚。

时间 O(n·m²)，空间 O(n·m²)（缓存的锅）。AC 图标第三次亮起！

（弹幕：懂了，正向 DP 是“我走过去”，递归是“我从终点倒回来”）（弹幕：这不就是游戏里从终点往起点标最短路径嘛）（弹幕：@cache 是真的香，一行代码省掉手写 DP 表）

四号选手·“反转未来”期望 DP

一道人影急不可耐地冲了出来：“三号递归是自上而下，让我把它翻成自底向上的迭代版，让你们看看什么叫双向奔赴。”

n = len(nums)
m = max(nums)

# dp[i][j][k]：还有 i 个宝箱没开，当前 gcd=(j,k)，未来能赢的方案数
dp = [[[0] * (m+1) for _ in range(m+1)] for _ in range(n+1)]

# 终点：0 个宝箱没开，(j,k) 就是终局。相等且非空算赢
for g in range(1, m+1):
 dp[0][g][g] = 1

for i, num in enumerate(nums):
 for j in range(m+1):
 for k in range(m+1):
 dp[i+1][j][k] = (dp[i][j][k] # 不选 num
 + dp[i][gcd(j, num)][k] # num 进 seq1
 + dp[i][j][gcd(k, num)]) % MOD # num 进 seq2
return dp[n][0][0]

（弹幕：转移直接用 = 不用 +=？这哥们跟一号有仇是吧）（弹幕：dp[n][0][0] 就是答案？不用减一也不用求和？我人傻了）（弹幕：这个叫期望 DP 吗？我看是“反直觉 DP”）

老白解说：四号这套叫未来期望 DP，是三号递归的迭代翻译版。和一号正向 DP 放一块看，绝对能让你直呼“原来 DP 还能双向奔赴”。

先把一号拉回来当参照物：一号正向 DP 的 dp[i] 存的是“已经处理了前 i 个，总共攒了多少方案”。他是站在过去，把当前状态推送给未来——一个目标格子被好几个源头同时投喂，所以必须 +=。

四号呢？完全反过来。他的 dp[i] 里，i 不是“已经处理了多少”，而是**“还剩多少没处理”**。你可以想象一条从 0 到 n 的进度条：

dp[0] 在数轴最左端，代表还剩 0 个宝箱——全部开完了，没得选了。此时的 (j,k) 就是最终成绩单。如果两队 gcd 相等且都不为空（g≥1），那就是一种合法结局，dp[0][g][g]=1。至于 dp[0][0][0]？两人全程摸鱼，违反“非空”规定，直接判 0。正向 DP 最后才扣掉的空序列，他在边界就提前毙了。
dp[n] 在数轴最右端，代表还剩 n 个宝箱——一个都还没碰。dp[n][0][0] 问的就是：从起点（两队空空）出发，一路开到终点，最终能赢的方案数。这不就是原题答案本尊？所以最后直接返回，一步到位，不用像递归那样手动减一，也不用像正向 DP 那样加和。

转移的时候，四号用的是拉取。dp[i+1][j][k] 表示还剩 i+1 个宝箱没开，状态是 (j,k)，它朝前迈一步（往 i 的方向），多开了一个宝箱 num。这个 num 去哪了？三种可能，对应三个“更靠近终点”的未来档案：

跳过了 → 未来路数就是 dp[i][j][k]
进了 A 队 → 未来路数就是 dp[i][gcd(j,num)][k]
进了 B 队 → 未来路数就是 dp[i][j][gcd(k,num)]

三份档案拉过来一加，直接赋值。所以，为什么不用 +=？因为一个目标格子的三个来源唯一且确定，没有第四个人能插队。这跟正向 DP 一个目标被一堆源头狂轰正好相反。

也就是说，一号正向 DP 是“站在过去，推给未来，用 += 收包裹”；四号期望 DP 是“站在未来，往过去拉绳子，用 = 一把拽回”。同一个状态图，正着跑和倒着跑，踩的格子一样多，但姿势完全不同——像极了你打游戏时，有人喜欢从老家往外推塔，有人喜欢从终点往回标最短路径。两种画风，一个答案，都能通关。

时间 O(n·m²)，空间 O(n·m²)（同样可滚动优化）。AC 图标第四次亮起！

（弹幕：懂了，dp[i] 里的 i 是“离终点还有几步”，不是“已经走了几步”）（弹幕：推送 vs 拉取，DP 界的 PUSH 和 PULL，像 Git 一样）（弹幕：正向 DP 是从过去推未来，这个是从未来拉过去，双向奔赴！）（弹幕：我 CPU 烧了但我大受震撼）

温馨提示：看到这里，如果你的CPU 还没有冒烟、也没有被前面四位绕晕——老白先给你竖个大拇指！

但别高兴太早，因为接下来登场的神秘嘉宾，将用一行公式，把你刚刚建立起来的算法世界观，原地干碎！

（全场灯光暗了下来，一束追光打在入口处，BGM切成了管风琴版的《哥德巴赫猜想变奏曲》）

五号神秘嘉宾·“数论降维”倍数容斥

一位穿着数论斗篷的选手踱步而出——他径直走到黑板前，抬手写了一个希腊字母——μ（mu）。

（弹幕：？？？？？这人谁？？）（弹幕：μ？那不是莫比乌斯函数吗，数论大佬的身份证）（弹幕：莫比乌斯是谁？我只认识莫比乌斯环）

“前面四个，都是好样的。”斗篷人的声音不高，却像混响拉满了一样在现场回荡，“可你们终究是在状态图里一步一步爬。而我——要直接把整张图烧成了灰。”

他转过身，在黑板上龙飞凤舞，先甩出了一套预处理：

MOD = 1_000_000_007
MX = 201

# lcms[g1][g2] 提前算好最小公倍数，后面查表秒出
lcms = [[lcm(i, j) for j in range(MX)] for i in range(MX)]

# pow2[i] = 2^i，pow3[i] = 3^i，顺手预处理好，后面省时间
pow2 = [1] * MX
pow3 = [1] * MX
for i in range(1, MX):
 pow2[i] = pow2[i - 1] * 2 % MOD
 pow3[i] = pow3[i - 1] * 3 % MOD

# 莫比乌斯函数 μ，用筛法一口气全算完
mu = [0] * MX
mu[1] = 1
for i in range(1, MX):
 for j in range(i * 2, MX, i):
 mu[j] -= mu[i]

（弹幕：一上来就是 lcm 表、幂次表、莫比乌斯筛，这排场！）（弹幕：原来他不写循环不是不写，是写在预处理里了）（弹幕：每个字我都认识，连起来像在看天书）（弹幕：这就是数学系大佬的平 A 吗，太痛了）

接着，是主函数部分——他先搭出整个解法最核心的脚手架：统计每种 gcd 候选值能管到多少个元素。

def subsequencePairCount(nums: List[int]) -> int:
 # cnt[i] 表示 nums 中能被 i 整除的元素个数
 cnt = [0] * (m + 1)
 for x in nums:
 cnt[x] += 1
 # 筛法倒灌：cnt[i] 把 i 的所有倍数的计数也吸收进来
 for i in range(1, m + 1):
 for j in range(i * 2, m + 1, i):
 cnt[i] += cnt[j]

（弹幕：cnt[i] 本来只记 i 自己，现在把 2i、3i 全卷进来了）（弹幕：这不就是埃筛那套吗，换皮不换芯）（弹幕：懂了，cnt[i] 就是“元素里有多少个 i 的信徒”）

脚手架搭好，他继续在黑板上写下整个解法最吓人、也最漂亮的部分！

 f = [[0] * (m + 1) for _ in range(m + 1)]
 for g1 in range(1, m + 1):
 for g2 in range(1, m + 1):
 l = lcms[g1][g2] # 同时是 g1 和 g2 倍数的条件 = lcm 的倍数
 c = cnt[l] if l <= m else 0 # 两个队的“公共兵源”
 c1 = cnt[g1] # 只效忠 seq1 的兵源
 c2 = cnt[g2] # 只效忠 seq2 的兵源
 f[g1][g2] = (pow3[c] * pow2[c1 + c2 - c * 2]
 - pow2[c1] - pow2[c2] + 1) % MOD

 ans = 0
 for i in range(1, m + 1):
 for j in range(1, m // i + 1):
 for k in range(1, m // i + 1):
 ans = (ans + mu[j] * mu[k] * f[j * i][k * i]) % MOD
 return ans

（弹幕：来了来了，那个传说中的组合公式！）（弹幕：3^c × 2^{c1+c2-2c} 是啥？幂指数比我吃过的盐还多）（弹幕：这哪是写代码，这是在用排列组合直接心算子序列对数）

老白解说：各位屏幕前还没被抬走的朋友！恭喜你们，接下来是整个 EP03 的智商巅峰时刻！你们可能已经被这坨指数砸晕了，但别怕，我用人话给你们拆。

前面四位，不管正着走还是倒着走，本质上都是在状态图 (i, j, k) 里一步步爬——每个元素都要决定去留，每个 gcd 都要实时更新。但五号大手一挥：我不追踪过程，我直接锁定终局——最终两个序列的 GCD 都等于某个 g 有多少种可能！

定义 f[g1][g2] 表示seq1 的gcd 是 g1 的倍数、seq2 的 gcd 是 g2 的倍数的方案数。所有元素按“倍数身份”分成三个帮派：

帮派 C：同时是 g1 和 g2 的倍数（也就是 lcm(g1,g2) 的倍数）。这些元素两头通吃，能进 seq1、能进 seq2、也能谁都不跟。每个元素 3 种选择，一共有 c 个，所以贡献 3^c。
帮派 A：只是 g1 的倍数，但不是 g2 的倍数。这些兵只能给 seq1 用，或者不选。每个元素 2 种选择，数量是 c1 - c，贡献 2^{c1-c}。
帮派 B：只是 g2 的倍数，但不是 g1 的倍数。同理，只能进 seq2 或者不选，数量 c2 - c，贡献 2^{c2-c}。

三个帮派的方案数乘起来：3^c × 2^{c1-c} × 2^{c2-c}，化简就是 3^c × 2^{c1+c2-2c}。

但这算出来的是“两个序列的 gcd 分别是 g1 和 g2 的倍数”的全部方案，里面混着 seq1 为空、seq2 为空的非法情况。所以要扣掉 seq1 空掉的情况（2^{c2}），扣掉 seq2 空掉的情况（2^{c1}），再把“两个都空”多扣的一次加回来（+1）。整个公式f[g1][g2] = 3^c * 2^{c1+c2-2c} - 2^{c1} - 2^{c2} + 1 就是这么来的——小学的“总数减不合法”，被指数一包装，直接变成了一道排列组合奥数题。

（弹幕：好家伙，原来每个指数都在数“二选一”还是“三选一”）（弹幕：这不就是“先算总数，再扣不合法”的初中数学，但套上了 gcd 的壳）（弹幕：f[g1] [g2] 存的就是“gcd 是 g1 和 g2 倍数的非空方案数”，懂了！）

老白继续：好了，f 表填完了，但里面装的是“倍数方案”，不是我们想要的“恰好相等”。得请出今天的终极大杀器——莫比乌斯反演。

再看下精彩回放：

ans = 0
for i in range(1, m + 1):
 for j in range(1, m // i + 1):
 for k in range(1, m // i + 1):
 ans = (ans + mu[j] * mu[k] * f[j * i][k * i]) % MOD
return ans

（弹幕：三重循环？但 j 只到 m//i，实际跑不了多少次）（弹幕：莫比乌斯函数：我是一把筛子，专筛倍数，精准到微克）（弹幕：mu[j]*mu[k] 就是容斥的开关，把倍数层层剥掉）（弹幕：f 表里混着 (g1,2g1,3g1…) 的方案，μ 全给筛干净了）

老白继续：到这里还能挺住的朋友，你们是真正的勇士！

这最后一步的逻辑，说白了就是：f[g1][g2] 装着所有 (g1的倍数, g2的倍数) 的方案。现在我只想要恰好等于 g 的方案。怎么筛？莫比乌斯函数 μ 自带正负号，按倍数关系一乘一累加，多余的倍数层自动抵消，剩下的就是恰好那层。这就像用一张精密筛网，把所有粗颗粒滤掉，只留你想要的那一粒金沙。

整个过程，没有 dp 数组，没有 for num in nums 的主循环，甚至看不到“子序列”三个字。因为五号选手用组合数学，把子序列选择的排列组合一口吞进了指数里；又用莫比乌斯反演，把容斥的脏活累活全自动化了。复杂度？时间 O(m² log m) 级别，m=200 的时候比前面几位还快；空间 O(m²)，几张表就搞定。

AC 图标，第五次亮起——全环形竞技场上炸出金色烟花，飘下一串串数学符号——弹幕池瞬间被同一个符号刷屏：

（弹幕：μ μ μ μ μ）（弹幕：μ门永存）（弹幕：今天不是算法竞技场，是《走近科学》数论特辑）（弹幕：看完我大受震撼，感觉自己学了算法，又好像学了数学，又好像啥也没学）（弹幕：老白，下一期能不能来点阳间题，我的脑细胞阵亡了百分之九十）

伤害统计 & 赛后锐评

老白擦汗：看到这里，如果你还没有退出直播间——你是条汉子！今天的 EP03，咱们从正向 DP 的步步为营，一路杀到莫比乌斯反演的公式碾压。能跟到最后的，都是算法界的散仙！

导播，切数据面板！

选手	流派	核心操作	时间复杂度	空间复杂度	骚气指数	推荐场景	结果
一号	历史累积 DP	正向推送，老实 `+=` 记账	O(n·m²)	O(n·m²)	⭐⭐	面试求生	✅AC
二号	滚动数组	空间压缩，双缓冲轮换	O(n·m²)	O(m²)	⭐⭐⭐	内存敏感	✅AC
三号	递归 DFS	倒着问路，`@cache` 兜底	O(n·m²)	O(n·m²)	⭐⭐⭐⭐	快速原型	✅AC
四号	期望 DP	反向拉取，`=` 一把梭	O(n·m²)	O(n·m²)	⭐⭐⭐⭐	对称思维练习	✅AC
五号	倍数容斥	莫比乌斯反演，公式碾压	O(m² log m)	O(m²)	⭐⭐⭐⭐⭐	数学系炸鱼	✅AC

（弹幕：最稳妥的还是正向 DP，不容易错）（弹幕：不仅公式帅，速度还快，五号真的是人吗）（弹幕：空间从三维砍到二维，时间从八百万次砍到几十万次！）（弹幕：O(m² log m) 在 m=200 的时候就跑几十万次，比八百万次快了不止一个量级）（弹幕：全场最佳：莫比乌斯，输出全靠公式）

老白的出装推荐——请选择你的英雄：

面试求生：选一号历史累积 DP。逻辑直白，边界清晰，面试官一秒看懂你在干嘛。写出来就是“我基本功扎实”的无声宣言。稳，才是面试的第一生产力。
面试官追问“能优化吗”：掏出二号滚动数组。把 O(n·m²) 的空间一刀砍成 O(m²)，面试官当场在心里给你加分。“这个候选人，有工程意识。”
想秀递归思维：亮三号递归 DFS。代码短，@cache 一行封神，Python 玩家看了直呼内行。但记得搞清楚“从终点往回问”的状态定义，否则面试官会以为你在背题。
理解 DP 本质：把四号期望 DP 写出来。一旦你同时掌握了“推送”和“拉取”两种转移姿势，DP 在你眼里就不再是玄学，而是双向奔赴的对称艺术。
周赛装逼 / 数论专精：掏出五号倍数容斥。代码短、跑得快、数学味儿冲破天际，队友会以为你开了天眼。

（弹幕：这题 M=200 所以我选 DP，要是 M=1e5 我就跪着抄容斥）（弹幕：我选第六种：CV 大法，复制粘贴一把梭）（弹幕：一号和二号最实用，三号和四号最好玩，五号最吓人）（弹幕：今天不是算法竞技场，是《算法博物馆》开馆日）

尾声：

好了，今天的「算法竞技场 EP03」到此全部打板收工！这题的五个解法，就像 RPG 里的五种职业，各有神通。觉得这期让你对 DP 和容斥有了新的理解，把 “我全都要” 打在公屏上！Bug 清零，Offer 拿到手软，GCD 永远等于你期望的那个数。我是老白，在 EP04 的副本门口蹲你，咱们下期见！

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode1331 算法竞技场EP01：哈希流稳如老狗，二分流帅到飞起，你pick谁？

Sun, 12 Jul 2026 20:05:52 +0800

算法竞技场EP01：哈希流稳如老狗，二分流帅到飞起，你pick谁？

欢迎来到「算法竞技场」的直播间！我是你们的主播——老白。今天咱们不聊3A大作，来刷一个经典副本：LeetCode 1331：数组序号转换。（弹幕：大师又在水题！）

别急别急，这副本看似新手村教学，但里面藏着一个专门坑害萌新的超时诅咒。今天的解说，我就带大家看看三位玩家分别是怎么挑战的——有人开场就被秒，有人无伤通关，还有人秀得BOSS头皮发麻。

任务简报

给你一个数组 arr，把每个元素替换成它排序后的名次。
规则：数字越大名次越大，相同数字名次相同，名次从1开始，且尽可能小。

案例怪物：[40, 10, 20, 30]
排序去重后的实力榜：[10, 20, 30, 40] → 名次 [1, 2, 3, 4]
输出：[4, 1, 2, 3]

一号选手·暴力一行流

好的，一位萌新选手率先冲了上去！他掏出了一卷极其华丽的代码卷轴！

return [sorted(set(arr)).index(i) + 1 for i in arr]

观众们，一行流，极简美学！——但是，画面卡住了！加载圆圈转个不停，然后一个巨大的 TLE 砸在屏幕上，直接把萌新选手送回了复活点。

（弹幕：帅不过三秒哈哈哈）（弹幕：经典超时，我上次这么死还是在上次）（弹幕：老师：我不是说一行不好，但你这一行里藏了个O(n²)的炸弹）

导播，麻烦给个慢镜头：

sorted(set(arr)) 放在列表推导式里，每次循环都重新排列整个怪物图鉴！
.index(i) 又是从图鉴第一个开始挨个点名，线性大海捞针。

这就好比你在副本里，每砍一只小怪，都要把整个地图的怪物重新清点一遍，再从地图入口跑到它面前确认位置。时间复杂度爆炸成 O(n² log n)——BOSS还没见到呢，先把自己跑死了。

结论：这卷轴是诅咒道具，捡到请直接销毁。

二号选手·哈希圣光

接下来上场的是经验丰富的老玩家。他抬手就是一个 哈希映射·圣光护符！

def arrayRankTransform(arr: List[int]) -> List[int]:
 sorted_unique = sorted(set(arr)) # 一次排序，世界清净
 rank_map = {v:i for i,v in enumerate(sorted_unique,1)} # 人手一张名次卡
 return [rank_map[v] for v in arr] # 瞬移贴标签，德芙都没我丝滑

观众们，看这波操作！他先花 O(n log n) 的代价，一次性把怪物实力榜排好，给每个怪物发了名次卡片。然后拿着卡片直接 O(1) 瞬移贴标签，全程没有被诅咒摸到一下，完美通关！

数据面板：

排序耗时 O(n log n) （一次性投资，终身受益）
建表耗时：O(n) （给每个怪物发身份证）
查表总耗时 O(n) （O(1)查询就是爽）
总伤害 O(n log n)，BOSS直接融化，AC到手。

（弹幕：教练我想学这个）（弹幕：学会了，这就去和面试官对线，让他知道什么叫专业）（弹幕：哈希表YYDS！字典才是真神！）

这一套连招，逻辑清晰、性能拉满、面试官最爱，拿到任何场上都稳如老狗。

三号选手·二分飞刀

最后登场的，是职业选手的操作秀——他从怀里掏出了一柄寒光闪闪的 二分飞刀！

from bisect import bisect_left

def arrayRankTransform(arr: List[int]) -> List[int]:
 sorted_unique = sorted(set(arr))
 # 咻咻咻，二分飞刀连斩
 return [bisect_left(sorted_unique, val) + 1 for val in arr]

看这飞刀轨迹！——bisect_left 在有序列表里用折半查找，每次定位都是 O(log n)，砍掉一半搜索空间！虽然单次没圣光 O(1) 快，但这飞刀是C语言淬炼过的，常数因子极小，整套连招如德芙般纵享丝滑。

同样 O(n log n) 的DPS，但职业选手就是偏爱这种肌肉记忆般的微操。当你需要反复在同一个有序列表里搜索时，这招就是你的本命飞刀。

（弹幕：帅是一辈子的事）
（弹幕：不会二分不配叫玩家）（弹幕：面试的时候用这招，面试官眼睛都亮了）

伤害统计 & 出装推荐

选手	出装	单次查询	总伤害	结果
萌新	暴力一行流	O(m) 大海捞针	O(n² log n)	TLE 暴毙
老玩家	哈希圣光	O(1) 瞬移贴标	O(n log n)	AC 完美
职业哥	二分飞刀	O(log n) 飞刀斩	O(n log n)	AC 帅气

（弹幕：哈希：你负责帅，我负责赢，分工明确！）（弹幕：大师，能把第一行代码从我大脑里删除吗？这玩意儿有毒！）（弹幕：我选第四种：CV大法，复制粘贴永不过时）（弹幕：学到了学到了，这就去刷十道题巩固一下）

老白的出装推荐（敲黑板！）

打排位上分/面试对线，请用 哈希圣光，朴实无华且枯燥地赢。（面试官：“你的代码风格很稳健啊。"）
匹配局想秀/Code Review装逼，掏出 二分飞刀，把击杀镜头录下来发集锦。（同事：“卧槽，你这代码有点东西啊！"）
至于那个一行流卷轴……放仓库角落当纪念吧，提醒自己：不是所有一行代码都叫优雅。

好了，今天的「算法竞技场」直播就到这里！觉得过瘾的把 666 打在公屏上！（虽然我看不到哈哈哈）。我是老白，要继续去下个副本浪了，咱们野区再见！

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode2685 策划：组队才有加成！图论：单节点也是完全图

Sat, 11 Jul 2026 20:05:22 +0800

策划：组队才有加成！图论：单节点也是完全图

作为某氪金手游的掉落算法工程师，你的日常就是在概率和期望之间走钢丝，确保氪佬满意、白嫖党不至于删游、策划的 KPI 刚刚好。今天一大早，策划就带着一脸"我有好主意"的表情晃到你工位前。

“我们要搞个’固定队额外掉落加成系统！同一个队的人，如果彼此都配合过，就给他们额外的橙色装备掉率！”策划激情澎湃地比划，“这样玩家就会自发社交，我们的日活数据就好看了！”

你觉得这逻辑有点离谱——什么叫’彼此都配合过’？策划挠了挠头：“嗯…就是队里每两个人都至少组过一次队，而且队伍是封闭的，不能有外人掺和。比如你和 A 打过，A 和 B 打过，那你和 B 也必须打过。懂了没？”

你差点一口老血喷在键盘上。这不就是让你在玩家组队记录构成的无向图里，找出所有完全连通分量吗？！换句话说，就是一群既“全连接”又“绝对自闭”的玩家小圈子。你试图解释：“所以你想统计的就是图中的完全连通——”

但策划显然没耐心听你科普：“完全什么？不用给我整术语，反正你把数字给我就行，下周公会战活动要用。”

你叹了口气，想把策划丢进副本当BOSS刷。但KPI在手，你只能硬着头皮打开玩家组队记录的数据库：

n 个玩家，编号 0 到 n-1 edges 里是一条条组队记录——表示两个玩家曾经一起下过本

你的任务，就是在这张图里找出所有"完美固定队"的数量。

完美固定队的鉴定公式

首先明确问题本质：玩家们形成一个个封闭的小圈子——连通分量；圈子里任意两人都组过队——这个分量是一张完全图。你要找的，就是图中既是连通分量又是完全图的子图——完全连通分量。

好在大脑深处的图论存档还没完全坏道。关于完全图，大学老师那句刻进 DNA 的话自动弹了出来：

“一个有 k 个节点的完全图，恰好有 k × (k - 1) / 2 条边。”

道理也很简单，就是个等差数列求和。在一个 k 人完美固定队里，第一个人要和其余 k-1 人组队，第二个人再和剩下的 k-2 人组队（和第一个已经算过了），依此类推，最后一对是倒数第二人和最后一人。总组队次数就是：

(k-1) + (k-2) + (k-3) + … + 2 + 1 = k × (k - 1) / 2

如果少一条边，说明队伍里有两人从来没有配合过——这是策划口中的“塑料固定队”，不配拿加成。鉴定标准无比清晰：一个连通分量要成为完美连通分量，它的成员数 k 和内部边数必须满足 实际边数 = k × (k - 1) / 2。

理论就位，接下来要考虑的只有一件事——怎么在图上又快又稳地揪出所有小团体，然后验一验它们内部的边数有没有达标。

并查集：先把队伍圈出来

你习惯性地掏出祖传的并查集——这玩意儿专治各种连通性问题。先把所有一起打过本的玩家合并成一个个“潜在固定队”，然后再逐个验身——看每个队伍内部的边数是否满足完全图公式。

并查集的合并逻辑很朴素：遍历 edges，把每条边的两个节点 union 到一起。为了给策划留点面子，你还在合并时加了按秩合并——让老队伍当队长（秩高的当根节点），避免队伍层级太深，传话传半天（find操作变慢）。路径压缩顺手加上，下次查找队长时直接 O(1)。

parent = list(range(n)) # 初始化：每个人都是自己的队长
rank = [0] * n # 队伍等级：新队伍都是1级

def find(x):
 while parent[x] != x:
 parent[x] = parent[parent[x]] # 路径压缩
 x = parent[x]
 return x

def union(x, y):
 px, py = find(x), find(y)
 if px == py:
 return
 # 按秩合并：等级高的当队长
 if rank[px] < rank[py]:
 px, py = py, px
 parent[py] = px # 小队伍并入大队伍
 if rank[px] == rank[py]:
 rank[px] += 1 # 平级时，被挂靠的队长升一级

for u, v in edges:
 union(u, v)

队伍分好了，接下来就是简单的统计了：

数人头：每个队伍有多少玩家数配合次数：每个队伍打过多少次配合（边数）

你写了两个循环，分别输出每个队伍内部的玩家数和边数，再用个循环，把每个队伍和理论值 k * (k - 1) / 2 比对，如果一个队伍有 k 个人，内部边数恰好等于 k × (k - 1) / 2，那它就是完美固定队，计数加一。

# 统计每个队伍的玩家数
block_nodes = {}
for i in range(n):
 root = find(i)
 block_nodes[root] = block_nodes.get(root, 0) + 1

# 统计每个队伍的边数
block_edges = {}
for u, v in edges:
 root = find(u)
 block_edges[root] = block_edges.get(root, 0) + 1

# 数学鉴定
ans = 0
for root in block_nodes:
 v = block_nodes[root] # 队伍人数
 e = block_edges.get(root, 0) # 实际配合次数
 if e == v * (v - 1) // 2:
 ans += 1

return ans

虽然今天的数据范围不算大，但“先合并再逐个检查组内边数”这套流程总让你觉得多跑了一趟——合并完之后要回头遍历所有边来统计内部边数，等于把图扫了两遍。

明明在合并的时候就能顺便统计的东西，为什么要分两趟？你决定换一种更利落的姿势。

DFS：一脚踩到底，顺手记总账

思路非常直球：从每个没被访问过的节点出发，用 DFS 把整个连通分量一次性趟完。跑的过程中，你手里捏着两个计数器：V 记录这个小团体里有多少活人，E 记录所有人通讯录里的好友总数（图论术语叫“度数之和”，但你更愿意叫它“社交牛逼指数总和”）。

一个 V 人的完美固定队，内部应该有 V×(V-1)/2 条边。但 DFS 在统计的时候，每踩到一个节点就把它的全部好友数往 E 里加——每条边两端的人都会记一次，所以 E 里攒下的是边数的两倍。换句话说，对于真正的自闭全连接小队，E 应该恰好等于 V×(V-1)。

这个判定妙就妙在它同时验了两件事：如果 E < V×(V-1)，说明队内边数不够，有人互不认识，是塑料固定队；如果 E > V×(V-1)，说明有人偷偷和队外的人组队，社交海王实锤，团队不“自闭”。只有不多不少刚刚好，才算完美。

def countCompleteComponents(n: int, edges: List[List[int]]) -> int:
 g = [[] for _ in range(n)]
 for u, v in edges:
 g[u].append(v)
 g[v].append(u)

 visited = [False] * n

 def dfs(u):
 nonlocal V, E
 V += 1
 E += len(g[u])
 visited[u] = True
 for v in g[u]:
 if not visited[v]:
 dfs(v)

 ans = 0
 for i in range(n):
 if not visited[i]:
 V = E = 0
 dfs(i)
 if E == V * (V - 1):
 ans += 1

 return ans

一个 visited 数组管住所有节点，每次发车就新建一个栈，把起点塞进去，然后开始深挖。没有回头路，没有二次统计，搜完一块就扔一块，栈弹出最后一个节点时结论已经落地。时间复杂度 O(n+m)，空间 O(n+m)，比并查集少了一轮“遍历所有边归类”的扫尾工作。

尾声

你把全服完美固定队的数量打包发给策划：“统计完毕，名单见附件。这些队伍内部人人配合过，对外绝不多看，可以放心发额外掉落buff。”

策划秒回：“等等，你名单里怎么还有一堆单人队？一个人也算固定队？”

“单人成军，也算完美团队。”你淡定地解释，“毕竟一个人不需要配合任何人，从逻辑上来说确实是‘全连接’的——没有内部缺失的边，也没有外部社交，完美满足所有条件。”

策划沉默了好几秒：“……那白嫖党一个人刷本也能享受额外加成？”

你端起冰美式，敲下回复：“数学上是的。你设计的是社交激励系统，但图论不管这些——单点，也是一种完美。”

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3534 排序破随机，倍增压长途——传送门最短距离的 O(n log n) 绝杀

Fri, 10 Jul 2026 14:44:50 +0800

排序破随机，倍增压长途——传送门最短距离的 O(n log n) 绝杀

前情提要

《数字大陆》的策划上次被你一句“图论是障眼法，数组才是本体”打击得不轻。据说那天下午，他一个人坐在会议室里，盯着美术画了三天的传送门网络图发了整整半小时呆。

今天，他重新出现在你桌边，眼圈比昨天深了两个色号：“上次那个需求——” 他清了清嗓子，“确实……稍微简单了一点。”

你抬头看了他一眼。

策划迅速补充：“但这次不一样！这次我认真设计了！”

他“啪”地把一份新需求拍在桌上——新版本里，勇者试炼不再是一条规规矩矩的战力长廊。策划吸取了你的建议，把所有关卡彻底打乱：编号 0 的可能是灭世魔龙，编号 1 的可能是史莱姆，编号 2 又可能是深渊领主。总之，怪物战力 nums[i] 和关卡编号再也没有任何顺序关系。

传送门的生成规则倒是没变：

如果两个关卡的怪物战力之差不超过 maxDiff，它们之间就会生成一条双向传送门。

你点了点头：“所以还是查询两个节点是否连通？”

“不。” 策划脸上露出了“这次你总不能秒杀了吧”的笑容，“现在玩家不仅要知道能不能到，还要知道最少经过几扇传送门。”

他指着需求文档上的一行加粗文字：

对于每个查询 [u, v]，返回节点 u 到节点 v 的最短距离；如果无法到达，则返回 -1。

“玩家现在很讲究效率。”策划解释道，“萌新想少过几次加载界面，肝帝想研究最短刷图路线，速通玩家则表示多传送一次都是对世界纪录的侮辱。”

你沉默了两秒。

策划得意地抱起胳膊：“怎么样？这次总得老老实实建图跑最短路了吧？”

你没有回答，只是低头看向数据范围。

每次 BFS？服务器听完连夜跑路

最直接的方案确实是建图——对于所有节点对 (i, j)，如果满足|nums[i] - nums[j]| <= maxDiff，就在它们之间连一条无向边。图建好之后，每条查询从 u 出发跑一次标准 BFS，第一次到达 v 时的层数就是最短距离。

理论很标准，代码很正统，复杂度更是十分感人——n ≤ 10⁵，暴力枚举节点对建图就是 O(n²)，更要命的是，如果大量节点的战力值都很接近，这张图会趋近于一张完全图，边数同样直冲 O(n²)，然后你还要在这个庞然大物上跑10⁵次 BFS——这已经不只是超时的问题了，你的开发机会在按下回车的瞬间火箭式升温，公司当月的电费账单上会单独列一行你的名字。

你赶紧把“建完全图 + 全量 BFS”的方案丢进脑海中的回收站，顺手清空以防自己手贱还原。

数据范围不会说谎——n 和 queries 都是 10⁵ 级别，这意味着你需要 O(n log n) 以内的预处理，和 O(1) 或 O(log n) 的单次查询。

编号是乱的，但可以重新排队

策划只说 nums 没有排序，又没说我们不能自己排。

虽然策划把关卡编号搅成了一锅粥：0 号位蹲着战力 99999 的灭世魔龙，1 号位是战力 5 的史莱姆幼儿园，2 号位又变成战力 50 的精英怪，主打一个精神分裂式排列。但他忘了一条基本法——传送门只认战力差——战力值才是真正决定谁和谁能互相串门的社交属性。

你脑子里冒出一个非常自然的想法：

“那我把它们按战力重新排个队不就行了？”

于是，你祭出排序大法。把所有节点按战力从小到大排好，再用一个 pos 数组记下每个原节点排序后去了哪个新位置——毕竟查询给你的还是原来的编号 [u, v]。

# 按战力排序，order[k] 表示排序后第 k 个位置对应的原节点
idx = sorted(range(n), key=lambda i: nums[i])

# values：排序后的战力数组
values = [nums[node] for node in idx]

# pos[node]：原节点 node 在排序后数组里所在的位置
pos = [0] * n
for rank, node in enumerate(idx):
 pos[node] = rank

例如，原来的节点顺序是：

节点编号： 0 1 2
战力值： 99999 5 50

排序后就变成：

排序位置： 0 1 2
原节点： 1 2 0
战力值： 5 50 99999

于是：

pos[1] = 0
pos[2] = 1
pos[0] = 2

现在，任意原始查询 [u, v] 只需要做一次“花名册翻译”：

l, r = pos[u], pos[v]
if l > r:
 l, r = r, l

这么一来，原本被策划打乱的关卡，又按照战力整整齐齐地站成了一排。战力相近的节点重新成为邻居，昨天那条熟悉的副本长廊仿佛又回来了。

贪心+双指针：给每个关卡测量最大传送距离

“能一步跳得更远，为什么要故意跳近？”

你重新审视排序后的战力数组：对于位置 i，如果它能直接跳到右侧某个位置 j（即 values[j] - values[i] <= maxDiff），那么夹在 i 和 j 之间的所有位置，i 也全都能一步到达。

原因很朴素——数组 values 已经有序，values[i] <= values[k] <= values[j]，战力差只会更小，传送门全部畅通。也就是说，每个节点向右能直接到达的节点，一定构成一段连续区间，绝不会有“能跳到第 5 关却跳不到第 3 关”的玄学bug。

盯着这条性质，你很快想到——既然目标是找最短距离，那么对于这张看似边数爆炸的图，你根本不需要记每个节点 i 具体能跳到中间哪些位置，只需要记一个——从这里出发，一步最远能跳到哪个位置？ 剩下的全在射程之内，多记一笔都是对内存的不尊重。

你给这个最远位置起了个名字叫 farthest[i]。对于每个节点 i，找到最大的 j，使得 values[j] - values[i] <= maxDiff。因为 values 已经有序，当 i 向右移动时，满足条件的最右j也只会单调右移，不会回缩。一枚滑动窗口，左指针推着右指针走，O(n) 时间就能把整个 farthest 数组填满。

right = 0
for left in range(n):
 right = max(right, left)
 while (right + 1 < n and values[right + 1] - values[left] <= maxDiff):
 right += 1
 farthest[left] = right # f[i] = 从 i 跳 1 步能到达的最右位置

不过，久经沙场的你意识到一个问题——如果想知道从节点 0 到节点 12 最少要几步，难道要老老实实模拟“跳一步 → 看落点 → 再跳一步 → 再看落点 → …”？！

单次查询还好说，最坏情况下每次只往右挪一格，跳完一整条长廊需要 O(n) 步。但外面有十万次查询正排着队，O(n) 乘十万就是 O(n²) ，复杂度的噩梦换了件马甲又来了。

你把冰美式往桌上重重一顿——你需要一种更聪明的“跳步”技巧。

倍增：给传送技能装上连招系统

你靠在椅背上，盯着那条战力曲线和 farthest 数组，脑子里翻出了压箱底的老伙计——倍增。这个名字听起来像健身房术语，但它的核心思想非常炫酷：

与其一步一步数着传送次数往前挪，不如提前算好“跳 1 步最远到哪、跳 2 步最远到哪、跳 4 步最远到哪、跳 8 步最远到哪……”，把这些结果存成一张速查表。查询的时候从大步开始试，能跨一大步绝不碎步挪，用对数级的时间把距离凑出来。

就像 RPG 里赶路——能骑飞龙绝不下地跑，能开传送阵绝不腿着去。你现在的任务，就是给每个节点建一张“飞龙航班表”。

前面你已经拿到了跳一步（2⁰ = 1）的最远射程 farthest[i][0]。现在想知道多步能跳多远？很简单：两步就是一步再一步、四步就是两步再两步……状态转移直接得就像在技能树上点“二段跳”天赋——从 i 跳 2^k 步，可以先跳 2^(k-1) 步到一个中间落脚点，再从那里接着跳 2^(k-1) 步。两段接力，步数翻倍，射程指数级爆炸。

于是你重新定义了一张二维表 farthest[i][k]：表示从位置 i 出发，跳 2^k 步之后最远能到达的位置。递推公式一行搞定farthest[i][k] = farthest[ farthest[i][k-1] ][k-1]：

k = 0 是跳 1 步（2⁰ = 1）：就是刚才算的一步最远射程 farthest，每个节点一步能直接传送到的最关关卡。
k = 1 是跳 2 步（2¹ = 2）：先从 i 跳一步到 farthest[i][0]，再从这个落点跳一步到 farthest[ farthest[i][0] ][0]。两步接力，就是从 i 出发跳两步能覆盖的最远范围。
k = 2 是跳 4 步：先跳两步到 farthest[i][1]，再从那里跳两步到 farthest[ farthest[i][1] ][1]。以此类推。

m = (n).bit_length() # m=log2(n)+1，表示倍增的最大层数；如n=5时，m=3，表示最多可以跳2^2=4步
farthest = [[0] * m for _ in range(n)]

# k = 0：一步最远射程（双指针滑动窗口）
right = 0
for left in range(n):
 right = max(right, left)
 while (right + 1 < n and values[right + 1] - values[left] <= maxDiff ):
 right += 1
 farthest[left][0] = right # f[i][0] = 从 i 跳 1 步能到达的最右位置

# k >= 1：两段拼接，指数级扩展
for k in range(1, m):
 for i in range(n):
 farthest[i][k] = farthest[farthest[i][k-1] ][k-1]
 # 状态转移方程：从i跳2^j步 = 先从i跳2^(j-1)步到中间点，再从中间点跳2^(j-1)步

建完这张表，你感觉自己像个在机房里偷偷装加速器的网管——每个节点现在都自带一张“飞龙航班时刻表”，从跳 1 步到跳 2^k 步的最远落点，一查就有。

查询：从大步开始试，能跨一大步绝不碎步挪

表建好了，真正的表演现在开始。

对于每个查询 [l, r]（已经转换成排序后的新位置，且保证 l <= r），你要回答从 l 出发，最少跳几步能到达或越过 r。

策略就是贪心 + 倒序枚举——从最大的 k 开始往下试：如果从当前位置跳 2^k 步还够不着 r（即 farthest[cur][k] < r），那就毫不犹豫把这 2^k 步全吞下去——当前位置更新为 farthest[cur][k]，步数累加 2^k。

因为 k 是从大到小枚举的，每次跳跃都是“在不越过的前提下能跨的最大步”，就像玩大富翁掷骰子，先看看能不能掷出 8 步，不行再退而求其次试 4 步、2 步、1 步。用最少的次数逼近终点。

当所有 k 都试完，你的当前位置 cur 已经停在了 r 之前或恰好等于 r。如果 cur == r，说明刚好到站，当前累加的步数就是答案。如果 cur < r，说明还需要最后一跳——检查 farthest[cur][0] 能不能覆盖 r。如果能，步数加一，返回答案；如果不能，说明 r 在当前位置的最远射程之外，它俩中间有道断崖，返回 -1。

res = []

for u, v in queries:
 l, r = pos[u], pos[v] # 将原始节点编号转换为排序后的排名
 if l > r:
 l, r = r, l # 保证 l <= r，因为我们只关心从左到右的距离
 if l == r:
 res.append(0) # 特殊情况：同一个节点，距离为0
 continue
 step = 0
 for i in range(m - 1, -1, -1):
 if farthest[l][i] < r:
 l = farthest[l][i] # 没到r，执行这次跳跃
 step += 1 << i # 累加实际跳跃步数（2^i步！）

 if farthest[l][0] >= r: # 到达或超过r
 res.append(step + 1) # 把最后1步加上
 else:
 res.append(-1) # 无法到达，不连通

return res

双指针扫 farthest，倍增建表，倒序贪心查询。三步环环相扣，把一张被策划搅乱编号的随机图，重新拉回了 O(n log n) 的可控范围。

尾声

你把结果打包发给策划。不到一分钟，对话框就亮了起来：“这次你总建图了吧？”

“没有。”

“你跑 BFS 了？”

“也没有。”

“那最短路怎么求的？”

你想了想，回复道：“先把所有关卡按照战力重新排队。对每个关卡，只记录它一步最远能传到哪里。查询的时候，每一步都尽可能往远处跳，再用倍增一次跳 1、2、4、8…… 步。”

策划沉默了几秒：“所以我这次设计的传送网络……”

“本质上是一群站在数轴上的节点。”

“最短路……”

“本质上是跳跃游戏。”

“十万次查询……”

“本质上是倍增。”

对话框上方的“正在输入”闪了很久，最后只发来一句：“可这次 nums 明明没有排序！”

“是啊。” 你靠在椅背上，端起已经凉透的咖啡。

“你没排序，我可以自己排。”

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3532 伪图论真数组：策划想做开放世界，我却发现它只是几个连续副本区

Thu, 09 Jul 2026 12:44:26 +0800

伪图论真数组：策划想做开放世界，我却发现它只是几个连续副本区

《数字大陆》的策划最近沉迷《只狼》，连着一周每天死五十次之后，他悟了——真正的游戏就该让玩家只能往前，不能回头。于是他拍板在新版本里塞了一张叫“勇者试炼·一条路走到黑”的地图：一条从西到东笔直延伸的长廊，依次排列着 n 个副本关卡，编号 0 到 n-1。每个关卡蹲着一群怪物，战力值用 nums[i] 表示。出于“玩家不能向下碾压”的执念，这条长廊的战力被设计成非递减的——越往东怪越强。西边是战力 5 的史莱姆幼儿园，东边是战力 99999 的灭世魔龙战斗团，中间绝不会有“打完 BOSS 突然冒出三只新手村公鸡”的精神分裂体验。

今天早上，策划端着一杯冰美式准时出现在你工位旁，笑眯眯地把一份需求文档拍在你桌上。

“听我说，这个功能绝了——”他猛吸一口咖啡，“如果两个关卡的怪物战力差距不超过 maxDiff，它们之间就自动生成一条双向传送门。你想啊，战力差不多的副本之间空间稳定性最好，传送门一开，光效一炸，玩家就过去了。要是战力差太多——砰！虚空乱流！玩家直接被撕成像素碎片！我可不想被运营发邮件说‘又有玩家卡进地板了’。”

他完全不给你插嘴的机会：“还没完！我们要做个可达性检测系统。简单来说，就是判断——玩家从关卡 u 出发，能不能一路靠传送门跳到关卡 v？”。他打开了一张巨大的玩家需求表，继续说道：“毕竟现在的玩家可太会折腾了。你看，这批萌新想知道能不能偷偷传去高级区蹭经验，这群肝帝在研究哪些关卡属于同一个‘速刷联盟’。”他停顿了一下，“还有这几个家伙——专门研究怎么利用地图漏洞从新手村一路偷渡去打最终 BOSS。”

你沉默了两秒，试图用一句话终结这场需求轰炸，“明白，就是判断两个关卡在不在同一个连通分量里。”

策划眨了眨眼：“连通什么？反正你给我个布尔值就行，true 还是 false。” 说完，他露出职业策划特有的危险微笑，拍了拍你的肩膀：“放心，查询数量不多，也就十万条左右。例会前发我就行。”

第一反应：暴力建图？醒醒，你还想过试用期

你的第一反应很经典：既然 |nums[i] - nums[j]| <= maxDiff 就能连边，那我把所有满足条件的 (i, j) 对都找出来，建一张无向图，然后每次查询跑 BFS / DFS 判断是否可达，不就完事了？

你低头看向数据范围——n ≤ 10⁵ 个关卡，queries ≤ 10⁵ 次查询。好家伙，建图O(n²)，查询O(Q × N)，总复杂度10⁵ × 10⁵ = 10¹⁰——这个数字比你 Steam 库里所有游戏的累计时长换算成秒数还离谱。

“等等。” 你重新翻回需求文档。一行不起眼的信息，像 RPG 里的隐藏提示一样闪闪发光：

nums 已经按照非递减顺序排列。

这个条件绝对不是摆设。排序后的数组，就像一条从弱到强排列的副本长廊。传送门能不能开，只看相邻关卡的战力差。这就意味着这张图不是一张随意连接的蜘蛛网，而是一条被“战力断崖”切开的长链——所有连通块，都是一段一段连续的下标区间。

区域A 区域B 区域C
1--3--5--8 | 20--22 | 50--55
↑ ↑
断崖 断崖

一个隐隐约约的念头浮了上来——这是利用有序性，把图论里的“连通问题”，降维成区间分组问题。

破局之道：给每个区域发一个标签

既然连通块都是连续区间，那直接从左到右扫描一遍，给每个关卡贴个“连通块标签号”不就行了？对于这种线性结构，一个 tags 数组直接搞定，根本不用上并查集。

操作简单到可以写在便利贴上，再贴到策划的冰美式杯子上：

初始时 tags[0] = 0，第一个节点属于第 0 号连通块。然后从 i = 1 开始往右扫描：

如果 nums[i] - nums[i-1] > maxDiff，说明这里有个断崖，tags[i] = tags[i-1] + 1——新开一个连通块，换张新标签。
否则，tags[i] = tags[i-1]——和前一个节点同一个连通块，沿用旧标签。

扫完一遍之后，同一连通块内的所有节点连通块标签相同，不同连通块的标签绝对不同。任意查询 [u, v] 就是 O(1) 的判断：tags[u] == tags[v]？相等就是一家人，传送随便开；不等就是中间隔了断崖，虚空乱流警告。

def pathExistenceQueries(n: int, nums: List[int], maxDiff: int, queries: List[List[int]]) -> List[bool]:
 tags = [0] * n
 for i in range(1, n):
 tags[i] = tags[i-1] + (nums[i] - nums[i-1] > maxDiff)
 return [tags[r] == tags[l] for l, r in queries]

没有嵌套循环，没有图遍历，没有递归。一次单调扫描 O(n)，每个查询 O(1)，总复杂度 O(n + q)。策划的十万条查询，在 tags 数组面前不过是把同一个 == 判断十万遍。

尾声：

你把结果打包发给策划，对面秒回：“这么快？你建好图了？”

你靠在椅背上打字：“没建图。你这张图里所有的传送门，本质上就是把战力相近的相邻关卡串成一条链。中间那些战力差太大的地方自然断开，形成几个连续区域。”

策划那边沉默了几秒，然后弹出来一行字：“所以……我画了一堆传送门的连线图，还让美术做了三天特效。结果你告诉我，它就是几个连续区间？”

“对。一条长廊，几道断崖，几张标签。同一张标签随便走，不同标签过不去。”

你顿了顿，决定补一刀，“你设计的不是传送网络，是一段一段的连续区间。图论是障眼法，数组才是本体。”

策划又沉默了。你几乎能想象他坐在对面盯着自己的设计稿，对自己前半生设计哲学产生了怀疑。

于是你决定说点什么，语气像在安慰又像在补刀：“下次如果想让传送门真的像一张网，记得把战力值打乱，别排好序。那样我就真要建图了————不过嘛，玩家体验也会从’丝滑传送’变成’随机跳伞’，你要不要考虑一下这个平衡性~”

对话框那头终于又亮了：“……你先别走，我在写新需求。”

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3756 前缀和觉醒：十万查询瞬杀术，O(1)结印碾压群殴战场

Wed, 08 Jul 2026 12:36:45 +0800

前缀和觉醒：十万查询瞬杀术，O(1)结印碾压群殴战场

前情提要

昨天那场「单存档修复战」（3754. 连接非零数字并乘以其数字和 I）你还记得吧？磁盘坏道像一群虚空寄生虫，往玩家数据里随地大小 0。你祭出一套“纯数学流·逐位拆解连招”，平 A 带走全服第一氪佬的存档，操作秀得运维在群里连刷三个「大佬喝茶.jpg」。在你合上笔记本的瞬间，屏幕右下角又弹出运维的夺命连环消息——策划要在修复前先做一轮批量验伤，十万个查询区间，每个截子串、去零、拼接、求和、对轰，算出纯净校验码，好按损坏程度发补偿钻石。

今天早上 9:30，你端着刚冲好的咖啡坐到工位，发现运维已经 @ 了你三次：“哥，怎么样了？策划说十点半要开例会，他想在会上展示批量校验的结果。“你深吸一口气——昨天是单挑，今天是团本，平 A 清小怪的时代结束，是时候切一套群体大招了。

战场升级：从单挑到群殴

昨天的任务是这样的：

给你一个整数 n，过滤掉所有的 0，拼接成 x，计算 去零拼接x * 数字和sum。

今天的任务变成了这样：

给你一个长度为 10^5 的数字字符串 s，还有 10^5 个查询，每个查询让你处理一个子串 s[l..r]，执行和昨天一样的操作。返回所有查询的结果数组。

你心里快速拉了个复杂度：如果还用昨天的逐位拆解，每次查询都要遍历一遍子串，总复杂度 O(Q × N) = 10^5 × 10^5 = 10^10 次操作。好家伙，这个数字比你的加班时长还离谱，跑完别说十点半例会，连下个月版本更新都赶不上。你仿佛已经听见服务器风扇在悲鸣——不行，得请出「前缀和阵法」了。

破局关键：前缀和预炼化

你开始盘算：每次查询都是从原始字符串里截一段，再扫一遍做去零拼接，本质上是在重复计算——同一个位置的数字，可能被几十上百个查询区间扫过，每次都在做一模一样的事情，判断是不是零、累加数字和、去零拼接。

既然查询是海量的、区间是任意的，那为什么不提前把整条原始数据“炼化”一遍，把每个位置的关键信息预先算好、存进数组里？这样每次查询就像从数据库里查索引，O(1) 拿到中间结果，再拼装一下就能出答案。

你回想起经典的前缀和套路——算子串 [l, r] 的某个属性，往往可以用 pref[r] - pref[l-1] 的形式 O(1) 得到。比如，对于[l, r]区间内的**非零数字和 sum **，用前缀和数组 preSum[i] 表示 s[0..i-1] 中所有非零数字的和，那么 sum = preSum[r+1] - preSum[l]。O(1)，搞定。

但前缀和这个“减法”能成立，有个隐藏前提：属性必须是可加的，而且和顺序无关。

**去零拼接值 x **显然和顺序强相关。一旦区间内有零混迹其中，虽然非零数字之间的相对顺序不变，但它们中间的空位被“吃掉”了——比如 "102003" 变成 "123"，中间的零全是幽灵，2 直接跟在 1 后面，3 直接跟在 2 后面，原本隔着十万八千里的两个数字现在挨得紧紧的——零的出现会动态改变数字之间的位权关系，光靠一个前缀和数组没法直接算出 x。

你放下咖啡杯，意识到这个拼接操作才是真正的拦路虎。

关键洞察：把拼接拆成两件事

去零拼接值 x 说穿了就是一组非零数字按顺序排排坐，每个数字站在自己该站的数位上，拼成一个新的整数。写成算式就是：x = d₁ × 10^(k-1) + d₂ × 10^(k-2) + ... + dₖ × 10⁰，其中 k 是这组非零数字的总个数。每个数字的“站位”不由它在原串里的绝对位置决定，而由它在这个区间里排老几决定——前面还有几个非零数字，它就得往左挪几位。

假设整串 s 被切成三段：[0, l-1]、[l, r]、[r+1, n-1]。去零之后，这三段各自蜕变成一串纯数字。你给它们起了名字：第一段的拼接值叫 preVal[l]，第二段（我们要的那段）的拼接值叫 x，第二段里有 cnt 个非零数字，第一段加第二段合起来的拼接值叫 preVal[r+1]。

你盯着第一段和第二段去零后的连接，灵光炸裂——去零拼接操作本质上是“按序追加”（前缀 [0, l-1] 的拼接值后面，直接接上区间 [l, r] 的拼接值）。这不就是标准的“高位拼接低位”吗？第一段的拼接值往左挪 cnt 个位置（也就是乘以 10 的 cnt 次幂），腾出来的低位恰好由第二段的 x 填上：

preVal[r+1] = preVal[l] × 10^cnt + x

再赶紧把这个等式倒过来：

x = preVal[r+1] - preVal[l] × 10^cnt

这下好办了！preVal 本身从头扫到尾递推就行——遇非零数字就 preVal[i+1] = (preVal[i] × 10 + d) % MOD；cnt用一个标准的前缀和数组 preCnt 就能cnt = preCnt[r+1] - preCnt[l] O(1) 搞定；再提前预计算好 pow10 数组（pow10[cnt] 就是 10^cnt % MOD），这行公式就是 O(1) 的！

三前缀数组阵法：preSum、preVal、preCnt

你整理好一套干净利落的“三前缀数组阵法”。三个数组，各司其职，建好之后每个查询就是三次数组查找加两次算术运算，轻量得像刺客的连招：

preSum[i]——数字和总管：前 i 个字符中所有数字的和（0 不影响求和，所以等价于非零数字和）。sum = preSum[r+1] - preSum[l] 就是区间内非零数字的和，O(1) 秒出。
preVal[i]——拼接值档案库：前 i 个字符中去零拼接成的整数（对 MOD 取模）。递推规则：遇非零数字就 preVal[i+1] = (preVal[i] × 10 + d) % MOD，遇零则 preVal[i+1] = preVal[i]。它记录的是“如果从这里下刀，前面那段的拼接值是多少”，相当于给每个位置都拍了个快照。
preCnt[i]——位权修正计数器：前 i 个字符中非零数字的个数。cnt = preCnt[r+1] - preCnt[l] 就是区间内非零数字的个数，也是 preVal[l] 需要左移的位数。它管的是那个关键的 10^cnt 修正因子。

有了这三件法器，对于任意查询 [l, r]，你的施法流程直接变成一条流水线：

def sumAndMultiply(s: str, queries: List[List[int]]) -> List[int]:
 MOD = 10**9 + 7
 m = len(s)

 # 预计算 10 的幂次（pow10[k] = 10^k % MOD）
 pow10 = [1] * (m + 1)
 for i in range(1, m + 1):
 pow10[i] = (pow10[i-1] * 10) % MOD

 # 三个前缀数组
 preSum = [0] * (m + 1) # 数字和
 preVal = [0] * (m + 1) # 去零拼接值
 preCnt = [0] * (m + 1) # 非零数字个数

 for i in range(m):
 d = ord(s[i]) - 48 # 或者 int(s[i])
 preSum[i+1] = preSum[i] + d
 preCnt[i+1] = preCnt[i] + (d != 0)
 if d != 0:
 preVal[i+1] = (preVal[i] * 10 + d) % MOD
 else:
 preVal[i+1] = preVal[i]

 ans = []
 for l, r in queries:
 cnt = preCnt[r+1] - preCnt[l]
 if cnt == 0:
 ans.append(0)
 continue
 sum_val = preSum[r+1] - preSum[l]
 x = (preVal[r+1] - preVal[l] * pow10[cnt]) % MOD
 ans.append((x * sum_val) % MOD)
 return ans

你看着这段像乐高积木一样紧凑的代码，满意地往椅背上一靠。十万个查询在三个数组面前，不过是把同一套减法算术做十万遍——CPU 最不怕的就是重复劳动，让它跑去吧。

尾声

你把脚本跑完，十万条查询像开闸放水一样倾泻而过，终端上的进度条几乎没来得及显示就已经跳到 100%。从建数组到出结果，全程不到十秒，策划还没来得及在群里@你第四次。

用前缀和阵法瞬杀了十万次群殴，用空间换了时间，又让 CPU 少烧了几亿次循环。你端起那杯从九点半端到现在终于能喝一口的咖啡，温度刚好——就像 O(m) 预处理加 O(1) 查询，一切都卡在刚好的复杂度上。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3754 幽灵数据净化器：逆序拆解不反序，边界兜底不判断

Tue, 07 Jul 2026 12:50:52 +0800

幽灵数据净化器：逆序拆解不反序，边界兜底不判断

你是一名 MMO 游戏的后端开发，今天凌晨，运维给你打了个紧急电话：

“哥，数据库炸了。不是炸服的炸，是磁盘坏道——一批玩家的存档文件被物理污染了，里面混进了大量的 0 值噪声！策划说新版本明天十点上线，这些玩家的进度必须在这之前修好，修不好他就要在全员群里@你，原话是‘提头来见’。”

你揉了揉惺忪的睡眼，连上 VPN 打开日志，整个人瞬间清醒——不是因为冷，是血压。

事故现场：损坏的存档长啥样？

正常的存档应该是这样，干干净净，像个刚建号的萌新：

{
 "player_id": 12345,
 "level": 99,
 "gold": 987654,
 "equipment": [1, 2, 3, 4, 5]
}

但因为那片该死的坏道，存档被“虚空寄生虫”咬了无数口，凡是咬过的地方都变成了 0——像被格式化了半截：

{
 "player_id": 10203004, // 原本是 1234，但混进了三个 0
 "level": 1000, // 原本是 1，后面跟了三个幽灵 0
 "gold": 0, // 全损。这个玩家的金币全被磁盘吃了。
 "equipment": [1, 0, 2, 0, 3, 0, 0, 4] // 装备 ID 被噪声打成了筛子
}

你的任务，就是把这场灾难的物理损失降到最低：

数据清洗：干掉所有混进来的 0——它们是磁盘坏道的遗物，是噪声，是必须被抹除的幽灵数据。
数据重组：把幸存下来的非零数字按原始顺序拼起来，形成新数字 x。这是玩家真正的属性残片。
校验计算：算出 x 的数字和 sum，然后返回 x * sum 作为“纯净校验码”，用来给修复后的存档贴上一个能验证完整性的标签。

如果整段数据全是 0——比如"gold": 0——那说明彻底损坏，x = 0，sum = 0，返回 0。翻译成人话就是：“这档没救了，给玩家发补偿钻石，删号重练。”

字符串流的诱惑

你盯着亚瑟那个被污染的 player_id：10203004，第一反应和所有赶时间的程序员一样——字符串一把梭。

“转成字符串，把 '0' 全过滤掉，再转回整数，完事！”

但你久经沙场的第六感在你敲下回车前拉响了警报——全零存档。比如 "gold": 0，过滤完非零，字符串直接变成空串 ''。int('') 会毫不犹豫地抛出一个 ValueError，你的脚本当场炸成烟花，就像玩家在副本里把 Boss 打到 1% 血时游戏闪退一样令人抓狂。你不得不在外面裹一层 if-else 兜底，优雅度直接打八折。

return 0 if n==0 else (x := int(''.join(d for d in str(n) if d != '0'))) * sum(int(d) for d in str(x))

海象运算符 :=、生成器表达式、条件表达式，看起来非常 Pythonic。如果你只是想快速 AC，不在乎那点性能差距，这确实是 Python 玩家的终极快乐形态。

但是！ 作为一名有追求的开发，你知道在生产环境中，你可能需要处理百万级玩家的批量存档修复。这时候，每一次字符串分配、每一次类型转换，都是在浪费 CPU 周期。

能用平 A 解决的事，绝不多交一个大招。这是每个老玩家的职业素养。

纯数学流·逐位拆解连招

你深吸一口气，决定用最硬核的方式来解决这个问题——不依赖任何字符串库函数，纯靠算术运算。

def sumAndMultiply(n: int) -> int:
 x, s, pow10 = 0, 0, 1 # 三件初始装备：重组数/数字和/位权棒

 while n:
 n, d = divmod(n, 10) # 一刀切下最末位
 if d: # 非零？收编。
 x += pow10 * d # 让d站到正确的十进制位上
 s += d # 累加数字和
 pow10 *= 10 # 位权左移，给下一位腾位置

 return x * s # 纯净校验码

divmod(n, 10)——双刀流：一次运算同时拿到商和余数。在 CPython 底层，divmod 被编译成单条 CPU 指令，比分两行写 n // 10 和 n % 10 更快，而且语义干净利落：“把这个数给我拆成头和尾。”

pow10——动态位权棒：因为是从个位往高位拆，先剥出来的 d 其实是原数字的末位，直接拼会反序。pow10 像个不断左移的阶梯：个位数站 1 的阶梯上，十位数站 10 的阶梯上，百位数站 100 的阶梯上……无论你从哪头拆，最终的 x 都保持着原始顺序。这是纯数学流最精妙的设定——逆序拆解，正序重生。

边界自动兜底：如果 n = 0，while 循环一次都不执行，x = 0，s = 0，返回 0。不需要任何额外的 if-else 判断——逻辑本身就覆盖了全损存档的情况。符合你一贯朴素的错误处理哲学：最好的防御，是让漏洞根本不存在。

时间复杂度：O(log n)。一个十进制数 n 大约有 log₁₀ n 位，只遍历一次，每位常数时间操作。就算 n 顶到 10⁹，循环也才跑十次。空间复杂度：O(1)，全程只用了三个变量 x、s、pow10。

全程零字符串、零类型转换。没有临时字符串对象在堆里蹦迪，没有 str 与 int 之间的反复横跳，一切计算都在整数域内完成。处理百万级存档时，内存分配次数从“每条三次”直接归零，CPU 缓存命中率高得就像开了自瞄挂。

更骚的是，策划明天如果要改需求——“把过滤条件换成排除偶数”，你改一行：if d % 2 == 1。“还要顺便算个平均值”，加个计数器。“支持十六进制存档”，把 10 改成 16 就完事。纯数学流的架构就像一把能自由换刀片的美工刀，换个刀头只需要拧一下，绝不伤筋动骨。

进阶预告：LeetCode 3756 (II 版本) 的海量查询挑战**

你刚把亚瑟的存档修好，运维的消息又弹出来了，这次带着一种“我知道你要骂我但我还是要说”的语气：

“哥，干得漂亮！但策划刚紧急通知——在修复之前，先对所有损坏数据的各个子串区间做一波批量校验。他要根据每个玩家不同部位的损坏程度，决定补偿钻石的档位。十万个查询区间，五分钟后给结果。”

你盯着屏幕，沉默了三秒。当查询多到能碾碎 CPU 时，这场战斗已经从“单挑”升级成了“群殴”——如果每次查询都从头拆一遍数字，O(Q × log N)，Q = 10⁵，`N = 10⁵——等于用平 A 去打十万只怪，手速再快也要打到地老天荒。

你需要一个更强大的方案：前缀和预炼化。把整条原始数据提前预处理，让每次查询不用从头拆，而是直接取现成的结果——信条只有八个字：提前炼化，查询瞬发。

你把亚瑟的存档文件往旁边一推，平 A 已经不够用了，是时候换一套群体输出了。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode1288 一刀流·区间清理术：排序定乾坤，贪心斩冗余

Mon, 06 Jul 2026 10:42:26 +0800

🎮一刀流·区间清理术：排序定乾坤，贪心斩冗余

你是一名区间猎人，猎头公会甩给你一张悬赏令：清理一批“地图上的套娃区间”。

什么叫套娃区间？就是那些被其他区间完全罩住的倒霉蛋——比如 [3,6) 被 [2,8) 包得像俄罗斯套娃里的那个小娃娃，存在的唯一价值，就是被外面的老大哥代表。这种区间在地图里纯属“占着茅坑不拉屎”——明明霸着一组坐标，实际控制面积为零，纯粹浪费数据空间。不清理掉的话，策划又要开喷了：“你们的边界数据比我昨晚吃的麻辣烫还杂乱！”

你的任务很直白：数数清理完还剩多少个“独当一面的有效区间”。注意，不是让你真的一刀一刀删——数组这玩意儿，中间删一个元素，后面的编号全得往前挪一位，复杂度堪比主城开服时玩家挤传送阵。你只需要优雅地统计出“幸存者”的数量，然后把悬赏令拍回公会的桌子上，领赏走人。

但问题来了：你怎么知道哪个区间被当了套娃？暴力两两对比？拿每个区间去和全图所有区间单挑？O(n²) 的复杂度会让你的CPU 会觉得你在羞辱它。

你冷笑一声，从背后抽出一把泛着幽蓝暗光的太刀——排序之刃。刀身上刻着一行附魔铭文：

lambda x: (x[0], -x[1])

这把刀的排序法则简单粗暴：

主属性：按左端点升序排——谁左边起步更早，谁站前面。江湖规矩，先到先得。
副属性：如果左端点撞车了，按右端点降序排——谁地盘更大、谁罩得更远，谁就当大哥，站C位。

队友从后排探出脑袋：“哥，为啥右端点要降序？升序不是也挺整齐？我这强迫症看得浑身刺挠！”

你手腕一翻，刀锋在空中划出一道银弧，映出你半张冷峻的脸。你淡淡地吐出几个字：

“为了让罩得最远的大哥先出场。大哥站前面，后面那些小弟一旦被大哥的地盘完全包住，我连刀都不用抬，看一眼就知道它是套娃。装逼要装全套，排序也要有兵法——这叫先发制人，后发制于人。”

你拔出排序之刃，刀尖指天，念出一段古老的咒语：

intervals.sort(key=lambda x: (x[0], -x[1]))

一瞬间，整个地图开始剧烈震动。左端点小的区间像被磁铁吸住一样，连滚带爬地挤向队伍前排；左端点撞车的区间们则开始了残酷的内卷——右端点大的冲击 C 位，右端点小的被动回退。

你看着这支被咒语驯服的队伍，嘴角微微上扬：猎人的工作，从列队完毕那一刻起，就已经结束了九成。 剩下的一成，不过是走个过场，收个人头而已。

你提着排序之刃，刀尖拖在石板地面上，迸出呲呲的火星，像一场即将开场的屠杀预告片。你把左手摊开，掌心浮现出一个变量 max_right，初始值为 0——它记录的是你这一路走来，刀锋扫过的最远右疆界。

你迈开步子，从队头走到队尾，每经过一个区间 [a, b)，只问一个问题：

“你的右边界 b，有没有超过我这把刀至今扫过的极限？”

一问一斩，绝无多余动作。

情况一：b ≤ max_right 这厮的右边界没有突破前人留下的记录——左边已经被大哥盖住（排序铁律之下，它的左端点不可能比前辈更靠左，顶多打个平手），右边又被大哥的疆域完全碾压——从头到脚，无一处突围。教科书级别的套娃，连挣扎的资格都不配拥有。不计数，下一个。
情况二：b > max_right 嚯！这小子的右边界炸出了新高，硬生生把已知疆土撕开一道缺口！哪怕它的左边界还是被某个大哥压制，至少右边这一段是独享的，是旁人够不着的“独家战区”。这不是套娃，这是开拓者，是配得上被计数的高手。你眼中寒光微闪，幸存者计数 +1，同时腕部一转，刀锋向前劈出一道半月弧光——max_right 应声刷新为 b，地图上烙下一道崭新的疆界线。

你就这样从头走到尾，一步不停，一眼不回头看。排序之刃帮你压死了左边界——后来者永远不可能比前辈站得更靠左。max_right 帮你盯死了右边界——只要后辈的右边界没超过前辈的最远记录，必被吞噬。双刃合璧，一刀封喉，套娃无所遁形。

def removeCoveredIntervals(intervals: List[List[int]]) -> int:
 intervals.sort(key=lambda x: (x[0], -x[1]))
 res = 0
 max_right = 0
 for i in range(len(intervals)):
 if max_right < intervals[i][1]:
 res += 1
 max_right = intervals[i][1]
 return res

一套刀法行云流水，遍历 O(n)，叠加上排序咒语的 O(n log n)，总花费让隔壁还在硬莽双重循环的剑圣羞愧到想删号。至于空间？除排序本身，全程只祭出两个变量——res 与 max_right，堪称环保猎人的典范。

队友在语音频道里惊呼：“卧槽这就完了？你这输出是开了倍速挂还是我电脑卡了？”

你扛起排序之刃，刀身上的附魔铭文在暗处微微脉动。那些曾在地图数据里混吃等死的套娃区间，已被从逻辑上彻底抹除——连删除的痕迹都没留下，仿佛它们从一开始就没在这张地图上刷新过。

你头也不回，步入公会大厅的阴影深处，只抛下一句话，冷得像刀锋入鞘的最后一声轻响：

“猎人不打无谓之猎，套娃不配占用 CPU。”

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode1310 两种DP，一把神装

Sun, 05 Jul 2026 20:02:23 +0800

🎮两种DP，一把神装

你，一位身披重甲的骑士，站在城堡的右下角（别问为什么不在正门，问就是策划设计的）。城堡的最深处——左上角，藏着一把传说中的武器：“全服第一·金光闪闪·一刀999·屠龙宝刀”。装备就是尊严，皮肤就是战力，这把刀要是落入别人手里，你在服务器里的排名就得从“榜一大哥”变成“榜外小弟”。

但这座城堡有个变态设定：每个房间要么堆着金币（数字 1~9），要么蹲着一只打呼噜的精英怪（障碍 X），而且你的重甲只允许三个移动方向——向上、向左、向左上角斜走。 向下？不存在的，骑士的尊严不允许走回头路，况且甲胄太重，下楼梯膝盖受不了。

你的目标非常清晰：

收集最多的金币——买不起屠龙宝刀的皮肤，你拿什么在队友面前装逼？
统计有多少种走法能刚好拿到这么多金币——万一队友问“你怎么来的”，你可以装作风轻云淡：“路线不多，也就几十种，我都算过了。”

如果根本走不到藏宝室……那就 [0, 0] 灰溜溜回城，看着世界频道刷屏：“恭喜玩家【隔壁剑圣】获得屠龙宝刀！”

动态规划双雄：一把刀，两种姿势

你站在起点，握紧了手中的剑。作为全服排名前三的骑士，你深知拿到这把刀的方式不止一种。今天，你打算用两种姿势征服这座城堡——先用商人的精算推演全局，再用猛男的头铁正面硬刚。一种姿势算胜负，两种姿势定乾坤。队友在语音里问：“你行不行啊？”你冷笑一声，回了两个字：“看号。”

姿势一：后向 DP——商人骑士的沙盘推演

“别急着往前冲，先想想终点在哪儿。”

你没有急着冲锋，而是把剑往地上一插，盘腿坐下，从背包里掏出一张泛黄的羊皮卷轴。卷轴封面写着四个字：“逆向演算”。

这个姿势的精髓是：假装你已经站在藏宝室门口了，然后倒着走回起点，沿途在每块地砖上记账。 定义 dp[i][j] = [maxGold, count]，意思是“从 (i,j) 出发走到藏宝室，最多能捞多少金币，以及有几条路能捞到这个数”。

藏宝室 E：你就站在终点，还没拔刀，口袋里零金币进账（E 本身不掉落），最大金币 = 0，方案数 = 1。
精英怪房间 X：绕行，绕行！标记为不可达，金币 = -∞，方案数 = 0。谁拉怪谁负责，商人只打必赢的团。
普通金币房：你回头看——因为是倒着推，下一步其实是正向走法的“上一步”，也就是下方、右方、右下三个方向。扫一眼这三个邻居的账本，挑出 maxGold 最大的那个，把方案数抄过来；如果有多个邻居并列最大，说明多条路都能让你捞到同样的最大金币，就把它们的方案数累加起来。

然后，弯腰把当前房间地板缝里的金币（数字）抠出来加上——商人连一个铜板都不放过，这是职业素养。

当你倒推回起点 S 时，账本上赫然写着两个数字：最大金币数，和对应的路线方案数。如果最大金币还是 -∞，那说明连藏宝室的门都摸不到——不过全服前三的骑士，不存在这种情况。

def pathsWithMaxScore(board):
 MOD = 10**9 + 7
 n = len(board)
 if board[n-1][n-1] == 'X' or board[0][0] == 'X':
 return [0, 0]

 # dp[i][j] = [max_score, count]
 dp = [[[float('-inf'), 0] for _ in range(n)] for _ in range(n)]
 dp[0][0] = [0, 1] # 站在藏宝室门口，不走路不捡钱，一种站姿

 # 倒推的三个方向：下、右、右下
 dirs = [(1, 0), (0, 1), (1, 1)]

 for i in range(n):
 for j in range(n):
 if i == 0 and j == 0:
 continue
 if board[i][j] == 'X':
 continue

 max_score = float('-inf')
 total_cnt = 0
 for di, dj in dirs:
 pi, pj = i - di, j - dj # 回头看是谁走过来的
 if 0 <= pi < n and 0 <= pj < n and board[pi][pj] != 'X':
 score, cnt = dp[pi][pj]
 if score > max_score:
 max_score = score
 total_cnt = cnt
 elif score == max_score:
 total_cnt = (total_cnt + cnt) % MOD

 if max_score != float('-inf'):
 add = 0
 if board[i][j] not in ('E', 'S'):
 add = int(board[i][j])
 dp[i][j] = [max_score + add, total_cnt]

 res = dp[n-1][n-1]
 return [res[0] if res[0] != float('-inf') else 0, res[1] % MOD]

你合上卷轴，拔出插在地上的剑。商人姿势的精髓在于：不动一刀一枪，胜负已在指尖。 队友在语音里沉默了——这哥们坐地上画了张图，就把路线全算完了？

姿势二：前向 DP——头铁猛男的正面碾压

“管他那么多，先冲再说！”

你把卷轴塞回背包，活动了一下肩胛骨，盔甲发出咔咔的金属摩擦声。“算完了？算完了就该开怪了。”

第二个姿势，是你最擅长的：正面冲锋，见一个房间踹一扇门，边跑边记。 这个姿势的哲学是：“路线是跑出来的，金币是捡出来的，骑士的功勋写在前胸，不在账本！”

定义 dp[i][j] = [maxGold, count]，意思是“从起点冲到这里，最多已经捞了多少金币，以及有几条路能捞到这个数”。

起点 S：你就站在这儿，还没开冲，口袋零金币，方案数 = 1——先原地吼一个 Buff，气势不能输。
精英怪房间 X：直接跳过！猛男虽然头铁，但还没铁到单挑睡着的精英怪——万一吵醒了团灭，队友要喷你。
普通金币房：你一脚踹开门，先看一眼是从哪个方向冲来的——因为正向只能向上、向左、向左上走，所以到达 (i,j) 的上一个房间必然是它的上方、左方、左上方三个之一。从这三个方向里挑出 maxGold 最大的那个，把方案数搬过来（并列最大就累加）。然后低头一看，地板上有金币？弯腰，捡，一气呵成。动作快得像开了自动拾取，猛男捡钱从不墨迹。

当你一脚踹开藏宝室的大门时，口袋里的金币叮当乱响，手里的路线图已经被汗水和激情浸透。你低头一看——嘿，和刚才商人姿势算出来的数字一模一样！

def pathsWithMaxScore(board):
 MOD = 10**9 + 7
 n = len(board)
 if board[n-1][n-1] == 'X' or board[0][0] == 'X':
 return [0, 0]

 dp = [[[float('-inf'), 0] for _ in range(n)] for _ in range(n)]
 dp[n-1][n-1] = [0, 1] # 站在起点，还没冲，零金币，一种站姿

 # 前推方向：上、左、左上
 dirs = [(-1, 0), (0, -1), (-1, -1)]

 for i in range(n-1, -1, -1):
 for j in range(n-1, -1, -1):
 if i == n-1 and j == n-1:
 continue
 if board[i][j] == 'X':
 continue

 max_score = float('-inf')
 total_cnt = 0
 for di, dj in dirs:
 pi, pj = i - di, j - dj # 回头看：谁来的
 if 0 <= pi < n and 0 <= pj < n and board[pi][pj] != 'X':
 score, cnt = dp[pi][pj]
 if score > max_score:
 max_score = score
 total_cnt = cnt
 elif score == max_score:
 total_cnt = (total_cnt + cnt) % MOD

 if max_score != float('-inf'):
 add = 0
 if board[i][j] not in ('E', 'S'):
 add = int(board[i][j])
 dp[i][j] = [max_score + add, total_cnt]

 res = dp[0][0]
 return [res[0] if res[0] != float('-inf') else 0, res[1] % MOD]

你站在藏宝室中央，屠龙宝刀插在你面前的地砖里，金光把整个房间照得像开了 HDR。你的左手攥着金币袋，右手握着路线图，两个姿势给出的数字严丝合缝。

尾声：

你拔出屠龙宝刀，刀身发出嗡嗡的鸣响，世界频道弹出全服公告：

【系统公告】恭喜玩家“DP骑士”获得【屠龙宝刀】，服务器首杀！

队友在语音里炸了锅：“卧槽牛逼！你到底是算的还是莽的？”

你扛着刀走出城堡，眼眶微湿——因为宝刀的金光有点刺眼。你淡淡地回了句：“两种姿势，一种答案。双 DP 通关，不服来辩。”

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode2492 图鉴更新：不找路径，只扫连通块，并查集一键通关

Sat, 04 Jul 2026 20:22:54 +0800

🎮图鉴更新：不找路径，只扫连通块，并查集一键通关

你是一名资深运维，信奉"预判风险就是节约生命"，技能树上最亮眼的天赋就是在服务器崩溃前把锅甩出去。这天运维小哥丢来一个任务：从1 号测试机，一路 SSH 到n 号生产机，中间跳板机的安全系数 distance 一个比一个离谱——数字越小越刺激，敲个回车就可能蓝屏、宕机、主板升天。整条链路的安全性由最烂那台跳板机决定（木桶效应，也是生产事故的第一块多米诺），崩了你会被截图挂上 Slack #incident-recap 频道循环处刑。

你的任务说白了就是：所有可能跳转路径里，最坏能踩到多烂的跳板机——也就是最小安全系数的最小值。为什么求下限？因为甩锅要趁早。只要你摸清全网最脆的那台机器，就能理直气壮输出：

“团队，本次路径不可避免触碰了安全系数 3 的遗产服务器，已连续运行 999 天，属不可抗力……”

你甚至故意绕远路去踩它——毕竟策划给了你一个 BUG 级技能：可以反复走同一条路、也可以多次到达同一节点。这意味着你可以像刷副本一样，把整张图的边全踩一遍，攒满“烂机器证据库”再晃悠到终点。只要 1 号和 n 号服务器连通，你总能溜达到那个最脆节点上——这不是冒险，这是战略性踩雷。

这压根不是最短路，是考连通性：1 和 n 所在连通块内所有边的最小值。

你邪魅一笑，从工具箱抽出两件神装，准备展开这场甩锅之旅。

DFS

从 1 号机出发，把能连上的跳板机全踩一遍，顺便记下见过的最小安全系数。

递归 DFS：实现起来干净利落，像一把匕首。

 def minScore(n: int, roads: List[List[int]]) -> int:
 # 无向图，双向建边
 g = [[] for _ in range(n + 1)]
 for u, v, cost in roads:
 g[u].append((v, cost))
 g[v].append((u, cost))

 vis = [False] * (n + 1)
 ans = float('inf')

 # 递归 DFS：一条路走到黑，撞墙再回溯
 def dfs(u: int):
 nonlocal ans
 vis[u] = True
 for v, cost in g[u]:
 ans = min(ans, cost)
 if not vis[v]: # 如果下一个 v 还没访问过
 dfs(v) # 递归访问 v（系统会自动把返回地址压入调用栈）

 dfs(1) # 从 1 号机出发，开始踩点
 return ans

但递归匕首有个致命弱点：跳板机太多→调用栈太深→RecursionError，锅还没甩出去自己先炸了，留下满地碎片成为第二天晨会的素材：“看，这就是那个写出无限递归的天才。”

成熟运维当然有栈式防炸甲——手动模拟递归，把系统调用栈换成自己维护的列表栈，稳如老狗。

迭代 DFS：和递归版逻辑完全一样，只是把"系统自动压栈"换成了"手动 append/pop"。

 def minScore(n: int, roads: List[List[int]]) -> int:
 g = [[] for _ in range(n + 1)]
 for u, v, cost in roads:
 g[u].append((v, cost))
 g[v].append((u, cost))

 vis = [False] * (n + 1)
 ans = float('inf')

 # 迭代 DFS：手动栈，稳如老狗
 stack = [1] # 手动栈，从 1 号服务器开始
 vis[1] = True # 标记起点已访问，到此一游
 while stack:
 u = stack.pop()
 for v, cost in g[u]:
 ans = min(ans, cost)
 if not vis[v]:
 vis[v] = True
 stack.append(v)

 return ans

**两种 DFS 本质相同：**遍历 1 号机所在的连通分量，沿途捡最小的边。时间 O(n+m)，空间 O(n+m)。递归版优雅简洁，像个精炼的甩锅话术；迭代版稳健可控，像个详细的甩锅邮件。

但你的强迫症开始隐隐作痛：为了找一个连通块的最小边，居然要把所有节点和边都扫一遍？这种“战略性踩雷”的脚本，是不是有点太敬业了？

你重新审视手里的底牌。策划给了你三个关键信息：

可以重复走 → 不需要关心具体路径，只关心连通分量
求最小边权 → 这是整个连通分量的集体属性，完全可以边建边维护
单次查询 → 只问 1 和 n 所在连通块的最小值，不问过程，不问路径

这三条信息指向同一个结论：你要的不过是 1 号和 n 号服务器所在连通分量里的最小边权。而能直接维护连通分量、顺手还能记个最小值的，正是工具箱底层压着的另一件神器——并查集。它天生为连通性而生，连图都不用完整建，边读边合并，账本随时可查。

并查集——连通性的天选之子

真正的甩锅大师，从来不止一手准备。

并查集天生就是用来维护连通分量的神器——它能把整张图压缩成若干个集合，每个集合的根节点手里攥着该集合的集体属性。查询时只需 find(1)，瞬间拿到答案——不用遍历、不回溯、不废话，查询 O(α(n)) ≈ O(1)，甩锅 O(∞)。

你只需要三步：

初始化：每个节点自立门户，parent[i]=i，min_cost[i]=∞
合并：遍历所有道路，把相连的节点合并到同一集合，顺手更新该集合的最小安全值
查询：返回节点 1 所在集合的最小安全值，就是答案

这招完全绕开了显式的图遍历，直接把问题降维成"集合合并 + 最小值维护"。

基础版并查集：

一个 parent 数组、一个 min_cost 数组，合并时随便把一方挂在另一方下面（谁当爹都行），查找时带路径压缩（把沿途节点全挂到根下面，下次一查就中）。时间复杂度近似 O(m α(n))，空间 O(n)：

# 并查集
class UnionFind:
 def __init__(self, n):
 self.parent = list(range(n)) # parent[i] 表示节点i的父节点
 self.min_cost = [float('inf')] * n # min_cost[i] 表示节点i所在集合的最小边权

 def find(self, x):
 if self.parent[x] != x:
 self.parent[x] = self.find(self.parent[x]) # 路径压缩
 return self.parent[x]

 def union(self, x, y, cost):
 """合并 x 和 y 所在的集合，同时更新最小边权"""
 px, py = self.find(x), self.find(y)
 if px != py:
 self.parent[px] = py
 self.min_cost[py] = min(self.min_cost[py], self.min_cost[px], cost)
 else:
 self.min_cost[px] = min(self.min_cost[px], cost)


class Solution:
 def minScore(self, n: int, roads: List[List[int]]) -> int:
 uf = UnionFind(n + 1)
 for u, v, cost in roads:
 uf.union(u, v, cost)
 return uf.min_cost[uf.find(1)]

但基础版有一个隐患：合并时总是 parent[px] = py，可能导致树变得极高（极端情况退化成链表），虽然路径压缩能挽回一些，但你想优雅到底，于是祭出按秩合并优化：加一个 rank 数组记录树的深度（或大小），永远把小树挂在大树下面，确保树高稳定在 O(log n)。搭配路径压缩，双管齐下，性能拉满。

按秩合并版：

合并时比较两棵树的"秩"（近似高度或节点数），把矮树挂到高树下，避免树过高导致 find 变慢。

# 并查集
class UnionFindOptimize:
 def __init__(self, n):
 self.parent = list(range(n)) # parent[i] 表示节点i的父节点
 self.min_cost = [float('inf')] * n # min_cost[i] 表示节点i所在集合的最小边权
 self.rank = [0] * n # rank[i] 表示节点 i 所在树的秩（近似高度） 

 def find(self, x):
 if self.parent[x] != x:
 self.parent[x] = self.find(self.parent[x]) # 路径压缩
 return self.parent[x]

 def union(self, x, y, cost):
 """按秩合并 x 和 y 所在的集合，同时更新最小边权"""
 px, py = self.find(x), self.find(y)
 if px == py:
 self.min_cost[px] = min(self.min_cost[px], cost)
 return

 # 按秩合并：矮树挂到高树下
 if self.rank[px] < self.rank[py]:
 self.parent[px] = py # px 树矮，把 px 挂到 py 下
 self.min_cost[py] = min(self.min_cost[py], self.min_cost[px], cost)
 elif self.rank[px] > self.rank[py]:
 self.parent[py] = px # py 树矮，把 py 挂到 px 下
 self.min_cost[px] = min(self.min_cost[px], self.min_cost[py], cost)
 else:
 self.parent[py] = px # 两树一样高，随便挂（这里把 py 挂到 px 下）
 self.min_cost[px] = min(self.min_cost[px], self.min_cost[py], cost)
 self.rank[px] += 1 # px 树高度 +1

class Solution:
 def minScore(self, n: int, roads: List[List[int]]) -> int:
 uf = UnionFindOptimized(n + 1)
 for u, v, cost in roads:
 uf.union(u, v, cost)
 return uf.min_cost[uf.find(1)]

时间复杂度 O(m α(n))，空间 O(n)。最关键的是——你根本不需要显式建图，边读边合并，流水线作业，潇洒得像开着自动拾取刷副本。并查集这把降维打击杖，让你在甩锅的路上又领先了一个身位。

尾声：

你合上笔记本，从工位抽屉里翻出那本牛皮封面的 《踩坑指南》——这是你多年运维生涯的血泪结晶，封面上还沾着上次服务器爆炸时溅到的咖啡渍。你翻到最新一页，工工整整地写下今天的战利品——一张随身携带的判断流程图：

拿到一个图论题，先问自己：和连通性有关吗？ ├─ 是 → 需要具体路径吗？ │ ├─ 是 → DFS/BFS │ └─ 否 → 需要维护连通分量的属性吗？ │ ├─ 是 → 并查集 │ └─ 否 → 边是动态加的？频繁查询？ │ ├─ 是 → 并查集 │ └─ 否 → DFS/BFS 也可以 │ └─ 否 → 是最短路径/层次问题吗？ ├─ 是 → BFS / Dijkstra └─ 否 → 需要遍历整张图吗？ ├─ 是 → DFS/BFS └─ 否 → 看情况开盲盒

你深吸一口气，准备好了完美的甩锅话术：“主管，不是我的问题，是 1 号服务器所在连通分量里有台安全系数只有 3 的遗产服务器，这是并查集算出来的，数学不会骗人。如果您不信，我可以给您画个 Union-Find 的树形图。”

存档已保存，下张地图见。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3286 DAG 阈值猎杀：二分特工的探针三连击

Fri, 03 Jul 2026 16:56:44 +0800

🎮DAG 阈值猎杀：二分特工的探针三连击！

你是一名网络特工，代号“二分”——不是因为你长得二分，而是你解决问题时总喜欢把答案劈成两半，逼它自己招供。今天你接到的任务比以往更离谱：从总部 0 号节点出发，穿越一张由单向光缆编织的有向无环图（DAG），抵达最后一处未被黑客攻破的数据中心 n-1。沿途的中转服务器，有些还在线（online[i]=true），有些已经挂了。节点之间由单向光缆连接，每条光缆上都贴着一张维修价签 cost，明码标价。

上司甩给你一笔可怜的预算 k，要你挑一条路，把沿途经过的光缆通通维护一遍。规矩很明确：总花费不许超支，沿途服务器必须在线——你总不能对着一台冒烟的机柜敲 ping 吧。

你决定，要在所有合法路径中，找出那个最小边成本最大的路径。为什么盯着最小边？因为短板决定体验，瓶颈决定命运——哪怕路上有一根 1 块钱的劣质网线，它就能把整条万兆光纤拖成PPT播放器。让这条路上最烂的那段，也比其他所有合法路径的最烂段要强——这是属于特工的尊严，也是属于打工人的倔强。

当然，如果连一条合法路径都不存在……那就带着 -1 回去挨批。

二分阈值猎杀

这个问题说白了是个“双约束”修罗场——既要让路径上的最小边成本尽可能大，又要让总成本不超过 k。就像老板既要马儿跑得快，又要马儿不吃草一样。

但你丝毫不慌——"最大化最小值"，这五个字就是二分查找的接头暗号。

如果阈值 x 可行（即存在一条路径，所有边成本 ≥ x，且总成本 ≤ k），那么任何比 x 小的阈值也一定可行（因为放宽了边限制，路径只会更多）。反过来，如果 x 不可行，那么比 x 大的阈值更不可能可行。

单调性成立，猎杀开始。你像切西瓜一样，把答案范围 [l, r] 一分为二，反复猜、反复验证，直到精确命中那个最优阈值。

你给这套"猜答案 → 验答案"的流程起了个中二代号：阈值探针。

def findMaxPathScore(n: int, edges: List[List[int]], online: List[bool], k: int) -> int:
 n = len(online)
 g = [[] for _ in range(n)]
 l, r = float('inf'), 0

 # 建图(只走在线节点)和确定边界
 for u, v, cost in edges:
 if not online[u] or not online[v]:
 continue
 g[u].append((v, cost))
 r = max(r, cost)
 l = min(l, cost)

 # 阈值探针!
 def check(limit: int) -> bool:
 # todo: 检查阈值 limit 是否可行 
 pass

 # 二分答案
 if not check(l):
 return -1

 while l <= r:
 mid = (l + r) >> 1
 if check(mid):
 l = mid + 1
 else:
 r = mid - 1

 return r

现在，你必须给这个空壳探针注入灵魂。

check(limit) 要干的事很明确：在只允许走成本 ≥ limit 的边这个前提下，判断能否从 0 走到 n-1，且总花费 ≤ k。

Dijkstra 最短路 + 二分（最稳健的探针）

你脑子里第一个蹦出来的，是图论祖师爷 Dijkstra 老爷子。他老人家的算法精髓就四个字：贪心 + 单调——用一个最小堆永远优先处理当前花费最小的节点，保证第一次抵达就是最优。

现在你把 Dijkstra 改装成一台"阈值检查器"：

维护一个 dist 数组，记录从起点到每个节点的最小花费，初始时只有 dist[0] = 0，其余为正无穷。
堆里存 (累计花费, 节点)，每次弹出花费最小的节点。如果当前花费已经超过 k——继续走就是贴钱打工，直接return False。
如果弹出的恰好是终点n-1，恭喜，Dijkstra 保证第一次弹出终点就是全局最小总花费，它不超预算，意味着limit 肯定可行，return True。
如果当前弹出的花费比 dist[u] 还大？说明这是个过时记录——之前已经有更便宜的路到过u了，果断扔掉。
遍历 u 的所有出边，cost < limit 的直接无视（太次，配不上你的追求），只对cost >= limit 的“硬货”做松弛：如果 dist[u] + cost < dist[v]，更新 dist[v] 并入堆。

这个检查器有多稳？一次 Dijkstra 是 O(m log n)，套上二分 O(log C)，总复杂度 O(m log n log C)，对于题目规模来说，就像用 4090 跑扫雷，绝对稳如老狗。

# 解法一：Dijkstra 最短路
def check(limit: int) -> bool:
 dis = [float('inf')] * n
 dis[0] = 0
 pq = [(0, 0)] # (累计花费, 节点)
 while pq:
 cur, u = heapq.heappop(pq)
 if cur > k:
 return False # 超预算，直接死刑
 if u == n-1:
 return True # 第一次抵达终点 = 最小花费，预算内通关
 if cur > dis[u]:
 continue # 过时的记录，跳过
 for v, cost in g[u]:
 if cost < limit:
 continue
 if dis[v] > dis[u] + cost:
 dis[v] = dis[u] + cost
 heapq.heappush(pq, (dis[v], v))

 return False

你刚觉得Dijkstra这把重剑稳如老狗，但转念一想——这图可是DAG啊！有向无环，意味着路径天生有序，根本不需要堆去维护什么优先级。于是你决定换一把更轻巧的匕首。

记忆化搜索 + 二分（灵巧的回溯探针）

既然 DAG 无环，那递归天然就是安全的——不用担心无限套娃，因为没有环可以绕回去。

路径天生有序，递归回溯就能把每条边捋一遍。而且 n 的范围不算太大，记忆化搜索正好派上用场：从终点倒推，一路回溯，把中间结果缓存下来，既省堆又省脑细胞。

思路也很直球：定义 dfs(u) 表示从节点 u 出发，在只允许边成本 ≥ limit 的条件下，到达终点 n-1 所需的最小总花费。

你从 0 开始递归，对于当前节点 u：

如果 u 恰好是终点，那就不用再花一分钱，返回 0；
否则，遍历 u 的所有出边 (v, cost)，只挑 cost >= limit 的硬边走，递归计算 dfs(v)，加上当前边的成本 cost，取所有结果中的最小值；
用 @cache 装饰器自动缓存每个 u 的计算结果——这样每个节点最多算一次，后面的递归直接复用。

最后，如果 dfs(0) <= k，说明阈值 limit 可行。

整个过程就像从终点往回铺路标：你只关心"从当前位置到终点最少花多少钱"，而每个子问题结构相同，递归套娃加上缓存，把"反向推导"玩成了自动化流水线。时间复杂度O(m)（每条边最多被访问一次），乘上二分的O(log C)，总复杂度O(m log C)——比 Dijkstra 省掉了整个堆操作的log n，轻快得像卸了甲的轻骑兵。

# 解法二：记忆化搜索
def check(limit: int) -> bool:
 @cache
 def dfs(u: int) -> int:
 if u == n-1:
 return 0
 ans = float('inf')
 for v, cost in g[u]:
 if cost >= limit:
 ans = min(ans, dfs(v) + cost)
 return ans

 return dfs(0) <= k

你舞着这把递归匕首，咧开的嘴角还没来得及合上，脑子里突然闪过一个声音：“递归深度告警。” 没错，万一哪天数据规模翻倍，你的递归栈就可能当场爆掉，留下一地 RecursionError 的碎片。

作为一名成熟的特工，你习惯把命运攥在自己手里——与其依赖黑盒子的调用栈，不如自己动手排兵布阵，勤劳迭代。于是，你收起匕首，抽出第三把武器——拓扑排序 + DP。

拓扑排序 DP + 二分（终极流水线探针）

拓扑排序是 DAG 的天选搭档。它能把所有节点排成一条流水线，保证每个节点轮到它的时候，所有前驱都已经处理完毕。这意味着你可以顺着流水线一路往前递推，不需要堆来排序，不需要递归来回溯，一个普通队列就搞定。

它和记忆化搜索，本质上是同一道递推公式的两面：

记忆化是 “拉”：dfs(u) 向后继节点要答案，一层层往下问，答案再一层层往回传；
拓扑排序是 “推”：dp[u] 算完直接塞给后继节点，按拓扑序从前往后走，接力棒一样往下传。

区别在于——“谁先算谁后算"这件事，记忆化靠递归栈隐式决定，拓扑排序靠入度归零机制显式决定——入度归零的先上，处理完它的后继，后继入度减一，新的归零节点跟上。整个顺序由 DAG 的结构天然锁定，比递归栈靠谱得多，也比堆排序轻快得多。

不过开工前有个小坑要填：图中可能存在一些不可达的"孤岛节点”——入度为 0 但不是起点，没有任何边指向它们，从起点绝对到不了。这些孤岛如果留着，它们的后继会一直等不到入度归零，整条链路直接卡死。所以先做一轮预处理，把这些坏死组织清理干净：

def findMaxPathScore(edges: List[List[int]], online: List[bool], k: int) -> int:
 n = len(online)
 g = [[] for _ in range(n)]
 l, r = float('inf'), 0
 deg = [0] * n # 记录节点入度

 for u, v, cost in edges:
 if not online[u] or not online[v]:
 continue
 g[u].append((v, cost))
 r = max(r, cost)
 l = min(l, cost)
 deg[v] += 1 # 更新节点入度

 # 阈值探针!
 # 先预处理：剥离从起点不可达的"孤岛节点"
 q = deque([i for i in range(1, n) if deg[i] == 0]) # 入度为 0 且不是起点的节点
 while q:
 u = q.popleft() # 弹出一个孤岛
 for v, _ in g[u]:
 deg[v] -= 1 # 孤岛的后继入度减 1
 if v and deg[v] == 0: # 后继也变成孤岛了（且不是起点）
 q.append(v) # 加入剥离队列

 def check(limit: int) -> bool:
 # todo: 检查阈值 limit 是否可行 
 pass

 # 二分答案
 ......

剥完之后，剩下的 deg 就是一份干净的、只保留从起点可达结构的入度表。

接下来 check(limit) 就清爽了，三步走：

初始化：复制入度表 cdeg = deg.copy()，dp数组全填无穷大，初始化 dp[0]=0，队列只放起点 0；

为什么要 deg.copy()？因为 check 里的拓扑排序是破坏性的——每处理一个节点就 cdeg[v] -= 1，跑完一次 check 后整个入度表就全被减成 0 了。但二分要调几十次 check，每次都需要一份完整的、初始状态的入度表。所以每次都得 copy 一份新的来"消耗"。
流水线推进：弹出节点 u，如果是终点n-1，直接返回 dp[u] <= k——此时所有前驱都已处理完毕；
松弛 + 传递：遍历u的出边，只走cost >= limit的硬边做松弛，更新dp[v]。注意：不管边够不够硬，cdeg[v] 都要减一——边权过滤管的是 dp 值，入度递减管的是拓扑序，两条线互不干扰。入度归零的节点入队，轮到它上场。

时间复杂度 O(m) 一次检查，套上二分O(log C)，总复杂度 O(m log C)。无递归、无堆栈、遇终点提前宣判——DAG 上的性能天花板。

def findMaxPathScore(edges: List[List[int]], online: List[bool], k: int) -> int:
 n = len(online)
 g = [[] for _ in range(n)]
 l, r = float('inf'), 0
 deg = [0] * n # 记录节点入度

 for u, v, cost in edges:
 if not online[u] or not online[v]:
 continue
 g[u].append((v, cost))
 r = max(r, cost)
 l = min(l, cost)
 deg[v] += 1

 # 阈值探针!
 # 预处理：剥离从起点不可达的"孤岛节点"
 q = deque([i for i in range(1, n) if deg[i] == 0])
 while q:
 u = q.popleft()
 for v, _ in g[u]:
 deg[v] -= 1
 if v and deg[v] == 0:
 q.append(v)

 def check(limit: int) -> bool:
 dp = [float('inf')] * n # dp[i]: 从起点到 i 的最小总花费
 cdeg = deg.copy() # 拷贝入度——拓扑排序会消耗它，不能动原件
 dp[0] = 0
 q = deque([0])
 while q:
 u = q.popleft()
 if u == n - 1:
 return dp[u] <= k # 到达终点，提前宣判！
 for v, cost in g[u]:
 if cost >= limit:
 dp[v] = min(dp[v], dp[u] + cost) # 松弛：只走够硬的边
 cdeg[v] -= 1 # 入度必减——跟边权无关，这是拓扑序的事
 if cdeg[v] == 0: # 前驱全部处理完毕，轮到 v 上场
 q.append(v)
 return False

 # 二分答案
 ......

尾声

探针归位，二分收敛——这是你第无数次看着二分框架优雅地合拢，像狙击镜里十字准星缓缓锁住目标。

Dijkstra 重剑无锋，记忆化匕首如风，拓扑排序流水线降维打击——三连击打完收工，最终撑起整个猎杀框架的，还是那招最朴素的祖传手艺——二分：把一个"既要又要"的双约束难题，劈成一道道简单的判断题：“够不够？行不行？能还是不能？”

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3286 0-1网格求生指南：血条战士 01-BFS 的觉醒

Thu, 02 Jul 2026 12:27:54 +0800

🎮0-1网格求生指南：血条战士 01-BFS 的觉醒！

你是一个 血条战士，初始满血 health 点。你站在矩形网格的左上角 (0,0)，准备冲向右下角的传送门 (m-1,n-1)。网格里只有两种地板：绿草地 0 和陷阱 1。踩到绿草地，毫发无伤；踩到陷阱，当场 -1 血。

规则很残酷：任何时候你的血量必须大于 0，一旦血条见底，直接原地去世。就算冲到传送门前，踏进去那一刻血量也得 >0，否则倒在终点线上也算输。

你的目标很简单：活着到达终点。

这是一场“最小受伤大赛”

你先算了笔账：不管你在网格里怎么蛇皮走位，这一路踩到的陷阱总数，就是你整趟旅程的“受伤点数”。只要存在一条路，能让你从起点到终点的受伤点数 严格小于 你的初始血量 health，你就一定能活着通关。

于是你恍然大悟——哪有什么刀山火海，策划压根就是在考你数学。所谓“最小伤害路”，翻译过来就三个字：最短路。

在这张 0-1 网格里，找一条从左上到右下的路径，使得沿途经过的 1 的个数最少。

Dijkstra（最短路）

如果你是个愣头青，从起点闷头乱冲，大概率走到一半就发现血条飙红、后路已断，只能仰天长叹：“早知道换条路了……”

痛定思痛，你用“读档重来”的神技，悟出第一招保命法门：带优先级的探索——也就是 Dijkstra 算法。从此，你不再是个无头苍蝇，而是化身为精打细算的铁公鸡旅人，永远先探最安全的方向，小心翼翼试验每一寸土地。

你准备好一个魔法小本 dist，记录到达每个格子的 当前最小受伤次数，一开始全部写成 -1（表示"从未涉足"）。起点的受伤次数直接等于 grid[0][0]——没错，起点本身也可能是个阴险的陷阱，先扣为敬。你把起点塞进一个优先队列（小顶堆），在"轻伤优先"的原则下层层推进：

每次从堆顶请出受伤最轻的格子，先核对它是否已经在小本上被"盖章定案"（dis ≥ 0）。如果是，说明这条线索是迟到的"马后炮"——已经有一条更好的路径写进本子了，果断扔掉；否则，它就是目前的最优解，立刻盖章（写入 dis），并向四个邻居探头张望。凡是还没被盖章的邻居（dis < 0），就把这个邻居和"当前受伤 + 该邻居伤害"打包丢进优先队列，让它排队等登场。

直到队列彻底清空，小本里便刻满了从起点到每个可达格子的最小受伤次数——而右下角 dis[m-1][n-1]，正是你千辛万苦要找的那条最苟路线的代价。如果它 < health，恭喜，血条足够你浪。

def findSafeWalk(grid: List[List[int]], health: int) -> bool:
 m, n = len(grid), len(grid[0])
 dirs = [(-1, 0), (1, 0), (0, 1), (0, -1)]

 dis = [[-1] * n for _ in range(m)] # 魔法小本，-1 表示"从未涉足"
 q = [(grid[0][0], 0, 0)] # 优先队列（小顶堆），起点先入队
 while q:
 val, x, y = heapq.heappop(q) # 弹出当前累积伤害最轻的格子
 if dis[x][y] >= 0: # 已盖章？马后炮，扔掉 
 continue
 dis[x][y] = val # 盖章定案，记录最优受伤次数
 for dx, dy in dirs:
 nx, ny = x + dx, y + dy
 if 0 <= nx < m and 0 <= ny < n and dis[nx][ny] < 0:
 heapq.heappush(q, (val + grid[nx][ny], nx, ny)) # 邻居入队

 return dis[-1][-1] < health

复杂度：O(mn log(mn))——最坏情况每个格子都要入堆一次，堆操作log(mn)。

双端口袋与 01BFS

跑完 Dijkstra，你盯着那个 O(mn \log(mn)) 的复杂度，觉得有点冤——这破地图只有两种伤害——踩草地不掉血（0），踩陷阱掉 1 血（1），就两个档位，干嘛还要雇个堆来排序？

杀鸡焉用牛刀。你果断扔掉优先队列，掏出一个双端队列——这玩意儿两头都能塞东西，堪称"插队神器"。核心操作只有两条：遇到草地就塞到队首，优先走；遇到陷阱就塞到队尾，等平坦的走完再说。这就是01BFS。

你走得更快了。因为你永远在“不增加受伤”的前提下疯狂扩张版图，只有万不得已才去吃陷阱。伤害只有 0 和 1 两个档位，队列里躺着的格子，受伤次数要么是 k，要么是 k+1——从队首到队尾严格单调不减，天然保持从小到大的顺序，跟 Dijkstra 一样正确，却完全不需堆排序。

def findSafeWalk(grid: List[List[int]], health: int) -> bool:
 m, n = len(grid), len(grid[0])
 dirs = [(-1, 0), (1, 0), (0, 1), (0, -1)]

 dis = [[float('inf')] * n for _ in range(m)]
 dis[0][0] = grid[0][0]
 q = deque()
 q.appendleft((0, 0))

 while q:
 x, y = q.popleft()
 for dx, dy in dirs:
 nx, ny = x + dx, y + dy
 if 0 <= nx < m and 0 <= ny < n:
 cost = dis[x][y] +grid[nx][ny]
 if cost < dis[nx][ny]:
 dis[nx][ny] = cost
 if grid[nx][ny] == 0:
 q.appendleft((nx, ny)) # 草地插队
 else:
 q.append((nx, ny)) # 陷阱排队尾
 return dis[-1][-1] < health

复杂度：O(mn)，每个格子只进出队列一次，双端队列每次操作 O(1)，比 Dijkstra 快了一个 log 身位。

剪枝与“终点直通车”

01-BFS 已经够快了，但你还不满足——明明有些路走到一半就已经"必死无疑"，你却还傻乎乎地继续往外扩展，这不是浪费感情吗？

剪枝思路很简单：在探索邻居时，如果从起点到该邻居的累积伤害已经 ≥ health，那这条路径注定无法让你活着通关——别入队了，直接掐断。不合法的格子连进队列的资格都没有，搜索树当场修剪干净。

光剪枝还不够。你又悟出一层更深的奥义：不管是 Dijkstra 还是 01-BFS，格子出队的顺序都是按受伤次数从小到大的。这意味着——你第一次从队列里掏出终点 (m-1, n-1) 的那一刻，手里的受伤次数就是全图最优解！

何必探完整张地图？剪枝 + 直通车双管齐下，终点一到，直接宣判：

如果最小受伤次数 < health → 大喊一声 true，开传送门溜了。
如果最小受伤次数 ≥ health → 苦笑一声 false，老老实实读档吧。

 def findSafeWalk(grid: List[List[int]], health: int) -> bool:
 m, n = len(grid), len(grid[0])
 dirs = [(-1, 0), (1, 0), (0, 1), (0, -1)]

 dis = [[float('inf')] * n for _ in range(m)]
 dis[0][0] = grid[0][0]
 q = deque()
 q.appendleft((0, 0))

 while q:
 x, y = q.popleft()
 if x == m - 1 and y == n - 1: # 终点到手，当场宣判
 return True
 for dx, dy in dirs:
 nx, ny = x + dx, y + dy
 if nx < 0 or nx >= m or ny < 0 or ny >= n:
 continue
 cost = dis[x][y] + grid[nx][ny]
 if cost >= health: # 入队前剪枝：必死之路，不配入队
 continue
 if cost < dis[nx][ny]:
 dis[nx][ny] = cost
 if grid[nx][ny] == 0:
 q.appendleft((nx, ny))
 else:
 q.append((nx, ny))
 return False # 队列清空仍未到达终点，无解

尾声

你到达了终点，胸口的血条摇摇欲坠，但硬是没归零。没有在半路被陷阱榨干，也没有在最后一步功亏一篑，稳得连你自己都有点意外。

一路下来，Dijkstra 是你的稳健老哥，堆排序兜底不翻车；01-BFS 是你的飙车利器，双端队列省掉过路费；剪枝 + 终点直通车是最终形态——死路不踩，到站就下，用最少的代价趟穿了整张 0-1 网格。

存档已保存，下张地图见。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode2812 地牢逃生指南：论如何优雅地绕开所有小偷

Wed, 01 Jul 2026 14:15:55 +0800

🎮地牢逃生指南：论如何优雅地绕开所有小偷

你是一名勇者，代号“零”，此刻正站在一座 n × n 地牢grid的左上角 (0,0)。地牢的某些格子里藏着面目可憎的小偷（grid[r][c] = 1），他们不偷装备，专偷你辛苦攒下的金币。你的任务是从 (0,0) 走到右下角的出口 (n-1, n-1)。移动规则很传统：上下左右随便走，但不能斜着飞（地牢天花板太矮，轻功施展不开）。最关键的是：你希望整条路尽可能远离小偷。毕竟离小偷越近，你的钱包就越危险。

那么问题来了：怎么衡量一条路够不够"安全"？

一条路径的安全系数，定义为整条路径上的所有格子中，离小偷距离最小的那个值。换句话说，就是你这一路上最危险的那一格距离小偷有多远。安全系数越大，说明你这一路最危险的时候也离小偷挺远，体验舒适。

你要找的，就是所有从入口到出口的路径中，最大的安全系数到底是多少。

开胃菜：如果小偷已经堵门了？

先说个扎心的情况：如果起点 (0,0) 或终点 (n-1,n-1) 本身就是小偷老巢 (grid[r] [c]=1)，那你的冒险还没开始就结束了。安全系数注定是 0，因为你一出生就被包围了——就像刚进副本就发现BOSS站在复活点上——别挣扎了，直接返回 0 完事（除非你光脚不怕穿鞋的，但任务描述里没给你这个隐藏选项）。

n = len(grid)
if grid[0][0] == 1 or grid[n-1][n-1] == 1:
 return 0

侦察阶段：多源 BFS 扫描每个格子的“安全分”

排除掉上面的倒霉情况后，你决定先做个详细的地图侦察。“知己知彼，百战不殆”，这句老话在游戏里同样适用——你不会不带地图就去开荒对吧？

于是，你掏出了大杀器——多源 BFS 探测卫星。传统 BFS 是从一个点开始扩散，像往湖里扔一颗石子；多源 BFS 是同时从所有小偷的位置开始扩散，像同时在湖里扔了一堆石子，看谁的波纹先扫到某个点。

具体操作如下：

初始化：把所有小偷格子同时扔进队列（像卫星同时锁定所有贼窝），它们的距离设为 0；
层层扩散：每次从队列里取出一个点，向四个方向扩展。第一次扫描到某个格子时，记录的距离就是它到最近小偷的曼哈顿距离；
完成扫描：O(n²) 时间后，你就得到了一张完整的"安全地图" dis[r] [c]，数值越大越安全，数值为 0 的地方就是小偷的老巢

这一步就像在游戏里开了全图视野，每个格子离最近的敌人有多远一目了然。

# dis[][]: 存储每个点到最近小偷的距离
dis = [[-1] * n for _ in range(n)] # -1表示未访问
dirs = [(-1, 0), (1, 0), (0, 1), (0, -1)] # 四个方向

# 初始化：所有小偷位置入队
q = deque()
for i in range(n):
 for j in range(n):
 if grid[i][j] == 1:
 dis[i][j] = 0
 q.append((i, j))

# 多源BFS计算每个点到最近小偷的距离
while q:
 x, y = q.popleft()
 for dx, dy in dirs:
 nx, ny = x + dx, y + dy
 if 0 <= nx < n and 0 <= ny < n and dis[nx][ny] == -1:
 dis[nx][ny] = dis[x][y] + 1
 q.append((nx, ny))

现在你手里有了这张安全地图，接下来的问题就是：怎么用它找到那条"最安全"的路径？

找一条从左上到右下的路，让路上最小的那个数字尽量大。

解法一：二分查找

既然不知道最优的安全系数是多少，但你至少能回答一个问题：是否存在一条从入口到出口的路径，路上每个格子的安全值都 ≥ K？ 如果有，那真正的安全系数至少是 K。

显然，K 越小越容易满足，K 越大越困难，这不就是二分查找最喜欢的单调性吗？于是你直接把 K 扔进二分锅里翻炒：

每次猜一个中间值 mid，用 BFS 或 DFS 检查：只走安全值 ≥ mid 的格子，能不能从起点到终点。能，说明门槛还能再高点，lo = mid + 1（贪心本性暴露）；不能，就说明门槛太高了，hi = mid - 1（该降降期望了）。反复试探，最终夹出最大的可行门槛 k 。

方法很稳妥，就是有点磨叽——每次二分都要重新扫一遍地图，就像反复翻看同一本攻略书的铁憨憨。

# 已有 dis 安全地图

def check(limit: int) -> bool:
 visit = [[False] * n for _ in range(n)]
 q = deque()
 q.append((0, 0))
 visit[0][0] = True
 while q:
 x, y = q.popleft()
 if x == n-1 and y == n-1:
 return True
 for dx, dy in dirs:
 nx, ny = x + dx, y + dy
 if (0 <= nx < n and 0 <= ny < n
 and not visit[nx][ny] and dis[nx][ny] >= limit):
 q.append((nx, ny))
 visit[nx][ny] = True
 return False

# 二分查找
res = 0
lo, hi = 0, min(dis[0][0], dis[n-1][n-1])
while lo <= hi:
 mid = (lo + hi) // 2
 if check(mid):
 res = mid
 lo = mid + 1
 else:
 hi = mid - 1

return res

时间复杂度：O(n² log n)。多源 BFS 预处理 O(n²)，二分 log(n) 次，每次 BFS 检查又是 O(n²)。空间复杂度：O(n²)。

解法二：潜行大师的直觉（Dijkstra 最大瓶颈路）

你合上二分的攻略，眉头一皱：每次检查都要重新 BFS，就像在迷宫里反复走已经探过的路，太死板了。能不能一次搞定？你想起江湖上的一种传说：把安全值看作“路宽”，要找一条从起点到终点“最窄处最宽”的路径。这不就是经典的最大瓶颈路径问题吗？

于是你套上 Dijkstra 的风衣(贪心 + 松弛)，化身潜行大师，只不过把"累加距离"换成"维护最小值"，把"找最短"换成"找最大最小值"。具体来说：

用一个最大堆维护当前所有探索到的路径，按该路径的瓶颈值（即整条路径上最危险那一步的安全系数）从大到小排序。起点的瓶颈值就是 dis[0][0]。每次从堆里弹出瓶颈值最大的路径，然后用它向四周扩展：走到邻居 (nx, ny) 时，新路径的瓶颈值是 min(当前瓶颈值, dis[nx][ny])（经典的木桶效应——一个短板拉低全家）。

如果这个新瓶颈值比已知的到达该格子的最优瓶颈值更大，就更新记录并入堆。因为你永远优先探索“当前最安全”的路径，所以第一次弹出终点时，那个瓶颈值就是全局最优——完全不用等所有路径都跑完。

这样，你只需在安全地图上跑一次 Dijkstra 变种，没有二分的重复扫描，复杂度还是 O(n² log n)，但实际常数更小，优雅得像在刀尖上跳舞。

# 已有 dis 安全地图

# Dijkstra算法变种：找"最大最小值"路径，就是最大化一条路径的瓶颈（路径上最危险的那一步的安全系数）
visit = [[False] * n for _ in range(n)]
visit[0][0] = True

pq = [(-dis[0][0], 0, 0)]] # 优先队列用负数技巧得到最大堆效果：每次弹出安全值最高的格子
max_safeness = min(dis[0][0], dis[n - 1][n - 1]) # 初始安全系数

while pq:
 val, cx, cy = heapq.heappop(pq) # 弹出当前安全系数最高的点
 val = -val # 转回正数
 max_safeness = min(max_safeness, val) # 更新路径的最小安全系数
 if cx == n - 1 and cy == n - 1:
 break
 for dx, dy in dirs:
 nx, ny = cx + dx, cy + dy
 if 0 <= nx < n and 0 <= ny < n and not visit[nx][ny]:
 visit[nx][ny] = True
 heapq.heappush(pq, (-dis[nx][ny], nx, ny))

return max_safeness

时间复杂度：O(n² log n)（堆操作）。空间复杂度：O(n²)。

解法三：上帝视角的点灯游戏（并查集+分层优化）

前两种解法虽然都能过，但你心里总觉得差点意思。二分太磨叽，Dijkstra 虽优雅却仍要供着一座优先队列的大佛。有没有一种思路，能换个角度，彻底绕开这些麻烦？

深夜 debug 到第 42 杯咖啡时，你突然灵光炸裂：既然我想找一条路，让路上的最小安全值尽量大——那为什么不直接从最安全的格子开始，一个个"点亮"，直到起点和终点连通呢？

这就像玩一款逆向的点灯游戏：地牢里所有格子一开始都是黑的（不可用），你把它们按安全值从高到低依次点亮。每点亮一个格子，就和它四周已经被点亮的邻居连成一片（并查集合并）。当起点 (0,0) 和终点 (n-1,n-1) 第一次被连进同一片区域时——恭喜！那一刻你正在点亮的格子的距离值 d，就是你能获得的最大安全系数。

为什么？因为你按从大到小的顺序点亮格子，当前这一轮点亮的 d 就是已点亮区域里安全值最小的那一档。起点和终点刚好在这一步连通，说明恰好存在一条全程安全值 ≥ d 的路径，而 d+1 的时候它们还不连通。这不就是最优解嘛——无需二分，无需优先队列，一个排序加一个并查集就搞定了。

你兴奋地搓搓小手，准备重新跑一遍多源 BFS ，在算出每个格子到最近小偷的距离时，把所有格子塞进一个 cells 列表里，然后按距离逆序遍历（实际上BFS 天然保证了列表里的格子是按距离递增排列的，逆序就是从大到小，连 sort 都省了），再用一个带 rank 的 UnionFind 类来维护连通性——每点亮一个格子，就和四周已经被点亮的邻居合并，然后检查起点和终点是否在同一个集合里。稳如老狗。

等等。

你你盯着刚跑完的多源 BFS 发了一会儿呆，忽然醒悟：BFS 本身就是按距离一层一层扩散的啊！小偷在距离 0 的层，然后距离 1 的层，距离 2 的层……这分明就是天然的分组！早知如此，在 BFS 的时候顺手把同一距离的格子收集进 groups[d] 里，岂不比事后再排序聪明一百倍？

于是你立即改写 BFS，分层收集格子。等 BFS 结束，你手里不仅有一份安全地图，还多了一份从 0 到最大距离的分层花名册，直接从最大距离倒序遍历，一层一层点亮，连排序的 O(n² log n) 都省成了 O(n²)，常数小到令人发指。

既然分层已天然就绪，你索性把并查集也精简到底：什么 UnionFind 类、花里胡哨的封装统统不要。就一个 fa 数组（list 存父节点），外加一个带路径压缩的 find 函数，一行 fa[x] = find(fa[x]) 搞定一切。合并时直接 fa[find(a)] = find(b)，简单粗暴，却能在近乎 O(1) 的均摊时间内把两个格子所在的区域焊在一起。

先 BFS 分层建图，再逆序点灯 + 极简并查集判定连通，一气呵成。

def maximumSafenessFactor(grid):
 n = len(grid)
 if grid[0][0] == 1 or grid[n-1][n-1] == 1:
 return 0

 # 多源BFS，同时按距离分层 
 dis = [[-1] * n for _ in range(n)]
 q = []
 # 初始化：所有小偷位置入队
 for i in range(n):
 for j in range(n):
 if grid[i][j] == 1:
 q.append((i, j))
 dis[i][j] = 0

 groups = [q] # groups[d]存储所有距离为d的点（分层记录）
 while q:
 tmp = q # 当前层的所有点
 q = []
 for i, j in tmp:
 for x, y in (i + 1, j), (i - 1, j), (i, j + 1), (i, j - 1):
 if 0 <= x < n and 0 <= y < n and dis[x][y] < 0:
 dis[x][y] = len(groups) # 新一层的距离
 q.append((x, y))
 groups.append(q) # 将当前层加入groups

 # 极简并查集 
 fa = list(range(n * n))

 def find(x: int) -> int:
 if fa[x] != x:
 fa[x] = find(fa[x])
 return fa[x]

 # 从最大距离倒序遍历，逐层点亮 
 for d in range(len(groups) - 2, 0, -1):
 # 激活所有距离为d的点
 for i, j in groups[d]:
 # 与四周距离 ≥ d 的已点亮邻居合并
 for x, y in (i + 1, j), (i - 1, j), (i, j + 1), (i, j - 1):
 if 0 <= x < n and 0 <= y < n and dis[x][y] >= d:
 fa[find(x * n + y)] = find(i * n + j)
 # 检查起点和终点是否连通
 if find(0) == find(n * n - 1):
 return d

 return 0

时间复杂度：O(n²)，多源 BFS 分层 O(n²)，倒序点灯并查集近似 O(n²)。空间复杂度：O(n²)。

尾声

三种解法，三种不同的快乐：二分是铁憨憨的稳妥，Dijkstra 是贪心轻功的优雅，并查集分层是逆向思维的通透。

无论你选哪条路，底层都是同一张由多源 BFS 绘制的“安全地图”。它告诉你每个格子离最近的坏蛋有多远，而你要做的，不过是在这张图上用自己的方式写一个“勇者不寄”的故事。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode1358 滑动窗口的一体两面：追安全点 vs 数左端点

Tue, 30 Jun 2026 11:28:05 +0800

滑动窗口的一体两面：追安全点 vs 数左端点

有一个笔直的街道上住着 n 个居民，每个居民只会塞给你一种魔法糖果：a 糖、b 糖或 c 糖。你是一个勇者，想要挑战一个成就：“在一次连续的逛街中，收集齐a、b、c 三种糖果”。规则很简单：你从某个起点居民开始，一路往东走，到某个终点居民结束。如果在这段路程中，你的口袋里三种糖至少各有一颗，就算一次成功的逛街。你想知道整条街上一共有多少种成功的逛街方案（不同的起点‑终点组合）。

首先考虑一种情况：如果整条街上根本没有 a 糖，或者没有 b 糖，或者没有 c 糖，那你无论怎么逛，都不可能集齐三种，答案注定是 0。

但假设三种糖都有，游戏正式开始。

你随便选了个起点 left，口袋空空地出发了。每经过一个居民，就收下他给的糖，并且在一个小本子上记下每种糖的数量。你必须在某处结束逛街，但有个诅咒：如果你在逛街结束的时候，口袋里的糖果种类不足三种，诅咒就会发动，把你变成一只青蛙。所以你必须一直往前走，直到集齐三种糖，才敢停下。

你硬着头皮往前走，直到走到某个站点 right 时，惊喜地发现口袋里的糖果种类终于凑齐了三种！你安全了，可以在这里结束逛街了。更重要的是，你发现只要有了 right这个安全点，在 right之后任何一个站点结束都能保证口袋里的三种糖都只多不少，诅咒永远不会发动。所以以 left 为起点的成功方案，就是从 right 到街道末尾的所有站点数，也就是 n - right 种。

你高兴地记下这个数目。但你是个贪婪的冒险者，怎么能满足于一个起点的统计？你要榨干整条街的剩余价值。于是，你把 left 居民给你的那颗糖无情地扔掉——因为接下来你打算从 left+1 出发，left和她的糖果已经是过去时了。扔掉之后，你瞅了一眼小本子：

如果本子上三种糖的数量都还大于 0，说明即使从 left+1 出发，走到当前的 right 也已经是安全的，你连一步都不用多走，就可以立刻收割同样的 n - right 种方案。于是你美滋滋地把这个数又加了一遍。
如果扔掉 left 的糖后，某种糖的数量变成了 0，口袋里的种类掉回了两种——不好！青蛙诅咒感应到了你的软弱，开始蠢蠢欲动！你吓得赶紧从当前的 right 继续向东跑，一边跑一边收新的糖果，直到再次集齐三种，找到一个新安全点 right'。此时你才长舒一口气，把 n - right' 加入账本。

你就这样不断重复：扔掉最左边起点的糖，如果种类不够三就拼命往右跑，直到再次安全；如果够三种就直接算账。直到你的起点 left 越过了街道尽头，这场与青蛙诅咒的博弈才算结束。而你账本上累加的数字，就是所有的成功逛街方案数。

这个不断调整左起点、右安全点的过程，就是滑动窗口。你的左指针 left 就是窗口左边界，右指针 right 是右边界，窗口里的糖果种类始终维持在“刚好集齐三种”的最左安全位置。每当种类够三，你就用 n - right 收割一波答案，然后左指针右移，窗口收缩；一旦种类掉下去，就立刻扩展右指针去救急。两个指针都只往右不回头，全程 O(n)，完美通关。

def numberOfSubstrings(s: str) -> int:
 n = len(s)
 cnt = {'a': 0, 'b': 0, 'c': 0}
 ans = left = 0

 for right in range(n):
 # 右指针扩展，收下糖果
 cnt[s[right]] += 1

 # 当三种糖果都至少有一颗时，可以安全结束逛街
 while cnt['a'] > 0 and cnt['b'] > 0 and cnt['c'] > 0:
 # 以 left 为起点的所有安全终点数
 ans += n - right

 # 扔掉 left 的糖果，左指针右移
 cnt[s[left]] -= 1
 left += 1

 return ans

时间复杂度：O(n)，每个指针最多移动 n 次。空间复杂度：O(1)，只维护了一个固定大小的计数字典。

上面的思路直白得像刚拿到驾照的新手上路——左指针每次抬离合都担心熄火。你总觉得还能再优雅一点。

你决定换个角度看这个问题。

刚才是固定左端点，辛辛苦苦找第一个合法的右端点。但如果反过来——固定右端点，去找最远的合法左端点呢？

假设你现在站在位置 right，刚收下这颗糖。此时窗口 [left, right] 内三种糖都齐了。那么对于任意一个比 left 还靠左的起点 left'，子串 s[left':right+1] 里的糖果只会更多，肯定也包含三种。

也就是说，以 right 为终点的合法子串数量，恰好就是 left 的值（左端点可以选 0, 1, 2, …, left-1，一共 left 种可能）。这让你想到了一个更优雅的滑动窗口实现——

你不再需要每找到一个安全点就去算 n - right，而是站在每个右端点上，只问一句话——“最靠右的、让窗口刚好不满足三种糖的左边界在哪？”这个左边界就是 left，而 0 到 left-1 统统合法。

于是你可以在一次遍历中，一边往右走一边默默维护这个 left，每走一步就把 left 加到答案里，连内层 while 里收割答案的环节都省了，循环结构更干净。

def numberOfSubstrings(s: str) -> int:
 n = len(s)
 cnt = {'a': 0, 'b': 0, 'c': 0}
 ans = left = 0

 for right in range(n):
 cnt[s[right]] += 1

 # 只要三种糖都齐了，就拼命往右推左边界，直到刚好不齐
 while cnt['a'] > 0 and cnt['b'] > 0 and cnt['c'] > 0:
 cnt[s[left]] -= 1
 left += 1

 # 此时 left 正好是第一个让窗口不满足三种糖的左端点 => 0 到 left-1 都合法，共 left 个
 ans += left

 return ans

时间复杂度:O(n)。空间复杂度:O(1)。

写完你长舒一口气，两个版本都像你的亲儿子一样珍贵。一个追着安全点跑，紧张刺激，像在玩神庙逃亡；一个固定右端点默默计数，像个老会计拨算盘，从容不迫。但无论哪个，青蛙诅咒都只能蹲在街角干瞪眼——你的滑动窗口指针永远不回退，时间复杂度 O(n)，空间 O(1)，一丝破绽都没有。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode1967 村长云服务器 IV：当暴力美学遇上AC自动机

Mon, 29 Jun 2026 15:03:17 +0800

💻村长云服务器 IV：当暴力美学遇上AC自动机！

村长抱着那台熟悉的二手服务器冲进院子，机箱上的标签从’村长云服务器·公测版’ 又升级成了’‘村长云服务器·旗舰版’’——手写字歪歪扭扭，一看就是老头自己拿马克笔描的。风扇还是那个风扇，嗡嗡声堪比直升机，升了版本号没升硬件，典型的“软件升级，硬件抗压”。

“小白！老板娘说抽奖系统现在流量暴涨，用户发的弹幕里老有人刷敏感词！什么’代抽’、‘外挂’、‘假一赔十’——把评论区搞得乌烟瘴气！”村长把显示器往桌上一搁，屏幕上滚动着一条超长弹幕文本，旁边密密麻麻列着一百多个敏感词，从"代抽"到"假货"，从"退款"到"差评"，琳琅满目，活像一本黑话词典。

“老板娘要我上线一个‘敏感词拦截系统’，统计文本里到底命中了多少个敏感词！” 村长咽了口唾沫：“她还说了，如果今天搞不定，就把我的服务器拿去垫桌角！”

我瞥了眼数据范围：word 长度 100，patterns 数量 100，每个模式串长度不超过 100——这任务倒是不难。

暴力一行流

“这不就是找子串吗？”我嘴角一勾，“Python 里有 in 运算符，一行流搞定！看我的 Pythonic 大法——”

def numOfStrings(patterns: List[str], word: str) -> int:
 return sum(p in word for p in patterns)

一气呵成。我得意地晃了晃鼠标，“这就叫站在巨人的肩膀上——哦不，是站在 CPython 的肩膀上！in 运算符底层调用的是 C 实现的字符串查找算法，常数小、效率高，对于这种小规模数据绰绰有余。人生苦短，我用 Python，能一行解决的事，绝不多写第二行！”

话音未落，后脑勺"啪"地挨了轻轻一下——“一行流能 AC，是因为评测机今天心情好，数据没上强度。”

老勇者不知何时已站在我身后，手眼神锐利如刀：“如果 patterns 有十万个，word 长度百万，你这 in 每次都要从头扫描 word。数据量一上去，CPython 的肩膀也扛不住。”

我愣了一下：“呃……十万个模式串？百万长度的文本？老板娘的抽奖系统怎么可能会有这么大流量？”

老勇者微微一笑：“年轻人，格局打开。你现在做的小题，是未来大战的预演。听说过多模式匹配吗？那可是搜索引擎、病毒扫描、内容审核系统的核心武器。今天好好学一招，将来遇到千万级数据就不至于被按在地上摩擦。”

多模式匹配

“小子，听好了。”老勇者从我的本子上撕了张纸，拿起笔就开始画，“在一个文本串中同时查找多个模式串——这叫多模式匹配问题（Multi-Pattern Matching）。对于这种问题，有几把经典武器。”

“第一把，暴力遍历。”他指了指屏幕上的 in 操作符，“就是你刚才那行代码。每个模式串独立扫描 word，相当于派一百个侦探，每个人都要把整栋楼从头搜到尾。数据小的时候确实能用，数据一大，就是百人团灭现场。O(m × n)，不解释。”

“第二把，KMP 单模式优化。”他在纸上画了一排箭头，“预处理模式串，构建一个部分匹配表，在失配时跳过已经匹配过的前缀，避免重复比较。相当于每个侦探都带着一张‘搜过的地方不用再搜’的线索图。但问题是——你还是要派一百个侦探分别搜一遍楼——KMP 只优化了单个侦探的效率，没减少侦探的数量。有 m 个模式串，就要跑 m 次 KMP。”

“第三把：Trie 树（字典树）。”老勇者在纸上又画了一棵树，节点上标满了字母，“把所有模式串插进一棵树里，共享前缀。比如 ‘abc’ 和 ‘abd’，它们的前缀 ‘ab’ 可以共用，走到分叉路口再各走各的。空间换时间。”

他停顿了一下，用笔重重一点：“但 Trie 有个致命缺陷：当你在某个节点失配时，必须回到根节点重新开始。比如你匹配了 ‘abcde’，下一个字符不是 ‘f’，你就得从根节点的 ‘a’ 重新来。文本串的指针要回溯，最坏情况依然是 O(n × m)。相当于侦探走到死胡同，必须跑回大楼入口重新找路。纯 Trie 没有记忆，不会跳跃，只能硬着头皮回溯。”

他扫了我一眼，确认我跟上了节奏，然后在纸的正中央写下四个大字，字迹遒劲有力：

“第四把：AC 自动机（Aho-Corasick Automaton）。”

“多模式匹配的终极武器。”老勇者的声音低沉而充满力量，“ Trie 树 + KMP 失败指针思想的融合体——Trie 负责存储所有模式串，KMP 的失配思想负责处理失配时的跳转。所有模式串构建成一棵 Trie，然后加上两个指针——fail 和 last——让文本串在自动机上只跑一趟，就能同时匹配所有模式串。”

他在 Trie 树上画了一堆虚线箭头：“核心在于两个指针：fail 指针（失配指针） 和 last 指针（后缀链接）！”

Fail 指针：失配时的传送门

“核心一：fail 指针。fail 指针指向的是’当前字符串的最长真后缀’，且这个后缀也是某个模式串的前缀。” 老勇者指了指图上的节点，“当你在当前节点失配（下一个字符不匹配）时，就跳到 fail 指向的节点继续尝试匹配，不需要回到根节点重新开始！”

他顿了顿：“比如你匹配了 ‘abcd’，失配了，fail 指针可能指向 ‘bcd’、‘cd’ 或 ’d’ 对应的节点——具体是哪个，取决于哪个后缀同时也是某个模式串的前缀。”

“这和 KMP 的 next 数组异曲同工，但它是跨模式串的——KMP 只在单个模式串内部跳转，AC 自动机的 fail 可以在不同模式串之间跳跃。相当于侦探在迷宫里走到死胡同，不是传送回城，而是通过密道直接跳到另一条分支上。文本串的指针永不回溯——这是 AC 自动机的灵魂。”

Last 指针：直达模式串末尾的捷径

“核心二：last 指针。”他继续画箭头，“ fail 指针有个小问题：它跳到的节点，不一定是某个模式串的末尾。比如你匹配到 ‘abcde’，fail 指针可能跳到 ‘cde’，但 ‘cde’ 可能只是个中间节点，不是完整的模式串。如果只靠 fail，你还得继续沿着 fail 链一层一层往上跳，直到找到某个模式串的末尾，或者跳回根节点。”

“这时候就需要 last 指针了——后缀链接，直接指向 fail 链上第一个是模式串末尾的节点。如果整条 fail 链上都没有模式串末尾，last 就指向根节点。它相当于 fail 链上的‘直达电梯’——不用一层一层爬楼梯，直接按顶层按钮就到了。”

他笔锋一转：“回到刚才的例子。你站在 ‘abcde’ 节点，想收集所有以当前位置结尾的模式串。先检查自己：如果是模式串末尾，记下来。然后沿着 last 指针一跳，直接飞到 fail 链上下一个模式串末尾（比如 ‘cde’ 如果恰好是某个模式串，last 就指向它）。再检查，再跳，直到跳到根节点为止。整个过程，你只访问了模式串末尾节点，中间那些不是末尾的节点全被跳过了。这就是 O(1) 均摊时间的秘密——每收集一个命中才走一步，零命中零步，十个命中十步。比沿着 fail 链一个一个节点傻找，效率高了一个数量级。”

老勇者放下笔，总结道：“AC 自动机的生命周期分三步。第一步，构建 Trie，把所有模式串插进去。第二步，构建 fail 和 last 指针，BFS 一遍搞定。第三步，查询文本串，逐个读入字符，在自动机上转移状态——失配时靠 fail 跳转，命中时靠 last 收集。时间复杂度 O(n + m + z)，n 是文本长，m 是所有模式串总长，z 是匹配次数。”

他盯着我，一字一顿地说：“看到没？跟模式串数量无关。相当于只派一个侦探，但他脑子里装着所有敏感词的线索地图，还有传送门（fail）和快捷通道（last），搜一遍楼就把所有敏感词全揪出来。”

我听得头皮发麻：“把暴力匹配的重复劳动，通过预处理转化成智能跳转？”

“没错！”老勇者眼中闪过一丝赞许，“AC 自动机的思想非常优雅——它把多模式匹配问题转化成了确定有限状态机（DFA）的问题。你每读入一个字符，就在状态机里转移一次，瞬间就能知道当前匹配到了哪些模式串。这就像玩游戏时开了全图挂+自动寻路，一眼就能看到所有敌人的位置，还能自动规划最优路径。”

我感觉灵光一闪：“AC 自动机就是把 Trie 树上的匹配路径编码成了状态，fail 指针就是失配时的状态转移！”

“悟性不错。”老勇者难得地点点头，“那现在，想不想亲手实现一把这个’全图挂’？”

我摩拳擦掌：“当然！给我代码模板，我要开始抄——哦不，是开始学习了！”

AC 自动机

第一步：定义 Trie 树节点

首先，Trie 树的每个节点代表一个字符，从根节点到某个节点的路径就是一个字符串。需要四个字段：son 数组存储 26 个字母的子节点，fail 是失配跳转指针，last 是直达下一个模式串末尾的后缀链接，cnt 用来记录这个节点是多少个模式串的结尾。"

class Node:
 __slots__ = 'son', 'fail', 'last', 'cnt'

 def __init__(self):
 self.son = [None] * 26 # 26个小写字母的子节点（a-z对应索引0-25）
 self.fail = None # 失配指针：当前字符不匹配时跳到哪里
 self.last = None # 后缀链接：快速跳到下一个一定是模式串末尾的节点
 self.cnt = 0 # 该节点是多少个模式串的末尾（计数器）

第二步：构建 AC 自动机

接下来，把所有模式串插入 Trie 树。这部分和普通字典树一模一样——遍历每个字符，沿着 son 往下走，没有子节点就新建，走到末尾时 cnt++，表示这里是一个模式串的终点。

class AhoCorasick:
 def __init__(self):
 self.root = Node()

 def put(self, pattern: str) -> None:
 cur = self.root
 for ch in pattern:
 i = ord(ch) - ord('a') # 字符转索引
 if cur.son[i] is None:
 cur.son[i] = Node() # 没有这个子节点就创建
 cur = cur.son[i]
 cur.cnt += 1 # 标记这是一个模式串的末尾

“注意看”，老勇者提醒道，“cnt 是累加的。如果 patterns 里有三个 “a”，那么表示 “a” 的那个节点的 cnt 就是 3。这样在查询时，我们一次性就能知道有多少个相同的模式串在这里匹配。”

第三步：构建 fail 和 last 指针（BFS）

“重头戏来了——构建 fail 和 last 指针。这是 AC 自动机的灵魂所在。”老勇者搓了搓手，仿佛在展示什么绝世武功，“用 BFS（广度优先搜索）逐层处理整棵 Trie 树。”

初始化部分：根节点的 fail 和 last 都指向自己，因为根节点没有父节点，失配了也只能回到自己。然后遍历根节点的每个子节点：如果 son[i] 为空，就让它直接指向根节点，形成自循环——这样匹配时遇到不存在的字符能自动回到起点；如果 son[i] 存在，它的 fail 和 last 都指向根节点（第一层节点的 fail 只能是根），然后入队等待后续处理。

def build_fail(self) -> None:
 self.root.fail = self.root.last = self.root # 根节点的 fail 和 last 都指向自己

 q = deque() # BFS 队列 
 # 初始化第一层节点（根的直接子节点）
 for i, son in enumerate(self.root.son):
 if son is None:
 self.root.son[i] = self.root # 虚拟子节点：直接指向根节点，方便后续失配时跳转
 continue
 son.fail = son.last = self.root # 第一层的 fail 和 last 都指向根
 q.append(son) # 入队，后续处理它的子节点

 # BFS 遍历整棵树，逐层构建 fail 和 last 指针
 while q:
 cur = q.popleft() # 取出队首节点
 for i, son in enumerate(cur.son): # 遍历当前节点的26个子节点
 if son is None:
 # 路径压缩：空子节点直接指向 cur.fail 的对应子节点
 # 这样匹配时遇到不存在的字符，一步就能跳到下一个可能匹配的位置
 cur.son[i] = cur.fail.son[i]
 continue

 # 计算 son 节点的 fail 指针：沿着父节点的 fail 链找
 # cur.fail.son[i] 就是"以 cur 的最长可匹配后缀为前缀，且下一个字符也是 ch 的节点"
 son.fail = cur.fail.son[i]

 # 计算 son 节点的 last 指针：直达下一个一定是模式串末尾的节点
 # 如果 fail 节点本身就是某个模式串的末尾（cnt > 0），last 就指向 fail
 # 否则指向 fail.last，继续沿着后缀链接往上找
 son.last = son.fail if son.fail.cnt else son.fail.last

 q.append(son) # 处理完当前节点，把它加入队列，后续处理它的子节点

我挠挠头，指着那行 cur.son[i] = cur.fail.son[i] 问：“等等，这里为什么要修改 son 数组？这不是把原来的 Trie 树结构改了吗？”

“这就是路径压缩的精髓！”老勇者眼睛一亮，“原本如果 son[i] 为空，匹配时你得手动沿着 fail 链一层层往上找，直到找到某个节点有 son[i]。现在直接把空子节点指向 cur.fail.son[i]，匹配时不管 son[i] 存不存在，直接 cur = cur.son[i] 跳过去就完事——要么是真正的子节点，匹配成功；要么是 fail 链上的后备节点，失配后跳转到下一个可能位置。省掉了中间跑路的时间，一步到位。”

第四步：查询文本串

最后是查询阶段。从根节点出发，遍历 word 的每个字符。因为路径压缩了，son[i] 总有值——要么是真正的子节点，要么是 fail 链上的后备节点——所以直接 cur = cur.son[i] 就行，全程不需要手动判断失配。每到一个新节点，沿着 last 链收集所有命中的模式串。

class Solution:
 def numOfStrings(self, patterns: List[str], word: str) -> int:
 ac = AhoCorasick()
 for pattern in patterns:
 ac.put(pattern) # 把所有模式串插入 AC 自动机
 ac.build_fail() # 构建 fail 和 last 指针

 ord_a = ord('a')
 cur = ac.root # 当前状态，从根节点开始
 ans = 0 # 统计匹配的模式串数量

 # 遍历文本串的每个字符
 for ch in word:
 cur = cur.son[ord(ch) - ord_a] # 自动机转移，无需判空 
 match_node = cur
 while match_node.cnt >= 0: # cnt >= 0 表示这个节点还没被统计过
 ans += match_node.cnt # 累加这个节点是多少个模式串的末尾
 match_node.cnt = -1 # 标记为已统计，避免重复计数
 match_node = match_node.last # 跳到下一个可能是模式串末尾的节点

 return ans

我盯着那个 while match_node.cnt >= 0 的循环问：“为什么要标记为 -1？这个循环是在干嘛？”

“避免重复统计同一个模式串。”老勇者解释道，“假设 patterns = ["a", "ab", "abc"]，word = "abc"。当匹配到 'c' 时，当前节点表示 "abc"，它本身是模式串末尾，cnt=1；它的 last 链可能指向 "ab" 对应的节点，也是模式串末尾；继续沿着 last 链走，可能还指向 "a" 对应的节点。需要沿着这条链把所有匹配的模式串全统计一遍。”

“但需要统计的是‘patterns 中有多少个字符串是 word 的子串’，而不是‘总共匹配了多少次’。如果 word 后面又出现了一个 "abc"，你不能把 "abc" 再算一遍。所以第一次匹配到时，把 cnt 累加到答案，然后立刻标记为 -1——之后不管 word 里再出现多少次 "abc"，while 循环的条件 cnt >= 0 都不满足，直接跳过。这就叫‘见一次就标记，绝不重复计数’。”

“哦！”我恍然大悟，“last 链负责一次匹配中收集所有命中的模式串，cnt = -1 负责跨匹配去重——两条机制，一个管纵向深度，一个管横向广度，完美配合！”

“没错！”老勇者赞许地点点头，“这下你真懂了。”

尾声

提交，AC！这次不是靠 CPython 的肩膀，而是靠自动机的铁拳——文本串只扫一遍，跟模式串数量无关。

p in word 的暴力一行流，每次 in 都是独立的扫描，相当于给每个敏感词派一个侦探，让他们各自为战，每个人都要把整栋大楼从头到尾搜一遍；而 AC 自动机，则是把所有的扫描合并成了一次遍历——只派一个侦探，但他脑子里装着所有敏感词的线索地图，脚下踩着传送门（fail 指针），手里拿着快捷通道（last 指针），搜一遍楼就能把所有敏感词连锅端！从 O(m × n) 到 O(n + m)，差距不是常数倍，是数量级的碾压。

“好！好！好！”村长看着运行结果，乐得合不拢嘴，一把抱住那台还在嗡嗡作响的二手机箱，“这下服务器保住了！我的‘村长云旗舰版’不用去垫桌角了！”

他激动地抹了把眼泪，但随即又凑到我身边，搓着手问道：“小白啊，真遇到大规模流量——比如老板娘的抽奖系统突然爆火，同时有十万个用户在线疯狂刷屏，老板娘要拦截十万个敏感词、处理百万字的文本……就用这个 AC 自动机，顶得住吗？”

我看着他那张写满担忧的脸，忍不住笑了：“村长，把心放回肚子里！AC 自动机的时间复杂度是 O(n + m + z)——跟模式串的数量完全无关！就算有一万个敏感词，也只是 Trie 树稍微大一点，查询的时候，文本串依然只需要从头到尾扫一遍！”

我瞅着屏幕上的AC自动机，掷地有声地说：“有了 AC 自动机，以后就算流量翻十倍、一百倍，你的服务器也照样扛得住！”

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode1846 数组变形记：从混乱到有序的贪心进化

Sun, 28 Jun 2026 16:41:39 +0800

数组变形记：从混乱到有序的贪心进化

你是一个肝帝玩家，背包里塞满了各种等级的装备——从+1的破烂新手剑到+999的传说级神器，应有尽有。

游戏规则：

你可以把装备降级（+999→+1，血亏但没办法，就当被策划砍了一刀）
可以调整穿戴顺序（今天想当萌新，明天想装大佬）
第一件装备必须是 +1（新手村规定，大佬也得从菜鸟做起）
相邻装备等级差不能超过 1（你不能穿着+1的内裤，外面套+999的铠甲，NPC会报警的）

问：你这波骚操作下来，最高能凑出多少级的装备？

这其实是个**「贪心算法」**的经典套路——就像玩《文明6》铺城，你总想把科技值堆到最高，但每个城市只能研究相邻的科技树，不能跳级。你想让最后一个城市科技等级最高？那得从头开始规划，一步一个脚印。

V1.0：贪心 + 排序

既然可以任意重排，那最直观的思路就是从小到大排序。为什么？

想象你在搭一座楼梯，每级台阶最多比上一级高 1。你手里有一堆高度不同的砖块，只能削不能垫（这什么奇葩施工队？）。你想让楼梯尽可能高，是不是应该：

先把矮砖放前面当底座（+1 的新手砖）
高砖放后面冲顶（+999 的传说砖，可能被削成 +5）

你要是反过来，把 +999 的砖放第一块，对不起，规则说第一块必须是 +1，你直接血亏 998 级。把高砖放前面，后面接个矮砖，瞬间断档，就像你穿了神装头盔，脚上还是草鞋，整体战力被短板卡死，白瞎了前面的高等级。

这就是贪心的本质：排序后，让每个位置尽可能贴近上界。

def maximumElementAfterDecrementingAndRearranging(arr: List[int]) -> int:
 arr.sort()
 arr[0] = 1
 for i in range(1, len(arr)):
 arr[i] = min(arr[i], arr[i-1] + 1)
 return arr[-1]

就像打 Boss 时的连招系统：你必须按顺序出招，每一招的伤害不能超过上一招 +1，但你可以通过"降伤"来保证连招不断。最终你的总伤害取决于连招长度和每一步的上限。

时间复杂度 O(n log n)，空间复杂度 O(1)（如果不算排序的栈空间）。

但是！这个解法需要修改原数组。作为一个有洁癖的程序员，你眉头紧锁——在真正的工程里，修改入参就像在多人协作时擅自改别人代码——万一其他线程还在读这个数组呢？万一上游调用方还指着原始数据做日志呢？这感觉就像你在《魔兽世界》团队副本里，突然把坦克的装备全换成布甲——团灭只在一瞬间。

更何况，每次循环都要访问 arr[i-1]，虽然没啥性能问题，但总让人觉得代码有点"紧耦合"，不够优雅。就像你写代码时非要依赖上一个函数的返回值，而不是用参数传递，调试的时候能让你怀疑人生。

于是你开始琢磨：能不能不碰原数组，用一个变量来搞定？

V2.0：极简贪心，状态压缩

让我们来做个状态压缩：我们真的需要知道数组的具体形态吗？

不需要！我们只需要知道**“当前能构建的最大值”**是多少——这就像玩游戏时，你只看角色等级面板上的数字，不需要记住他穿了什么装备、背包里有什么道具——等级是核心状态，装备只是实现细节。

也就是说，把状态压缩成一个变量 ans，初始为 0（还没开始构建）。然后遍历排序后的数组：

如果当前元素 a > ans：说明我们可以用它来把 ans 提升 1（因为相邻差 1，所以最多 +1）
否则：这个元素太小或刚好，无法帮助我们提升最大值，直接跳过——就像打《原神》时抽到重复角色，虽然有点用（可以当狗粮），但不能让你突破等级上限。

def maximumElementAfterDecrementingAndRearranging(arr: List[int]) -> int:
 arr.sort() # 先排个序，从小到大排列
 ans = 0 # 当前能达到的最高等级（初始为 0，新手村都没出）
 for a in arr: # 遍历每个装备
 if a > ans: # 如果这个装备等级 > 当前最高等级
 ans += 1 # 那就能提升 1 级（贪心：能升就升，绝不客气）
 return ans # 返回最终等级

你品，你细品：这不就是《文明6》里的科技树吗？你每研究一个前置科技，下一个科技才能解锁。如果你的科技点（a）大于当前时代（ans），你就可以进入下一个时代（ans += 1）。如果小于等于，说明你卡科技了，等下一轮吧。

空间复杂度：O(1)，只用了一个变量 ans，环保且不修改原数组，线程安全！

但是！排序法始终有一个痛点：O(n log n) 的时间复杂度。对于 n=10^5，虽然也够用，就像你用60Hz显示器打游戏，能玩——但作为一个有追求的程序员，你怎么会满足于此？——毕竟，性能优化就像游戏里的"帧数提升"，能 60 帧绝不 30 帧，能 O(n) 绝不 O(n log n)。

V3.0：计数排序 + 桶思想

我们其实不需要完整的排序。

为什么？因为最终答案的上界就是 n（数组长度），我们最多构建出 [1, 2, 3, ..., n]，最大值就是 n。

为什么答案上界是 n？因为数组长度为 n，最理想情况就是 [1, 2, 3, ..., n]，最大值 = n。即使所有元素都是 10^9，你也只能构建出 1, 2, 3, ..., n 这样的序列，最大值就是 n。所以，大于 n 的元素和等于 n 的元素没有区别——它们都只是“足够大的砖块”，都可以用来帮你一步步往上堆。

这就像给酒店分配房间：不管客人多有钱，最多只能住总统套房（第 n 层）。再有钱也只能住那里，不能住到天上去。

既然值域有限（1 ~ n），那我直接空间换时间，上计数排序（桶排序）！

不需要玩什么快排归并，直接用桶统计每个值出现多少次。因为值域是 n，所以计数数组长度也就是 n+1，小得可怜——对于 n=10^5 来说，开个 100001 大小的数组，也就几百 KB。

核心思路分三步：

第一步：统计资源遍历原数组，把每个元素塞进对应的桶里：如果值 <= n，直接计入对应的桶 cnt[value] += 1 如果值 > n，统一计入 cnt[n] += 1（总统套房原则：再有钱也只能住顶层）
第二步：贪心升级从 1 到 n 依次处理每个桶，用贪心的思想计算能达到的最大值。我们希望构建的序列是 1, 2, 3, 4, 5, …，每遇到一个足够大的元素，ans 就 +1。用计数数组 cnt[i] 表示有多少个元素的值可以用来构建等级 i。当我们处理到值 i 时，我们有 cnt[i] 个"资源"可以用来把 ans 往上推。但 ans 不能超过 i，因为你最多只能构建到 i——就像你手里只有 1 到 5 级的砖块，再怎么堆也堆不出 6 级台阶。这是规则限制，不是技术问题。
第三步：返回答案遍历完所有桶后，ans 就是最终能达到的最高等级。

def maximumElementAfterDecrementingAndRearranging(arr: List[int]) -> int:
 n = len(arr)
 cnt = [0] * (n + 1) # 计数桶，下标 0 不用，1~n 有效
 for a in arr:
 cnt[min(a, n)] += 1 # 大于 n 的统统塞进 n 号桶（总统套房）
 ans = 0
 for i in range(1, n + 1): # 从 1 到 n 依次处理
 ans = min(ans + cnt[i], i) # 用资源提升，但上限是 i
 return ans

用 O(n) 的桶，换掉 O(n log n) 的排序。就像你在游戏里用“氪金”换“肝度”：虽然花了点空间（桶），但时间上直接起飞——从 O(n log n) 降到 O(n)。

收工！

从O(n log n)肝到O(n)，从"改入参"进化到"只读不写"，从"看装备"抽象到"只看等级"——这波优化就像给游戏换了块RTX 4090，丝滑得不像话。

刷完题，你信心满满地打开《艾尔登法环》，准备把"贪心策略"用在Boss战上：先打简单的攒资源，再去挑战女武神。然后发现自己被一锤子砸回篝火——游戏里的Boss根本不吃你这一套，该秒还是秒，管你+几的装备。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3020 平方峰过山车：平方峰上顶点单，指数飞升序列短

Sat, 27 Jun 2026 17:53:51 +0800

🎢平方峰过山车：平方峰上顶点单，指数飞升序列短

今天一早，村长的飞鸽传书就砸在我桌上——那个奇奇怪怪游乐园又来新活了。上次锯齿过山车的奖金还没结清呢，这次又搞了个什么姐妹项目——平方峰过山车！

“又是过山车？这游乐园是跟过山车杠上了还是预算只够建一种项目？” 我展开任务书，只见上面画着一张极其诡异的设计图——轨道中间高、两边低，还不是均匀分布的，像一座被镜子对折过的陡峭山峰！

“这爬坡方式也太反人类了吧！从起点开始，每次不是乘2，是平方！平方！x变成x²，再变成x⁴，一路指数爆炸往上飙，到了峰值再对称地开方降回来——起步是2G的推背感，到山顶直接变成256G，是要把乘客压成二维生物吗？！”

平方峰过山车设计规范：

从数组 nums 中选子集，使子集的元素能排成这样的对称模式：[x,x²,x⁴,...,x^k,...,x⁴,x²,x]

也就是说，先不断平方上升到顶，再对称下降

例如：[2, 4, 16, 4, 2] 、[3, 9, 3] 都符合；但 [2, 4, 8, 4, 2] 不符合（8 不是 4 的平方）

目标：找出能满足这个模式的最大子集的大小。

“这帮人是不是对‘刺激’有什么误解？”我忍不住吐槽，“重力加速度不够，用平方来凑？别的游乐园追求的是‘游客的欢笑’，他们追求的是‘游客的尖叫和扁平化’！”

但我目光下移，突然看到了村长在图纸最下方用红笔加粗的一行小字：

村长注：nums 长度最大 10^5，每个数最大 10^9。奖金翻倍！务必搞定！！

“奖金翻倍……”我盯着那四个字，原本吐槽的嘴瞬间闭上了。上次锯齿过山车的钱还没到账，这次翻倍——虽然不知道基数是多少，但翻倍这个词就像游戏里爆出双倍经验卡一样让人心跳加速。

我十指交叉，发出一声清脆的响声，脑子迅速活动起来——这模式有个致命的特点：序列关于正中心对称。

第一步：对称结构

对称意味着配对，配对意味着频次。序列里除了中心点可以独一份，其他所有值都必须成对出现。

也就是说，对于[x, x², x⁴, …, x^k, …, x⁴, x², x]，除了山顶那个峰值可以独一份，其他所有值都必须成对出现（左右各一个）。所以，答案一定是个奇数：峰值占一个，左右各一对占两个，像一座完美的山峰。

结构搞清楚了。那直接暴力枚举每个数作为起点，不断平方往上找，统计最长合法序列，可行吗？

问题是：枚举每个数作为起点的时候，这个序列会往上爬多高？

第二步：平方增长是最强剪刀

我盯着那个“平方”操作——平方增长是什么概念？2 平方变 4，4 平方变 16，16 平方变 256，256 平方变 65536，65536 平方直接炸穿 10^9。从最小的 2 开始，平方五次就超过任务给出的数值上限了。也就是说，序列的长度绝对不会超过 2×5+1=11——才十一个元素！

这意味着暴力枚举每个不同的数作为起点时，最多只需要尝试 5-6 次平方操作！总计算量完全可控。平方增长简直就是最强的剪刀，一刀把指数级可能性砍成了常数级。

“先搞个哈希表统计每个数字出现的次数。”我掏出键盘，“然后对每个数字进行’攀登’，取最大的序列长度！”

第三步：特判 1

等等——手指悬在键盘上，一个极其特殊的数字从脑子里蹦了出来： 1！——1 的平方永远是 1，如果把它当成普通数字处理，平方操作会陷入死循环！

1 必须单独处理，不能进入循环。序列里可以塞任意多个 1，但任务要求选子集，1 的个数受限于数组里实际出现了多少个 1。如果数组里有 5 个 1，最多取 5 个排成 [1,1,1,1,1]；如果有 4 个 1，最多取 3 个——因为中心点要独一份，两侧必须对称。所以，1 的答案就是：奇数直接取，偶数减一。

搞定 1 这个特例，把它从哈希表里踢出去，防止后续循环踩坑。

第四步：暴力枚举

剩下的逻辑就清晰了：枚举每个不同的数作为起点 x，尝试不断平方，看能爬多高。

from collections import Counter

class Solution:
 def maximumLength(self, nums: list[int]) -> int:
 cnt = Counter(nums)

 # 特判 1：1的平方还是1，只能取奇数个
 ans = (cnt[1] - 1) | 1 # 偶数减一，奇数不变
 del cnt[1] # 处理完1，踢出去，防止死循环

 for num in set(nums):
 if num == 1:
 continue # 1 已经处理过了

 res = 0
 temp = num
 # 只要当前数至少有2个，就可以左右各放一个
 while cnt.get(temp, 0) >= 2:
 res += 2 # 左右各一个，+2
 temp *= temp # 平方，继续上升

 # 退出循环时，检查顶点是否存在
 ans = max(ans, res + (1 if cnt.get(temp, 0) >= 1 else -1))

 return ans

O(n) 统计频次，O(n · log log M) 暴力扩展——M 是最大值 10^9，最大序列长度不超过 11，总复杂度约等于 O(n)，干净利落。

村长拿着结果，乐颠颠地往游乐园方向跑了，说这次要是能把锯齿过山车的尾款和平方峰的翻倍奖金一起讨回来——他就给那台二手服务器换个静音风扇。看着老头的背影消失在村口，我忍不住开始好奇这个游乐园的策划到底是什么来头。

锯齿过山车好歹还是线性增长，相邻节点差不超过1，轨道起伏有规律可循；到了平方峰，直接放飞自我，起步就是平方，指数爆炸往上飙，到了峰值再开方降回来。这脑回路，策划怕不是从数学系毕业的——乘客不在他们的考量范围内，他们在乎的是“这个递推式够不够漂亮”。

平方峰上顶点单，指数飞升序列短。 数字一哥提前踢，暴力枚举直通关。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3739 村长云服务器 II：三年日志又何妨，哈希O(n)镇全场

Fri, 26 Jun 2026 11:25:42 +0800

🖥️ 村长云服务器 II：三年日志又何妨，哈希O(n)镇全场

上回说到，村长的二手服务器靠着我从暴力到前缀和再到哈希增量的三重大法稳住了阵脚，故障窗口一个不少全揪了出来。老头抱着服务器乐颠颠地去找老板娘邀功。我当时拍着胸脯吹了牛，说三十年也照跑不误。

才过了一天，牛就真找上门了。今天一大早，村长又抱着那台熟悉的二手服务器冲进来，机箱上的标签竟从“村长云服务器·内测版”升级成了“村长云服务器·公测版”，只是那风扇的咆哮声听起来，像是随时准备原地起飞。

“小白！老板娘看了昨天的故障窗口报告，非常满意！”村长把显示器往桌上一搁，屏幕上的日志流像瀑布一样疯狂刷屏，滚动速度快得能闪瞎眼，“ 她说‘村长云果然靠谱’，反手就把抽奖活动的规模扩大了十倍！现在不只是小卖部，全村五十家商铺都用上了我的服务器！”

村长擦着额头的汗，“而且这只是开始！老板娘说活动要持续一个月，到时候日志量可能突破百万！我昨天不信邪，想试试你最开始那个暴力法还能不能跑——就是你写的第一版，双重循环那个——结果……”他咽了口唾沫，心有余悸地说，“跑了三分钟还没出结果，老板娘差点就要换老李的服务器了！”

我接过显示器，扫了一眼数据范围：n = 10^5。十万条日志。暴力O(n²)肯定会被创飞，但昨天在老勇者的点化下，我已经提前从O(n²)一路优化到O(n log n)再到O(n)，哈希表+动态维护f的终极版本就躺在我的魔法书里。

“村长，您这不是自找苦吃吗？”我靠在椅背上，连袖子都懒得撸，“明明昨天老勇者已经把终极法宝塞您眼前了，您偏要回去翻那本已经淘汰的暴力秘籍。“

我调出昨天哈希表+增量维护的终极版本。cnt是哈希表，记录每种前缀和出现了几次；s是当前前缀和，f是动态维护的变量，每步更新只需O(1)。一趟遍历，没有嵌套循环，没有二分查找。一个字符都不用改，直接复制粘贴。

from collections import defaultdict

class Solution:
 def countMajoritySubarrays(self, nums: List[int], target: int) -> int:
 cnt = defaultdict(int) # 初始化哈希表，记录每个前缀和出现的次数
 cnt[0] = 1 # 哨兵：还没开始时的前缀和为0，出现1次

 ans = s = f = 0 # ans最终答案，s当前前缀和，f当前合法起点个数
 for num in nums:
 if num == target:
 f += cnt[s] # s 即将变成 s+1，原本前缀和等于 s 的那些起点现在都合法了
 s += 1 # 更新前缀和
 else:
 s -= 1 # 先更新前缀和
 f -= cnt[s] # s 已经变成 s-1，原本前缀和等于 s-1 的那些起点现在不合法了
 ans += f # 累加当前位置的贡献
 cnt[s] += 1 # 将当前前缀和的出现次数加1

 return ans

提交，AC。“看到没？”我拍着屏幕上那段哈希表代码，像个刚打赢Boss的菜鸟勇者，“这就是昨天老勇者敲出来的终极奥义——步长±1，增量维护，哈希O(1)查找！整体O(n)通关！O(n)是什么意思？就是日志量翻十倍，时间也只翻十倍！昨天几千条跑了几毫秒，今天十万条顶多也就几十毫秒！”

村长盯着代码里的cnt[s]和f变量，挠了挠头：“等等，让我捋捋……遇到FAIL就s -= 1然后f -= cnt[s]，遇到SUCCESS就f += cnt[s]然后s += 1——每次更新只要O(1)，一趟循环完事？就这么简单？”

“就这么简单！步长±1这个性质，让原本需要SortedList二分查找的操作，退化成了加减法。不是数据结构选得好，是数据变化的规律挖得深——老勇者原话。”

村长若有所思地点点头，然后问了一个让我差点从椅子上摔下来的问题：“那如果老板娘把活动搞到太阳系毁灭呢？日志量无限大怎么办？”

“理论上，只要磁盘能存下，O(n)就能跑。磁盘存不下的话——那就不是算法的问题，是您该给服务器加硬盘了。或者换个老板娘，让她别把活动搞那么大。”

看着村长抱着服务器远去的背影，我靠在椅背上，脑海中回放着这两天的算法之旅，从O(n²)到O(n)，三步进化：

暴力枚举 O(n²) ：双重循环，硬刚所有子数组。直观但低效，像用放大镜在沙漠里数沙子。
前缀和+SortedList O(n log n)：把区间问题转成查询问题，用平衡树加速。快了不少，但要在红黑树里爬来爬去。
前缀和 + 哈希增量 O(n)：抓住步长±1的命门，用变量f动态维护。不再依赖重型数据结构，像直接开了上帝视角，一步到位。

三步进化，是一场思维方式的三重升级——从“暴力硬刚”到“找规律走捷径”，从“依赖重型数据结构”到“洞察数据本质”。

脑子一旦转起来就停不住。今天十万条的日志O(n)秒过，但如果老板娘的需求继续升级呢？

如果老板娘再搞大点——全村五十家商铺、每人每秒都在抽奖、日志量破亿——单机O(n)迟早撞上物理天花板。到时候就得把日志分片，扔到多台服务器上并行处理——每台机器独立算自己那段的净胜球前缀和，最后汇总的时候要处理跨分片边界的区间。这个“跨片合并”才是分布式最难啃的骨头，搞不好要请MapReduce出山。

或者老板娘换了个需求——不要离线统计了，要实时监控，每秒刷新一次故障窗口数量——那哈希表就不够用了，得上支持动态前缀和查询的结构——树状数组或者线段树，每次日志写入O(log n)更新，每次查询O(log n)出结果。从离线批处理变成在线流式，数据结构跟着需求一起升级。

再或者，老板娘不仅想知道故障窗口有几个，还想知道“最长的故障窗口有多长”、“故障密度最高的时间段在哪里”——那光靠f变量就兜不住了，得上更复杂的状态追踪，最长窗口、密度峰值，每一个新需求都是一个新的算法副本。

我突然感觉背上一片冷汗——倒不是被这些未来需求吓的，而是忽然意识到，算法工程师的日常，就像是一条永不停歇的日志流。需求来的时候像是 DDoS 攻击，流量瞬间爆表，CPU 直接拉满；开发的时候像在打一个无限副本的 Boss，刚交完差还没来得及存档，产品经理就带着新需求闪亮登场了——发需求的时间复杂度是O(1)，随时随地，想到就来；而客户的想象力空间复杂度是O(∞)，永不封顶，比老板娘的抽奖活动还能膨胀。

不过转念一想，昨天不也是从O(n²)一路进化过来了吗？兵来将挡，需求来了解法挡。

三年日志哈希扛，昨日神功今上场。 客户之心深似海，日日精进破新墙。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3737 村长云服务器危机：从暴力枚举到哈希增量的三重奏

Thu, 25 Jun 2026 14:12:59 +0800

🎮 村长云服务器危机：从暴力枚举到哈希增量的三重奏

“小白！我搞了台二手服务器！” 今天一大早，村长抱着一个嗡嗡作响的铁盒子冲进来，机箱风扇发出拖拉机般的轰鸣声。机箱上贴着歪歪扭扭的标签——村长云服务器·内测版，旁边还画了一个丑萌丑萌的云朵图案。

他把显示器往桌上一搁，屏幕上是一条不断刷新的日志流，每行要么是绿色的"SUCCESS"，要么是红色的 “FAIL”，密密麻麻地滚动着，像黑客帝国里的代码雨。

“你看这个监控系统，”村长指着屏幕，自豪中带着几分心虚，“它每秒记录一次请求状态——成功或者失败。小卖部老板娘把她的抽奖系统挂在我这台服务器上了，结果运行了三天，抽奖页面崩了五回！”

他压低声音，神色紧张：“老板娘说如果再崩，她就换隔壁村老李的服务器。我得找出所有出问题的时间段，证明我的服务器只是‘短暂波动’，不是‘性能不行’！”

我凑近一看，日志已经跑了好几千条，密密麻麻的绿色和红色交替闪烁，像一棵圣诞树。村长调出一个运维面板，上面写着故障判定规则：

如果一段连续时间内，失败请求的次数超过总请求数的一半，这段区间就是“故障窗口”。

“也就是说，我需要统计所有可能的故障窗口，看看哪些时间段服务器最脆弱——” 村长搓着手，一脸殷勤地看着我，“小白，你不是最擅长统计什么‘子数组个数’吗？帮我算算？算完了我给你充一百块服务器体验券！”

我盯着屏幕上的日志流：“这不就是把 FAIL 当成 target，SUCCESS 当成其他元素，找所有 target 出现次数超过一半的子数组吗——" 于是，我拍拍胸脯，自信地说：”村长，没问题！净胜球统计，FAIL +1，SUCCESS -1，净胜球大于 0 就是故障窗口。先上暴力跑通逻辑！“

第一幕·暴力初探

双重循环枚举所有可能的连续时间段（也就是所有子数组）。外层循环定起点，内层循环往后扩展，同时维护一个净胜球计数器cnt——遇到target就+1，遇到非target就-1。cnt大于0的瞬间，说明从起点到当前位置这段区间里，target的出场次数已经压过了其他元素，故障窗口成立，答案加一。

def countMajoritySubarrays(nums: List[int], target: int) -> int:
 n = len(nums)
 ans = 0
 for i in range(n): # 枚举子数组的起始位置
 cnt = 0 # target 相对于其他元素的净胜球
 for j in range(i, n): # 枚举子数组的结束位置
 cnt += 1 if nums[j] == target else -1 # 如果是target，+1；否则-1
 if cnt > 0: # 如果target的净胜球大于0，说明它是主要元素
 ans += 1 # 计数器加1
 return ans

跑了一遍样例——完美。我正准备提交，瞥见村长的服务器日志已经跑到了好几千条，红色的 FAIL 和绿色的 SUCCESS 还在屏幕上疯狂滚动。“村长，您这日志数据量多大？”我问道。

“不多不多，目前才几千条，”村长摆摆手，一脸轻松，“不过老板娘说抽奖活动要持续一年！每天都有新日志！到时候我这’村长云’的数据量可是海量的！”

我心里暗暗叫苦——几千条用 O(n²) 还能扛住，但一年下来怕是能积累到十万条甚至更多——那时候就是上百亿次操作了。O(n²) 的暴力法绝对会炸，连渣都不剩。

“不行，我得提前想好优化方案。”我盯着代码里那个 cnt 变量，陷入了沉思。

第二幕·前缀和+SortedList

暴力法的瓶颈很明显：对于每一个起点i，暴力法都要从i出发一步一步往右走，边加边判——相邻两个起点 i 和 i+1 之间，大量中间计算结果被白白扔掉了。明明[i, j]和[i+1, j]的净胜球只差nums[i]这一个元素的贡献，但暴力法把整段重新算了一遍。重复计算，O(n²)的万恶之源。

如果能用什么东西把“从开头到某个位置”的净胜球存下来，那任意区间[i, j]的净胜球就变成了两个值的减法。等等——这不就是前缀和吗！

我在草稿纸上快速推导：

定义 prefix[k] 为前 k 条记录的净胜球，prefix[0] = 0，表示还没开始时的空状态。

对于任意区间 (i, j]，它的净胜球就是 prefix[j] - prefix[i]。

要让它成为故障窗口，需要 prefix[j] - prefix[i] > 0，

移项得：prefix[j] > prefix[i]

“对于每个位置 j，我不再需要枚举所有可能的起点 i，而是只需要统计前面有多少个位置的前缀和小于 prefix[j]！”

原本要枚举所有子数组的问题，现在变成了一个动态查询问题——随着遍历的进行，不断维护一个历史前缀和的集合，并快速查询“有多少个历史值小于当前值”。

用什么数据结构存前缀和来支持快速查询呢？我在脑子里飞快地过了一遍：普通数组？查询需要遍历，O(n)，pass。排序数组？插入需要移动元素，还是 O(n)，pass。平衡二叉搜索树——插入和查询都是 O(log n)，完美！Python 标准库里虽然没有平衡树，但 sortedcontainers 里的 SortedList 就是这个角色的天选之子——内部维护有序列表，支持 O(log n) 的二分查找和插入，简直是给这道题量身定做的！

思路瞬间清晰起来：

初始化一个 SortedList，放入初始前缀和 0（对应prefix[0]，表示还没开始时的状态）
遍历数组，维护当前前缀和 s：如果当前元素是 target，前缀和 +1；否则 -1
对于每个位置，用 bisect_left(s) 查询有多少个历史前缀和小于 s，累加到答案中
将当前前缀和 s 加入 SortedList，供后续位置查询。

from sortedcontainers import SortedList

def countMajoritySubarrays(nums: List[int], target: int) -> int:
 sl = SortedList([0]) # 初始化前缀和有序列表，包含哨兵0
 ans = s = 0 # ans是答案，s是当前前缀和
 for x in nums:
 s += 1 if x == target else -1 # 更新前缀和
 ans += sl.bisect_left(s) # 查找小于s的前缀和个数
 sl.add(s) # 将当前前缀和加入有序列表
 return ans

提交，AC弹出来的速度比服务器日志刷新还快。暴力到有序，时间复杂度就从 O(n²) 降到了 O(n log n)！就算日志增长到十万条，也能在合理时间内算完！

村长看着运维面板上标注出来的故障窗口，乐得合不拢嘴：“这些时间段的故障窗口果然集中在下半夜！我就说下半夜没人值班，服务器自己跑着跑着就崩了！看老板娘还怎么怪我的二手服务器不行！”

“数据结构的力量！” 我得意地晃了晃鼠标，“能用 O(n log n) 绝不用 O(n²)，能秀操作绝不写普通代码。村长，您这二手服务器配上我这优化算法，就是生产级稳定性——” 话还没说完，后脑勺挨了精准的一下。

第三幕·哈希表 + 动态维护

“SortedList 都掏出来了，有长进。”老勇者扫了眼屏幕上那段 SortedList 代码，嘴角微微上扬。

“O(n log n) 能过，”他话锋一转，“但你这还是在用有序结构做查找。SortedList 内部维护了一棵红黑树，每次插入和查询都要在树里走一圈，常数因子不小。”

我愣了一下：“什么意思？这可是 O(n log n) 的高效算法啊！”

老勇者拿过笔，在纸上画了一条上下波动的折线，“你仔细看，你这前缀和 s 每次怎么变的？”

“遇到 target 加一，遇到非 target 减一。步子很小，每次只变 ±1。”

“这就是关键——步子很小。”老勇者用笔尖在折线上点了点，“你想过没有，既然 s 每次只变化 1，那’有多少个历史前缀和小于 s’这个数量，是不是也不需要每次都重新计算？”

我皱起眉头：“不重新计算？s 变了之后，符合条件的历史位置会变啊……”

“没错，但它们的变化是有规律的。”老勇者眼中闪过一丝狡黠，“如果你维护一个变量 f，表示’以当前位置为右端点时，满足 prefix[i] < s的左端点个数’。当 s 变化时，f 不需要从头算——它只需要做一次增量更新。”

我若有所思：“增量更新？每次加多少，减多少？”

“看 s 怎么变。”老勇者在纸上写下递推关系，“如果当前元素是 target，s 会增加 1，变成 new_s = s + 1 。原来那些前缀和 < s 的 i 依然满足条件。此外，那些前缀和恰好等于s 的 i ，现在也满足条件了——因为 s < new_s 。”

他停顿了一下，盯着我问：“所以，f 应该增加多少？”

我脑子飞速运转：“应该增加……那些前缀和恰好等于 s 的历史位置个数？”

“正是！”老勇者满意地点头，“如果我们用一个哈希表 cnt 来记录每个前缀和出现的次数，那么 cnt[s] 就是前缀和恰好等于 s 的历史位置个数。所以当 s 增加 1 时，f 应该增加 cnt[s]。”

老勇者又把笔尖折向下方：“反过来，如果当前元素不是 target，s 会减少 1，变成 new_s = s - 1。原来那些前缀和< s 的历史位置中，那些前缀和恰好等于 new_s（也就是 s - 1）的位置，现在不再满足条件了——因为现在要求的是小于 new_s，而它们等于 new_s，不满足’严格小于’。”

他抬起头，眼神锐利：“所以，f 应该减去多少？”

我恍然大悟：“应该减去那些前缀和恰好等于 new_s 的历史位置个数，也就是 cnt[s - 1]！”

“没错！”老勇者露出欣慰的笑容，“通过这种方式，每次只需要 O(1) 的时间就能更新 f，连二分查找都省了！”

def countMajoritySubarrays(nums: List[int], target: int) -> int:
 cnt = defaultdict(int)
 cnt[0] = 1 # 初始前缀和0出现一次（哨兵）
 ans = s = f = 0
 for x in nums:
 if x == target:
 f += cnt[s] # 新增那些前缀和恰好等于当前s的起始位置
 s += 1
 else:
 s -= 1
 f -= cnt[s] # 减去那些前缀和恰好等于新s的起始位置（不再满足条件）
 ans += f # 累加当前位置的贡献
 cnt[s] += 1 # 将当前前缀和加入哈希表
 return ans

提交，AC 弹出来的速度比村长那台二手服务器的风扇还快——O(n) 空间，O(n) 时间！

“每次更新f只需要O(1)，然后把f累加到答案，再把新的s加入哈希表。”我激动地指着屏幕，“一趟遍历，没有任何嵌套循环，也没有任何二分查找！纯纯的O(n)！从O(n²)暴力到O(n log n)有序集合，再到O(n)哈希表——这优化曲线比过山车还刺激！”

老勇者点了点头：“步长±1这个性质，让你不用再问‘有多少个小于s’，只需要在s变化的时候把答案顺手更新一下。SortedList是通用解，哈希表+变量f是特化解——知道什么时候该通用，什么时候该特化，这趟副本才算没白刷。”

尾声

村长抱着服务器乐颠颠地回去找老板娘邀功了，跑出去老远还能听见他在喊：“小白！老板娘说抽奖活动可能要搞三年，日志量会爆炸——你那O(n)扛得住吗？”

我靠在椅背上，总觉得这句式有点耳熟——上次村长说‘这个需求很简单’，隔天就甩过来一个‘锯齿过山车 II’。这次直接喊三年，怕不又是‘村长云监控 II’的预告，那种在数据量后面加好几个零的加强版。

“扛得住！”我扯着嗓子回了一句，“三年日志算什么，三十年也照跑不误！O(n)的意思就是日志翻倍，时间只翻倍——除非老板娘把抽奖活动搞到太阳系毁灭，不然我这算法稳如老狗！”

我把三版代码并排收进魔法书，在旁边补了几句：

**暴力枚举探本质，前缀和转区间查。 ** SortedList虽快非极致，哈希增量最潇洒。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3700 锯齿过山车·续：数量飙十亿，矩阵快速幂！

Wed, 24 Jun 2026 17:20:11 +0800

🎢 锯齿过山车·续：数量飙十亿，矩阵快速幂！

上回说到，我用前缀和加原地滚动，把计算锯齿过山车轨道方案数的复杂度从 O(nk²) 压到了 O(nk)，村长乐颠颠地去游乐园领赏金了。老勇者临走时扔下一句：“如果n飙到10^6，前缀和也不够用，那就得上矩阵快速幂了。”

我本以为这只是老勇者随口一提的“远期预告”，毕竟谁能闲着没事建一条十亿个节点的过山车？

没想到今天一大早，村长灰头土脸地就撞了进来：“小白！！” 他双手撑在桌子上，眼神里写满了绝望：“游乐园没给奖金！他们说上次的方案只适用于小规模轨道，现在要建一条真正的‘超级锯齿过山车’！轨道节点数量从 2000 暴涨到……到……”

他颤抖着伸出手指，声音都在劈叉：“十亿！十亿个节点！从村头一直铺到海岸线上的那种！你上次那套 O(n×k) 算法直接跪在地上摩擦，连渣都不剩啊！”

我接过他手里皱巴巴的需求文档，还是那座熟悉的锯齿过山车，但设计图上的参数变了——

锯齿过山车·超长版

轨道点数 n：3 ≤ n ≤ 10^9（昨天才 2000，今天直接通货膨胀？）

高度范围 [l, r]：1 ≤ l < r ≤ 75（昨天是 2000，今天反而缩水了？）

其他规则不变：相邻不等，连续三个不能严格递增或递减

目标：求方案总数，对 10^9+7 取模

10^9，**十亿次循环。**就算每次只做一次加法，O(nk) 在 n=10^9、k=75 时也是 750 亿次运算！就算评测机是超算，每秒处理 10^9 次，也得跑 75 秒！况且它的耐心只有 2 秒——暴力是死路，前缀和也是死路——前缀和再快也甩不掉外层那十亿次迭代啊！

“矩阵快速幂……“我喃喃自语，脑子里回放着老勇者昨天的话，“能把 O(n) 的线性递推优化成 O(log n)……”

log₂(10^9) ≈ 30。也就是说，如果能用上矩阵快速幂，原本需要十亿次的迭代，现在只需要 30 次！这压缩比，简直是用了量子传送门直接从起点跳到终点！

矩阵快速幂？听起来像是高维魔法

我深吸一口气，强迫自己冷静下来，开始拆解这个听起来很唬人的概念。

矩阵快速幂，名字听着玄乎，像是什么 SSR 级角色的终极技能。但剥开外壳看本质，它其实就是把快速幂的思想从标量扩展到矩阵，从而把 n 次矩阵乘法压缩到 log n 次。

先来个快速幂的极简回顾，免得待会儿在矩阵的迷宫里迷路：

快速幂的核心思想：计算 a^n 不需要傻乎乎地乘 n 次，而可以利用二进制分解。

比如要计算 a^13，把 13 写成二进制形式：13 = 1101(₂)。这意味着：a^13 = a^(8+4+1) = a^8 × a^4 × a^1

具体做法就像是在玩"翻倍游戏”：

初始化结果 res = 1，底数 base = a

从低位到高位遍历 n 的二进制位

如果当前位是 1，就把当前的 base 累乘到 res 中

每步让 base 自乘（base = base × base），n 右移一位

通过二进制分解，只需要计算 log n 次乘法，而不是 n 次。时间复杂度从 O(n) 降到 O(log n)，压缩比，简直像是用了空间折叠技术！

def pow_mul(a, n):
res = 1
while n:
if n & 1: # 如果当前二进制位是 1
res *= a # 累乘到结果
a *= a # 底数自乘
n >>= 1 # n 右移一位
return res

温习完毕，再回到这次的任务上来。

我的 DP 转移是线性的——每一步都只做加法和数乘，没有非线性操作（比如取 max、min 或者条件判断）。这意味着，整个转移过程完全可以表示成一个矩阵乘法！

如果我能构造一个转移矩阵 M 和一个初始状态向量 F₁，使得：

F₂ = M × F₁ F₃ = M × F₂ = M² × F₁ … Fₙ = M^(n-1) × F₁

那么我只需要计算 M^(n-1)，然后乘以 F₁，就能直接得到第 n 层的状态！而 M^(n-1) 可以用快速幂在 O(log n) 次矩阵乘法内完成！

我在纸上又画了个对比图：

普通 DP: F₁ → F₂ → F₃ → … → Fₙ (n-1 步，O(n) 时间) 矩阵快速幂: F₁ ⇒ M^(n-1)×F₁ = Fₙ (log n 次矩阵乘法，O(log n) 时间)

这简直像是给你的 DP 装上了火箭推进器——原本要一步步走的 n 步，现在只要 log n 次"瞬移"就能到达！从村头到海岸线，以前要走十亿步，现在只要 30 次传送门跳跃！

思路通了！我兴奋地掏出键盘，准备大干一场。

第一步：把 DP 状态转化成向量形式

“首先，我需要把 DP 状态转化成向量形式。“我自言自语道，手指在桌面上敲着节拍。

“昨天的状态是 f0[j] 和 f1[j]，分别表示最后一个元素是 j 且最后两个元素递增/递减的方案数。那我可以把这些状态拼成一个长度为 2k 的列向量……”

我在草稿纸上写下状态向量的结构：

状态向量 F = [f0[0], f0[1], …, f0[k-1], f1[0], f1[1], …, f1[k-1]]ᵀ

长度为 2k，当 k=75 时就是 150 维。这个维度完全可控，既不会大到内存爆炸，也不会小到失去表达能力。完美！

第二步：构造转移矩阵 M

“然后，我需要构造一个 2k × 2k 的转移矩阵 M，使得 F_{i+1} = M × F_i。”

我盯着纸上那个 150×150 的空矩阵格子，感觉像是在面对一个巨大的数独谜题。怎么填？

先回顾一下昨天的状态转移公式：

对于 f0_new[j]（以 j 结尾且最后两步递增）： f0_new[j] = sum(f1_old[p]) where p < j 对于 f1_new[j]（以 j 结尾且最后两步递减）： f1_new[j] = sum(f0_old[p]) where p > j

这意味着，F{i+1} 中的每一个分量，都依赖于 F_i 中多个分量的累加和。

我皱起眉头：“每个新状态都依赖于多个旧状态的累加，这怎么用矩阵表示？区间求和的关系怎么转化成矩阵的系数？这难道要我给每个位置都写一个求和公式？”

就在我抓耳挠腮之际，脑海中突然闪过一道灵光——矩阵乘法的本质就是’加权求和’！

当我计算 M × F 时，结果向量的第 i 个元素等于：

(M × F)[i] = Σ M[i] [j] × F[j] （对所有 j 求和）

这不就是矩阵 M 的第 i 行与向量 F 的点积吗？

也就是说，如果我想让：

f0_new[j] = sum(f1_old[k]) where k < j

我只需要在矩阵 M 的第 j 行，把所有对应 f1_old[k]（k < j）的位置填成 1，其他位置填 0！这样，当矩阵乘法执行时，这些 1 就会把对应的 f1_old[k] “挑选"出来并累加，而 0 会把不相关的元素过滤掉！

这就像是给矩阵装上了过滤器——只让需要的元素通过，其他的统统拦截！

我激动地在草稿纸上画出了转移矩阵的结构：

对于f0[j] = f1[0] + f1[1] + … + f1[j-1] ，转移矩阵里对应的那部分是一个下三角全1矩阵。对于f1[j] = f0[j+1] + f0[j+2] + … + f0[k-1]，对应的是一个上三角全1矩阵。

转移矩阵 M 的结构（2k × 2k）：

| 0 B | ← 上半部分：f0_new 依赖 f1_old | C 0 | ← 下半部分：f1_new 依赖 f0_old

其中： B 是 k×k 的下三角全 1 矩阵（B[i] [j]=1 当且仅当 j < i） C 是 k×k 的上三角全 1 矩阵（C[i] [j]=1 当且仅当 j > i） 0 是 k×k 的全零矩阵

我盯着这个分块反对角矩阵，感觉自己像是破解了一个古老的密码。原来，看似复杂的区间求和，在矩阵的世界里，不过是填 0 和 1 的游戏罢了！

# 转移矩阵 M，大小2k × 2k
m = [[0] * (k*2) for _ in range(k*2)]

# 上半部分：f0[i] 依赖所有 f1[j] where j < i
for i in range(k):
 for j in range(i):
 m[i][k+j] = 1 # 第 i 行，第 k+j 列为 1

# 下半部分：f1[i] 依赖所有 f0[j] where j > i
for i in range(k):
 for j in range(i+1, k):
 m[k+i][j] = 1 # 第 k+i 行，第 j 列为 1

第三步：组装矩阵快速幂——把零件拼成火箭

想清楚矩阵的构造，剩下的就是体力活了。我需要实现三个组件：

矩阵乘法 mul：计算两个 2k × 2k 矩阵的乘积
矩阵快速幂 pow_mul：计算 M^(n-1) × F₁
主函数 zigZagArrays：构造矩阵、调用快速幂、统计结果

我开始写完整的代码，就像是在组装一台精密的仪器：

MOD = 10**9 + 7

def mul(a: List[List[int]], b: List[List[int]]) -> List[List[int]]:
 """矩阵乘法：C = A × B"""
 return [[sum(x*y for x, y in zip(row, col))%MOD for col in zip(*b)]
 for row in a]

def pow_mul(a: List[List[int]], n: int, f1: List[List[int]]) -> List[List[int]]:
 """矩阵快速幂：计算 A^n × F1"""
 res = f1
 while n:
 if n & 1:
 res = mul(a, res)
 a = mul(a, a)
 n >>= 1
 return res

class Solution:
 def zigZagArrays(self, n: int, l: int, r: int) -> int:
 k = r - l + 1 # 高度范围的长度

 # 构造转移矩阵 M，大小 2k × 2k
 m = [[0] * (k*2) for _ in range(k*2)]
 for i in range(k):
 for j in range(i):
 m[i][k+j] = 1
 for i in range(k):
 for j in range(i+1, k):
 m[k+i][j] = 1

 # 初始状态向量 F1，所有值为 1（第一个元素可以是任意值）
 f1 = [[1] for _ in range(k*2)]

 # 计算 M^(n-1) × F1
 fn = pow_mul(m, n-1, f1)

 # 统计所有状态的方案数之和
 return sum(row[0] for row in fn) % MOD

小样例先跑下，完美通过！再算算复杂度：矩阵乘法 O((2k)³) = O(8k³) ≈ O(k³)。快速幂需要 log n 次矩阵乘法，所以总复杂度是 O(k³ log n)。代入数值：k=75, n=10^9，log₂(10^9) ≈ 30。75³ × 30 ≈ 1.2 × 10^7 次运算。也就是说，总操作量大约一千两百万次。怎么说呢，这个量级就像是早高峰的地铁——挤是挤了点，但只要不被卡住，还是能在规定时间内到达终点。

我深吸一口气，点击提交。屏幕闪烁了两秒——绿色的Accepted弹了出来！运行时间1.8秒，差点就超时了。

“过了！”我差点从椅子上跳起来，“虽然跑得慢了点儿，但能在2秒内ac，就是胜利！” 十亿次迭代被压缩到三千万次矩阵运算，这压缩比简直像是把一整条过山车轨道卷成了一个弹簧！

就在我得意洋洋，准备发朋友圈炫耀这波“极限压线”操作时，后脑勺又挨了精准的一下——力道刚好能把我从“我真牛逼”的幻觉里敲回现实。

老勇者登场——优化的边界

“不错嘛，”老勇者站在我身后，嘴角带着一丝笑意，“学会用朴素矩阵快速幂 AC 了。1.8秒，压线过——看来评测机今天心情不错，没卡你的常数因子。”

我揉着后脑勺，有点不好意思地嘿嘿一笑：“运气好，运气好。不过您看这1.8秒，心悬得很。有没有什么优化方法，能让它过得更稳一点？”

老勇者点了点屏幕：“你的解法很标准了——构造转移矩阵，实现矩阵快速幂，计算 M^(n-1) × F₁。这套流程你掌握得很扎实。矩阵快速幂的适用条件、转移矩阵的构造技巧，这两个核心点你都踩准了。”

他顿了顿，扫了一眼我屏幕上那个矩阵乘法的代码：“不过，既然你问到了优化，那我就提供一个思路。”

“你的转移矩阵是分块反对角矩阵，一半下三角全1，一半上三角全1。这种特殊结构，乘向量的时候其实不需要 O(k²) 的三重循环——下三角全1乘向量就是做前缀和，上三角全1乘向量就是做后缀和。跟昨天的原地滚动一个道理。一趟 O(k) 搞定，不用构建完整的转移矩阵。

我脑子“嗡”了一下，有点懵：“您的意思是……矩阵快速幂里每一轮乘向量都能压到 O(k)，总复杂度压到 O(k² log n)？”

“对。”老勇者点点头，话锋却一转，“但我只是提供这个思路，不要求你现在就去实现。”

我愣了一下，满脸写着“为什么”：“为什么？这不是能让代码跑得更快吗？”

“因为你已经 AC 了。”老勇者瞥了我一眼，“1.8秒和0.5秒，在判题机眼里都是绿色的‘通过’。但如果现在去实现这个优化，你得把矩阵乘法拆成两种情况——矩阵乘矩阵和矩阵乘向量。代码量翻倍，边界条件翻倍，调试时间也翻倍。为了省这1.3秒，把原本清晰的代码搅成一锅粥，不值得。”

他敲了敲我的屏幕：“刷题不是打比赛，AC 之后多花一小时抠常数，不如把这一小时用来消化今天学到的矩阵快速幂骨架。优化是锦上添花，骨架才是雪中送炭。k=75 的时候 O(k³ log n) 够用，下次 k 飙到 500，再掏出前缀和优化不迟——到时候你自然会感谢今天先把骨架练熟了。”

尾声：

我靠在椅背上，盯着屏幕上那个绿色的 Accepted，紧绷的肩膀终于放松下来。

为了凑出那个 1.8 秒的极限压线，我敲代码时手心全是汗，生怕评测机稍微打个盹就给我个 TLE。现在想想，从十亿次循环压到三十次矩阵乘法，已经是一波酣畅淋漓的战斗了。至于前缀和优化矩阵乘法——遇到k飙到500的时候再说，毕竟骨架学透才是正经事——

十亿节点莫惊慌，线性递推矩阵扛。
快速幂里藏乾坤，有缘再战五百强。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3699 锯齿过山车：从暴力O(nk²)到原地滚动的三轮进化

Tue, 23 Jun 2026 16:26:37 +0800

🎮锯齿过山车：从暴力O(nk²)到原地滚动的三轮进化

烈日当空，连村里那只掉毛信鸽都热得趴在窗台上，仿佛随时会触发什么 HeatStrokeException。我正把头伸进锅炉房里仅存的阴凉角落，院门又被“砰”地一脚踹开了。

“小白！游乐园那边来大工程了！” 村长一个滑铲冲进了屋。他满头大汗，手里举着一张画得歪歪扭扭的过山车设计图，上面密密麻麻的折线，看起来就像是我昨晚熬夜打排位时的心电图。

“游乐园？”我转过身，警惕地看着他，“就是之前一位老爷子被‘递归过山车’甩上天，然后一直在天上 return 不下来，最后触发Stack Overflow的那个游乐园？”

“哎呀，那是老黄历了！现在的游乐园可是正经项目！”村长把那张“心电图”拍在我的桌上，“新项目——锯齿过山车！要求轨道必须起伏跌宕！任意两个相邻节点高度不能相同，任意三个连续节点不能一路向上或一路向下！现在需要算出所有可能的轨道设计方案！”

我瞥了一眼他塞过来的需求文档：

锯齿过山车设计规范：

轨道由 n 个点组成，每个点的高度在 [l, r] 范围内

相邻两个点的高度不能相同（不然车会卡住）

任意连续三个点不能严格递增或严格递减（不然乘客会被甩飞）

求满足条件的轨道设计方案总数，对 10^9+7 取模

//////////////////////////////////////////////////\

村长一边擦汗，一边压低声音补充道：“n 最大 2000，高度范围也是 2000。如果今天能解决，奖金分你一半！”

一听“奖金”两个字，我原本因为高温而处于低功耗模式的大脑瞬间超频。我一拍胸脯，豪气干云，“不就是个计数问题吗？动态规划一把梭！"

状态机 DP——处理相邻约束的神器

既然牛皮已经吹出去了，接下来就是正经的思路分析时间。

先分析‘锯齿形’的本质。我盯着过山车轨道的示意图，三个节点的关系，其实只由前两个节点的大小关系和当前节点的值决定。具体来说，就像过山车的方向变化：

如果前两个节点是递增（轨道在上升 /），那当前节点必须比前一个节点小（轨道开始下降\），形成‘增-减’锯齿（/\）。
如果前两个节点是递减（轨道在下降\），那当前节点必须比前一个节点大（轨道开始上升/），形成‘减-增’锯齿（/）。

也就是说，DP 的状态需要记录两个信息：

当前节点的值是多少（记作 j）
前两个节点的关系是递增还是递减（记作 0 表示递减，1 表示递增）

所以，状态设计很清晰：

dp[j][0]：表示当前轨道节点高度为 j，且前两个节点是递减关系的方案数。 dp[j][1]：表示当前轨道节点高度为 j，且前两个节点是递增关系的方案数。

至于状态转移，其实就是模拟轨道的走向：

当要计算新的 dp[j][1]（递增状态）时，意味着前一个状态必须是递减的，且前一个位置的值要小于 j： => dp[j] [1] = 所有 dp[k] [0] 的和，其中 k < j

当要计算新的 dp[j][0]（递减状态）时，意味着前一个状态必须是递增的，且前一个位置的值要大于 j： => dp[j] [0] = 所有 dp[k] [1] 的和，其中 k > j

初始条件也很简单：

对于第一个节点，它可以是 [l, r] 范围内的任意值，而且没有"前两个节点的关系"这个概念（毕竟只有一个点，谈不上增减）。所以可以认为第一个节点的所有取值都是合法的，方案数各为 1。

想清楚这些，我突然意识到——这不就是经典的状态机 DP 吗？用状态记录局部信息（这里是增减关系），用转移保证全局约束（不能有连续三个递增或递减）。就像玩游戏时的存档读档，每个状态都是一个存档点，转移方程就是游戏规则。

我兴奋地跳了起来：二维 DP ！状态数 O(n×k)，每次转移 O(k)，总复杂度 O(n×k²)！等等，n和k都是2000——”

“等等——”，我掰着手指头算了一下，脸上的笑容逐渐凝固。8e9次运算。八十亿。就算我的CPU是液氮冷却的超算，这运算量一上，估计我也得跟那位递归过山车上的老爷子一样——迟迟return回不来。

我咽了口唾沫，深吸了口气——不管了，先跑个逻辑验证再说！

暴力DP——躲不开TLE的阴影

我噼里啪啦敲下暴力 DP，忐忑地点下了“Submit”：

MOD = 10**9 + 7
k = r - l + 1 # 高度范围的长度

# dp[j][0/1]: 最后一个节点值是 j+l，0表示递减，1表示递增
dp = [[0, 0] for _ in range(k)]

# 初始化：第一个节点可以是任意值
for j in range(k):
 dp[j][0] = 1
 dp[j][1] = 1

# 从第二个节点开始迭代 DP
for i in range(2, n + 1):
 new_dp = [[0, 0] for _ in range(k)] # 创建新的 DP 数组，用于存储当前状态

 for j in range(k): # 当前节点可填的值（高度范围内）
 # 计算 new_dp[j][1]：递增状态，前一个状态必须是递减，且值 < j
 for prev in range(j):
 new_dp[j][1] = (new_dp[j][1] + dp[prev][0]) % MOD

 # 计算 new_dp[j][0]：递减状态，前一个状态必须是递增，且值 > j
 for prev in range(j + 1, k):
 new_dp[j][0] = (new_dp[j][0] + dp[prev][1]) % MOD

 dp = new_dp # 用新层的状态替换旧层

# 最后一层DP完成后，统计所有可能的方案数
ans = 0
for j in range(k):
 ans = (ans + dp[j][0] + dp[j][1]) % MOD

return ans

提交——红色TLE如期而至——八十亿次循环，Python跑完的时间够我把泡面从红烧牛肉味吃到全系列绝版。

我盯着屏幕上那个红叉，陷入了沉思：“所以……我的状态转移是对的，只是姿势不对？”

前缀和优化——区间求和必杀技

“你的内层循环在干什么？” 老勇者不知道什么时候出现在我身后，手上还拿着两瓶冰可乐。

我像是看到了救星：“大佬！快救救孩子！” 老勇者递给我一瓶可乐，指了指我的代码：

“你看，你的转移方程是这样的：

new_dp[j][1] = sum(dp[k][0])，其中 k < j
new_dp[j][0] = sum(dp[k][1])，其中 k > j

这是什么——典型的区间求和问题！你在内层循环里每次都重新遍历累加，当然慢。如果能在 O(1) 时间内得到任意区间的和，是不是就能把内层循环砍掉？”

我眼睛一亮，脑海中仿佛有一道闪电劈过，照亮了我那被 TLE 阴影笼罩的大脑：“您的意思是……前缀和？！”

“一点就通。”老勇者满意地点点头，“前缀和的核心思想是预处理+查表。具体到你的问题，就是把‘小于 j 的递减状态之和’ prefix[j] ，和用于计算 ‘大于 j 的递增状态之和’ prefix[k]、prefix[j+1] 提前算好，O(1) 直接拿。这样内层循环就从 O(k) 降到了 O(1)，总复杂度从 O(n×k²) 降到了 O(n×k)。”

我恍然大悟，猛地一拍大腿：“对！用 accumulate 快速计算前缀和，把转移变成 O(1)！这像把每次都要现算的账本，提前做成了汇总表，查账的时候直接翻对应页就行！"

老勇者点了点头，又补了一刀：“还有，你那个二维数组是不觉得碍眼吗？”

“你仔细看，“老勇者指了指代码，“你的 dp 数组在每一轮迭代时，只依赖于上一层的状态，两层之间互不干扰。但你每轮都新建一个 new_dp，内存不要钱啊？而且频繁创建新对象还会触发 GC，进一步拖慢速度。”

“你有没有想过，”他顿了顿，“用两个一维数组 f0 和 f1 交替更新就行了。”

“f0[j] 表示最后一个节点值是 j 且前两个节点递增的方案数，f1[j] 表示最后一个节点值是 j 且前两个节点递减的方案数。每轮迭代先算出两个前缀和数组 s0 和 s1，然后遍历每个高度 j，直接用前缀和更新 f0[j] 和 f1[j]。”

我盯着他，脑子里像是有无数个齿轮在飞速转动，然后"咔哒"一声，全部咬合到位——“就像玩 RPG 游戏，前缀和是直接用传送卷轴到指定等级，原地优化是连背包都不用整理，直接把装备换成新的！”

MOD = 10 ** 9 + 7
k = r - l + 1

f0 = [1] * k
f1 = [1] * k

# 从第二个位置开始迭代
for _ in range(n - 1):
 s0 = list(accumulate(f0, initial=0))
 s1 = list(accumulate(f1, initial=0))
 for j in range(k):
 f0[j] = s1[j] % MOD
 f1[j] = (s0[k] - s0[j + 1]) % MOD

return (sum(f0) + sum(f1)) % MOD

提交，AC 瞬弹。绿色的勾号亮起的瞬间，我差点从椅子上蹦起来。我刚准备截屏纪念下，老勇者突然伸手按住了我的键盘。

原地滚动——状态复用的巅峰

“等等，”他眯起眼睛，“你那个s0和s1数组，是真的需要单独存起来吗？”

我愣住了：“什么意思？不存前缀和数组……我怎么查表？s1[j]是f1的前缀和，s0[k] - s0[j+1]是f0的后缀和，没有这两个数组，难道每次都重新算一遍？”

“你仔细看。”老勇者指着代码里的循环，“f1[j] 需要的是 s1[j]——也就是 f1 中所有下标小于 j 的值的和。f0[j] 需要的是 s0[k] - s0[j+1]——也就是 f0 中所有下标大于 j 的值的和。这两个东西，一定要提前把整个前缀和数组全算出来才能拿吗？”

“前缀和是顺着走，后缀和是逆着走。”他在纸上画了一行从左到右的箭头，又在上面画了一行从右到左的箭头，“你完全可以在更新状态的同时，用一个变量维护当前累加值——顺着走的时候，每走一步就把当前值加入累加器，下一步的转移直接取这个累加器。逆着走同理，只是方向反过来。”

老勇者嘴角勾起一丝神秘的微笑，像是在玩一个高深的文字游戏：”原地滚动——前缀和和后缀和的计算就和状态更新融为一体，空间压到O(1)，时间还是O(nk)，常数还更小。”

“……您的意思是，在更新 f0[j] 和 f1[j] 的同时，用一个变量 pre 来实时维护前缀和？”我试图厘清头绪，感觉大脑CPU要干烧了。

老勇者看我这副快要宕机的样子，叹了口气，敲了段示意代码：

# 计算 f1[j]：依赖所有 f0[k] (k < j) 的和
pre = 0
for j in range(k):
 f1[j] = pre # pre 就是 sum(f0[0], f0[1], ..., f0[j-1]) 
 pre += f0[j] # 把当前的 f0[j] 加入前缀和，为下一个 j 做准备

“看到没？” 老勇者指了指代码，“f1[j] 依赖于 f0 的前缀和，也就是所有下标小于 j 的 f0 之和。从左到右顺着遍历，用一个变量 pre 一路累加 f0 的值。走到 j 的时候，pre 恰好就是 f0[0] 到 f0[j-1] 的累加和——直接赋值给 f1[j]，然后顺手把当前 f0[j] 加进 pre 里，为下一个位置做准备。”

“不要额外开 s0 数组的空间，一轮 O(k) 遍历就能同时完成前缀和的计算和状态的更新。这就是原地计算前缀和的精髓——边算边用，用完即弃。”

我琢磨了一会，恍然大悟：“那对于 f0[j]（递减状态），我需要的是所有大于 j 的 f1[k] 之和，也就是后缀和。我可以从右到左遍历，用同样的方法维护一个 suf 变量！”

“总算通了。”老勇者满意地笑了，“一趟顺着走更新 f1，一趟逆着走更新 f0。两趟遍历，两个变量，前缀和和后缀和就地计算，算完即用，用完即弃。根本不用调 accumulate ！”

他顿了顿，补充道：“还有最后一个细节——你有没有发现，每一轮迭代结束后，f0 和 f1 的角色其实互换了？”

我仔细想了想，瞬时明白了：“对啊！因为下一轮的‘递增状态’依赖于上一轮的‘递减状态’，反之亦然。所以我可以在计算完后，直接交换 f0 和 f1 的引用，这样下一轮迭代时，原来的 f1 就变成了新的 f0，原来的 f0 变成了新的 f1。这样我就不需要额外的变量来存储新状态，直接在原数组上修改就行！”

老勇者眼中闪过一丝赞赏：“没错。这就是滚动数组的思想。把两轮之间的状态复用做到了极致——不仅省空间，还避免了频繁创建新对象的开销。”

MOD = 1_000_000_007
k = r - l + 1

f0 = [1] * k
f1 = [1] * k

# 从第二个位置开始迭代
for _ in range(n - 1):
 # 从左到右遍历，用 pre变量维护前缀和，同时更新 f1[i]
 pre = 0
 for i, v in enumerate(f1):
 f1[i] = pre % MOD # 先赋值再累加，保证 f1[i] 得到的是 f0[0] 到 f0[i-1] 的和
 pre += v

 # 从右到左遍历，用 suf变量维护后缀和，同时更新 f0[i]
 suf = 0
 for i in range(k - 1, -1, -1):
 v = f0[i]
 f0[i] = suf % MOD # 同样先赋值再累加，保证 f0[i] 得到的是 f1[i+1] 到 f1[k-1] 的和
 suf += v

 # 交换 f0 和 f1，为下一轮迭代做准备
 f0, f1 = f1, f0

# 统计所有可能的最后一个元素的方案数
return (sum(f0) + sum(f1)) % MOD

我看着这段代码，感觉它就像一件艺术品——简洁、优雅、高效。没有多余的数组，没有嵌套的循环，只有两个一维数组和三个变量，就完成了整个 DP 的计算。

“这才是真正的原地算法。”老勇者拿起桌上那瓶快乐水，畅快地灌了一大口，“时间复杂度 O(n×k)，空间复杂度 O(k)，而且常数因子极小。Python 跑四百万次运算，也就是一眨眼的功夫。”

“大佬，”我深吸一口气，双手抱拳，“您这点拨简直是把我的脑子从单核直接超频到了多核啊！”

老勇者微微一笑，放下快乐水，语气变得语重心长：“记住，优化的本质不是炫技，而是找到问题的结构和规律。”

他伸出三根手指，像是在数技能冷却时间：

“第一，前缀和之所以能用，是因为你的转移方程涉及区间求和——这是问题的数学结构。
第二，原地计算之所以可行，是因为你的遍历顺序和前缀和的累积方向一致——这是算法的执行顺序。
第三，滚动数组之所以有效，是因为你的状态只依赖于上一层——这是 DP 的状态依赖关系。

这些技巧都不是孤立的魔法，而是建立在对问题深刻理解基础上的组合拳。就像打游戏时的连招，不是死记硬背按键顺序，而是知道每个技能的冷却时间、攻击范围和衔接时机。”

他站起身，拍了拍我的肩膀，力道不轻不重：“算法也是一样，懂原理，才能玩出花。你今天的表现不错——至少没在我说完’前缀和’之后问我’那是啥’。”

我挠了挠头，有点不好意思：“那不是因为有您在嘛……”

老勇者哼了一声，算是接受了我的马屁：“前缀和是优化 DP 的常规武器，今天你算是正式入门了。”

他把可乐往口袋一揣，转身向门口走去。快走到门边时，突然停下脚步，回头补了句：“如果下次 n 飙到 10^6，前缀和也不够用，那就得上矩阵快速幂了。不过那是另一个副本的事了。”

我站在原地，脑子里回荡着"矩阵快速幂"“另一个副本"这些词——矩阵快速幂？今天的脑容量都快被锯齿形数组撑爆了好吧！

尾声

窗外那只掉毛信鸽被热得翅膀都懒得扇，蹲在窗台上歪头看我，眼神里写满了“你这题优化得比我的羽毛还顺”。

从开二维DP到前缀和优化，从前缀和数组到原地滚动——同一道题，三轮迭代，每一次都在追问同一个问题：这个中间结果真的需要存吗？能现场算的，就别存；能用变量滚动的，就别开数组。

望着老勇者离去的背影，我默默在魔法书上写下今天的总结：

以后遇到类似的 DP 问题，记得多问自己几个问题：

转移方程能不能简化？（有没有重复计算可以消除？）

空间能不能进一步优化？（能不能原地计算？能不能滚动数组？）

状态定义能不能更精简？（有没有冗余信息可以砍掉？）

写完，我合上魔法书，长舒一口气。今天的收获，够我消化好一会了。

又道是：

锯齿轨道zig又zag，暴力炸出 TLE。
前缀和表砍循环，原地滚动省空间。 **大佬指点迷津处，矩阵快速幂再见。 **

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode1189 木桶短板定产量，Counter 计数展风光

Mon, 22 Jun 2026 11:32:53 +0800

🎮木桶短板定产量，Counter 计数展风光

今天，村长又双叒叕发布了个所谓的“简单日常任务”——说是野外刷新了一批字母史莱姆，这玩意儿打死之后不掉金币，只疯狂掉落小写字母碎片。只要集齐一套 “balloon” 的碎片，就能搓出一个气球炸弹，用来炸开村东头那个卡了三个版本的传送门。

“小白啊，背包 text 里已经攒了一堆碎片了，赶紧算算能搓几个炸弹。”村长叼着烟斗，头也不抬地疯狂画饼。

我默默打开背包，看着里面那串乱码一样的字符串：“nlaebolko”。好家伙，这字母碎片堆得，简直像极了抽卡游戏里满屏的R级狗粮。

“这还不简单？”我挑了挑眉，嘴角勾起一抹“基操勿6”的自信微笑，“村长，您这任务，不就是个经典的木桶效应嘛！木桶能装多少水，取决于最短的那块木板；我能合成多少次炸弹，取决于哪个字母最先被榨干！在编程界，这叫取最小值（Min），在管理学里，这叫‘寻找系统瓶颈’！”

我心里暗暗吐槽：村长这老头，怕不是偷偷去B站刷了《管理学原理》的速成网课，学了个木桶理论就跑来给我当策划了？啧，理论一套套，代码写不好，说的就是他这种人。

“要拼一个 ‘balloon’，配方是：1个 b、1个 a、2个 l、2个 o、1个 n。首先，我得给 text 做个全量扫描，统计每个字母的库存，然后找出最少的那个——”

“手动写个字典遍历统计？太 low 了，简直是原始人行为！”我反手掏出一块散发着赛博朋克蓝光的魔法计数板（俗称 collections.Counter），在村长面前晃了晃：

🔧 传说级道具：Counter 来源：官方collections 模块功能：自动扫描可迭代对象，瞬间统计每个元素的爆率（次数），并返回一个字典-like 的对象效果：一行代码，优雅计数，时间复杂度稳稳压在 O(n)，告别 O(n²) 的龟速遍历！

“一行代码，搞定计数！“我潇洒地敲下：

def maxNumberOfBalloons(text: str) -> int:
 cnt = Counter(text)
 return min(cnt['b'], cnt['a'], cnt['l'] // 2, cnt['o'] // 2, cnt['n'])

等等——如果 text 里根本没有某个字母会怎么样？比如 text=“leetcode”，里面就没一个 ‘b’ 数。我试了一下：cnt[‘b’] 会返回 0！因为 Counter 的特性是访问不存在的键时返回 0 而不是报错！所以 min(0, …) 的结果就是 0，正好完美契合“缺一个字母就白搭”的逻辑。

我一拍大腿，“ 这才是真正的’内置容错外挂’！连异常处理都省了！python官方是懂我们的！”

我对着背包里的碎片，露出了奸商般的微笑——把 “nlaebolko” 传进去——cnt[‘b’]=1, cnt[‘a’]=1, cnt[’l’]//2=1, cnt[‘o’]//2=1, cnt[’n’]=1，取最小值得 1。 “完美！刚好搓 1 个炸弹。”

村长又丢来一串更长的：“loonbalxballpoon”。我重新调用：b=2, a=2, l=4//2=2, o=4//2=2, n=2，取最小值得 2。 “稳了，两个炸弹！”

村长点点头，但嘴角带着一丝狡黠：“那要是以后让你合成 “apple” 呢？你不得重新写个函数？”

我愣了一下，“村长，您这属于典型的‘需求变更’ ！我这刚写完 “balloon” ，您转头就要 “apple”，这搁我们开发圈，得加钱的！”

但我很快稳住了阵脚，冷笑一声：““真以为我是那种写死配置的脚本小子吗？格局打开，咱们直接上配置驱动！”

我深吸一口气，开始向村长展示什么叫真正的“高内聚低耦合”：

“把目标字符串也丢给 Counter 处理，直接拿到配方字典！然后，遍历这个配方字典，用背包里的库存除以配方需求量，最后再取个全局 min。这样一来，别说合成 'apple'，你就是让我搓个 'abracadabra'，我也能一行代码给你算出来！”

def maxNumberOfBalloons(text: str, word: str) -> int:
 cnt_word = Counter(word)
 cnt_text = Counter(text)
 return min(cnt_text[char] // cnt_word[char] for char in word)

“看到没？生成器表达式加字典遍历，优雅，丝滑，毫无冗余！”我自信地瞅了眼村长。

结果村长吧嗒吧嗒抽了两口烟斗，沉默了一会儿，憋出一句：“哦，懂了。那如果背包是空的呢？”

我愣住了——如果cnt_text[ch] 访问不到就直接返回 0，0 // cnt_word[ch] 还是 0，min 里面有一个 0，整个结果就是 0。不会报错啊！

“村长，“我眯起眼睛，往前凑了半步，“您这是在给我做边界测试呢？”

村长嘿嘿一笑：“不，我是在教你，什么叫防御性编程。你以为这就完了？万一哪天系统升级，字母史莱姆掉落的碎片里混进了大写字母，或者带空格、带标点符号，你的 Counter 还能认出来吗？”

我：“……”好家伙，这是从算法题直接跳到数据清洗了是吧？

我咬咬牙，把代码又往上叠了一层：“ 加层过滤！先来个 .lower() 统一转小写，再来个 filter(str.isalpha, …) 把非字母字符全扬了，最后再丢给 Counter！这样总行了吧？上到国际通用字母，下到emoji，全部能处理！”

村长满意地点点头，把烟斗往鞋底上磕了磕：“不错，孺子可教。不过……”

“不过什么？！”我感觉脑门上突突的。

“不过村东头那个传送门，”村长指了指远处，“其实不是卡BUG了。是上个月我我嫌密码太简单，改成了 ‘abracadabra’，结果转头就忘了……” 村长继续说道：“你刚才这么一说，我忽然想起来密码是啥了。”

村长又补了句：“你搓的这几个炸弹也别浪费，拿去村西头的池塘炸点小鱼吧，最近鱼有点多。“

我默默地把 Counter 收回背包，深吸一口气，微笑着说：“村长，您知道在计算机领域，把简单问题复杂化，然后假装自己解决了什么大难题的人，一般叫什么吗？”

村长：“叫什么？”

我：“架构师。”

村长：“……滚。”

这正是：

气球合成别蛮干，Counter 计数展风光。

木桶短板定产量，村长一言全白忙。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode1833 贪心扫货不迟疑，计数先求最大值

Sun, 21 Jun 2026 16:36:06 +0800

🎮 贪心扫货不迟疑，计数先求最大值

炎炎夏日，Tony同学热得快要融化了。他冲进雪糕店，发现货架上摆着n支雪糕，每支价格不同（costs[i]）。站在冰柜前，Tony双眼放光，脑海里只有一个声音在回荡：“买到最多数量的雪糕！”

但问题来了——Tony摸了摸口袋，只有 coins 块现金，如何在预算内实现雪糕自由？

第一幕：贪心的直觉

Tony的第一反应极其符合人类本能：买最便宜的！

这就好比下副本刷怪，你只有有限的血瓶（coins），小怪（便宜雪糕）攻击力低，你能多砍几只攒经验；Boss（贵雪糕）一刀暴击你就得回泉水读秒。贪心算法的核心教义就是——每次都做当前看似最优的选择，绝不回头，像个渣男。

于是Tony开始扫荡货架：

class Solution:
 def maxIceCream(self, costs: List[int], coins: int) -> int:
 costs.sort() # 排序，从白菜价到天价
 for i, cost in enumerate(costs):
 if coins < cost: # 买不起了，GG
 return i
 coins -= cost # 咬牙买下，钱包-1s
 return len(costs) # 直接清空老板库存！

他抓着一大把雪糕就往收银台冲，嘴里还念叨着：“先买便宜的，剩下的钢镚儿还能凑一根，这波血赚！”

就在这时，柜台后面慢悠悠地探出一颗脑袋——雪糕店老板，一个穿着格子衫、发际线略显峥嵘的中年男人，鼻梁上架着那副仿佛焊死在脸上的黑框眼镜。

老板推了推眼镜，打量了Tony一番：“哟，小伙子，骨骼精奇啊！一眼就看穿了贪心的本质。不过嘛……”

Tony一愣：“不过啥？”

老板冷笑一声：“你有没有想过，如果雪糕价格范围很小，比如最贵的也就几块钱，你没必要把整个数组排序——O(n log n) 虽然不慢，但还有更骚的操作。”

Tony 眼睛一亮：”更骚的操作？“

老板诡谲一笑，吐出四个字：“计数排序（Counting Sort）。”

第二幕：计数排序——批发场景的神器

老板从柜台底下抽出一张皱巴巴的进货单，用圆珠笔在上面画了个表格：

场景：假设雪糕价格只有 1~5 块钱，n=100000。 普通排序：O(n log n) ≈ 100000 × 17 = 170万次比较。 计数排序：O(n + maxCost) ≈ 100000 + 5 = 10万次操作。

Tony眼睛都亮了：“快了一整个数量级？！”

老板扬了扬下巴：“没错。计数排序不比较大小，它数数——统计每个价格出现了多少次，然后从便宜到贵依次购买。就好比你玩抽卡游戏，管它具体是哪张卡呢，你只看‘1星有几张’、‘2星有几张’，然后从低到高无脑合成突破，这效率不就上来了？”

说罢，老板从柜台底下又摸出一把布满灰尘的机械键盘， C 和 V 键磨损严重，他手指像飞一样：

class Solution:
 def maxIceCream(self, costs: List[int], coins: int) -> int:
 # 找到最贵的雪糕——决定桶的数量
 mx = max(costs)
 # 开一个计数数组，像超市货架标签一样，每个价格一个格子
 cnt = [0] * (mx + 1)
 for cost in costs:
 cnt[cost] += 1

 # 从 1 块钱开始，按顺序扫货
 ans = 0
 for cost in range(1, mx + 1):
 if coins < cost: # 钱不够买当前价格的雪糕了
 break
 num = min(cnt[cost], coins // cost) # 预算能买得起几根？直接算出来
 coins -= num * cost
 ans += num
 return ans

Tony看得目瞪口呆：“ coins // price 直接批量采购，比我之前那 for 循环一根根买要快多了！用空间换时间，拿内存换执行速度，经典套路！”

老板满意地点头：“懂行！计数排序的精髓就是开个 count 数组存每个价格的出现次数，空间复杂度 O(maxCost)。价格区间越小，它越猛。我平时批发雪糕都是这么算的——不吹牛，进货单我从来不用计算器，脑子一跑计数排序，老板都得喊我一声‘人形自走ERP’。”

他顿了顿，语气突然变得语重心长：“不过嘛……要是敢把价格上限干到一亿，开个一亿长度的数组——那场面，内存当场就得给你报个 MemoryError。遇到这种情况，还是老老实实 sort() 吧。毕竟咱是来买雪糕的，不是来给服务器做压力测试的，对吧？”

第三幕：大佬的传说

Tony 捧着雪糕，忍不住问：“老板，你以前是干嘛的？这代码写得比我老师还溜。”

老板叹了口气，望向窗外的烈日，眼神仿佛穿透了雪糕店的天花板，伸向了遥远的服务器机房。

“我以前啊……” 老板缓缓摘下黑框眼镜，用格子衫的衣角擦了擦，“ 在某大厂干过七年，负责核心交易链路的库存系统。每年大促那天，全球几亿人同时抢购，我就得在毫秒之间算出‘最多能买多少件商品’——跟你今天这雪糕问题，本质一模一样，就是规模大了亿点点。”

Tony嘴里的冰棍差点掉下来：“卧槽，那你为啥跑来卖雪糕？”

老板重新戴上眼镜，嘴角抽搐了一下：“那年双十一，我为了优化一个排序模块，强行上计数排序，结果商品价格范围没估算好——有个奢侈品的价格是九千九百九十九万……我抬手就开了一个一亿长度的 count 数组，内存直接原地爆炸。整个订单系统卡了整整三秒钟。”

他顿了顿，拿起一根绿豆冰棍狠狠咬了一口：“三秒钟意味着什么？三秒钟足够用户截屏发微博骂你十八遍，足够竞品写一篇‘某厂又崩了’的公众号爆文，足够老板的脸色从猪肝色变成五彩斑斓的黑。第二天，HR就把我叫进小黑屋，递给我一张纸条，上面写着：‘感谢贡献，江湖再见’。”

Tony 听得头皮发麻：“所以你就拿着赔偿金开了雪糕店？”

老板摊了摊手：“不然呢？我面了一圈，面试官问我‘你上次线上事故的原因是什么’，我说‘计数排序数组开太大了’，然后就没了下文。后来我一想，算了，自己当老板吧。至少在这里，雪糕价格上限不会超过二十块，我手动写个 count[21] 的数组，内存绝对不会爆——爆了也就损失几根老冰棍，不至于让几亿人刷不出购物车。”

Tony啃着最后一根冰棍，若有所思：“所以——计数排序本身没毛病，错的是没先看一眼 max(costs)。”

老板一拍大腿：“你总算开窍了！先看最大值再决定用啥算法，前置防御式编程’，是我拿七年职业生涯换来的经验教训。你要记住——提前优化是万恶之源，但提前检查数据范围是保命之道。”

Tony郑重地点点头，把最后一口冰棍吞下去，含含糊糊地说：“懂了，明天我就把这句话刻在键盘上。”

这正是：

贪心扫货不迟疑，计数先求最大值。 老板当年爆内存，如今卖糕教解题。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode1840 十亿高楼莫开阵，万点锚链定乾坤

Sat, 20 Jun 2026 22:40:44 +0800

🎮 十亿高楼莫开阵，万点锚链定乾坤

你是一个刚拿到城市规划师资格证的新人，市长给了你一个看似简单的任务：

“小伙子，给你 n 块地，给我建一排楼。记住三条规矩：”

第一栋楼必须是平地（高度 0） —— “市政府的脸面，不能比隔壁穷”
相邻楼高度差不能超过 1 —— “市民恐高，差距太大要打架的”
有些地块有硬性限高令 —— “某些地段被大佬盯上了，你懂的”

目标：在不违反任何规则的前提下，让最高的楼尽可能高。

听起来很简单？呵呵，天真。n 最大能达到 10^9，你要是敢开个数组暴力模拟，内存直接 OOM 给你看，连报错信息都来不及显示就 GG 了。

naive 玩家的陷阱：

 def maxBuilding(self, n: int, restrictions: List[List[int]]) -> int:
 # 直接开数组，炸你没商量
 heights = [-1] * (n + 1)
 heights[1] = 0
 for idx, h in restrictions:
 heights[idx] = h

 # 从前往后推
 for i in range(2, n + 1):
 if heights[i] == -1 or heights[i] > heights[i - 1] + 1:
 heights[i] = heights[i - 1] + 1

 # 从后往前推
 for i in range(n - 1, 0, -1):
 if heights[i] > heights[i + 1] + 1:
 heights[i] = heights[i + 1] + 1

 return max(heights)

逻辑非常直观，开一个长度为n+1的数组，1号楼高度0，所有限高令填进去，然后：

从左往右扫一遍：每栋楼最多比左边高 1 层（“老王家的楼比你高一截，你不能比他高太多”）
从右往左扫一遍：每栋楼最多比右边高 1 层（“老李家的楼也得考虑，做人要圆滑”）
取最大值：完事！

思路没毛病，代码写得也挺工整，如果这是在面试的话，你已经成功拿到——“谢谢参与”！

当 n = 10^9 时，你将需要创建出一个长度为 10^9 + 1 的列表。每个整数在 Python 里大约占用 28 字节（别问为什么这么多，问就是 Python 的对象头、引用计数、类型指针一堆开销），总内存 ≈ 10^9 × 28 bytes ≈ 28 GB——28 GB！

你的电脑会经历以下心路历程：

第 1 秒： “嗯？用户要申请 28GB 内存？行吧，我看看…” 第 2 秒： “等等，系统总共才 16GB，这哥们儿疯了吧？” 第 3 秒： “不行，我得阻止这场灾难——MemoryError！滚！”

然后你的程序连个像样的报错都来不及打印，就直接被操作系统掐死了，就像游戏里刚出新手村就被满级 Boss 一巴掌拍回重生点，连复活币都来不及用。

🕳 脑洞小剧场 1：面试官：“你这个算法的空间复杂度是多少？” 你：“O(n)… 呃，应该是线性级别？” 面试官：“那如果 n 是十亿呢？” 你：“那就… 换台内存更大的机器？实在不行上分布式？” 面试官（微笑）：“好的，今天的面试就到这里，出门右转不送。”

🕳 脑洞小剧场 2：现实中的程序员：“我代码本地测试好好的啊，怎么一上线就崩？” 运维大哥（看着监控大屏上飙升的内存曲线）：“你这哪是写代码，你这是在挖矿吧？” Python 解释器：“兄弟，我知道你是搞算法的，但你能不能有点 B 树？我这小身板扛不住你这么造啊！”

正确的姿势：四两拨千斤

既然不能遍历所有建筑，那就只处理有限制条件的建筑！毕竟n大到十亿，但限制只有十万。而且，最重要的是，没有限制的建筑，它们的高度完全由相邻的限制点决定——就像游戏里的 NPC，行为完全由几个关键剧情点控制。你不需要模拟整个开放世界，只需要抓住主线任务的关键节点。

也就是说，只需要把有限制的位置拎出来，两两相邻之间从两端往中间爬坡，最高点就是这段区间的天际线峰值。

第一步：添加两个"隐形守护者"，把1号楼和n号楼也当成限制点加进去：第一栋楼高度为 0（[1, 0]），最后一栋楼理论上可以无限高（[n, inf]）——至少在没受到限制传导之前是这样。

第二步：按建筑编号从小到大排序，就像把NPC按出场顺序排好。

class Solution:
 def maxBuilding(self, n: int, restrictions: List[List[int]]) -> int:
 # 第一步：加上两个"隐形锚点"
 restrictions += [[1, 0], [n, inf]]

 # 第二步：按建筑编号从小到大排序
 restrictions.sort(key=lambda a: a[0])

 # 第三步：准备两轮扫描：
 m = len(restrictions)
 h = [0] * m # h[i] 表示第 i 个锚点的真实最大高度

第三步：双向松弛——左右横跳直到收敛

从左往右扫第一遍。每两个相邻限制点之间隔了d栋楼，左端点高度已知，右端点有硬性上限。从左边出发，每往右一栋楼最多升1层，传过来的理论最大值是左端点高度 + d，但它还有个硬性上限卡着，所以实际高度取两者的较小值。

 # 从左往右扫，传导"左边来的限制"
 for i in range(1, m):
 dist = restrictions[i][0] - restrictions[i-1][0]
 h[i] = min(h[i-1] + dist, restrictions[i][1])

第一遍扫完还不够。从右往左再扫一遍——限制是双向传导的——每个点的高度取“右边传来的理论最大值”和“当前高度”的较小值。

 # 从右往左扫，传导"右边来的限制"
 for i in range(m-2, -1, -1):
 dist = restrictions[i+1][0] - restrictions[i][0]
 h[i] = min(h[i], h[i+1] + dist)

两轮传导下来，每个限制点的实际最大高度就定死了，确保每个点都收到了来自两侧的“最严要求”。

就像是在玩一个‘传话筒’游戏。第一轮从左往右传，每个锚点说：‘我从左边过来，最多只能到这么高’。第二轮从右往左传，每个锚点又说：‘我从右边过来，最多也只能到这么高’。两轮传完，每个锚点的真实最大高度就出来了。

这叫"动态规划的双向松弛操作"。听不懂没关系，你就理解为"左右横跳直到收敛"，类似于 Bellman-Ford 算法求最短路的思路，只不过这里是求"最高高度"。

最后一步：计算相邻限制点之间的峰值

限制点的高度全部确定之后，剩下的就是算相邻两点之间的天际线峰值。

两个限制点之间，左边高度h1，右边高度h2，距离d。从左边往上爬，从右边往上爬，两条坡道在中间某处相遇，那个顶点的高度就是(d + h1 + h2) // 2。就像在两个固定高度的塔之间搭一座拱桥，你要让桥的最高点尽可能高，但又不能让坡度太陡。这个公式就是在计算最优拱形的顶点。

遍历所有相邻限制点对，取最大的顶点高度，就是全城的天际线之巅。

 # 两个锚点之间的最高高度 = (距离 + 左高 + 右高) // 2
 return max(restrictions[i + 1][0] - restrictions[i][0] + h[i] + h[i + 1]
 for i in range(m - 1)) // 2

时间O(m log m)，空间O(m)，只需要存储限制点，而不是所有建筑。

把十亿次操作压缩成十万次，把28GB内存压缩成几个变量——不是靠更快的机器，是靠更聪明的思路。

通关口诀：

十亿高楼莫开阵，万点锚链定乾坤。

双向传导消冲突，拱桥公式现峰值。

不要试图控制每一个细节（内存会炸），而是要抓住关键节点（限制点），让它们之间的区域自动达到最优状态。

这不就是人生吗？——你不可能掌控每一件事，但你可以抓住那些真正重要的转折点！

等等——这是什么强行升华的鸡汤转折？！打住！！

现实很骨感的，就算你抓住了人生的关键节点，你人生的内存该爆还是得爆。你老板不会因为你懂“拱桥公式”就给你涨薪，你对象也不会因为你会写“双向扫描”就不跟你分手。

所以，收起你的文艺细胞，先把今天的拱桥公式消化透。起码保证下次面试，不会再因为这题收到面试官微笑着递来的 MemoryError 好人卡。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode1732 莫道水题无意义，心态修炼在其中

Fri, 19 Jun 2026 23:32:30 +0800

🎮莫道水题无意义，心态修炼在其中

清晨的阳光刚透过窗帘缝隙，我正沉浸在"泡面配码，法力无边"的晨间仪式中，窗户再次传来了那熟悉的"砰"的一声闷响。那只掉毛的信鸽又一次精准地砸在了我的键盘旁边——差点把我的 Enter 键给砸飞了。

我熟练地抽出纸条，村长的狂草一如既往地奔放：“小白！今天给你来个休闲养生局！自行车手骑行问题，求最高海拔！简单题，签到题，送分题！别问为什么又是签到，问就是端午节福利大礼包！”

端午节福利？一个虚拟骑行的海拔计算题？我把纸条翻了个面——空白。再翻回来，确实只有这几行字。

靠，这抠门老头，拿一道算法题当端午节福利？别人家的福利是粽子咸鸭蛋，我的福利是数组遍历求前缀和的最大值？要不要再贴个标签——“祝您端午安康，O(n)时间O(1)空间”？村长这是把抠门发挥到了大气层以外！要是让隔壁村的勇者知道，还以为我们村穷到连节日福利都得靠刷题兑换。

窗外的信鸽咕咕叫了两声，眼神里写满了"你自己品"三个大字，然后扑棱着翅膀飞走了。

签到题的自我修养

我把纸条揉成一团，拉过椅子坐下。嘴上嫌弃，身体诚实——来都来了，签到后再嗦面。

“有一个自行车手打算进行一场公路骑行……路线由 n+1 个不同海拔的点组成，从海拔0开始。gain[i]是点i和点i+1的净海拔高度差。返回最高点的海拔。”

再看示例：gain = [-5, 1, 5, 0, -7]，海拔序列为 [0, -5, -4, 1, 1, -6]，最高是1。

“这哪是骑行啊，“我忍不住吐槽，“这哥们骑的是过山车吧？一会儿上一会儿下，还净海拔高度差，说得这么高大上，不就是 ‘当前位置 += gain[i]’ 吗？”

我挑了挑眉，这题就是求前缀和的最大值：从 0 出发，一路累加 gain[i]，沿途顺手记下最大值。

朴实无华的前缀和

思路简单得像新手村教程关卡：一个变量 current 记录当前海拔，每过一个赛段就加上高度差；另一个变量 ans 记录沿途遇到的最高点。一趟遍历，两个变量，O(n)时间，O(1)空间，连数组都不用开。

class Solution:
 def largestAltitude(self, gain: List[int]) -> int:
 ans = tmp = 0
 for val in gain:
 tmp += val # 累加当前的高度差
 ans = max(ans, tmp) # 更新最大值
 return ans

点击提交，AC 瞬弹。我盯着那个绿色大勾，总觉得少了点什么。就像全副武装准备打 Boss，结果进门发现是个史莱姆，一刀下去就爆了，连经验值都没给几点。

Pythonic 的优雅一击

就在我准备关题吃面时，脑子里突然蹦出一个念头：“等等，有没有更 Pythonic 的写法？”

一个熟悉的名字——itertools.accumulate——浮现在我的脑袋里，仿佛在大喊“用我用我！”

“accumulate 函数，用于生成累积和。”我回想起文档里的解释，“给它一个可迭代对象，它会返回一个迭代器，依次产生累积的结果。默认是累加，这不正好合适？” 更妙的是，accumulate 还有一个 initial 参数，可以指定初始值。这道题里，自行车手从海拔 0 开始，正好可以用 initial=0 来表示起点。

我兴奋地敲下了新的实现，“Pythonic 一行流！”

from itertools import accumulate

class Solution:
 def largestAltitude(self, gain: List[int]) -> int:
 return max(accumulate(gain, initial=0))

``accumulate(gain, initial=0)依次产出0, gain[0], gain[0]+gain[1], …——完整的海拔序列直接出来了。max` 一把捞出最高点。

再次提交，AC。“这才是 Python 程序员该有的样子嘛！“我得意地笑了笑，“用内置库函数代替手写循环，代码简洁优雅，还能装一波’我很懂 Python’的逼。”

尾声：签到的意义

“所以说，“我一边嗦面一边自言自语，“这道题的意义到底是什么？村长不可能无缘无故给我塞一道’Hello World’级别的签到题吧？”

信鸽不知什么时候又飞回来了，停在窗台上，冲我咕咕叫了两声。我盯着它看了一会儿，“莫非，村长这是在训练我的心态？——遇到难题不要慌，遇到水题不要浪！”

信鸽歪着头看我，眼神里三分认可七分"你戏真多”。我翻开魔法书，在最新一页写下：

海拔爬升前缀和，一行代码定风波。 莫道水题无意义，心态修炼在其中。

写完，我合上魔法书。村长的端午节福利虽然抠门，但至少让我复习了一下 accumulate 的用法。嗯，就当是吃了个代码味的粽子吧。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode1344 钟面追及本寻常，惊觉快慢指针藏

Thu, 18 Jun 2026 11:29:57 +0800

🎮钟面追及本寻常，惊觉快慢指针藏

我盯着屏幕上村长新发来的任务卷轴，眉头皱得能夹死一只苍蝇。

“时钟指针的夹角……” 我念出声来，“给你两个数 hour 和 minutes，请返回在时钟上，由给定时间的时针和分针组成的较小角的角度？” 我揉了揉眼睛，把卷轴翻来覆去看了三遍，就……一个钟？

“村长是不是把我的智商当成了可以随便揉捏的面团？” 我把卷轴往桌上一拍，昨天把我甩到 4.5 PB 的虚空里找第 k 个字符，今天让我算钟表夹角？这跨度简直就像刚打完《艾尔登法环》的玛莲妮亚，突然被塞了一盘《宝宝巴士》。

窗外，那只掉毛的信鸽正好飞过，冲我咕咕叫了两声，语气里充满了“别高兴太早，这是暴风雨前的宁静”的意味。

我懒得理它，拉过椅子坐下，顺手把泡面推到一边。既然村长要考我小学数学，那我就用最优雅的姿态把这个签到题拿下——就当是给被逆推心法摩擦的脑子做个马杀鸡。

真·快慢指针

“经典的小学数学追及相遇问题——” 我拿起笔，在纸上画了一个圆，“只不过把直线轨道换成了圆形——分针一小时跑一圈，时针十二小时跑一圈。追及的两个‘人’换成了时针和分针，速度单位从‘米每秒’变成了‘度每分’。”

整个钟面 360 度，12 个大格，每个大格 30 度，60 个小格，每个小格 6 度。分针是个急性子，1 小时跑一圈 360 度，每分钟跑 6 度。时针是个摸鱼大师，1 小时才挪 30 度，每分钟挪 0.5 度。我轻松地吹了声口哨：“分针每分钟 6 度，时针每分钟 0.5 度，相对速度 5.5 度每分——”

等等。我盯着纸上的两个速度值——脑子里蹦出一个熟悉的画面。

“一个跑得快，一个跑得慢，还在同一个环形轨道上转悠……”我猛地一拍大腿，整个人从椅子上弹了起来，“这特么不就是真·快慢指针吗？！”

想当年刷链表题的时候，为了判环、找入环点，硬生生造了一个 fast 和一个 slow 在链表上赛跑，一个走两步一个走一步，while 循环里每轮都小心翼翼，生怕指针指飞了直接喜提 NullPointerException。

结果现在？人家物理引擎直接给你安排好了！分针就是那个 fast 指针，时针就是那个 slow 指针，它俩天然就在环形轨道上跑，连 while 循环都不用写，相对速度直接做减法就完事了。刷了那么多链表题，快慢指针的终极形态原来藏在钟面上。

“村长这波属于是跨界致敬了。”我轻快地笑了笑，在纸上写下计算公式。

以 12 点方向为 0 度基准：

分针角度 = minutes * 6
时针角度 = (hour % 12) * 30 + minutes * 0.5

那个 hour % 12 纯粹是我的强迫症，十二点当成零来处理，不然算出来是三百六十度，数学上没错，但脑子里总会冒出“这不转了一圈回到原点吗”的自我怀疑。

两针相减取绝对值，如果超过 180 度就用 360 减一下，取较小的那个角。

class Solution:
 def angleClock(self, hour: int, minutes: int) -> float:
 # 分针角度：每分钟6度
 min_degree = minutes * 6

 # 时针角度：每小时30度 + 每分钟0.5度
 hour_degree = (hour % 12) * 30 + minutes * 0.5

 # 两针夹角的绝对值
 diff = abs(hour_degree - min_degree)

 # 取较小角（不超过180度）
 return min(diff, 360 - diff)

点击提交，AC 几乎是在我眨眼的瞬间就弹了出来。

我靠在椅背上，盯着那个绿勾，突然感到一阵前所未有的空虚。没有熟悉的后脑勺崩，没有老勇者的灵魂拷问，连泡面都还没来得及坨。这也太简单了吧，简单到让人觉得有点敷衍。

但转念一想，村长这波跨界致敬还是挺有意思的——小学数学的皮，链表算法的魂。翻开魔法书，我在最新一页写下：

钟面追及本寻常，惊觉快慢指针藏。 寥寥几行破签到，难得泡面尚未凉。

写完，我端起泡面，美美地嗦了一大口，享受着这难得的清静。

“砰！” 窗外又传来一声熟悉的闷响。

我条件反射地护住泡面碗，抬头一看——那只掉毛的信鸽又来了，嘴里叼着一张新的小纸条。我把纸条抽出来，上面是村长歪歪扭扭的字迹：“小白，今天热热身。明天再上强度。另外，鸽粮经费已经批了，但被我拿去抽卡了，你继续喂它点泡面。——村长”

“……” 我把纸条揉成一团，精准地投进了垃圾桶。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3614 倒转乾坤寻真身，去冗存真见精神

Wed, 17 Jun 2026 12:08:54 +0800

🎮倒转乾坤寻真身，去冗存真见精神

早上，我刚把一碗热气腾腾的泡面端上桌，准备享受这碳水与油脂交织的美好清晨，窗户又发出了熟悉的“砰砰”声。我眼疾手快地把碗往旁边一挪，果不其然，那只掉毛的信鸽像一架失去动力的无人机，精准地砸向桌面。

“你就不能换个着陆点？”我把鸽子往旁边拨了拨，熟练地抽出它嘴里叼着的羊皮纸。展开一看，村长的狂草再次扑面而来：“小白！字母大陆又更新了！这次不要求返回整个密文，只要求返回最终密文的第 k 个字母（下标从 0 开始）！如果 k 越界了，就返回一个 .！另外，字符串长度上限已经放宽到 10^5 ，祝你好运！”

“果然来了。” 我盯着那个 10^5，昨天 19 个井号就炸出 52 万个字符，模拟还能硬扛；今天 s 的长度放到十万，里面说不定藏着一整支井号军团。模拟要是敢上场，评测机怕是要把我的提交记录裱起来挂在“反面教材”专栏里。

我深吸一口气，把昨天老勇者画的那张竖杠图从魔法书里抽出来，平铺在桌上。

昨天老勇者已经给我透了底，说这类题是“空间逆推”的主场——“#号是复制对称，%号是镜像对称，*号是末端删减。找第 k 个字符，就是在一场逆向追踪里，从终点坐标一路剥开层层嵌套的几何变换，精准锁定最初的‘本体’。”

这段心法我在脑子里念叨了半宿，连做梦都在算对称位置。今天，是时候上招式了。

正向探路，反向溯源

开干之前先盘逻辑。昨天老勇者留下的话头很清楚——逆向追踪，从终点坐标一路剥开层层嵌套的几何变换。但在那之前，我得先正向探路，记下沿路操作对字符串几何结构的影响。就像顺着折痕一路摸回纸片最初的形状，首先得知道每次对折、翻面、撕角之后，纸片变成了多大。不需要知道纸上写了什么字，只需要知道尺寸。

“第一步，正向探路。”

我在纸上画了一个从左到右的箭头，“还是从左到右扫一遍操作序列，但不存实际字符，只记录每一步之后 result 的长度。字母来了，长度加一；星号来了，长度减一；井号来了，长度翻倍；百分号来了，长度不变。一趟扫完，我手里就有一张‘长度变化表’——每个操作时刻，result 有多长，清清楚楚。”

 # 正向扫描，只记长度
 n = len(s)
 size = [0] * n
 for i, c in enumerate(s):
 if c.isalpha():
 size[i] = (size[i - 1] if i > 0 else 0) + 1
 elif c == '*':
 size[i] = max(0, (size[i - 1] if i > 0 else 0) - 1)
 elif c == '#':
 size[i] = (size[i - 1] if i > 0 else 0) * 2
 else:
 size[i] = size[i - 1] if i > 0 else 0

全程只存长度，不存字母，井号再多也只翻倍长度值，不翻倍数据本身。不管字符串膨胀到多少个 2 的 n 次方，一个整数数组就能装下。size[i] 就是第 i 步操作后，result 的真实长度。

有了这张表，我就能从终点开始，拿着目标坐标 k 一路往回倒推。

“第二步，反向溯源。”

我盯着 size 数组，就像看到了一条从终点延伸回起点的时光隧道。从最后一个操作开始往前推，每一步都追问同一个问题：当前位置上的字符，到底是从哪来的？

如果当前操作是 #号，说明字符串是左右对称拼接的，长度翻倍前是 m，翻倍后是 2m。k 落在左半边就不用管，落在右半边就映射回左半边的对应位置——k -= m；

如果是%号，说明发生了镜像反转，直接把 k 映射到对称位置——size[i] - 1 - k；

如果是*号，它只删了末尾，对前面的字符位置没影响，直接跳过；

如果是字母，那就看 k 是不是刚好指向当前长度的末尾——如果是，恭喜你，抓到本体了，直接返回这个字母。

 # 边界检查：如果 k 越界，直接返回 '.'
 if k >= size[n - 1]:
 return '.'

 # 反向溯源，从后往前剥开几何变换
 for i in range(n - 1, -1, -1):
 c = s[i]
 if c.isalpha():
 # k 正好指向当前末尾的字母
 if k == size[i] - 1:
 return c
 elif c == '*':
 # 退格只删末尾，不影响前面的位置
 continue
 elif c == '#':
 # 落在右半边，映射回左半边
 m = size[i] // 2
 if k >= m:
 k -= m
 else: # '%'
 # 镜像映射
 k = size[i] - 1 - k

 return '.'

写完提交，AC 弹出。我靠到椅背上，端起泡面准备嗦一口——面已经坨了，但这不重要——后脑勺又挨了精准的一下。时机还是那么恰到好处，刚好卡在我 AC 之后、吃面之前的那零点五秒。

“不错，没让我失望。”老勇者的声音从背后传来，带着一丝赞许，“正向打表记长度，反向溯源追位置。时间复杂度 O(n)，空间也控制在了 O(n)。看来昨天的‘空间结构’心法，你已经炼成招式了。”

”不过——”他话锋一转，点了点屏幕上那个 size 数组，“你为了存这张‘长度变化表’，可是老老实实开了一个长度为 10^5 的数组。虽然没爆内存，但不够优雅。”

我愣了一下：“不存这个，逆推的时候怎么知道每一步的长度？”

“你忘了吗？”老勇者嘴角勾起一抹狡黠的笑，“所有的操作都是可逆的。既然你能从前往后算出长度，为什么不能从后往前把长度‘还原’回去？”

去冗存真，反向还原

“反向溯源的时候，真的需要整个 size 数组吗？”

老勇者拉过椅子坐下，继续说：“你从最后一步开始往前推。最后一步的长度拿到后，你完全可以根据当前操作倒推出前一步的长度——字母就减一，星号就加一，井号就除以二，百分号不变。这样逆着推回去，每一步你都能实时算出前一步的长度。一个 sz 变量就够了，数组是冗余的。”

我愣了半秒，恍然大悟——既然反向时能自己把长度重新算出来，那正向的数组打表确实可以扔了。

“正向探路，反向还原。一个变量足矣。”老勇者靠回椅背上，表情仿佛在说“接下来的活你自己干”。

我坐直身子，立刻动手优化。先正向扫一遍拿到最终长度 sz，然后反向遍历的同时用 sz 实时逆推。井号时看 k 在左半还是右半，同时把 sz 除以二；百分号时做镜像映射，sz 不变；星号时 sz 加一；字母时 sz 减一，如果 k 正好指向末尾就直接返回。

 def processStr(self, s: str, k: int) -> str:
 n = len(s)

 # 第一步：正向探路，最终长度sz
 sz = 0
 for c in s:
 if c == '*':
 sz = max(sz - 1, 0)
 elif c == '#':
 sz *= 2
 elif c != '%':
 sz += 1

 if k >= sz:
 return '.'

 # 第二步：反向溯源，同时倒推还原 sz
 for c in reversed(s):
 if c == '*':
 # 还原长度，退格是减一，往前推就加一
 sz += 1
 elif c == '#':
 # 还原长度，除以 2
 sz //= 2
 if k >= sz:
 k -= sz
 elif c == '%':
 # 长度不变，反转 k 的位置
 k = sz - 1 - k
 else:
 # 还原长度：字母让长度加一，所以往前推就减一
 sz -= 1
 if k == sz:
 return c

 return '.'

提交，再次 AC。代码更短，内存从 O(n) 压到 O(1)，连 size 数组的影都没了。正向的账在反向时一笔一笔倒着算清楚，数组是冗余，变量才是本质。

老勇者看着屏幕上的绿色大勾，微微点头：“逆推的极致，是把正向的账也一并省掉。能现场反推的，就别提前存。记住了？”

我端起泡面，终于嗦了一大口。面已经坨成了一团红烧牛肉味的线团，但汤汁吸得饱满，每一根面条都透着“ac完题”的满足感——比任何米其林摆盘都香。

我把两版代码并排夹进魔法书里，在昨天“正序模拟过试炼，空间逆推破天机”的下边又加了几行：

正序模拟过试炼，空间逆推破天机。 若问虚空第几字，倒转乾坤寻真身。 长度可逆无需表，去冗存真见精神。

写完最后一个字，我合上魔法书，起身去给那只还在掉毛的鸽子也分了点泡面。这家伙每次送信都预谋要砸我碗里，估计村长那个老抠门，连鸽粮钱都省下来充steam余额了，

“多吃点，”我掰了半根面条放到它面前，“回去还得飞呢。上次村长偷偷买《艾尔登法环》dlc的时候，我就知道你没好日子过。” 鸽子低头啄了两口面条，抬起头冲我咕咕两声，不知道是感谢还是嫌面太坨，扑棱着翅膀飞走了，临走还不忘在我手背上留下一根灰羽当“回执”。

我捏着那根羽毛笑了笑，把它夹进魔法书的扉页里。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3612 正序模拟过试炼，空间逆推破天机

Tue, 16 Jun 2026 12:56:34 +0800

🎮 正序模拟过试炼，空间逆推破天机

距离上次在字母大陆抓“双面间谍”已经过去好一阵子了。我本以为那片大陆的服务器早已关服，大家各自安好。没想到今天一大早，我正蹲在火炉边嗦泡面，窗户就被啄得砰砰作响——一只明显没睡醒的鸽子叼着封信，扑腾了两下，精准地一头栽进了我的泡面碗里。

我捞出那封湿漉漉的羊皮纸信，展开一看，上面赫然是村长那仿佛被狗啃过一样的狂草：“小白！字母大陆更新资料片了！那些字母不知道怎么搞的，混进了一批‘魔法操作符’——星号、井号和百分号。现在整条字符串就像被施了咒一样，你得按照规则从左到右处理每个字符，才能还原出最终的真言！规则如下——”

小写字母：正常添加到结果中；
'*'：退格符，删掉结果中的最后一个字母（如果有的话）；
'#'：复制符，把当前的结果复制一份，追加到自身后面；
'%'：反转符，把当前的结果整个倒过来。

“这不就是纯纯的字符串模拟吗？”我看着这一大串规则，眉头微挑，“只要建个空列表，按顺序遍历一遍，遇到啥操作就执行啥，最后返回结果不就完事了？”

栈式模拟：result就是一个操作栈

我把那只还在碗里打嗝的鸽子拎出去，抄起键盘开始敲代码：这种从左到右逐字符处理的任务，核心就是一个可变的result字符串。Python里直接拿list当栈用——字母来了就append，星号来了就pop，井号和百分号稍微复杂点但也都是列表操作，整个流程就是一台简单的状态机。

def applyOperations(self, s: str) -> str:
 result = []
 for ch in s:
 if ch == '*':
 if result:
 result.pop() # 退格
 elif ch == '#':
 result = result + result # 复制
 elif ch == '%':
 result.reverse() # 反转
 else:
 result.append(ch) # 追加
 return ''.join(result)

写完，提交，AC！我刚惬意地靠到椅背上，后脑勺又"啪"地挨了轻轻一下——力道极其精准，刚好能让我精神一振，又不至于把我拍痛。

“又来？” 我捂着后脑勺，不用回头就知道是谁。

“逻辑清晰，没有遗漏，时间复杂度也合格。” 老勇者慢条斯理地说道，“但是小白啊，你有没有想过一个问题？”

我叹了口气，熟练地摆出虚心求教的姿态：“什么问题？难道我的 if-elif 分支不够优雅？”

“内存问题。”老勇者指着屏幕上那行 result = result + result，“你看这个 # 操作，如果遇到连续的几个 #，比如 a##，你的 result 会瞬间从长度 1 变成 2，再变成 4。每次翻倍，你都在重新分配一块新内存，把整个 result 从头到尾拷贝一遍。”

他又指了指数据范围：“现在这题 s.length ≤ 20，最极端的情况——一个 a 后面跟 19 个 # 号。19次翻倍之后，result 最终长度是 2 的 19 次方，大约 52 万个字符。内存占用也就 4 到 5 兆，中间所有拷贝操作加起来大概一百万次元素复制，Python 眨个眼就完事了。“

老勇者顿了顿，眼神变得深邃起来：“ 你的模拟现在能 AC，不是因为它没问题，是数据量太小，小到把问题捂住了。这就好比你在澡盆里试航一艘纸船——不漏水，不代表它能出海。”

“如果把 s 的长度提到十万呢？或者仅仅是 a 后面跟上 49 个 # 号——49次翻倍，result 长度变成 2 的 49 次方，” 老勇者瞅了我一眼，“你知道那占多少内存吗？大约 4.5 PB。别说你的电脑，全村锅炉房的魔法硬盘加起来都塞不下。到时候直接一个 MemoryError，原地炸锅。”

我盯着代码，倒吸一口凉气。刚才跑样例还觉得模拟挺丝滑，现在一想——那不过是因为策划手下留情，把数据范围压到了 20。如果数据量不加限制，# 号的指数膨胀就是一颗定时炸弹，只等大数据量的 II 版本一发布就引爆。

“那 …… II 版本怎么办？”我挠着头，刚 AC 的喜悦凉了大半，“如果要返回整个字符串，模拟肯定扛不住啊！”

“问得好。”老勇者神秘一笑，眼角的皱纹都透着狡黠，“如果 II 版本不问整个字符串，只问你一个问题——最终 result 的第 k 个字符是什么？你还会爆内存吗？”

我愣住了。只找第 k 个字符？那确实不用把整个 result 算出来，只需要知道k位置上的字符是谁就行了——就像你不需要把整卷录像带从头放一遍，只需定位到第 k 帧，看一眼那一帧的画面就够了。

“可是……” 我追问，“不存整个 result，怎么知道第 k 个位置上的字符是从哪来的？”

找第 k 个字符？那又是另一个故事了

“换个角度——”

老勇者拿过笔，在纸上画了一条长横线，然后在线中间画了一道竖杠，把横线一分为二。“你看，每次#号操作，本质上是把当前字符串一式两份——左边是原来的，右边是复制出来的。%号呢，是把左边倒过来。* 号是把最右边那个删掉。” 他把笔尖在那条竖杠上敲了敲，“仔细看，每种操作，都在字符串的空间结构上留下了痕迹。”

“ 假设你经过 n 次#操作后，最终字符串的长度膨胀到了 2 的 n 次方。那么第 k 个字符，它一定在这个庞然大物的某一半里。要么在左半边，要么在右半边。如果是右半边，它一定是被某个#号从左边复制过去的；如果是左半边，它根本没被那次#号影响。%号同理——如果一个字符在反转区间里，它的实际来源一定在对称位置。”

我盯着纸上那条竖杠，脑子里突然闪过一道光：“等等——所以我不需要把整个字符串造出来？只需要拿着 k，从最后一个操作开始往前推，判断它落在当前区间的哪一半，然后反向映射回去？”

“正是。”老勇者把笔一搁，“每次操作都在改变字符串的几何结构——# 号是复制对称，% 号是镜像对称，* 号是末端删减。你从最终位置出发，一层一层剥开这些操作，就能追溯到最初的来源。”

他顿了顿，看着我若有所思的表情，嘴角勾起一抹意味深长的笑：“今天先把这个‘空间结构’的直觉消化下。具体怎么从后往前推、怎么判断左半右半、怎么处理反转映射……明天再教你。”

他站起身朝门口走去，走到门边又停了一下：“心法先入脑，招式才使得出来。”

门轻轻关上。我重新看向屏幕上那段刚 AC 的模拟代码——刚才还觉得它挺靠谱，现在再看，那行 result = result + result 简直像在嘲笑我：你能 AC，是因为策划给你放了片海。

我默念着老勇者的心法：“#号是复制对称，%号是镜像对称，*号是末端删减。找第 k 个字符，就是在一场逆向追踪里，从终点坐标一路剥开层层嵌套的几何变换，精准锁定最初的’本体‘。” 哪天村长真把我扔进 II 版本那 4.5 PB 的虚空里，我还得靠这套“空间逆推”的招式，捞出唯一的真相。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode2095 快慢指针找前驱，虚拟节点消特判

Mon, 15 Jun 2026 12:36:59 +0800

🎮 快慢指针找前驱，虚拟节点消特判

昨天村长把“对称之盾”爆出来后，乐得像个两百斤的傻子。听说他那 Steam Deck 的风扇嗡嗡转了一宿，隔着半堵墙都能听见装备界面循环播放的BGM。今天一大早，我正蹲在锅炉边添柴，寻思着要不要摸个鱼，院门“砰”地一声又被一脚踹开。

“小白！出Bug了！”村长冲进来，屏幕上还是昨天那条魔法项链，但这次画风突变——项链正中间的环正在疯狂闪烁刺眼的红光，还伴随着刺耳的警报声。

“你看！锻造台提示说，项链的能量回路必须重新平衡！”村长把屏幕怼到我脸上，唾沫星子差点喷我眼睛里，“要删掉正中间那个环！只有把它‘优化’掉，整条链子的对称性才能稳定，我的盾牌属性才能生效！”

我接过电脑，屏幕上那条项链依然排成一条直线，圆环之间用箭头连接。这次的任务不是求什么孪生和了，而是简单粗暴的物理超度——定位正中间的节点，把它从链上摘掉。如果节点数是奇数，中间只有一个；如果是偶数，中间有两个，取靠后的那个，也就是下标为 ⌊n/2⌋ 的那个。

“村长，这不就是经典的删除链表中间节点吗？快慢指针的老本行。”我撸起袖子，“只不过这次不是找中点本身，而是要找它的前驱节点——毕竟单向链表只认 next 不认 prev，要删掉中点，得让前一个节点直接跳过它，指向它的下一个节点，完成物理断联。”

快慢指针找前驱

我抄起键盘，开始盘逻辑。对付这种单链表找位置的活儿，还得是快慢指针这对老搭档—— fast 每次走两步，slow 每次走一步，等 fast 走到尽头，slow 刚好站在中间节点上。

不过这次有个小细节：我们要删的恰好就是中间节点本身。单向链表是个无情的数据结构——每个节点只认 next，不认 prev，想删谁，得先找到它的前任。为了让 slow 最终稳稳停在中间节点的前一个位置，我决定让 fast 抢跑两步——等 fast 跑到终点时，slow 自然就卡在前驱的位置上了。

def deleteMiddle(self, head: Optional[ListNode]) -> Optional[ListNode]:
 # 边界情况：只有一个节点，删掉后链表为空
 if not head.next:
 return None

 slow, fast = head, head
 # fast 先走两步，让 slow 慢一拍，最终 slow 停在中间节点的前驱
 fast = fast.next.next
 while fast and fast.next:
 slow = slow.next
 fast = fast.next.next

 # 物理断联：让前驱直接指向中间节点的下一个节点
 slow.next = slow.next.next
 return head

提交，AC。我把屏幕转过去，正准备向村长邀功：“搞定！中间的红环已经被抠掉了！”

“啪。” 后脑勺突然挨了轻轻一下。老勇者不知何时又出现在我身后，盯着我的代码。

“快慢指针找前驱，O(N) 时间，O(1) 空间，逻辑没毛病。” 他抿了一口茶，慢条斯理地说道，“但是小白啊，你的边界条件处理得不够优雅。你看，为了处理只有一个节点的情况，你硬生生在函数开头打了一个if补丁！这在架构设计里叫什么？这叫‘补丁式编程’！万一哪天需求变了，变成删倒数第二个节点，你是不是还得再打一排补丁？”

我愣在原地：“那……怎么改进？”

“虚拟头节点（Dummy Node）。” 老勇者微微一笑，“Dummy Node，链表题里的万能站位符。”

虚拟节点消特判

“在链表最前面加一个哑节点 dummy，不参与战斗，只负责站位。让 slow 从 dummy 出发，fast 从真正的 head 出发，同时走。这样一来，slow 天然比 fast 慢了一拍——不需要手动抢跑。而且不管要删的是不是真正的头节点，slow 永远指着被删节点的前驱，连 if not head.next 的特判都省了。最后返回 dummy.next，完美。”

def deleteMiddle(self, head: Optional[ListNode]) -> Optional[ListNode]:
 # 引入虚拟头节点，消灭边界特判
 dummy = ListNode(0, head)

 # slow从dummy出发，fast从head出发
 slow, fast = dummy, head
 while fast and fast.next:
 slow = slow.next
 fast = fast.next.next

 slow.next = slow.next.next
 return dummy.next

我思路瞬间清爽了，虚拟头结点就像一个站在队伍最前面的替补队员，不参与比赛，但保证排头有人。slow 和 fast 从不同起点同时出发，天然拉开了一拍的差距。原本那个让人头疼的‘头节点可能被删’或者‘单节点越界’的边界问题，全部被 dummy 给消化掉——代码从八行缩到六行，特判抹除，逻辑一马平川。

“虚拟头结点是链表题的万能润滑剂，” 老勇者拍了拍我的肩膀，“遇到删除操作，先想想能不能用 dummy 把边界条件统一掉。记住一句话：能少写一行特判，就少埋一个 Bug。”

两套解法记心间，村长大坑无尽头

村长那边，项链中间那个闪烁红光的环“咔嚓”一声碎裂消失，剩下两半自动接合，整条链子散发出稳定的蓝色光芒。对称之盾的属性面板刷新了——防御力后面多了一行金色小字：“已激活：链路平衡加成”。

老头激动得抱着机器原地蹦跶，“拿到了！平衡加成！我就知道删掉中间那个环管用！”

我靠在椅背上，端起茶杯。平心而论，“快指针抢跑 + 前驱定位” 的解法虽然多打了一个 if 补丁，但逻辑清晰、稳如老狗，每一步都清清楚楚；而老勇者的 Dummy Node 技巧也确实把原本需要特殊处理的边界条件化于无形，代码更短，逻辑更纯粹。我把两种写法并排收进魔法书，记了一笔：快慢指针找前驱，虚拟节点消特判。

看着村长心满意足地溜达出门的背影，我忍不住在心里嘀咕：村长这条魔法项链的副本连打了两天，每天解锁一个新花样。不知道明天锻造台会不会又整出什么链表操作的新皮肤——也许是指定位置插入？也许是每隔 k 个删一个？照这个趋势下去，迟早有一天他会拿着一条带环的链表跑来问我：“小白啊，你看这链子它怎么自己咬住尾巴了？”

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode2130 快慢指针拆项链，递归回溯借东风

Sun, 14 Jun 2026 12:37:13 +0800

🎮快慢指针拆项链，递归回溯借东风

今天我正蹲在锅炉边享受难得的清静，熟悉的Steam Deck风扇声又由远及近地碾了过来。村长捧着电脑冲了进来，屏幕上闪烁着一条由圆环串联而成的项链，每个环上标着数字，还散发着淡蓝色的魔法光芒。

“小白！游戏里掉落了一条神秘的项链！“村长的眼睛比项链还亮，“你看，这链子一共 n 个环，n 还是偶数！游戏提示说蕴含什么对称的力量——从两头往中间数，第 i 个环和第 n-1-i 个环叫‘孪生环’！每对孪生环放在一起会产生能量共鸣，共鸣值就是两个环上的数字之和！需要找出最强共鸣值提交给锻造台，才能解锁传说中的对称之盾！”

我接过电脑，屏幕上那条项链排成一条直线，圆环之间用箭头连接——这不就是链表吗？偶数个节点，首尾对称配对，求最大孪生和。“村长，您直接把它塞进一个数组里，然后用个 for 循环，左边一个指针右边一个指针往中间夹击不就行了？”

村长一听，胡子都翘起来了：“糊涂！数组是什么？那是连续内存！这链子这么长，万一中间断了，你还得重新分配一大块连续的内存空间来存它！我们村的魔法锅炉用的就是碎片化内存管理，最忌讳动不动就开大数组！最好是 O(1) 空间复杂度，原地解决！”

我叹了口气，行吧，那只能对链表本身进行物理改造了。

斩链刀·反转术

梳理下思路：快慢指针找中点，反转后半段，然后前后同时遍历配对——正好是 O(n) 时间加 O(1) 空间。

我抄起键盘开干：快慢指针是老搭档了，fast 每次走两步，slow 每次走一步，当 fast 跑到终点时，slow 正好卡在中点。然后把后半段链表反转，让尾节点变成新头。最后前半段从原头出发，后半段从新头出发，一边走一边求和，max 一路追最大值。

class Solution:
 def middleNode(self, head: Optional[ListNode]) -> Optional[ListNode]:
 slow = fast = head
 while fast and fast.next:
 slow = slow.next
 fast = fast.next.next
 return slow

 def reverseList(self, head: Optional[ListNode]) -> Optional[ListNode]:
 pre, cur = None, head
 while cur:
 nxt = cur.next
 cur.next = pre
 pre = cur
 cur = nxt
 return pre

 def pairSum(self, head: Optional[ListNode]) -> int:
 mid_node = self.middleNode(head)
 second_head = self.reverseList(mid_node)
 ans = 0
 while second_head:
 ans = max(ans, head.val + second_head.val)
 head = head.next
 second_head = second_head.next
 return ans

提交，AC。“村长，这什么孪生环啊，分明是把链表反转加双指针的经典面试题穿上了魔法项链的皮肤！连‘对称之盾’这种道具名都起得跟算法术语似的。”我一边吐槽，一边我把计算出的最大孪生和报给村长：“是 10086！”

村长激动地一拍大腿：“好！我就知道这条项链大有玄机！你听听，10086——这数字多耳熟，我上个月充话费打的就是这个号！我得赶紧提交共鸣值，对称之盾在锻造台上已经冒金光了！”说罢，他便捧着电脑倒腾了起来。

回溯剑·递归道

“快慢指针加反转链表，O(n)时间，O(1)空间，写得不错。” 熟悉的声音从身后传来。

老勇者不知何时倚在了门框上，手里端着一杯枸杞茶，瞅着屏幕。他接着抿了一口茶，“但你有没有想过，你为了算个最大值，把人家好好的链表给拆了？这叫破坏性读取，懂不懂？”

我愣在原地：“可是村长说要 O(1) 空间……”

“O(1) 空间只是手段，不是目的。”老勇者放下茶杯，指尖在键盘上飞舞：

class Solution:
 def pairSum(self, head: Optional[ListNode]) -> int:
 left = head
 ans = 0

 def dfs(node):
 if node:
 # 先递归到底，node走到链表尾部
 dfs(node.next)
 # 回溯时，node 从尾向头走，left 从头向尾走，两者天然形成孪生配对
 nonlocal left, ans
 ans = max(ans, left.val + node.val)
 left = left.next

 dfs(head)
 return ans

我盯着那段代码，瞳孔地震：“等等……这是……”

“没错。”老勇者微微一笑，“递归回溯。函数调用栈本身就是一条隐形的链表。利用调用栈天然的 LIFO 特性，当你一路递归到底再回溯上来时，node 是从尾部往头部走的，而我的 left 是从头部往尾部走的。两者在回溯过程中自然相遇——这不就是最完美的孪生配对吗？”

他顿了顿，悠悠地吐出一句：“不需要找中点，不需要反转链表，不需要手动维护三个指针。代码只有十几行，逻辑优雅得像首诗。”

确定vs优雅之辩

村长凑过来，盯着老勇者的那段代码，眉头拧成了麻花：“递归？链表用递归？不怕爆栈？你这 dfs(node.next) 一层套一层，万一这链子有十万个节点，一半也有五万层，到时候一个 StackOverflowError，连个报错信息都来不及打就炸了！这叫优雅？这这叫给评测机递刀子，给生产环境埋炸弹！“

他气的胡子一翘一翘的：“我告诉你，真正的工程化思维是什么？是确定性！是能跑在生产环境里不炸的稳定性！不是让你在这儿写什么‘回溯的诗’！诗能当饭吃吗？诗能让服务器不宕机吗？不能！”

面对村长唾沫横飞的“工程化”说教，老勇者连眼皮都没抬一下。他轻轻抿了口茶：“老村长啊，你只盯着爆栈的定时炸弹，却没看见迭代反转的副作用。小白那套快慢指针加反转链表的做法，原地把人家后半段链表的 next 全拧反了。这在算法设计里叫什么？这叫‘破坏性副作用’！“

老勇者的声音不大，却字字诛心：”如果在生产环境里，另一个线程正在遍历这条链表——比如统计它的长度——小白这一刀切下去，那个线程当场就得给你抛出一个 NullPointerException。递归虽然费栈，但它不修改原数据，是纯函数式的读操作，没有破坏性副作用。你管这叫定时炸弹，我倒觉得这是读写分离的架构美学。”

村长一听，胡子又翘了起来：“你跟我谈架构美学？我告诉你，在服务器机房里，内存就是命！你那一层层递归调用栈——五万层栈帧，每帧存局部变量和返回地址，空间开销是O(n)，比小白那O(1)的迭代反转多了一整个数量级！题目数据量小的时候你还能装优雅，数据量一上来，操作系统直接甩个 SIGSEGV 送你回老家！”

老勇者也不恼，只是慢条斯理地吹了吹茶杯里的热气：“迭代反转O(1)额外空间不假，但那是在原地修改的前提下——它把原链表拆了重装。如果这道题要求保留原链表不变，你那一套就得先拷贝再反转，空间一样O(n)。递归的回溯本质上是在调用栈上隐式地维护了一个‘从尾到头’的遍历顺序，不需要显式修改任何指针。你说它费栈，我说它省心。哪套方案更优，取决于约束条件，不是一棍子打死的事。”

两人你一言我一语，一个坚持“爆栈风险不可控”，一个反驳“并发环境下数据完整性更重要”，唾沫星子横飞，简直比代码评审会上架构师和SRE吵架还激烈。

我呆呆地坐在角落里，看着这两位大佬争得面红耳赤。半晌，我弱弱地举起手，试图打破这剑拔弩张的气氛：“那个……两位前辈……”

两人同时转过头：“说！！”

我咽了口唾沫，小声说道：“其实……这题如果用 Python 写的话，直接把链表转成列表，然后双指针从两头往中间夹击求最大值……不仅不用反转链表，也不用递归爆栈，而且运行速度比你们俩都快……”

空气突然安静了。

村长和老勇者对视了一眼，同时冷哼一声，异口同声地骂道：“闭嘴！！”

说完，两人一甩袖子，各自背着手气呼呼地走了出去，只留我一个人在风中凌乱。

所以……我这算不算是凭一己之力，终结了一场史诗级的技术辩论？

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3838 绝对防御！手动Hash与模运算的土豆级零信任协议

Sat, 13 Jun 2026 22:13:24 +0800

🎮绝对防御！手动Hash与模运算的土豆级零信任协议

今天一大早，村长神神秘秘地塞给我一本皱巴巴的手册，封面上歪歪扭扭写着《v2.6.13版字母权重表》，旁边还盖了个萝卜章。手册里夹着一张纸条，上面是几串密文单词，每个单词旁边画着鬼画符一样的标记。

“小白，”村长压低声音，眼神里透着三分警惕七分得意，“我最近搞了套加密算法，能把所有任务指令都编码成奇怪的字符串。你看这张表，a对应几斤几两，b对应几斤几两……全是我亲手标的。纸条上那几串密文，你给我实时翻译下看看。”

我接过那张手绘的权重表，嘴角抽搐：“村长，这都2026年了，您还在用手动哈希？连个JWT都不用？咱村不是刚通了5G吗，隔壁勇者团都用上OAuth2.0了。”

村长捋了捋胡子，一脸高深莫测：“年轻人，这叫复古硬核加密。万一哪天基站被炸了，云计算挂了，咱村的秘密指令还得靠这张纸传。再说了，我这算法密钥只有咱俩知道——绝无第三方持有，零信任架构懂不懂？少废话，赶紧算！”

我翻开手册，开头就写了三条让人血压飙升的规则：

第一条，每个单词的“密码值”= 单词里每个字母在权重表中对应值的总和。

我心中暗想，说得跟什么上古魔法似的，小学二年级的加法运算也敢叫加密。瞥了眼村长，他正自顾自地捋着胡子，仿佛这真的是什么惊天动地的黑科技。

第二条，把总和对 26 取模，得到一个 0~25 的数字。

我叹了口气，经典 % 26，取模压缩。村长您是不是觉得26个字母刚好能塞进一个byte的低5位？内存优化强迫症是吧？

第三条，倒序映射： 0 → ‘z’, 1 → ‘y’, …, 25 → ‘a’。

我盯着这行规则看了足足五秒钟，终于绷不住了：“等等！正常人不都是 0→‘a’ 吗？为什么这里是反的？村长你是不是把ASCII表贴反了？还是说这是为了防止我们用 char + 'a' 一行搞定而故意加的debuff？！”

村长在旁边嘿嘿一笑：“哦，那个啊……因为我觉得从z开始数比较有仪式感。你想啊，z是字母表的终点，从终点往起点映射，有一种‘落叶归根’的哲学意味。怎么，有意见？”

我深吸一口气，把到嘴边的吐槽硬生生咽了回去：“没意见，您说了算。我写还不行吗。”

既然规则已经明确到这种程度，那还有什么好犹豫的？直接模拟就完事了！

class Solution:
 def mapWordWeight(self, words: List[str], weights: List[int]) -> str:
 ans = []
 ord_a = ord('a')
 ord_z = ord('z')
 for word in words:
 weight = sum(weights[ord(c) - ord_a] for c in word) % 26
 ans.append(chr(ord_z - weight))
 return ''.join(ans)

提交，AC，一气呵成。我把翻译出来的指令条递给村长——上面赫然写着：“下午三点村口开会讨论秋季土豆种植计划。”

村长接过指令条，满意地点点头：“好！解密成功！这套算法果然只有你能驾驭！” 说完，他背着手，迈着那种“绝世高手下山”的六亲不认步伐，慢悠悠地踱出了院子，甚至还哼起了不知名的小曲儿。

我呆立在原地，瞅着村长那逐渐远去的背影，感觉自己的CPU温度正在飙升。这老头……搞了权重累加、取模压缩、倒序映射三层加密，连‘落叶归根’的哲学都用上了，就为了保护土豆种植计划？！他到底在防谁啊？防隔壁村的猪吗？！再说了，谁家好人会把最高机密写在一本皱巴巴的手册上啊？要是来场暴雨，或者被哪只不长眼的乌鸦当成筑巢材料叼走，咱村的零信任架构直接物理层面崩了好吗！

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3559 二进制传送门觉醒：当每个节点都能瞬间跳跃

Fri, 12 Jun 2026 15:25:32 +0800

🎮二进制传送门觉醒：当每个节点都能瞬间跳跃

今天一大早，我刚推开村口锅炉房的门，就看见村长蹲在那儿，顶着两个黑眼圈，怀里抱着笔记本电脑，屏幕上’‘奇数流宗师’‘几个烫金大字一闪一闪的，后面跟着密密麻麻的查询列表，滚动条缩成了一个小点。墨菲定律诚不欺我——怕什么来什么。

‘‘小白！‘‘村长看到我，像装了雷达一样从地上弹起来，‘‘这个成就太难了！你看，宗师成就要求处理任意两个节点之间的路径查询，不是只有根到叶子那么简单！‘‘他疯狂划拉屏幕，‘‘查询可能是从1号到5号，从3号到7号，从8号到2号……我把昨天你那套压扁成链的代码套进去，跑的我风扇狂转，Steam Deck差点起飞——结果还没跑完！’’

我心里一沉。昨天那是从根到最深叶子，路径只有一条，深度k固定，一行快速幂秒杀。今天是任意两点之间的路径——每条查询的起点终点都不一样，路径长度k各不相同。昨天的对称性trick倒是还能用——路径上有k条边，方案数还是2^{k-1}。但问题变成了：怎么快速算出任意两点间的路径长度？

我在草稿纸上开始画树。假设查询节点4和节点5，路径是4→3→5，长度是2，查询节点2和节点5，路径是2→1→3→5，长度是3。关键藏在这些路径的交汇处——它们不是一条直线冲到底的，而是先往上爬到某个公共祖先，再拐弯往下。那个’‘分叉点’‘就是最近公共祖先，LCA。那么，对于每个查询(u, v)，路径长度 k = depth[u] + depth[v] - 2*depth[LCA]。有了k，对称性trick照旧——方案数还是2^{k-1}。

关键在于，怎么快速找到LCA？

遇事不决先暴力？

既然LCA的定义是两个节点往上爬、第一个相遇的祖先，那最朴素的做法就是模拟这个爬树过程：从u一路爬到根，把沿途所有节点记下来；再从v一路爬到根，看哪个节点最先出现在u的路径里。

对于查询(u, v)，分别爬树记录路径，暴力比对找第一个共同节点： find_path(node) 函数记录从node到根节点的路径，find_lca_brute_force(u, v)函数暴力找u和v的最近公共祖先(LCA)。

# 暴力LCA解法：通过爬树找最近公共祖先 
def assignEdgeWeights(edges: List[List[int]], queries: List[List[int]]) -> List[int]:
 MOD = 1_000_000_007
 n = len(edges) + 1
 g = [[] for _ in range(n + 1)]
 for x, y in edges:
 g[x].append(y)
 g[y].append(x)

 # 预处理父节点和深度
 parent = [0] * (n + 1) # parent[i]表示节点i的父节点
 depth = [0] * (n + 1) # depth[i]表示节点i的深度 

 def dfs(x: int, fa: int) -> None:
 parent[x] = fa
 for y in g[x]:
 if y != fa: # 避免回溯到父节点
 depth[y] = depth[x] + 1
 dfs(y, x)

 dfs(1, 0) # 从根节点1开始DFS，根节点的父节点设为0（虚拟节点）

 # 记录从node到根节点的路径列表（包含node和根节点）
 def find_path_to_root(node: int) -> list:
 path = []
 current = node
 while current != 0: # 一直爬到根节点的父节点（虚拟节点0）
 path.append(current)
 current = parent[current]
 return path

 # 暴力找u和v的最近公共祖先(LCA)
 def find_lca_brute_force(u: int, v: int) -> int:
 path_u = find_path_to_root(u)
 path_v = find_path_to_root(v)
 path_u_set = set(path_u) # 将path_u转为集合，方便快速查找 
 # 从v的路径往上找，第一个在u路径中的节点就是LCA
 for node in path_v:
 if node in path_u_set:
 return node
 return 1 # 理论上不会到这里，因为根节点一定是公共祖先

 # 计算u到v的路径长度k = depth[u] + depth[v] - 2*depth[LCA]
 def get_distance(u: int, v: int) -> int:
 lca = find_lca_brute_force(u, v)
 return depth[u] + depth[v] - 2 * depth[lca]

 # 计算k条边的赋值方案中，使总和为奇数的方案数
 def count_odd_ways(k: int) -> int:
 return pow(2, k - 1, MOD) if k != 0 else 0

 # 处理每个查询
 answer = []
 for x, y in queries:
 if x == y: # 同一点，路径长度为0，方案数为0 
 answer.append(0)
 else:
 # 计算路径长度
 path_length = get_distance(x, y)
 # 计算方案数
 answer.append(count_odd_ways(path_length))

 return answer

我默默算了笔账：查询数量十万，每次暴力找LCA——find_path 爬树最坏O(n)，node in path_v 又是O(n)，总复杂度O(q*n)，十万乘十万，评测机不弹TLE才怪。

正一筹莫展，后脑勺挨了轻轻一下——力道依旧精准。老勇者的声音从背后传来：“又在暴力枚举？”

我捂着后脑勺，感觉救星到了。老勇者瞄了一眼屏幕上的查询列表，又看了一眼我的那段爬树代码，叹了口气：“你啊，总是用O(n)的方法硬刚O(log n)能解决的问题。告诉我，你知道倍增法求LCA吗？”

我心虚地缩了缩脖子：“听说过，Binary Lifting……但一直没学，总觉得二进制跳来跳去的有点玄乎……”

“二进制提升，求LCA的神器。“老勇者打了个响指，“准备让暴力爬树法退役吧，你该学点真正的树上跳跃姿势了！”

当LCA遇上二进制提升！

他在纸上画了一棵枝繁叶茂的大树，并在旁边写下几个大字——’’预处理 + 快速查询 = 降维打击’’。

“暴力法的痛点在哪？“老勇者指向树上的一个节点，“每次查询都要从节点一步步往上爬，像蜗牛一样。如果树退化成一条链，爬一次就是O(n)。十万次查询就是O(nq)，评测机不TLE才是见鬼了。”

‘‘不一步一步爬？‘‘我感到匪夷所思。毕竟在我的认知里，树只能沿着边往上走，要么dfs，要么bfs——就像RPG里爬塔，每层楼梯都得踩一遍，怎么可能跳过中间楼层直接到顶层？

‘’预处理。‘‘老勇者吐出三个字，‘‘提前给每个节点装上 ‘快捷传送门’——不只存它的父节点，而是存它的第1级祖先、第2级祖先、第4级祖先、第8级祖先……直到第2^16级祖先。这样查询的时候，你就可以’跳着走’，而不是’爬着走’。这就是二进制提升的名字由来——用2的幂次来加速跳跃。”

我挠头：‘‘为什么偏偏是2的幂次？’’

‘‘因为任何整数都可以拆成二进制。‘‘老勇者瞅了我一眼，‘‘比如13 = 8 + 4 + 1 = 2^3 + 2^2 + 2^0。如果你要往上跳13步，不用一步一步爬，只需要跳三次：先跳8步，再跳4步，最后跳1步。每次跳跃都是O(1)，总共O(log n)。从蜗牛进化成袋鼠，靠的就是二进制拆分。’’

他在纸上写下了核心定义：pa[x][i] = x的第2^i级祖先，也就是节点x向上跳2^i步到达的祖先。

‘‘哦——’’ 我若有所思，‘‘提前处理好节点的2的幂次级祖先们？可是这要怎么算？每个节点都跳一遍不还是炸？”

‘’动态规划。‘‘老勇者写下状态转移方程：pa[x][i+1] = pa[pa[x][i]][i]，’’ x的第2^{i+1}级祖先，等于x的第2^i级祖先再往上跳2^i步。’’

我感觉脑子有点转不过来：‘‘这不会跳错？套娃套得我头晕。’’

‘‘不会。‘‘老勇者画了个示意图，‘‘假设x的第2级祖先是a，a的第2级祖先是b。x到a是2步，a到b也是2步，那x到b就是4步——所以b就是x的第4级祖先。这个递推的精髓在于：用已知的短距离跳跃，组合出未知的长距离跳跃。2^i级的祖先你已经在上一轮算好了，拿它再跳一次2^i，就是2^{i+1}级。倍增就是这么来的——每一步都建立在之前所有步的基础上，像盖楼一样一层一层往上搭。’’

“DFS的时候，一边往下走一边顺手填。走到一个节点时，它的所有2的幂次祖先都已经在上层被算好了，你只需要用父节点的数据往上递推——pa[x][0]是父节点，pa[x][1]是爷爷，pa[x][2]是爷爷的爷爷，以此类推。一棵树遍历完，每个节点都自带一套二进制传送门，以后找LCA的时候，你就不需要再爬树了，直接让节点按二进制拆分往上层跳就行。’’

老勇者接着写下了完整的预处理代码：

class LcaBinaryLifting:
 def __init__(self, edges: List[List[int]]):
 n = len(edges) + 1
 m = n.bit_length() # 计算需要多少层：log2(n)向上取整

 g = [[] for _ in range(n)]
 for x, y in edges:
 x -= 1 # 节点编号从0开始（内部处理更方便）
 y -= 1
 g[x].append(y)
 g[y].append(x)

 # depth[i]: 节点i的深度（根节点深度为0）
 depth = [0] * n
 # pa[i][j]: 节点i的第2^j级祖先（-1表示不存在）
 pa = [[-1] * m for _ in range(n)]

 def dfs(x: int, fa: int) -> None:
 pa[x][0] = fa # 第2^0=1级祖先就是父节点
 for y in g[x]:
 if y != fa:
 depth[y] = depth[x] + 1
 dfs(y, x)

 dfs(0, -1) # 从根节点0开始DFS，根节点的父节点设为-1

 # 动态规划计算更高级的祖先，状态转移 pa[x][i+1] = pa[pa[x][i]][i]
 for i in range(m - 1):
 for x in range(n):
 if (p := pa[x][i]) != -1: # 如果2^i级祖先存在
 pa[x][i + 1] = pa[p][i] # 计算2^(i+1)级祖先

 self.depth = depth
 self.pa = pa

“你看，“老勇者指着代码，“第一步，建图。第二步，DFS预处理每个节点的深度和直接父节点（pa[x] [0]）。第三步，动态规划计算更高级的祖先。外层循环 log n次，内层循环n次，总共n log n。”

他打了个比方：“预处理一次性完成，之后每次查询都能直接享受红利——就好比副本开荒前先把全图传送点踩一遍，开荒的时候直接飞过去，不用每次都从新手村跑图。”

我盯着代码看了一会，一拍大腿：“也就是说，预处理好了以后，找LCA就不需要一步一步爬树了，而是二进制跳跃！因为LCA肯定是两个节点都能跳到的地方——先让深度大的那个跳到和另一个同一高度，然后两个一起往上蹦，只要跳完之后两人不在同一个节点，就说明还没跳到公共祖先，继续往上跳！”

“是这个道理。” 老勇者竖起四根手指，“听好了，找LCA分四步——”

“第一步，对齐深度。确保x在y上方（depth[x] ≤ depth[y]），如果x更深就交换。然后把y往上跳，跳到和x同一深度。怎么跳？把深度差拆成二进制，按位跳——差13层就先跳8层再跳4层再跳1层。”

“第二步，来个判断——如果跳完之后y == x，说明x本身就是y的祖先，直接返回x。这种情况比如x是y的爷爷，把y提到x的高度之后，发现两人站在同一个节点上，那LCA就是x。”

“第三步，同时倍增跳跃。让x和y从大到小尝试往上跳——从最大的步长（比如2^16）开始试。如果跳完之后x和y的祖先还不一样，说明LCA还在上面，那就跳；如果一样了，说明已经跳到LCA或LCA以上了，就不跳。循环走完，x和y会停在LCA的紧下方——也就是LCA的下一层。”

“第四步，返回它们的父节点pa[x][0]，就是LCA。”

class LcaBinaryLifting:
 def __init__(self, edges: List[List[int]]):
 ......
 self.depth = depth
 self.pa = pa

 def get_kth_ancestor(self, node: int, k: int) -> int:
 for i in range(k.bit_length()): # 遍历k的每一位二进制位
 if k >> i & 1: # k 二进制从低到高第 i 位是 1；
 node = self.pa[node][i] # 往上跳2^i步
 return node

 def get_lca(self, x: int, y: int) -> int:
 if self.depth[x] > self.depth[y]:
 x, y = y, x # 确保x的深度不大于y

 # 1. 使y和x在同一深度
 y = self.get_kth_ancestor(y, self.depth[y] - self.depth[x])
 # 2. 检查是否重合
 if y == x:
 return x # x本身就是y的祖先
 # 3. 倍增跳跃：从最大的步长开始尝试
 for i in range(len(self.pa[x]) - 1, -1, -1):
 px, py = self.pa[x][i], self.pa[y][i]
 if px != py:
 x, y = px, py # 同时往上跳 2**i 步
 # 4. 此时x和y的父节点就是LCA
 return self.pa[x][0]

我盯着那段for i in range(len(self.pa[x]) - 1, -1, -1)的代码，有点困惑：“为什么要从大到小跳？”

“因为要尽快接近LCA，但又不能跳过。“老勇者打了个比方，“就像用砝码称重——先试最大的砝码，太重的就撤掉，刚好就留着，这样精度最高。从小到大跳的话，你跳完1步、2步、4步……到后面可能会跳过LCA，还得退回来，退回来又不知道退多少。从大到小是贪心，每次跳最大可能的步数，但保证不跳过LCA——因为跳过的话 pa[x][i] == pa[y][i]，说明这步太大了，LCA在下面，就不跳。这样就能保证每次都能最大程度地接近LCA，最终刚好卡在LCA正下方，再往上一步就是LCA。”

我反应过来了：“所以最后返回pa[x][0]——x的父节点——就是LCA？预处理O(n log n)，查询O(log n)，这就是二进制提升找LCA的威力？”

“没错。“老勇者点点头，话锋一转，“来，LCA有了，路径长度怎么算？你之前推导过。”

我愣了一下，脑子里迅速回放开始写的公式：“k = depth[u] + depth[v] - 2*depth[LCA]！“抄起键盘补上：

class LcaBinaryLifting:
 ......
 def get_dis(self, x: int, y: int) -> int:
 return self.depth[x] + self.depth[y] - self.depth[self.get_lca(x, y)] * 2

老勇者满意地点点头：“LCA拿到，套公式算出k，再套昨天的对称性结论——方案数 = 2^{k-1}，这题就解决了。”

他顺手补上主函数，一行列表推导式，对每个查询(x, y)，如果x == y，答案是0；否则答案是2^{路径长度减一}：

# 预处理2的幂（用于快速计算方案数）
MOD = 1_000_000_007
POW2 = [0] * 10 ** 5
POW2[0] = 1
for i in range(1, len(POW2)):
 POW2[i] = POW2[i - 1] * 2 % MOD

class Solution:
 def assignEdgeWeights(self, edges: List[List[int]], queries: List[List[int]]) -> List[int]:
 g = LcaBinaryLifting(edges) # 初始化LCA结构
 return [
 POW2[g.get_dis(x - 1, y - 1) - 1] if x != y else 0
 for x, y in queries
 ]

我盯着那段 POW2 数组：“为什么不直接用 pow(2, k-1, MOD)？Python内置的快速幂不是挺快吗？”

老勇者瞪了我一眼，恨铁不成钢地说：“还是预处理！pow 再快也是快速幂，十万次查询，每次O(log k)，就是十万乘十七，一百七十万次运算。但如果提前把2的幂打好表——POW2[i] = 2^i mod MOD——预处理O(n)一次性搞定，之后每次查表O(1)。空间换时间，经典到不能再经典的套路。”

我这才醒悟过来，“哦——就像游戏里提前算好所有技能伤害表，战斗时直接查，不用现场按计算器！”

“总算回过神了你。“老勇者点点头，“不过记住，预处理的数组大小要掐准数据范围。题目n ≤ 10^5，POW2开10^5就够。开小了查询越界，开大了浪费内存——这就是程序员的’度’。”

终章

我把整套代码拼起来，提交。屏幕上的查询列表飞速滚动，一个一个2^{k-1}弹出来，快得像是开了倍速——村长的Steam Deck传来一声清脆的 ‘叮’——‘‘奇数流宗师’‘成就图标从灰色变成金色，再从金色变成带粒子特效的彩虹色，老头激动得差点把电脑举过头顶，“拿到了！宗师！双层成就！我就知道找你是对的！”

我靠在椅背上，盯着那串 LcaBinaryLifting 的代码，想要把它刻进脑袋里——毕竟学会了树上跳跃的神功，我可不想再一步一步蜗牛爬了。老勇者这招“二进制提升”，听起来像黑客，用起来像开挂，真香。

村长抱着电脑乐颠颠地回去了，Steam Deck的风扇声从远处传来，不知道他又在肝什么新成就。我合上魔法书，往锅炉里添了根柴。今天的树上轻功够我消化几天了——下次再见到老勇者，我一定要把倍增表倒背如流。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3558：对称性的觉醒：当奇数和偶数平分天下

Thu, 11 Jun 2026 13:00:38 +0800

🎮 对称性的觉醒：当奇数和偶数平分天下

听说村长最近沉迷于一款叫《技能树大亨》的RPG游戏——我怀疑这老头把省下来的钱全充了Steam余额，账号时长怕不是比我刷题还多。今天一大早，我正蹲在锅炉边添柴，电脑屏幕突然弹出老头的远程协助请求。点下接受，村长的游戏画面直接投屏过来——他的人物正卡在技能树界面，鼠标在一棵枝繁叶茂的树状图上疯狂画圈，技能节点之间的连线旁还标注着"普通升级: 1点"和"强化升级: 2点"。

“小白！我的隐藏成就卡住了！“村长的声音从屏幕那头炸出来，急得像是副本门口等着拉人的团长，“从根技能1号出发，每条连线可以选普通升级花1点，或者强化升级花2点。隐藏成就叫’奇数流大师’，要求算出有多少种加点法能使到达最深那个终极技能的总消耗是奇数！”

我盯着屏幕，扫到成就描述末尾一行不起眼的小字——“忽略从根到最深节点路径外的所有边”。这不就把一棵树压缩成一条链吗？只有从根到最深节点的那条路径算数，其他枝丫全是气氛组，约等于RPG里站桩喊固定台词的NPC。问题瞬缩成两件事：第一，最深那层在哪儿——也就是最大深度k是多少；第二，这k条边上各赋1或2，总和为奇数的组合数是多少。

第一步：找深度是DFS的肌肉记忆

题目给的是无向树——边[1,2]表示1和2互通，虽然根定在1，但遍历必须双向通行，否则DFS 会困在叶子节点，剩下的分支全遍历不到。所以建邻接表时必须每条边两头都加——1的邻居里有2，2的邻居里也有1，双向车道全登记，DFS才能想去哪去哪。

但双向建图有一个经典坑——不记父节点的话，DFS会在父子之间来回横跳，像喝醉的勇者在两个房间之间来回读条，直到栈溢出教我做人。所以递归时带个fa参数当“防回退机制”——告诉DFS“你刚从你爸那儿过来，别再回去了”

MOD = 1_000_000_007
n = len(edges) + 1
g = [[] for _ in range(n + 1)]
for x, y in edges:
 g[x].append(y)
 g[y].append(x)

def dfs(x: int, fa: int) -> int:
 d = 0
 for y in g[x]:
 if y != fa: # 不递归到父节点，防止无限循环
 d = max(d, dfs(y, x) + 1)
 return d

k = dfs(1, 0)

双向建图 + fa过滤 = 无向图当有向树遍历。叶子节点没有非父邻居，直接返回0；自底向上逐层加一，max取最大深度。这套组合拳打过无数次的DFS模板——就像RPG里的基础连招。

深度k到手。

第二步：奇偶性的对称美学

接下来是核心——k条边，每条1或2，总和为奇数的方案数。

1是奇数，2是偶数，总和为奇数等价于路径上有奇数个1。枚举C(k,1) + C(k,3) + C(k,5) + …？我数学早就连本带利还给老师了，组合数求和公式长啥样都忘了，更别说还要取模。

等等——换个思路：如果前k-1条边的和是偶数，最后一条只能选1把总和扳成奇数；前k-1条边的和是奇数，最后一条必须选2把总和保持奇数。

也就是说，前k-1条边可以自由发挥，最后一条边只能被迫营业——有且仅有一种选择能救场。所以总方案数就是前k-1条边的任意组合数——前k-1条每条自由选1或2，总共2^{k-1}种。

再往深层想的话，这可以说是奇偶对称性的必然结果：对于任意k≥1，在所有2^k种赋值中，权重和为奇数和偶数的方案数永远平分天下，各占一半。

这不是什么巧合，是奇偶性天生的对称：把最后一条边从1翻成2，奇偶就翻转，所有方案两两配对，恰好一半奇一半偶。所以答案=2^k / 2 = 2^{k-1}。不用枚举，不用求和，一行对称性直接秒杀。

return pow(2, k - 1, MOD)

pow(base, exp, mod)快速幂，底层用二分指数，O(log k)搞定，属实是标准库里的隐藏神器。

收工？

我敲下回车，屏幕那头村长的隐藏成就图标“叮”地一声亮了，金色光芒闪得他差点把电脑抱起来转圈。“拿到了！奇数流大师！我就知道找你是对的！” 村长的声音兴奋得像刚抽到SSR。

我刚想谦虚两句，突然看到游戏界面上弹出一个新的成就预告——“奇数流宗师：应对任意两个技能节点之间的路径，计算奇偶方案数，解锁终极加点方案”。

我心里咯噔一下。任意两个节点之间的路径？那可不是今天这种“从根到最深叶子”的单条快车道了——查询可能从任意节点出发，到任意节点结束，路径长度各不相同，有些说不定还会往上走到公共祖先再拐下去。奇偶对称性的核心没变，路径上有k条边，方案数还是2^{k-1}，但每条查询的k都不一样，怎么快速找出任意两点之间的距离？

我感觉自己的后背开始冒汗。

村长还在屏幕那头兴奋地嚷嚷：“小白，你看这个’奇数流宗师’成就，好像有点意思啊！要不你现在帮我看看……”

“今、今天就算了吧！“我慌忙打断他，“我得去……去添柴！锅炉要熄了！”

说完，我果断切断了远程连接，瘫在椅子上长长地舒了一口气。

明天的事，明天再说吧。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3691从堆到树：一道题的两个平行宇宙

Wed, 10 Jun 2026 16:10:20 +0800

🎮从堆到树：一道题的两个平行宇宙

今天的任务卷轴——3691. 最大子数组总值 II——规则赫然写着：选恰好 k 个不同的非空子数组，可以重叠，同一个子数组不能被选择超过一次。求最大极差之和。

我差点笑出声。这不就是老勇者昨天拿红笔在我羊皮纸上改出来的那道“如果加上约束”吗？连标点符号都没改！直接上昨天那套代码——隧道模型 + 贪心堆 + 稀疏表。稀疏表预处理 O(n log n)，每条隧道初始最深段入堆，候选池恒定 n 个，每次弹堆顶累加极差、同一隧道缩一格压回，k 次堆操作 O(k log n)。提交，AC，一气呵成。

我往椅背上一靠，长长地舒了一口气。今天这副本过得这么快，说白了还得感谢老勇者昨天提前给我开的小灶，跟考前泄题似的。我严重怀疑这老头是策划部的内鬼。我端起茶杯，想着今天终于不用担心被弹脑瓜崩——毕竟答案是他自己教的，他总不能弹自己吧？

茶杯刚端到嘴边，茶水表面映出一个熟悉的身影。我手一抖，滚烫的茶水差点浇在裤裆上。老勇者正站在我身后，低头看着我的屏幕，表情介于"孺子可教"和"你还差得远"之间。

“大、大师……“我结结巴巴地说道，“你怎么又来了？！这题不就是昨天你红笔改的那道吗，没加新约束，原封不动！我用的是你教的隧道模型加堆加稀疏表，一个变量都没改！”

“别紧张。“老勇者笑了笑，在我肩上轻轻拍了拍——终于不是弹脑瓜崩，“昨天教你的，今天能直接用上，说明你记住了，理解了’固定一端、贪心另一端’的精髓。我来不是为了弹你，是来问你一个问题。”

“问题？“我心里咯噔一下，毕竟老勇者的"问题"通常意味着"你又掉坑里了"或者"还有更优解”。

老勇者指了指我的代码：“隧道模型加堆，k 次堆操作 O(k log n)，k 到十万的时候千万级操作量，常数拉满。如果哪天 k 飙到 10^6、10^7，你这个堆还撑得住吗？”

我倒吸一口凉气。说实话，我压根没想过这个问题。能过就行，还要什么自行车？但老勇者这么一说，我突然意识到：这解法复杂度跟 k 线性相关，k 越大越慢。现在 k ≤ 10^5 能过，但如果 k 到了 10^6、10^7 呢？如果这是一道交互题，要求在线查询呢？

“真正的勇士，“老勇者缓缓开口，“敢于直面惨淡的复杂度，敢于正视淋漓的 TLE。如果有一种方法，复杂度跟 k 彻底解耦，能在 O(n log n) 的时间内解决，不管 k 有多大都稳如泰山——你想不想学？”

我手里的茶杯"啪"地掉在地上：“O(n log n)？跟 k 无关？这都违反信息论了吧？！”

老勇者狡黠一笑，”二分答案，上古时代用来处理 Top-K 问题的禁忌魔法。它的核心思想简单得反直觉：不直接找那 k 个子数组，而是先找到第 k 大的极差值到底是多少，然后分类统计。

“等等，你是说……我不需要知道前 k 名分别是谁，只需要知道第 k 名的分数是多少？” 我感觉自己的世界观在崩塌。

“对。”老勇者打了个响指，空中应声浮现出一排数字，“就像你不需要把全班成绩单从头排到尾，只需要知道第十名的分数——然后比它高的全录，刚好压线的挑几个凑够人数，剩下的全刷。这种思路叫二分答案判定，把选择问题降维成判定问题。在很多 Top-K 场景里，都是降维打击的利器。”

第一重封印：二分答案——先找阈值，再分类统计

老勇者在卷轴背面画出一条数轴，从 0 标到 max(nums) - min(nums)。

“想象你在玩一个猜数字游戏。我告诉你：存在一个阈值 low_d，所有极差严格大于 low_d 的子数组，数量凑不够 k 个；但如果把等于 low_d 的也加上，数量就够 k 了——甚至超过 k。这个 low_d 是什么？”

我想了想：“这不就是第 k 大的极差值吗？排名刚好卡在第 k 位的那个人！”

“没错。“老勇者点点头，手指在数轴上轻轻一划，“如果我们能快速算出’有多少个子数组的极差 ≥ X’，就能用二分查找精准定位这个 low_d。找到之后，问题就拆成三块：极差严格大于 low_d 的全选；极差刚好等于 low_d 的，挑几个补满 k 个；极差小于 low_d 的直接pass。最后用选中的子数组去求和。”

我眼睛一亮：“这不就高考录取吗！先划分数线，过线的全录，压线的按志愿顺序挑，没达线的回家种地。把 Top-K 选择问题降维成一个判定问题——‘这个分数线划得合不合理？’——然后二分答案！”

“是这个道理。“老勇者笑了笑，话锋陡然一转，“不过，现在你只是知道了解法蓝图。蓝图里最关键的那块砖还没烧——怎么高效判定？给你一个阈值 X，你怎么快速统计出极差 ≥ X 的子数组到底有多少个？”

我嘴巴闭得紧紧的，心里反复默念——绝对不能提 O(n²) 暴力枚举，求生欲告诉我，沉默是金。

他瞅了瞅我：“这就引出了第二重封印——滑动窗口加单调队列。想学的话，把你脑子里那个 O(n²) 的念头掐掉，我要往里面塞点真正高效的东西。”

第二重封印：滑动窗口 + 单调队列——像塔防游戏一样收缩防线

老勇者在纸上画了一个窗口 [left, i]，左右两端各站着一个守卫，一个盯最大值，一个盯最小值。

“想象你在玩一个塔防游戏。右端点 i 是你不断往前推的兵线，每次加入一个新元素，你要维护窗口内的最大值和最小值，确保极差始终小于 X。一旦极差飙到 ≥ X，说明战线崩了，就得把左端点 left 往右挪，收缩防线，直到极差重新掉回安全线以下。”

他写下一段代码，我凑了过去，看到两个双端队列 min_q 和 max_q，一个单调递增存最小值候选，一个单调递减存最大值候选。每次 i 右移，新元素入队，过期元素被窗口淘汰。关键在最后一句：cnt += left——对于当前右端点 i，左端点在 [0, left-1] 范围内的所有子数组，极差都 ≥ X，所以直接累加 left 就是新增的数量。一旦 cnt 攒到 k，就说明这个阈值太低，数量超标了，直接打回。

def check(low_d: int) -> bool:
 low_d += 1 # 实际检查的是极差 >= low_d+1
 min_q = deque() # 单调递增队列，维护最小值的下标
 max_q = deque() # 单调递减队列，维护最大值的下标
 cnt = left = 0

 for i, x in enumerate(nums):
 # 1. 右边入队：维护单调性
 while min_q and x <= nums[min_q[-1]]:
 min_q.pop()
 min_q.append(i)

 while max_q and x >= nums[max_q[-1]]:
 max_q.pop()
 max_q.append(i)

 # 2. 左边出队：收缩窗口直到极差 < low_d+1
 while nums[max_q[0]] - nums[min_q[0]] >= low_d:
 left += 1
 if min_q[0] < left: # 队首不在窗口中
 min_q.popleft()
 if max_q[0] < left: # 队首不在窗口中
 max_q.popleft()

 cnt += left # 对于右端点i，有left个左端点使得极差 >= low_d+1
 if cnt >= k:
 return False # 数量够了，阈值太低
 return True # 数量不够，阈值太高

low_d = bisect_left(range(max(nums) - min(nums)), True, key=check)

我盯着那段单调队列的代码，感觉似曾相识：“等等，两个双端队列一左一右夹着窗口滑过去，最大值最小值实时追踪，这不就是 1438 题’绝对差不超过限制的最长连续子数组’的经典套路吗？那道题求的是窗口能撑到多长，这道题求的是子数组数量，就差在 cnt += left 这一行！”

“没错。“老勇者点点头，“对于当前右端点 i，左端点在 [0, left-1] 范围内的所有子数组，极差全都 ≥ low_d。所以直接累加 left，数量就出来了。判定函数的返回值也反过来用：返回 True 说明数量不够，阈值太高了，得往下降；返回 False 说明数量超了，阈值太低了，得往上抬。二分夹逼到最后，第一个让 check 返回 True 的 low_d，就是第 k 大的极差值。”

“但——“他话锋一转，眼神变得危险起来，“滑动窗口只能告诉你’有多少个’子数组过线了，至于每个过线子数组的极差具体是多少、加起来总和多大，它一概不管，就像个只数人头不登记分数的门卫。”

我感觉后背开始冒汗，“既然滑动窗口只能计数不能求和，那要求极差之和，难道要把每个子数组的最大最小值都查出来？这不又退回 O(n²) 了？”

‘‘所以才需要第三重封印。“老勇者在纸上写下三个大字——单调栈，“判定靠滑动窗口，求和靠单调栈加线段树——前者是哨兵站岗，只管数人头；后者是工程兵架桥，把每一段极差的具体数值算清楚。”

第三重封印：单调栈——给每个元素划地盘

“先解决第一步——怎么快速知道每个子数组的最小值和最大值由谁当。“老勇者叩了叩桌子，“对于每个位置 i，你怎么快速找到它左边第一个 ≤ nums[i] 的位置？”

我想了想：‘‘用一个单调递增栈，从左往右扫，栈顶就是左边第一个比当前元素小的位置？’’

‘‘对。‘‘老勇者提笔唰唰写下几行代码：

n = len(nums)
left_less_eq = [0] * n # 左边第一个 <= nums[i] 的位置
left_great_eq = [0] * n # 左边第一个 >= nums[i] 的位置
st1 = [-1] # 哨兵
st2 = [-1]
for i, x in enumerate(nums):
 while len(st1) > 1 and nums[st1[-1]] > x:
 st1.pop()
 left_less_eq[i] = st1[-1]
 st1.append(i)

 while len(st2) > 1 and nums[st2[-1]] < x:
 st2.pop()
 left_great_eq[i] = st2[-1]
 st2.append(i)

“两个单调栈，一趟扫描，分别追踪左边第一个 ≤ 和第一个 > 的位置。left_less_eq[i] 表示位置 i 左边第一个 ≤ nums[i] 的位置。这意味着在区间 (left_less_eq[i], i] 内，所有元素都严格大于 nums[i]。所以，以 i 为右端点、左端点落在这个区间内的所有子数组，最小值统统是 nums[i]。’’

我惊呼道：“那 left_greater_eq[i] 就是左边第一个 ≥ nums[i] 的位置，左端点落在 (left_greater_eq[i], i] 内的所有子数组，最大值都是 nums[i]！两个数组合起来，就把每个元素作为最小值或最大值的‘地盘’划得清清楚楚！”

“没错。相当于给每个元素发了一张地契——在它的地盘里，它就是最值。“老勇者点点头，“但光有地盘还不够。你想想，随着右端点 i 不断往右移，每个左端点 j 对应的子数组 [j, i] 的最小值和最大值是动态变化的。新元素一加入，某些左端点对应的最值就要更新。你需要一个数据结构，能把这些动态变化的最值维护起来，还能快速查询任意左端点区间内的最值之和。”

我感觉脑细胞已经开始集体抗议：“今天的强度过分了啊——动态维护所有左端点的最值？还区间查询求和？这活儿谁干得了？队列不行，栈也不行，总不能上树吧——”

老勇者咳了一声，连锅炉里的火都抖了三抖，“你说对了——就是要上树。欢迎来到地狱模式的最终章：懒标记线段树。”

第四重封印：懒标记线段树——动态维护所有左端点的极值

老勇者在纸上画出一棵倒挂的二叉树，每个节点上挂着四面小旗，分别写着 sum_min、sum_max、l_min、l_max。

“线段树的下标 j 代表’以 j 为左端点，当前 i 为右端点‘的子数组 [j, i]。每个节点管一片连续的左端点区间，维护四个值——sum_min 是这个区间内所有左端点对应的当前子数组的最小值之和，sum_max 是最大值之和。l_min 和 l_max 是懒标记，代表这个区间内所有左端点被统一刷成的’共同最小值’和’共同最大值’。”

我感觉自己的 SAN 值正在狂掉：“等等，为什么存’和’？还有那个’懒标记’是什么鬼？听起来像我的拖延症一样。”

“因为你要的不是单个子数组的极差，而是’所有极差 ≥ low_d 的子数组的极差之和’。“老勇者耐心地解释，“如果你只存单个最值，查区间 [0, l] 的极差之和时，你得把 l+1 个左端点挨个捞出来，一个个减，一个个加——O(n)，求和又炸了。但每个节点提前把管辖区的 sum_max 和 sum_min 存好，一次区间查询直接拎出两个总和，极差之和 = sum_max - sum_min，O(log n) 完事。”

我恍然大悟：“所以线段树不是在存单个值，是在存’辖区总和’！每个节点提前把自己管的那段区间的账算好了，上面要查的时候直接报总数，不用一个一个数人头！”

“正是。这就是线段树的精髓——把 O(n) 的区间求和压成 O(log n) 的分块预结算。“老勇者话锋一转，“但光有查询还不够，你还得能更新。每次 i 往右移一位，新元素 nums[i] 加入，哪些左端点对应的子数组最值会变？”

我顺着他的目光看向之前写的单调栈代码：“左端点落在 (left_less_eq[i], i] 内的，最小值统统更新为 nums[i]；左端点落在 (left_greater_eq[i], i] 内的，最大值统统更新为 nums[i]。这就是两次区间赋值——每来一个新元素，就要把两片连续区间的所有左端点的最值全刷成同一个数。”

“对。区间赋值，暴力改是 O(n)，来一个元素改一片，总复杂度直接飙回 O(n²)。这时候懒标记就登场了。“老勇者指了指节点上那两面写有 l_min 和 l_max 的小旗，“以刷最小值为例——如果当前节点完全被覆盖，直接把它的 l_min 更新成 nums[i]，对应的 sum_min 就是 l_min × 区间长度，然后拍拍屁股走人，不用往下递归到每个叶子。它的子孙们先欠着，等下次查询或更新路过的时候再把这笔账还下去。这样一次区间赋值也是 O(log n)，而不是 O(n)。”

我目瞪口呆，“所以懒标记不是偷懒，是把区间赋值的活儿打包延期执行——每次只改大区间的总账，明细先欠着，等要查明细的时候再往下分摊！这不就是我平时写代码时的 ‘TODO: 稍后优化’ 吗？”

“你这说的……虽然不太恰当，但意外地准确。“老勇者嘴角抽搐了一下，“懒标记的核心思想就是延迟传播（Lazy Propagation）。更新时只改当前节点的标记和总和，不往下递归；查询或再次更新时，如果需要访问子节点，才把标记下传（spread）。这样保证每次操作都是 O(log n)。”

他提笔写下了一颗完整的懒标记线段树，看起来就像魔法阵一样：

class Node:
 # val = [sum_min, sum_max, l_min, l_max]
 # todo = [todo_min, todo_max]
 __slots__ = 'val', 'todo'

class LazySegmentTree:
 # 懒标记初始值
 _TODO_INIT = [-1, -1]

 def __init__(self, n: int):
 # 线段树维护一个长为 n 的数组（下标从 0 到 n-1）
 self._n = n
 self._tree = [Node() for _ in range(2 << (n - 1).bit_length())]
 self._build(1, 0, n - 1)

 # 合并两个 val
 def _merge_val(self, a: List[int], b: List[int]) -> List[int]:
 return [a[0] + b[0], a[1] + b[1], a[2], a[3]]

 # 把懒标记作用到 node 子树（本例为区间赋值）
 def _apply(self, node: int, l: int, r: int, todo) -> None:
 cur = self._tree[node]
 # 计算 tree[node] 区间的整体变化
 todo_min, todo_max = todo
 if todo_min >= 0:
 cur.val[0] = todo_min * (r - l + 1) # 区间最小值之和 = 最小值 × 区间长度
 cur.val[2] = todo_min # 记录共同最小值
 cur.todo[0] = todo_min # 设置懒标记
 if todo_max >= 0:
 cur.val[1] = todo_max * (r - l + 1) # 区间最大值之和
 cur.val[3] = todo_max
 cur.todo[1] = todo_max

 # 把当前节点的懒标记下传给左右儿子
 def _spread(self, node: int, l: int, r: int) -> None:
 todo = self._tree[node].todo
 if todo == self._TODO_INIT: # 没有需要下传的信息
 return
 m = (l + r) // 2
 self._apply(node * 2, l, m, todo) # 下传给左儿子
 self._apply(node * 2 + 1, m + 1, r, todo) # 下传给右儿子
 todo[:] = self._TODO_INIT[:] # 清空当前节点的懒标记

 # 合并左右儿子的 val 到当前节点的 val
 def _maintain(self, node: int) -> None:
 self._tree[node].val = self._merge_val(
 self._tree[node * 2].val,
 self._tree[node * 2 + 1].val
 )

 # 初始化线段树
 # 时间复杂度 O(n)
 def _build(self, node: int, l: int, r: int) -> None:
 self._tree[node].val = [0] * 4
 self._tree[node].todo = self._TODO_INIT[:]
 if l == r: # 叶子
 return
 m = (l + r) // 2
 self._build(node * 2, l, m) # 初始化左子树
 self._build(node * 2 + 1, m + 1, r) # 初始化右子树
 self._maintain(node)

 def _update(self, node: int, l: int, r: int, ql: int, qr: int, f: Tuple[int, int]) -> None:
 if ql <= l and r <= qr: # 当前子树完全在 [ql, qr] 内
 self._apply(node, l, r, f)
 return
 self._spread(node, l, r)
 m = (l + r) // 2
 if ql <= m: # 更新左子树
 self._update(node * 2, l, m, ql, qr, f)
 if qr > m: # 更新右子树
 self._update(node * 2 + 1, m + 1, r, ql, qr, f)
 self._maintain(node)

 def _query(self, node: int, l: int, r: int, ql: int, qr: int) -> List[int]:
 if ql <= l and r <= qr: # 当前子树完全在 [ql, qr] 内
 return self._tree[node].val
 self._spread(node, l, r)
 m = (l + r) // 2
 if qr <= m: # [ql, qr] 在左子树
 return self._query(node * 2, l, m, ql, qr)
 if ql > m: # [ql, qr] 在右子树
 return self._query(node * 2 + 1, m + 1, r, ql, qr)
 l_res = self._query(node * 2, l, m, ql, qr)
 r_res = self._query(node * 2 + 1, m + 1, r, ql, qr)
 return self._merge_val(l_res, r_res)

 def _find_last(self, node: int, l: int, r: int, ql: int, qr: int, f: Callable[[List[int]], int]) -> int:
 if l > qr or r < ql or not f(self._tree[node].val):
 return -1
 if l == r:
 return l
 self._spread(node, l, r)
 m = (l + r) // 2
 idx = self._find_last(node * 2 + 1, m + 1, r, ql, qr, f) # 优先查右子树
 if idx < 0:
 idx = self._find_last(node * 2, l, m, ql, qr, f) # 右子树没有再查左子树
 return idx

 # 用 f 更新 [ql, qr] 中的每个 a[i]
 # 0 <= ql <= qr <= n-1
 # 时间复杂度 O(log n)
 def update(self, ql: int, qr: int, f: Tuple[int, int]) -> None:
 self._update(1, 0, self._n - 1, ql, qr, f)

 # 返回用 _merge_val 合并所有 a[i] 的计算结果，其中 i 在闭区间 [ql, qr] 中
 # 0 <= ql <= qr <= n-1
 # 时间复杂度 O(log n)
 def query(self, ql: int, qr: int) -> List[int]:
 return self._query(1, 0, self._n - 1, ql, qr)

 # 返回 [ql, qr] 内最后一个满足 f 的下标
 # 0 <= ql <= qr <= n-1
 # 时间复杂度 O(log n)
 def find_last(self, ql: int, qr: int, f: Callable[[List[int]], int]) -> int:
 return self._find_last(1, 0, self._n - 1, ql, qr, f)

“注意看 _ apply 方法。“老勇者指着代码，"todo_min >= 0 表示要把这个区间的最小值设为 todo_min。那么 sum_min = todo_min × 区间长度，同时设置 l_min = todo_min 和懒标记 todo[0] = todo_min。_spread 方法负责把懒标记下传给子节点，然后清空当前节点的标记。”

我感觉脑子有点转不过来：“所以下传的时候，是把父节点的懒标记应用到子节点上，然后父节点的标记清零？这就像是老板把任务分配给下属，然后自己装作什么都没发生过？”

“差不多。“老勇者点点头，“但要注意，下传之前要检查懒标记是否是初始值（这里是 [-1, -1]）。如果是初始值，说明没有待下传的任务，直接返回。”

“还有 _merge_val 方法，合并左右儿子的信息时，sum_min 和 sum_max 直接相加，因为要统计总和；l_min 和 l_max 取左儿子的值——注意：这里有个前提——只有在区间被统一赋值时，l_min/l_max 才有意义，合并时实际上只用叶子节点的真实值。”

我盯着那段 find_last 的代码，感觉脑子快要烧了：“这个 find_last 为什么优先查右子树？”

“因为要找’最后一个’满足条件的位置。“老勇者解释道，“线段树的中序遍历是从左到右，所以右子树的下标更大。优先查右子树，如果右子树里有满足条件的，就直接返回；如果没有，再查左子树。这样保证找到的是最右边的那个。另外，注意看它开头的判断：if l > qr or r < ql or not f(self._tree[node].val) 。如果当前节点的 val 都不满足条件 f，那它的子节点肯定也不满足，直接剪枝返回 -1。这是线段树查询的经典优化。”

接着，他写下了主逻辑：

# Lazy 线段树
t = LazySegmentTree(n)
cnt = s = 0
for i, x in enumerate(nums):
 t.update(left_less_eq[i] + 1, i, (x, -1)) # 更新最小值
 t.update(left_great_eq[i] + 1, i, (-1, x)) # 更新最大值

 # 找到最后一个使得 最大值-最小值 >= low_d 的左端点
 l = t.find_last(0, i, lambda v: v[3] - v[2] >= low_d)

 if l >= 0:
 cnt += l + 1 # 有 l+1 个子数组满足条件
 d = t.query(0, l) # 查询这些子数组的 sum_min 和 sum_max
 s += d[1] - d[0] # 极差之和 = sum_max - sum_min

return s - (cnt - k) * low_d # 减掉多算的

“这就是全部流程。“老勇者一边写一边解释，“每次 i 往右移一位，先用单调栈确定地盘，再用线段树做两次区间赋值——把 (left_less_eq[i], i] 的最小值刷成 nums[i]，把(left_greater_eq[i], i] 的最大值刷成 nums[i]。更新完之后，在线段树上用 find_last 在区间 [0, i] 内从右往左找到最后一个满足最大值 - 最小值 ≥ low_d的左端点 l。”

他顿了顿，补了一句："find_last 就是线段树上做一次二分——从右往左找最后一个满足条件的叶子位置。因为极差随左端点左移单调不减，区间越长，极差越大，所以找到最后一个过线的左端点 l，[0, l] 内的就全过线了。直接区间查询 [0, l] 的 sum_max - sum_min，累加进答案 s，数量 cnt 累加 l+1。最后，二分阶段确定的 low_d 是第 k 大极差，实际统计的过线数量 cnt 可能超过 k，多出来的那些极差都等于 low_d，答案减去 (cnt - k) * low_d 收工。”

终章：封印解除

我瘫在椅子上，盯着那张画满二叉树、懒标记和单调栈的草稿纸，感觉自己的脑细胞像被矿脉采掘过一样，空了又满，满了又空。

“让我理一理……” 我扶着额头，把刚才那一整套流程在脑子里重新串了一遍：”

二分答案：定位第 k 大的极差值 low_d，把选择问题降维成判定问题——我不需要知道具体是哪 k 个子数组，只需要知道第 k 大的极差是多少
滑动窗口 + 单调队列：在 check 函数里统计极差 ≥ X 的子数组数量，用双端队列维护窗口的最大最小值，O(n) 完成判定
单调栈预处理：给每个元素划好地盘，确定每个元素作为最小值/最大值的影响范围——left_less_eq 和 left_great_eq 就是它们的地契
懒标记线段树：动态维护每个左端点对应的子数组的极值，快速统计过线子数组的极差之和——区间赋值用懒标记 O(log n)，区间查询直接报总数 O(log n)”

老勇者欣慰地点点头，像是在看一个终于学会走路的孩子：“现在你来算算复杂度——”

“二分答案 O(log(max_val))，每次 check O(n)，单调栈 O(n)，线段树 O(n log n)。总复杂度 O(n log n + n log(max_val))，跟 k 无关！”

“这是真正的优化。“老勇者缓缓地站起身，火光映射下，他的身影就像超人一样，“昨天的堆 + 稀疏表，复杂度跟 k 线性相关；今天的二分答案 + 线段树，完全摆脱了 k 的束缚。当 k 很大时，这就是降维打击。”

“不过——” 他的话音严肃了起来，“今天的解法虽然复杂度更优，但代码量是昨天的三倍，调试难度也是指数级上升。在实际面试中，除非面试官明确要求’优化掉 k’，否则昨天的堆版本就足够了。别为了炫技把自己坑了。”

我目送老勇者的背影消失在村口，然后低头看了看草稿纸上那密密麻麻的四重封印——二分答案、滑动窗口、单调栈、线段树，每一个单独拎出来都能撑起一道中等难度的题，今天它们被串成一条流水线，就为了从一个十万长度的数组里精准捞出前 k 大极差。

炫技？我连把这套代码完整写出来不报错都够呛，还炫技。脑细胞都快集体罢工了好吧。

我小心翼翼地把画满老勇者笔迹的草稿纸收进我的魔法书里，想起老勇者的话，在旁边加了一小行：能用一行流解决的问题，别上 DP；能用堆解决的问题，别上线段树。但如果约束真的逼到了那一步——也别怂，四重封印该解就解，大不了多薅些头发。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3689 贪心策略的两种命运：可重复选vs不可重复选

Tue, 09 Jun 2026 17:16:07 +0800

🎮 贪心策略的两种命运：可重复选vs不可重复选

能摆的时候别卷，该卷的时候别摆

村长又来信了。这次竟然是让村里的老黄牛慢悠悠驮过来的——我怀疑村长把信鸽的口粮预算都给砍了，这老头在省钱的路上已经走火入魔。我展开纸条一看：“ 小白，勇士团下周开荒新副本，出发前要做战力波动评估！规则如下：给一个数组 nums 和一个整数 k，从中选恰好 k 个非空子数组。子数组可以重叠，同一个子数组可以被选择超过一次。每个子数组的值 = 最大值 - 最小值，求最大可能的总值。”

我盯着“可以重叠”和“可以被选择超过一次”这两行字，手里的拨火棍差点掉进锅炉里。这不就是明摆着让我薅羊毛吗？整个数组就是天然的极差冠军——既然同一段能刷 k 遍，那就把极差冠军往死里薅——就像在游戏里找到经验值最高的怪，然后挂机刷 k 次，连走位都省了。

return (max(nums) - min(nums)) * k

一行流，三十秒 AC，我甚至有空给自己泡了杯茶。茶杯端到嘴边，我忽然顿住了——不对劲。非常不对劲。

我见过太多副本了——加一个约束，难度翻倍；砍一个约束，难度减半。但这题居然专门强调“子数组可以重叠”“同一个子数组可以反复选”——也就是说，“子数组之间不能重叠”和“每个子数组只能选一次”这两个最要命的约束全被砍了，直接退化成一个极值问题，难度标签形同虚设。这不是放水，这是泄洪啊。

事出反常必有妖。我正盯着屏幕发呆，后脑勺"啪"地挨了一下。不重不轻，力道精准得像调试过阈值的触发器。果然又是老勇者，手指还保持着弹脑瓜崩的姿势，“AC 了还发呆？不像你啊——”

“喂，大师，下次咱换个出场方式行吗？” 我揉着后脑勺嘟囔道，“这道题简单到诡异啊。” 我把题目指给他看，“‘可以重叠’、‘可以反复选’——约束全砍了，一行代码就搞定，策划是不是被盗号了？”

老勇者笑了：“策划没被盗号，他这是在告诉你——贪心的极致就是摆烂。既然能无限次选择最优解，就别整那些花里胡哨的，直接把最优解复制 k 份。你想想，如果连摆烂的机会都不给你，直接上硬核约束，你连这个一行流的心得都悟不到，直接被困难版锤进地里。”

“……所以，策划用心良苦就是为了教我读题？”

”能看穿什么时候该摆烂，也是一种本事。不过——"

老勇者话锋一转，眼神突然变得危险起来，“如果加上约束，阁下又将如何应对？”

他伸手拿起那张皱巴巴的羊皮纸，掏出随身携带的红笔——那个瞬间我甚至怀疑他是不是专门等着改我的题目——在纸上画了画，然后又递回给我。我低头一看：

“选择恰好 k 个不同的非空子数组。子数组可以重叠，同一个子数组不可以被选择超过一次。”

我倒吸一口凉气，手里的茶杯差点跟着羊皮纸一块儿掉进锅炉里。“不同的”非空子数组，“同一个子数组不能被选择超过一次”——约束一加，难度飞天。刚才一行流抓最肥的羊反复薅，现在每只羊只让薅一次，这不得挑出前k个最肥的羊？

我开始盘算：直接上暴力把所有可能的子数组全列出来，算极差，排序，取前 k 大。但长度为 n 的数组，子数组数量 n(n+1)/2，O(n²) 的候选集，n 大了直接炸，评测机怕是要给我唱一首《超时咏》。

“等等——题目只改了‘不能重复选同一段’，没禁止段之间重叠！！” 我拿着笔在纸上戳了戳，“既然可以重叠，那我不需要担心选了一段之后堵死其他段的问题。整个数组的极差max - min是冠军，只能用一次。把它用掉之后，第二大极差要么是抠掉最大值后剩下的区间，要么是抠掉最小值后剩下的区间——把最值抠掉，极差才可能变小。然后，季军就是从亚军的残骸里继续抠最值——”

我一拍脑门，“这不就是一个贪心扩展的过程吗？搞个大根堆维护候选池，每次挑极差最大的区间用掉，然后把它‘切开’——抠掉最大值或最小值之后，剩下的子区间重新扔回候选池里。重复 k 次，累加极差，搞定。大根堆！这可是高级数据结构，这把稳了。”

“方向是对的。”老勇者点点头，然后毫不留情地浇了一盆冷水，“但你的刀法有问题——候选池里的区间数量会指数爆炸，你这不叫堆，叫炸弹。想象一下，每次切一下产生两个新区间，k 次就是 2^k 个候选，你的堆会变成二叉树的坟场。"

我刚刚燃烧起来的小宇宙瞬间被浇灭，整个人像被触发了 NullPointerException 一样瘫在椅子上。大根堆都救不了我，那还有什么能救？

老勇者撇了我一眼，拿起笔在草稿纸上画了一条长线，标上刻度 0 到 n。“换个角度。别再跟切分死磕了。任意一个子数组都由两个东西决定——左端点 l 和右端点 r。固定 l，极差随 r 怎么变？”

我想了想：“r 越往右，区间越长，最大值只会变大或不变，最小值只会变小或不变——所以极差只增不减？”

“对。“老勇者在纸上画了几条平行的隧道，每条从不同起点出发，箭头齐刷刷指向右边，“”这就像玩一个挖矿游戏——固定起点，隧道越长，挖到的宝藏价值差越大。“

”初始地图上有 n 个起点，你站在每个起点 i，把每条隧道都从起点一路挖到最深处 [i, n)，把这 n 个候选段全扔进一个最大堆里。弹出堆顶——当前极差最大的区间——累加价值差进答案，然后把当前隧道在深度上缩一格，也就是把右端点从 r 减到 r-1，再压回堆里作为新的候选。如此重复 k 次即可。"

我盯着那排箭头：“等等——所以不是切碎区间？而是固定左端点，只缩短右端点？让堆里永远只有 n 个候选？！”

“对。每次弹出 [l, r)，压回 [l, r-1)。候选数恒定 n 个，不会指数爆炸。而且对于固定 l，极差随 r 单调不减，每次取堆顶一定是全局最优，贪心正确性有保证——这就是’隧道模型’，只在一个方向缩，不往两个方向切。"

“但每次缩一格要重新扫一遍极差不还是 O(n)，这是把爆炸从堆里挪到了查询里吗？“我皱着眉头，感觉这个方案还是有致命伤。

老勇者嘴角勾起一抹神秘的微笑：“所以你需要一件神器——能让任意区间的极差查询在 O(1) 时间内完成的神器。”

“O(1)？！“我差点从椅子上跳起来，“难道不用遍历就能知道最大值和最小值？这违反了信息论吧？在每个位置都装个预知未来的水晶球？”

“差不多。“老勇者真的从怀里掏出了一块……石板？上面刻满了密密麻麻的符文，“这叫稀疏表（Sparse Table），上古时代用来快速查询区间最值的魔法阵。核心思想很简单——提前把所有可能用到的区间的最值都算好存起来，用的时候直接查表。”

他抬手在空中划出一串发光的代码，稀疏表像闪亮的星星一样悬在半空：

def op(a, b):
 return (min(a[0], b[0]), max(a[1], b[1]))

class ST:
 def __init__(self, a):
 n = len(a)
 w = n.bit_length()
 st = [[None] * n for _ in range(w)]
 st[0] = [(x, x) for x in a]
 for i in range(1, w):
 for j in range(n - (1 << i) + 1):
 st[i][j] = op(st[i-1][j], st[i-1][j + (1 << (i-1))])
 self.st = st

 # 查询 [l, r) 左闭右开，返回极差
 def query(self, l, r):
 k = (r - l).bit_length() - 1
 mn, mx = op(self.st[k][l], self.st[k][r - (1 << k)])
 return mx - mn

“等等等等，“我被那一堆位运算晃得眼晕，“这玩意儿怎么看都像黑魔法……1 « i 是什么鬼？”

老勇者叹了口气，拿起笔在石板上画了个示意图：“别被位运算吓到。我给你翻译成人话——”

“第一层魔法：预处理所有 2 的幂次长度的区间。你看 st[0] 存的是长度为 1 的区间（就是单个元素），st[1] 存的是长度为 2 的区间，st[2] 存的是长度为 4 的区间，以此类推。1 « i 就是 2^i，左移一位相当于乘以 2。”

他在纸上画了一排格子：

原始数组: [1, 3, 2, 5, 4]

st 0 : [(1,1), (3,3), (2,2), (5,5), (4,4)] st1: [(1,3), (2,3), (2,5), (4,5)] st2: [(1,5), (2,5)]

" st[ i ] [ j ] 表示从位置 j 开始、长度为 2^i 的区间的 (最小值, 最大值)。关键在于——长区间可以由两个短区间拼出来。比如，长度为 4 的区间 [j, j+4) 可以拆成两个长度为 2 的区间 [j, j+2) 和 [j+2, j+4)，取它们的 min 和 max 就行。这就是 op 函数的作用——合并两个区间的极值。”

我盯着那个递推式 st[ i ] [ j ] = op(st[ i-1 ] [ j ] , st[ i-1 ] [ j + (1 « (i-1)) ])：“所以这是先把短的算好了，长的直接拼？”

“没错。ST 表预处理的复杂度是 O(n log n)，因为最多有 log n 层，每层最多 n 个元素。” 老勇者指着 query 方法，“真正的魔法在这里——怎么在 O(1) 时间内查询任意长度的区间？”

“假设我要查 [l, r)，长度是 len = r - l。我们需要找到不超过 len 的最大的 2 的幂次。比如 len=5，最大的幂次是 4（也就是 2^2），然后用两个长度为 4 的区间覆盖 [l, r)——一个从左边开始 [l, l+4)，一个从右边结束 [r-4, r)。这两个区间一定有重叠，但没关系，我们要的是最大值和最小值，重叠部分不影响结果。”

他在纸上画了个覆盖示意图：

数组: [1, 3, 2, 5, 4, 6, 3] |————| ← [l, l+4) 长度4 |————| ← [r-4, r) 长度4 |—————| ← [l, r) 长度5

“k = (r - l).bit_length() - 1 就是在找这个最大的幂次。op(self.st[ k ] [ l ], self.st[ k ] [ r - (1 « k) ]) 就是把两个区间拼起来，返回 (最小值, 最大值)，相减就是极差。”

我感觉脑子里有什么东西突然连通了：“所以稀疏表就是提前背好了所有标准长度（1, 2, 4, 8, 16…）的区间攻略，遇到任何长度的查询，就用两个标准区间拼出来？这确实是 O(1)，因为只需要查两次表再加一次合并！”

“对。不过要注意，稀疏表只能处理静态数组的区间查询，不能修改元素。如果要支持修改，就得用线段树或者树状数组。但这道题不需要修改，所以稀疏表是最优解。”

老勇者接着写下了主逻辑：初始化堆的时候，把每个起点 i 对应的最长隧道 [i, n) 的极差塞进去。因为隧道长度的缩减只会导致极差变小或不变，初始堆已经满足大根堆性质，连 heapify 都省了。循环 k 次，每次弹出堆顶，累加极差，然后把同一隧道缩一格 [l, r-1) 压回去。如果堆顶的极差已经等于 0，说明剩下的都是极差为 0 的区间，可以直接收工。

def maxTotalValue(self, nums, k):
n = len(nums)
st = ST(nums)
# 最大堆: (极差, l, r)，初始每条隧道挖到最深处
h = [(st.query(i, n), i, n) for i in range(n)]
ans = 0
for _ in range(k):
d, l, r = h[0]
if d == 0: # 极差为 0，收工
break
ans += d
# 弹出堆顶，同一隧道缩一格再压回去
heapreplace_max(h, (st.query(l, r-1), l, r-1))
return ans

我盯着这段代码，感觉像在看一个动态的挖矿图。堆里始终只有 n 个候选——每条矿脉一个。每次取走堆顶收益最大的矿段，同一条矿脉往浅层退一格，重新排队。稀疏表像一台地质探测仪，O(1) 就能查任意矿段的价值差。ST 表预处理O(n log n)，查询区间最值 O(1)。堆操作一次 O(log n)，k 次 O(k log n)。总复杂度 O(n log n + k log n)，稳稳扛住十万级。

“隧道模型 + 贪心堆 + 稀疏表，“我靠在椅背上，把这三个词在嘴里嚼了一遍，“固定一端，单调扩展，堆维护全局最优。极差查询交给 ST 表。这比我那套切分方案强太多了——那是中间开花，指数爆炸；这是单端收缩，候选数恒定。同一个贪心思路，区别这么大。”

老勇者拍了拍我的肩膀，转身向门口走去：“固定一端、贪心另一端，这种’隧道模型’在很多区间选 k 大的题里都能用。算法优化往往就是换个角度看问题，消除不必要的计算。记住，当你发现候选集要爆炸的时候，问问自己：能不能固定一个维度，只让另一个维度动？”

走到门口，他顿了顿，回头补了一句，眼神里闪烁着某种兴奋的光芒：“下次要是再加个约束——‘子数组不能重叠’的变种题，记得叫我——那时候，才是真正的战斗开始。动态规划的地狱之门，会为你敞开。”

我打了个寒颤，默默保存了今天的代码，顺手给文件加了个备份——万一哪天真的要用到呢？毕竟，在这个充满约束的世界里，唯一不变的就是变化本身。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode2161 装备分拣：一行流的诱惑与分桶的正道

Mon, 08 Jun 2026 12:47:26 +0800

🎮 装备分拣：一行流的诱惑与分桶的正道

“小白！”村长一脚踹开大门，怀里抱着一堆闪闪发光的装备，“昨晚勇士团连夜刷副本，爆了一地装备！你看这战力值——[9, 12, 5, 10, 14, 3, 10]。现在要以战力 10 为基准分三批：比 10 弱的给新手村，等于 10 的放仓库备用，比 10 强的给精英团。而且同一批装备必须按掉落顺序排列——这样好查记录，知道是哪只 BOSS 爆的！”

我接过装备清单扫了一眼，这不就是稳定三路划分吗？快排里的 partition 一个原地交换下去，相同元素的先后顺序直接乱套——这里要求组内保序，那就不能原地搞了，得上辅助空间。三个桶，一趟遍历：比 pivot 小的进左桶，相等的进中桶，大的进右桶。从左往右依次遍历，每个桶天然保持原数组的先后顺序。

正准备掏分桶代码，我脑子突然一抽：等等，Python 的 sort 不是稳定排序吗？Timsort 亲口承诺“相同键值保序”，那我直接用 key 函数把小于 pivot 的映射成 -1，等于的映射成 0，大于的映射成 1，然后排一遍不就行了？一行流，帅就完事。

nums.sort(key=lambda x: (x > pivot) - (x < pivot))

跑样例，输出完美。提交，AC 弹出。我往椅背上一靠，翘起二郎腿，心里已经开始给自己加戏——一行代码搞定装备分拣，村长直呼内行，精英团连夜给我加 Buff，仓库管理员感动得要把女儿许配给我。

正美着，后脑勺“啪”地挨了一下。

回头一看，老勇者叼着棒棒糖站在我身后，手指还保持着弹脑瓜崩的姿势。“你觉得这就算写完了？”

“AC 了啊！”我捂着后脑勺，指着屏幕上的绿色大勾。

“AC 不代表没毛病。”他点了点屏幕，“你这 sort，时间复杂度多少？”

“O(n log n)……”我声音小了一半，后脑勺还隐隐作痛。

”题目让你分组，不是让你排序。分组是 O(n) 的活——看一眼战力值，扔进对应的箱子，完事。你调 sort，等于雇了个全职排序师来当门卫。排序引擎不知道你只想分堆——它勤勤恳恳地比较、归并、插入，log n 层递归树跑满，就为了完成一个你早就知道答案的任务。而且 Timsort 底层 merge 要临时数组，额外空间也是 O(n)——你这一行流，时间复杂度输了，空间也没省。”

他把棒棒糖往嘴角一叼：“一行流看着帅，语义不对。用排序引擎做分组，技术债，利息 O(n log n)。哪天副本掉了一百万件装备，Boss 都刷新两轮了你的代码还在排序，勇士团站门口干等，回头差评全写你名字。”

我脸上的得意全部转移到了脚趾上。我默默地把那一行流注释掉，老老实实掏出了分桶三数组的写法：

遍历整个装备列表，比pivot弱的扔进 left 箱发往新手村；相等的扔进 mid 箱存仓库；比pivot强的扔进 right 箱送精英团。因为是从左往右按掉落顺序依次遍历的，每个箱子里的装备天然保持了原来的先后顺序，最后把三个箱子的装备按顺序拼接，分拣完毕：

def pivotArray(self, nums: List[int], pivot: int) -> List[int]:
 left, mid, right = [], [], []
 for x in nums:
 if x < pivot:
 left.append(x)
 elif x == pivot:
 mid.append(x)
 else:
 right.append(x)
 return left + mid + right

O(n) 时间，O(n) 额外空间，语义清晰，逻辑直白。村长看了眼分好的三箱装备，满意地点点头，抱着箱子去仓库贴标签了。

老勇者看着我把分桶版本提交上去，这次没弹脑瓜崩，点了点头：“记住，一行流能 AC 不代表它是最优解。sort 是通用排序，它不知道你只想分堆。能现场分组的，就别排序。”

我揉着后脑勺，默默记下了。但盯着那三个桶，还是忍不住追问了一句：“空间复杂度有没有优化空间？”

老勇者瞥了我一眼：“你愿意拿时间换，就可以。”

“原地交换加插入排序，能压到 O(1) 空间——每遇到一个元素，先判断它该去哪边，再用位移操作把它挪到对应位置，保证组内顺序不变。但每次挪位置都是 O(n)，总复杂度 O(n²)。O(1) 空间换 O(n²) 时间，等于徒手搬一百趟装备省一个空间戒指，血亏。”

他把棒棒糖往嘴里一叼，拍了拍我肩膀：“编程跟打副本一个道理——理解机制比硬刚更重要。稳定分区必须付出代价，要么付空间，要么付时间。n ≤ 10⁵ 的数据量，O(n) 空间换 O(n) 时间是血赚。省空间的念头，留着对付那些不要求稳定性的题——那才是原地交换大展拳脚的地方。”

窗外，勇士团扛着新到货的装备箱浩浩荡荡走过，村长跟在后面一路小跑，手里还抱着我分好的三摞清单。我把魔法书翻到今天这一页，在旁边批了三行：能分组的，就别排序。稳定分区，空间换时间是正道。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode2196：树根猎人：从一堆父子关系里揪出老祖宗

Sun, 07 Jun 2026 22:40:48 +0800

🎮 树根猎人：从一堆父子关系里揪出老祖宗

一只灰扑扑的信鸽扑棱着翅膀从窗口栽了进来，精准地砸中了我刚泡好的方便面。我解开它腿上的字条一看——是村长的笔迹：“邻村要建棵树，你帮忙看看。”

“建树？“我一个刷算法的，什么时候接了土木工程的活儿？这委托费够不够赔我这碗红烧牛肉面！翻到字条背面，还有一整页三元组：[parent, child, isLeft]。我恍然大悟，此树非彼树。邻村要建的是一棵家谱二叉树，但现在只有一堆零散的父子关系——不成树，也不知道根在哪。村长要我根据这些描述把树拼好，并找出根节点。

“清官难断家务事，“我把字条往桌上一拍，露出职业性的微笑，“但算法能解父子局。”

说白了，就是从一堆“谁是谁他爹”的八卦信息里重建完整的家族谱系。我理了理思路，这事分两步走：

第一步：补全亲属关系网
对着家谱名单，把每个人的直系亲属关系一条条补全——把每个节点造出来，顺便把父子指针挂上。这就像是给村里的每个人办身份证，然后记录他们的亲子关系。

第二步：找出老祖宗
那个只当爹、不当娃的根节点，就是我们要找的目标。在任一个三元组的 child 位置上出现的都是娃，而只有老祖宗——那个从来没当过子女的人——永远不会出现在 child 位置上。所以策略很简单：把所有出现过的 child 收集到一个集合里，再遍历所有节点，哪个不在 child 集合里，哪个就是根。

“这不就是玩‘谁是卧底’吗？”我自言自语，“所有人都有爹，就他没有——那他就是老祖宗。”

我搓搓手，开始落代码，先准备两样东西：

一个哈希表 nodes：以节点值为 key，存节点对象。这就好比是村里的户口本，每个人都在这里登记。
一个集合 children：专门登记所有当过娃的节点，用来筛根。这就是我们的"有爹人士名单”。

nodes = {}
children = set()

接着，遍历 descriptions 里的每一条 [parent, child, isLeft]。对于 parent 和 child，先去 nodes 里查一下：没有就当场 new 一个 TreeNode 塞进去。然后，根据 isLeft 把 child 挂到 parent 左边或右边，父子关系定下来。最后把 child 扔进 children 集合，留个案底，证明这孩子有爹。

for parent, child, is_left in descriptions:
if parent not in nodes:
nodes[parent] = TreeNode(parent)
if child not in nodes:
nodes[child] = TreeNode(child)
if is_left:
nodes[parent].left = nodes[child]
else:
nodes[parent].right = nodes[child]
children.add(child)

遍历跑完，整棵树的骨架就全部搭好了。接下来找根——那个唯一没出现在 children 集合里的人：

for x, node in nodes.items():
if x not in children:
return node

一趟主循环把建节点、挂关系、登记子女全部搞定，最后再来一趟小循环抓老祖。总复杂度 O(n)，线性扫描，丝滑流畅。

村长很快就过来要结果了。他戴着老花镜，眯着眼扫了下代码，点了点头：“哈希表挂节点这种基操就不夸你了——能想到把找根的线索嵌在建节点的同一个循环里，边建边登记，最后差集一把梭，说明你开始有‘数据处理流水线’的意识了。”

他把字条翻了个面，确认背面没有隐藏附加条件，满意地往怀里一揣：“行了，邻村还等着这棵树回去祭祖呢。对了，他们说要感谢你，送了你一袋土豆。”

“……土豆？”

“嗯，说是自家种的，纯天然无污染。”

我看了看桌上那碗被信鸽毁掉的方便面，又想了想这趟委托的收入，叹了口气。算了，至少不是 Bug。

送走村长后，我拆开那袋土豆，发现下面还压着一张小纸条：

“多谢相助。另：如果你愿意帮我们优化一下农田灌溉系统的最短路径算法，报酬是十袋土豆。”

我一把抓起纸条，搓成一团，扔了出去。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode2574：空间复杂度O(1)？村长说这是节俭美德！

Sat, 06 Jun 2026 12:36:25 +0800

🎮 空间复杂度O(1)？村长说这是节俭美德！

“小白，村里要搞个村运会！”村长塞给我一张皱巴巴的纸，上面歪歪扭扭画着一排数字：[10, 4, 8, 3]，“你看，这是咱村拔河比赛的对阵表！”

我定睛一看，“这……不就是个数组吗？”

“肤浅！”村长指着纸上那排数字，表情像在解说世界杯决赛，“这叫‘平衡指数’！对于每个人，我要知道他左边所有人的体重之和，与右边所有人的体重之和，差距有多大！这样我才能调整阵容，让两边势均力敌！”

我挠挠头：“……求每个位置的 |leftSum - rightSum| ？”

“对！”村长猛拍大腿，“就是这个意思！赶紧帮我算，下午就要贴对阵表了！”

我把对阵表往桌上一摊，思路直白得像村口那条水泥路——先从左往右扫一遍，记下每个位置左边所有人的体重之和；再从右往左扫一遍，记下右边所有人的体重之和；最后逐个位置算差值取绝对值：

def leftRightDifference(nums):
 n = len(nums)
 left_sum = [0] * n
 right_sum = [0] * n

 # 从左到右，计算每个位置的左侧总和
 for i in range(1, n):
 left_sum[i] = left_sum[i - 1] + nums[i - 1]

 # 从右到左，计算每个位置的右侧总和
 for i in range(n - 2, -1, -1):
 right_sum[i] = right_sum[i + 1] + nums[i + 1]

 # 计算差值的绝对值
 for i in range(n):
 answer[i] = abs(left_sum[i] - right_sum[i])

 return answer

村长凑过来看了一眼，表情有点复杂，就像 code review 时发现了一段能跑但让人血压升高的代码。

“小白啊，”他拍了拍桌上那张被我用掉的草稿纸，语气里透着一股“我不是心疼钱我是心疼资源”的味道，“拔河比赛有预赛、复赛、决赛三轮，每轮每个队伍你都给我开三张表——left_sum 、right_sum 、answer ——三轮下来草纸堆得比锅炉房还高。咱村的传统你忘了？！”

我愣了一下。好家伙，三个数组一字排开，每个数组都要从头填到尾，内存占用都快赶上一支拔河队的完整档案了。而且整个过程走完，这些数组就成了再也没人翻看的旧档案——村长心疼钱，我还心疼那多余的内存分配呢。

“节省……”我咬着笔杆，盯着那三个数组开始琢磨。left_sum 好办——用一个 left 变量一路滚到底就行。从最左边往右走，走哪儿加哪儿，根本不用开数组，一个变量搞定。但 right_sum 怎么办？右边队员的体重和，在从左往右走的时候是未知的——还没走到右边呢，怎么知道右边那群人加起来多重？除非我先算一遍总和。

总和！我一个激灵，在草稿纸上划拉起来：设全队总重 total = sum(nums)，对于位置 i，左边的体重和是 left，当前这个人自己的体重是 nums[i]，那右边的和right不就是 total - left - nums[i] 吗？

answer[i] = |left - right|
right = total - left - nums[i]
answer[i] = |left - (total - left - nums[i])| = |2 * left + nums[i] - total|

我整理了下思路：left_sum 用一个滚动的变量 left 取代，right_sum 用 total - left - nums[i] 表达式消解，answer 干脆直接写回原数组 nums，连额外空间都省了。代码从三循环三数组，缩成一趟遍历原地修改：

def leftRightDifference(nums):
total = sum(nums) # 全队总体重
left = 0 # 左边已经算过的人总体重，初始为 0
for i, num in enumerate(nums):
nums[i] = abs(left * 2 + num - total) # 计算差值，直接写回原数组
left += num # 把当前人算到左边的队伍里
return nums

时间复杂度 O(n)，空间复杂度 O(1)（不算答案数组的话），是真正的"原地算法"！

“三张表变零张，好啊！连草纸钱都省了！这才是咱们村的作风！” 村长高兴地直拍大腿，那兴奋劲儿比他自己拔赢了比赛还夸张。

老头把优化后的对阵表往怀里一揣，乐呵呵地走了。临出门又回头喊了一嗓子，“省下来的钱，回头给你加个鸡腿！我先去排兵布阵，下午预赛，记得来操场看拔河！”

门关上，我把拨火棍往锅炉边一靠，打开魔法书给 2574 也留了行记录：

2574 - 左右元素和的差值 解法：total 推右边和，数学去冗余。一趟遍历原地修改，O(n) 时间，O(1) 额外空间心得：右边和不是独立信息，是派生值。用老勇者的话说——能现场算的，就别存。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3753：游乐园峰谷过山车II

Fri, 05 Jun 2026 11:12:16 +0800

🎮 游乐园峰谷过山车 II：当数据量膨胀到万亿级

“来了。”

我靠窗坐着，魔法书摊在膝上，手边一杯茶冒着热气。窗外传来熟悉的脚步声——不是那种出大事的急匆匆跑法，而是不紧不慢、带着“ 我要来吓唬你了但我其实很期待看你反应 ” 的节奏。上次游乐园试运营、正式服连着来的时候，也是这个步调。如果把村长的每次出场录下来做傅里叶变换，峰值频率大概在“焦虑”和“幸灾乐祸”之间。

门被一脚踹开。“小白！游乐园又来任务了！”他手里挥着一封烫金信封，脸上的表情比上次更兴奋。

我接过信封，没急着拆。“村长，让我猜猜——波动值 II，规则一个字没改，数据量加了一串零。对吗？”

村长愣了一下，显然没料到我预判了他的预判。我把信封拆开，果然：

3753 - 范围内总波动值 II 规则：同 3751 数据范围：1 ≤ num1 ≤ num2 ≤ 10¹⁵

10¹⁵，十五位数。上次 3751 是 10⁵，六位数，暴力法直接遍历，几十万次操作，眨眼就跑完了。这次如果用同样的暴力对付 10¹⁵，遍历次数得用“万亿”做单位——从几十万到万亿，差了整整十个数量级。上次几十万次耗时不到 0.1 秒，这次暴力能跑到地老天荒。

但我没有慌，甚至有点小得意。因为昨天的我在老勇者敲烟斗的节奏里，已经把数位 DP 的核心思想刻入脑海了。不光学会了“怎么搜”，还搞懂了“怎么记”——限制状态和计算状态分家，波动值从行李升级成战报。而那两个版本的代码，昨天就躺进我的魔法书里了，一字一句，墨迹都还没褪色。

“村长，”我把茶杯放下，翻开魔法书到那两页代码，“你看，昨天老勇者教了我两种数位 DP 写法。第一种‘行李版’，把 waviness 放在参数里一路扛下去——最符合直觉，填完所有位直接返回累加好的成绩单。第二种‘战报版’，把 waviness 踢出参数表，变成返回值的一部分，每个子树统一上报 (子树波动值总和, 子树合法数字个数)。”

我用手指点了点代码里的核心差异，继续解释：“说句公道话，今天这数据量，两种其实都能跑。10¹⁵ 是十五位数，状态总数也就几万个，行李版的缓存虽然会漏掉一些命中，但状态空间本身不大，硬跑也能过——顶多比战报版多喘两口气，不至于升天。”

“但你猜我选哪个？”我把魔法书往他面前推了推，指着第二种写法旁边昨天重重划下的那行下划线——波动值是战报，不是行李。“行李版今天能过，但如果数据量换到 10¹⁸ 呢？换到 10¹⁰⁰ 呢？行李扛一路，缓存命中率随数据量一路下滑；战报往上交，数据涨到天上去也没关系。既然昨天已经想明白了，今天就没必要退回去走老路。”

我把战报版代码原封不动贴进提交框，一个字符都没改，点了提交。绿色大勾弹出来的时候，村长正在喝我给他倒的茶。他看了看屏幕上的 Accepted，又看了看耗时——表情从“我要看你翻车”变成了“你怎么又不翻车”，嘴唇抖了三抖，最后只憋出一句：“就这？”

“就这。”我把魔法书翻到昨天写的那条批注——“波动值是战报，不是行李”——在下面补了一行新记录：

3753 - 范围内总波动值 II 解法：同 3751 数位 DP 战报版，O(位数 × 状态数)，代码零改动数据范围：num2 ≤ 10¹⁵，位数从 6 涨到 16，状态数几乎没变心得体会：行李版今天也能过，但既然学会了看战报，就没必要再扛行李。好的状态设计，不惧数据膨胀——昨天多想十分钟，今天省下十个数量级，连代码都不用改一行。

村长看了看我魔法书上的批注，默默喝完了杯里的茶。他站起来走到门口，顿了顿，没回头：“下次要是再来个 III，范围扩到 10¹⁰⁰——你还这么稳？”

“理论上，”我重新拿起拨火棍，往锅炉里又添了根柴，“位数再涨十倍，状态数也就多个零。只要问题本质没变，战报永远管用。”

村长哼了一声，推开门的瞬间，风把他半句话吹了进来：“……你小子，学了点东西。”

门关上。我靠在椅背上，火苗在锅炉里欢快地蹿着。魔法书摊在膝上，两行批注一上一下——3751 教会我怎么写数位 DP，3753 教会我一个更重要的道理——最好的代码不是跑得最快的，而是数据量涨一百亿倍也不用改一行的。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3751：游乐园峰谷过山车

Thu, 04 Jun 2026 16:50:01 +0800

🎮 游乐园峰谷过山车：数位DP的修行

第一章：村长的新任务

“小白！别睡了！有新任务了！” 村长一脚踹开我家大门，手里挥舞着一份皱巴巴的羊皮卷轴。我一个激灵从床上弹起来，下意识就去摸魔法书——这开场白我太熟了，每次村长用这个句式，后面铁定跟着一道新题。

“还记得算法乐园那个没设 base case 的‘递归过山车’吗？”他把卷轴拍在我桌上，“乐园那边连夜开了事故复盘会，紧急关停了项目，总算把老爷爷从轨道上救下来了。他们痛定思痛，在旁边新建了个项目，叫‘数位过山车’。”

我拿起卷轴，村长继续解释：“ 这次项目上线前要做安全评估，再不敢直接莽了。新过山车的轨道由数字构成——每个数字就是一段铁轨，每一位是铁轨上的一个连接点。如果某一段连接点比两边都高，就是‘峰’；比两边都低，就是‘谷’。峰和谷太多意味着轨道起伏太剧烈，车开上去乘客容易被动升天，重蹈爷爷的覆辙。所以他们需要计算**‘波动值’**——也就是峰和谷的总数——来评估轨道安全性，决定安全带是用两根还是五根。”

我瞅了眼卷轴，上面写着波动值的定义：

峰：某一位数字严格大于左右两边——像山峰一样凸起来，在上面一览众山小。谷：某一位数字严格小于左右两边——像山谷一样凹下去，在里头抬头望星空。首尾两位不能算峰或谷——边界保护，毕竟第一个和最后一个连邻居都凑不齐。少于3位的数字波动值为0——太短了没法波动

“你的任务，” 村长用指关节敲了敲卷轴，“是计算区间 [num1, num2] 内所有数字的波动值之和。乐园那边要拿着这个数据去申请保险。”

我盯着卷轴看了三秒，突然笑出声：“这不就是遍历每个数字，拿字符串滑窗检查一下峰和谷嘛。zip(s, s[1:], s[2:]) 三连滑窗，峰谷一眼扫完，比在游戏里开扫描模式还快。村长你是不是又在放水？”

村长冷笑一声。那种笑容我见过——上次他给我推游乐园正式服 5×10⁴ 数据的时候，也是这副表情，像一个提前看过剧透的副本 Boss。“数据范围 num2 ≤ 10⁵，暴力当然能过。但我先给你打个预防针——说不定哪天范围就扩到 10¹⁸ 了呢？”

说完，村长便甩袖而去。我透过窗户望了一眼算法乐园的方向，那座“数位过山车”的轨道已经在晨光中闪闪发亮——10⁵ 嘛，先暴力 AC 了再说。至于 10¹⁸……到时候再想呗，未来的我肯定有办法。实在不行，不还有老勇者嘛。

第二章：暴力枚举——三连 zip 横扫千军

直接暴力：从 num1 一路遍历到 num2，每个数字转成字符串，然后掏出 Python 的 zip(s, s[1:], s[2:]) 三连滑窗，把连续三位 a、b、c 一次性拎出来。如果 a > b < c，说明 b 是个谷，轨道在这里砸了一个坑；如果 a < b > c，说明 b 是个峰，轨道在这里顶出一个包。每发现一个峰或谷，计数器加一。遍历完所有数字，返回总数完事。

def totalWaviness(num1: int, num2: int) -> int:
 res = 0
 for i in range(num1, num2 + 1): # 遍历区间内每个数字
 s = str(i) # 转成字符串方便逐位访问
 for a, b, c in zip(s, s[1:], s[2:]): # 滑动窗口取连续三位
 if a > b < c: # 谷
 res += 1
 elif a < b > c: # 峰
 res += 1
 return res

写完一跑，秒出AC。zip(s, s[1:], s[2:]) 这个三连滑窗真是比德芙还丝滑——s 是原字符串，s[1:] 是从第二位开始的字符串，s[2:] 是从第三位开始的字符串，三个错位排列的字符串往 zip 里一塞，直接吐出所有连续三位的组合。时间复杂度 O(N·L)，N 是区间长度，L 是数字平均位数。10⁵ 个数字，每个最多六七位，总操作量撑死几十万次。

第三章：小白的数位DP 困境

提交完暴力代码，我靠在椅背上准备摸鱼，脑子里却自动回放起村长临走时的那个冷笑——“如果哪天范围扩到 10¹⁸……”，我越想越不是滋味。村长的嘴，骗人的鬼，但村长的预言，比 stack trace 还准。上次他说“以后会有大数据版本”，隔天正式服就砸脸上了。这次他特意打个预防针，八成是在给我提前剧透。

10¹⁸ 意味着什么？意味着如果我还用暴力遍历，评测机怕是要甩我个TLE。我必须想一个不依赖区间长度的解法。

我在魔法书里翻来翻去，目光落在一页标注着“数位 DP”的章节上。那是老勇者上次去邻村之前塞给我的，说是“有空看看，以后用得上”。我当时翻了前两页，看到满眼的 dfs(i, is_limit, is_num) 就觉得脑壳疼，随手一合当枕头用了。现在想想，真是书到用时方恨少，码到跑时方觉糙。

“数位 DP……”我喃喃自语，“ 核心思想应该是按位搜索——把数字一位一位填出来，在填的过程中统计波动值。这样就不用枚举每一个完整的数字，而是枚举每一位可能的取值。相当于把十亿个数字压缩成几十个状态，用记忆化搜索代替暴力遍历。”

思路大概是——从最高位开始，逐位尝试 0 到 9——每填一个新的数字 d，我需要知道它和前一位 last_digit 的关系——变大了、变小了，还是持平。但峰和谷的判断需要三位数字。要判断前一位是不是峰，我得同时知道前一位的数字、更前一位的数字、以及当前位 d。也就是说，当我填下 d 的时候，才能回头判定前一位是不是峰或谷。“那我该记录什么状态？”我拿笔在草稿纸上乱画。

首先肯定要有 i，表示当前填到第几位，这是数位 DP 的标配，用来判断递归什么时候到头。然后得有 last_digit，记录上一位填的是什么数字，不然没法算当前位是升还是降。还得搞个 last_cmp，记录上一位和更前一位的比较趋势——上升记 1，下降记 -1，持平记 0。这样当上一位与当前位的新趋势 c 算出来之后，如果 c * last_cmp < 0，就说明趋势反转了，前一位要么是峰要么是谷，波动值加一。

“等等，” 我咬着笔杆皱起眉头，“还有上下界的问题。我只能在 num1 到 num2 之间搜，不能搜出范围外。需要 limit_low 和 limit_high 两个布尔值，分别标记当前是否要受下界和上界的约束。另外，如果 num1 和 num2 位数不同，比如num1=1，num2=100，数位对齐后数字 5 实际上是 ‘005’，前两个零不能参与峰谷判断，得想办法标记前面是否已经填过非零数字，没开始之前趋势 c 直接设成 0。”

我盯着纸上列出的状态参数——i、last_cmp、last_digit、limit_low、limit_high——光参数就已经五个了，还没算上前导零的判断。但更让我卡住的还不是参数多，而是另一个根本性的问题。

“返回值怎么设计？” 这是我最困惑的地方。之前学数位 DP 的时候，最常见的套路是“统计满足条件的数字个数”——dfs 返回从当前状态开始能构造出多少个合法数字，最后调用 dfs(0, true, true) 就是答案。还有一种是“统计权值和”——比如求所有数字的数位和之和，返回值是从当前状态开始所有数字的某个属性累加值。

但这道题既不是数个数，也不是简单的权值和。我要的是“波动值之和”——先算每个数字的波动值，再把所有数字的波动值加起来。波动值本身是一个数字内部峰和谷的计数，它在填数字的过程中动态累加，不是一个静态的属性。那么问题来了，我到底应该把波动值当成状态参数 waviness 一路传下去，到了底层直接返回？还是应该把它当成返回值的一部分，让每层递归把后续所有数字的波动值之和汇总上来？

我越想越乱，草稿纸上画满了状态转移图，又全划掉了。我盯着天花板上被锅炉熏出的水渍，第一次觉得数位 DP 比递归过山车还难。递归过山车好歹只有一个问题——没设 base case；而数位 DP 有一百个问题，每一个都在问我：“你这个状态设计对了吗？”参数怎么分、返回值怎么定、记忆化怎么开、前导零怎么处理，全搅在一起，像极了一个没有封装的单体应用——牵一发而动全身。

正在我纠结要不要干脆放弃治疗、等正式服上线再说的时候，门口传来一阵慢悠悠的脚步声，伴随着打火机点烟斗的“咔嗒”声——老勇者从邻村回来了。

“怎么，数位 DP 把你难住了？”他倚在门框上，慢悠悠地吐出一口烟圈。

第四章：老勇者的数位 DP 锦囊

老勇者没急着进屋，先在门口磕了磕烟斗里的灰，然后慢悠悠地踱到我桌前，低头扫了一眼我那画满又划掉的草稿纸。他看了足足五秒钟，表情就像在 code review 里看到了一坨没有注释的祖传代码。

“状态设计全写在纸上了，但你没把它们分清楚。”他把烟斗往桌角一敲，指着纸上那几个被我圈了又圈的参数，“数位 DP 的参数分两类——一类叫‘限制状态’，管的是‘你能填什么’；一类叫‘计算状态’，管的是‘你填完之后发生了什么’。你把它们全搅在一起，自然觉得脑子里的栈要溢出了。”

他在纸上画了一道线，左边写“限制”，右边写“计算”：

“限制状态有两个：limit_low 和 limit_high。它们只做一件事——卡死当前位能填的数字范围。如果 limit_high 为 true，说明前面每一位都死死贴着上界，当前位绝对不能超过 high_s[i]；一旦某一位填了一个比上界小的数字，后面的 limit_high 就永久变成 false，所有位直接解放，0 到 9 随便填。limit_low 同理，只不过方向相反——一旦某一位填了一个比下界大的数字，后面就再也不用看下界的脸色了。这两个参数就是数字世界里的边界门卫。”

“计算状态也有两个：last_digit 和 last_cmp。它们只做一件事——判断峰和谷。last_digit 是上一位的数字，last_cmp 是上一位和更前一位的趋势关系，1 是上升，-1 是下降，0 是持平。当你填下当前位 d 时，先算出新的趋势—— c = (d > last_digit) - (d < last_digit)，一个表达式同时处理大于、小于、等于三种情况，然后看一眼 c * last_cmp ：峰和谷本质都是方向改变，在数学上就是乘积为负，也就是说如果< 0，说明趋势反转，上一位要么是峰要么是谷，波动值加一。这两个参数完全不关心上下界，只关心数字之间的相对大小。”

“至于前导零——用 last_cmp == 0 就能兼顾。还没填有效数字之前，趋势保持为零，c * last_cmp 永远是 0，永远不会触发峰谷判断。把前导零的三个虚拟零拆开看，它们之间全是持平，趋势变化为零，自然不会有峰谷误判。”

他在两个区域之间又画了一根线，在计算状态那边补了一个参数：“至于波动值 waviness，它既不是限制也不是计算，它是你最终要交的答案本身。这个东西的处理方式，有两种流派：一种把它当行李一路扛下去，一种把它当战报一层层报上来。看好了，我两个都写给你。”

他在纸上写下第一种写法：

low_s = list(map(int, str(num1)))
high_s = list(map(int, str(num2)))
n = len(high_s)
diff_lh = n - len(low_s)

@cache
def dfs(i, waviness, last_cmp, last_digit, limit_low, limit_high):
 if i == n:
 return waviness

 lo = low_s[i - diff_lh] if limit_low and i >= diff_lh else 0
 hi = high_s[i] if limit_high else 9

 res = 0
 is_num = not limit_low or i >= diff_lh
 for d in range(lo, hi + 1):
 c = (d > last_digit) - (d < last_digit) if is_num else 0
 w = waviness
 if c * last_cmp < 0:
 w += 1
 res += dfs(i + 1, w, c, d,
 limit_low and d == lo,
 limit_high and d == hi)
 return res
return dfs(0, 0, 0, 0, True, True)

“这个版本最符合直觉——波动值放在参数里，顺着递归一路带到底。每发现一个峰或谷，就 w += 1，最后叶子节点把累加好的结果交上去。就像你拎着一个行李袋，每经过一个峰或谷就往袋子里扔一颗石子，到了终点直接把袋子倒出来数。状态设计也一目了然：limit_low 和 limit_high 是门卫，卡取值范围；last_digit 和 last_cmp 是轨道设计师，管峰谷判断；waviness 是最终成绩单，一路传到底。”

“但是，”他把烟斗往桌角一敲，“这个版本藏着一个坑——@cache 会把所有参数都当成缓存 key，包括 waviness——问题来了：到达同一个 (i, last_cmp, last_digit, limit_low, limit_high) 状态时，waviness 可能完全不一样，因为 waviness 不同，缓存会直接把它们当成了两个不同的状态，各算各的。等于你给每一条搜索路径都建了一个独立的缓存项，记忆化名存实亡，退化成了带 @cache 装饰器的暴力回溯。”

我盯着代码里那个被 @cache 包裹的 dfs，参数表里 waviness 赫然在列——每次峰谷累加，它就变一次，等于每条搜索路径都有一个独一无二的缓存 key——“那怎么改？”我追问。

“把 waviness 从参数里踢出去，让它变成返回值的一部分。行李别自己扛了，让每个子树统一上报战报。”他在纸上写下第二种写法：

low_s = list(map(int, str(num1)))
high_s = list(map(int, str(num2)))
n = len(high_s)
diff_lh = n - len(low_s)

# dfs 返回两个数：子树波动值总和，子树合法数字个数
@cache
def dfs(i, last_cmp, last_digit, limit_low, limit_high):
 if i == n:
 return 0, 1 # 能递归到终点的都是合法数字

 lo = low_s[i - diff_lh] if limit_low and i >= diff_lh else 0
 hi = high_s[i] if limit_high else 9

 waviness_sum = num_cnt = 0
 is_num = not limit_low or i > diff_lh # 前面是否填过数字
 for d in range(lo, hi + 1):
 # 当前填的数不是最高位，c 才有意义
 c = (d > last_digit) - (d < last_digit) if is_num else 0
 sub_waviness_sum, sub_num_cnt = dfs(i + 1, c, d,
 limit_low and d == lo,
 limit_high and d == hi)
 waviness_sum += sub_waviness_sum # 累加子树的波动值
 num_cnt += sub_num_cnt # 累加子树的合法数字个数
 if c * last_cmp < 0: # 形成了一个峰或谷
 waviness_sum += sub_num_cnt # 这个峰谷会出现在 sub_num_cnt 个数字中
 return waviness_sum, num_cnt

return dfs(0, 0, 0, True, True)[0]

“注意看，这个版本的返回值是一个元组——(子树波动值总和, 子树合法数字个数)。每个节点不从上面接收任何波动值，只向上汇报两件事：我这棵子树里所有完整数字的波动值加起来是多少，以及我这棵子树里一共有多少个合法数字。“ 他指着核心逻辑，继续解释道：“当发现当前位形成峰或谷时——也就是 c * last_cmp < 0 时，不是 +1，而是 + sub_num_cnt——因为当前位形成的这个峰或谷，不是只影响一个数字，而是会影响从这条路走到底的每一个合法数字。相当于你这个峰或谷不能只给自己加一分，而是要给从你这儿毕业的所有合法数字各加一分。”

他顿了顿，举了个例子：“假设处理数字范围 [100, 999]，当递归到第2位时：第一种写法：路径 1→2→? 和 1→3→? 会因为 waviness 不同而分别计算，即使它们在第2位之后的子树结构完全相同，缓存也命中不了，各算各的。第二种解法：对于相同的 (i=2, last_cmp, last_digit, limit_low, limit_high) 状态，子树返回的 (波动值总和, 数字个数) 永远一模一样——因为波动值不再是你自己扛的行李，而是子树统一上交的战报。不管之前的历史路径是什么，只要这五个参数相同，缓存直接命中，子树不用重新算。如果当前位恰好形成了峰或谷，直接 + sub_num_cnt，把贡献批量加上去，一步到位。”

我盯着两个版本来回看了好几遍，恍然大悟：“ 所以第一种是把波动值当‘个人行李’，每个搜索路径自己拎着走，但拎的东西不一样就没法共享存储柜。第二种是把波动值当‘团队战报’，每个子树统一汇总上报，相同的搜索状态无论从哪条路进来，返回的战报完全一样，共用储物柜。波动值从‘自己扛’变成了‘向上报’，waviness 从参数里消失，@cache 缓存命中率直接拉满。”

老勇者满意地点点头，把烟斗往嘴里一叼：“ 把波动值当行李扛下去，看似符合直觉，但每个搜索路径的行李内容都不一样，相同状态永远无法共享缓存——这是典型的“有后效性”，历史路径影响了当前决策，记忆化形同虚设。而把波动值当战报报上来，让每个子树返回一个与历史无关的元组 (子树波动值总和, 子树合法数字个数)，当前位的峰谷贡献通过 + sub_num_cnt 批量结算，五个参数锁死缓存 key，无后效性完美满足——这才是 DP 该有的样子。”

他站起身朝门口走去，快到门边时回头补了一句，“数位 DP 的精髓，不是怎么搜，而是怎么设计状态和返回值，让记忆化从装饰品变成核武器。波动值是行李还是战报，决定了你的缓存命中率是趋近于零还是接近一百。”

第五章：数位 DP 复盘——从行李到战报的进化

锅炉里的火苗噼啪响了两声，像极了我脑袋开窍的声音。

回看这一整天的折腾，从暴力滑窗到数位 DP，我踩的坑差不多能写一本短篇小说，名字都想好了，叫《数位 DP 从入门到放弃再到真香》。状态列不全，不知道谁该进参数、谁该进返回值，像个出门旅行把所有家当全攥在手里却找不到行李箱的焦虑旅客，最后还被缓存命中率敲打了一番，数位 DP 的门槛从来不在“能不能搜”，而在“搜完之后能不能记住”，而能不能记住，取决于状态设计有没有做到无后效性。

我把魔法书翻到“数位 DP”那一章，把两个版本工工整整地贴上去：

3751 - 范围内总波动值 I 暴力解法：zip 三连滑窗，O(N·L)，数据 10⁵ 时秒出数位 DP 解法：记忆化搜索，O(位数 × 状态数) 核心收获：波动值是战报，不是行李。限制状态和计算状态分开，记忆化才能真正发威。c * last_cmp < 0 一行统一峰谷判断。峰谷贡献不是 +1，是 + sub_num_cnt。

我在“波动值是战报，不是行李”下面又重重划了道下划线。靠在椅背上，我透过窗户望了一眼算法乐园的方向，天边那座数位过山车的轨道在夕阳下闪闪发亮。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3635：游乐园正式服的挑战

Wed, 03 Jun 2026 10:39:17 +0800

🎮 游乐园正式服的挑战：当昨天的代码遇上今天的数据量

上回说到，我和老勇者从“算法乐园”逃回村里，及时救活了村里的魔法锅炉。今天，我蹲在炉子旁边添柴边打盹，火焰舔着锅底，浓汤咕嘟咕嘟冒泡，节奏稳得像台跑了十年没崩过的服务器。昨天的游乐园副本虽然惊险，但好歹白嫖了两份战报，O(n+m) 的剪枝优化躺在魔法书里，想想还有点小得意。

正迷糊着，一阵急促的脚步声由远及近。我睁眼一看，村长又来了。这回他手里没有门票，而是举着一封烫金信封：“小白，算法乐园那边来消息了——说上次的游园体验是‘试运营版本’，现在正式版上线了，叫 ‘3635 - 最早完成陆地和水上游乐设施的时间 II’。规则一模一样，但是——”

他把信封翻开，只见上面写着醒目的数据范围：“陆地项目 n ≤ 5×10⁴，水上项目 m ≤ 5×10⁴，时间上限 10⁵。”

我瞌睡当场醒了一半。五万乘五万，那可是 2.5×10⁹ 的组合量。拿暴力双循环去莽，别说 AC，评测机都得先给我发一封投诉邮件。但我没有慌。准确地说，是慌了两秒之后，脑子里突然闪过一道光——等等，这题昨天不是刚做过吗？规则一模一样，那昨天在长椅上推出来的优化思路……

我猛地把魔法书翻到昨天画过山车标记的那一页。几行代码安安静静躺在那里，旁边还黏着一小坨棉花糖的糖霜痕迹，散发着淡淡的甜味：

def solve(firstStart, firstDur, secondStart, secondDur):
 min_finish = min(start + dur for start, dur in zip(firstStart, firstDur))
 return min(max(start, min_finish) + dur for start, dur in zip(secondStart, secondDur))

def earliestFullTime(landStart, landDur, waterStart, waterDur):
 return min(solve(landStart, landDur, waterStart, waterDur),
 solve(waterStart, waterDur, landStart, landDur))

我脑子里的灯泡亮得跟锅炉里的火光似的。昨天老勇者怎么说的来着？——“第一类设施里，只有最早结束的那个有意义，其他全是冗余信息。” 这句话跟数据量有半毛钱关系吗？没有。不管陆地项目是 100 个还是 50000 个，从陆地区出来的最早时间永远只取决于 min(start + duration)。你有一百个过山车还是五万个过山车，你只需要知道哪个能让你最早下来，剩下的四万九千九百九十九个全是冗余数据，剪枝一刀全砍掉。

关键在于solve 函数里那两个 zip 遍历。它们肩并肩站着，谁也不嵌套谁——第一个找 min_finish，第二个在水上项目里挑最优。n 和 m 从 100 膨胀到 5×10⁴，每个设施仍然只被摸一次，总共十万次操作。暴力法 2.5×10⁹，优化版 10⁵——差了整整四个数量级！这就好比别人在手动数麦粒，而你开了一台联合收割机——场地越大，差距越离谱。

代码一个字符都不用改。我原封不动贴上去，提交——秒 AC。耗时跟昨天跑 100 个项目的体感几乎一样，屏幕上弹出一个绿色的大勾，快得像锅炉里迸出的火星。村长在旁边看得一愣一愣的：“这就……做完了？那可是五万乘五万——”

“做完了，”我把魔法书往怀里一揣，拿起拨火棍继续给锅炉添柴，“昨天的我已经帮今天的我写好了。”

锅炉里的火苗欢快地蹿着，浓汤咕嘟咕嘟冒泡。我盯着跳动的火光，忍不住笑了。昨天在游乐园长椅上啃棉花糖的时候，还以为那段剪枝代码只是“今天先优雅一把，以后再说”。谁知道“以后”来得这么快——隔了一个晚上，正式版就砸脸上了。而代码躺在我的魔法书里，连个标点符号都没改，直接应战五万数据。这种感觉就像在新手村捡了一把木剑，以为后期还要换神装，结果发现这玩意是成长型神器，等级随角色自动缩放。

我把魔法书摊在锅炉边，在昨天的战报下面补了一行新记录：

3635 - 最早完成陆地和水上游乐设施的时间 II
解法：同 3633 优化版，O(n+m)，代码零改动，昨天多想十分钟，今天就省下四个数量级。
心得体会：剪枝剪得好，正式版再猛也不怕。暴力不是错，但知道什么时候不暴力，才是真正的抠门大师。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

leetcode3633：游乐园大冒险

Tue, 02 Jun 2026 10:48:27 +0800

🎮 游乐园大冒险——从暴力枚举到剪枝优化的最早回村攻略

昨天帮村长省下一大笔糖果钱，今天一大早，老头就笑呵呵地塞给我两张游乐园门票：“小白，干得漂亮！这是给你的福利——新开的‘算法乐园’，陆地项目和水上项目随便挑。不过有个条件——”

他压低声音，眼神突然犀利起来：“村里的魔法锅炉等着你回来添柴，你得给我早点回村。陆地区和水区各玩一个就撤，顺序你定，但要算出怎么安排能最早回来。记住，我要的是最早回村时间，不是玩得最爽——别玩疯了忘了正事！”

我捏着门票，心里一半是期待一半是吐槽：这哪是福利，这分明是换了个场景继续刷题。不过转念一想，陆地项目 n 最多 100 个，水上项目 m 也最多 100 个——这数据量不就是道热身题吗？

把门票往兜里一揣，我朝乐园大门走去。村长在后面又补了一嗓子：“回来晚了锅炉熄了，你上个月的 AC 我全给你清了！”

“收到收到，速战速决！”我头也不回地摆了摆手。

💥 第一战：直觉翻车——贪心的诱惑和陷阱

进了乐园，我先绕着园区转了一圈。左半边是陆地区，过山车轨道上挂着“Stack Overflow”的牌子，旋转木马叫“While True”，碰碰车场地写着“Index Out of Bounds”——好家伙，名字起得跟 bug 清单似的。右半边是水区，激流勇进叫“广度优先”，漂流叫“梯度下降”，还有个儿童泳池叫“Hello World”。

我掏出村长塞给我的设施清单。陆地项目 landStart[i] 是最早开放时间，landDur[i] 是玩一圈要多久；水上项目同理。规则就一条：两类各挑一个，顺序随意，玩完就走。求最早离开时间。

我往旁边的长椅上一坐，脑子里开始蹦各种贪心策略。先玩开放最早的？万一那个项目时长很长，另一个早就开放了，干等着浪费时间，典型的“先到先得但后到的人堵在门口”。先玩时长最短的？开放时间可能很晚，你这边三分钟完事了，那边还得等两个小时才能进去，更不靠谱。我甚至尝试先陆地后水上，每次都挑最早结束的组合，但发现不同组合之间互相影响，开放时间和持续时间互相牵制，贪心的局部最优推不出全局最优。

折腾了十分钟，代码里便充斥着各种 if-else 。我猛一拍脑门：：“我在干嘛？陆地最多 100 个，水上最多 100 个，总共才一万种组合。直接暴力枚举，两种顺序各算一遍取最小，不就完了？我这是在跟空气斗智斗勇！”

老勇者不知什么时候已经站在我身后，嘴里叼着根棒棒糖——儿童节的存货还没吃完——慢悠悠地吐了句：“数据量小的时候，暴力就是最优解。你刚才那通操作，属于典型的过早优化，面试官看了血压都上来了。”

我脸一红，赶紧把刚才那堆乱七八糟的代码全删了，老老实实写暴力。

⚡ 第二战：暴力枚举——简单粗暴，一拳超人

思路很直白：对于每一对陆地设施 i 和水上设施 j，算两种游玩顺序的完成时间，取最小值。

先陆地后水上：陆地 landStart[i]准时开始，landStart[i] + landDur[i]结束。水上最早waterStart[j] 开放，但必须等我从陆地项目出来，所以实际开始 max(waterStart[j], 陆地结束时间)，然后加上 waterDur[j]。
先水上后陆地：同理，水上开始 waterStart[j]，结束 waterStart[j] + waterDur[j]；陆地开始 max(landStart[i], 水上结束时间)，再加 landDur[i]。

遍历所有组合，记录全局最小值。

def earliestCompletionTime(landStart, landDur, waterStart, waterDur):
 ans = float('inf')
 for i in range(len(landStart)):
 for j in range(len(waterStart)):
 # 先陆地后水上
 land_end = landStart[i] + landDur[i]
 finish1 = max(waterStart[j], land_end) + waterDur[j]
 # 先水上后陆地
 water_end = waterStart[j] + waterDur[j]
 finish2 = max(landStart[i], water_end) + landDur[i]
 # 更新最小值
 ans = min(ans, finish1, finish2)
 return ans

写完一跑，样例秒过。我正准备截图留念，老勇者把一根棉花糖塞我手里——糖丝上竟然用糖霜写着“O(n×m)”，这乐园的主题贯彻得真是丧心病狂。

🚀 第三战：剪枝优化——从 O(n×m) 到 O(n+m)

“暴力双循环，数据小的时候没毛病——代码短、逻辑直、bug 藏不住。不过——” 老勇者话锋一转，“你想过没有，如果这道题出个 II，n 和 m 飙到十万，你这 O(n×m) 打算怎么收场？”

我咬了口棉花糖，含含糊糊地说：“那……那就再想办法呗，今天才 100，先爽了再说。”

“巧了，我有个办法，既能让你今天写得更优雅，也能给以后留条路。”老勇者把我从长椅上拽起来，指向园区地图，“你看，不管先玩陆地还是先玩水上，一旦你选定了第一类设施，第二类设施的等待时间只取决于你从第一类设施出来时的最早时间。换句话说——第一类设施里，你没必要每个都试，你只需要找到那个结束得最早的，因为出来得越早，留给第二类设施的缓冲就越大。”

我眼睛一亮：“你的意思是……如果我先玩陆地，只需要找出所有陆地项目里 start + duration 最小的那个值，记作 min_finish，这就是我从陆地区出来的最早时间。然后水上设施不管挑哪个，实际开始时间都是 max(waterStart, min_finish)，再加上自己的时长就是总完成时间。我只需要在水上项目里找一个能最早收工的就行！等等——这不就把嵌套循环拆成两个独立的单循环？！”

“一点就通。”老勇者满意地点点头，“ 第一个循环找陆地最早结束时间，第二个循环在水上设施里挑最优。先水上后陆地同理，把函数反转一下就行。总复杂度从 O(n×m) 降到了 O(n+m)，哪天数据真飙到十万，你也能面不改色。”

def solve(firstStart, firstDur, secondStart, secondDur):
 # 从第一类设施中找出最早结束时间
 min_finish = min(start + dur for start, dur in zip(firstStart, firstDur))
 # 在第二类设施中，找最早完成时间 
 return min(max(start, min_finish) + dur for start, dur in zip(secondStart, secondDur))

def earliestCompletionTime(landStart, landDur, waterStart, waterDur):
 land_water = solve(landStart, landDur, waterStart, waterDur)
 water_land = solve(waterStart, waterDur, landStart, landDur)
 return min(land_water, water_land)

我盯着这几行代码：“min_finish 是所有陆地项目里的最早结束时间……然后在水上项目里，每个都从 max(start, min_finish) 开始算完成时间，取最小。这不就是把我刚才内层循环的 land_end 换成了一个全局最优的常量吗？难怪能砍掉一层循环！”

“这就是去冗余。”老勇者把棒棒糖棍子一扔，精准投进三米外的垃圾桶，“暴力法里，你对每个陆地项目都重复计算了水上等待，但实际上最优解只可能从‘陆地最早结束’这个分支里产生——因为如果某个陆地项目结束得更晚，你从它出来再去玩水上，只有可能更晚，不会更早。所以直接把其他陆地项目剪枝掉，一步到位。这种思路就像数据库查询优化里的谓词下推——把过滤条件提前，减少后面要处理的数据量。”

他顿了顿，又补了一刀：“你今天这趟没白来。暴力是基操，优化是觉悟。能立刻理解 O(n+m) 的优化思路，说明你对问题结构的敏感度在涨。记住，以后看到‘两类各选一个，顺序任意’这种题型，先想想能不能把其中一类的选择压缩成一个最优候选值。剪枝剪得好，复杂度直接降维打击。”

我正想谦虚两句，旁边突然冲过来一个小孩，拽着他爸的袖子喊：“爸爸爸爸，我要玩那个‘递归过山车’！”他爸脸都绿了：“别，上次你爷爷玩了递归过山车没设 base case，到现在还在天上转呢！栈溢出一万多层，园区用 debugger 都救不下来，现在全家每天抬头都能看见爷爷在轨道上挥手！”

我和老勇者同时倒吸一口凉气，抬头一看——好家伙，天上真有个小黑点在轨道上循环，隐约还能听见“谁来帮我 return 一下——”的喊声。

“撤。”老勇者把棒棒糖从嘴里拔出来，起跑的脚步比 C++ 的 move 语义还快。

我抄起魔法书，跟着老勇者就往乐园门口冲，路过正在施工的新项目时，围挡上的海报差点让我们脚底打滑：“即将推出——并发漂流，同时体验三条河道，偶尔死锁，体验真实多线程。”

我们的脚步又加快了三成。

🎮 回村烧锅

回到村口，我把今天的两份战报收进魔法书——一份 O(n×m) 暴力版，一份 O(n+m) 剪枝版，旁边画了个过山车做标记，批注：“算法乐园，项目刺激，没设 base case 者慎入。”

刚合上书，村长就扛着锅铲冲了过来，围裙上还沾着火星：“小白！你可算回来了！锅炉火都快灭了，赶紧添柴！”

“来了来了！”我一把抓起柴火往炉膛里塞，火苗重新蹿起来，村长的眉头这才舒展开。

“村长，”我擦了把汗，往锅炉里又扔了根柴，“下次再发福利，换个正常点的游乐园行不？那个递归过山车，有个老头没设 base case，到现在还在天上转呢。”

村长愣了一下，抬头往乐园方向望了望——天边那个小黑点还在轨道上循环，隐约的“谁来帮我 return 啊——”随风飘来。他沉默了两秒，诚恳地点了点头：“行，下次发隔壁‘数据结构农场’的票，最多也就被二叉树的刺扎一下，至少人还能回来。”

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

Hello_world

Mon, 01 Jun 2026 10:52:10 +0800

中文：你好（nǐ hǎo）
英语：Hello（哈喽）
法语：Bonjour（布恩入）
西班牙语：¡Buenas!（哈咯）
日语：こんにちは（konnichiwa）
俄语：Привет（привет）
阿拉伯语：مرحبا（salaam）
德语：Hallo（古藤塔克）
葡萄牙语：Olá（奥拉）
希伯来语：(שלום（שלום

Posts on 我的小站

leetcode3345 赛博地牢：乘积谜锁

赛博地牢：乘积谜锁

序章：地精守门

第一章：暴力连斩

第二章：带0必杀

第三章：另一扇门

leetcode3310 深夜运维惊魂：那个叫k的方法有毒

深夜运维惊魂：那个叫k的方法有毒

一：方法的社交圈

二：标记"k家军"

三：移除决策

彩蛋

leetcode3731 逃课逮捕令：从 list 遍历 到 Set 精准锁头

逃课逮捕令：从 list 遍历 到 Set 精准锁头

黑历史 · 人工智障，逐个扫描

黑科技 · 哈希锁头，一秒查人

彩蛋· 逃课克星速查卡

leetcode1406 赌城风云·续：阿星的出师之战

赌城风云·续：阿星的出师之战

一、查尔斯的复仇

二、阿星的独角戏

三、从全表到滚动数组

四、欲盖弥彰

五、注定的结局

六、赌神的进阶

leetcode877 聚会杀手锏！石子游戏教你做一个没有感情的赢家

聚会杀手锏！石子游戏教你做一个没有感情的赢家

必胜操作手册：

必胜秘诀：

实战演示：

风险控制（为友谊续一秒）

写在最后（附赠代码一行）

leetcode486 净胜分心法：让你还没摸牌就知道会不会赢

净胜分心法：让你还没摸牌就知道会不会赢

一、牌桌之上，零和博弈

二、净胜分——赌神只看一件事

三、第一张牌

尾声：

leetcode3016 续 · 键盘上的权重战争

续 · 键盘上的权重战争

第一幕：频率加权下的贪心

第二幕 · 代码就是武器

第三幕 · 物理键的诅咒

尾声

leetcode3014 穿越者的键盘革命：数学赢了，产品输了，历史笑了

穿越者的键盘革命：数学赢了，产品输了，历史笑了

序章 · 你醒在2003年的芬兰

第一幕：为什么没有 1 和 0？

第二幕 · 贪心平摊

第三幕 · 黑莓的全键盘

尾声

leetcode3518 强迫症整理圣手的字典序试炼（二）：第k小之章

强迫症整理圣手的字典序试炼（二）：第k小之章

一、冷静，以及分治

二、比例递推——按比例切蛋糕

三、组合截断——或者叫“够用就行”

四、冗余备份

leetcode3517 强迫症整理圣手的字典序试炼

强迫症整理圣手的字典序试炼

一、来信

二、阿整的镜像整理大法

三、修罗场预告

leetcode1464 村长的自我修养：一次扫描擒二肥

村长的自我修养：一次扫描擒二肥

leetcode628 冲出混沌星域：三个天体的乘积弹弓

冲出混沌星域：三个天体的乘积弹弓

序章：3% 燃料，3.6 光年绝境

第一章：两条航线

第二章：一个疯子

第三章：半人马座的星光

彩蛋：飞船电脑“塔斯”的任务后分析日志

leetcode3536 XOR 0.5秒通关的人脑，和需要跑个循环的CPU

0.5秒通关的人脑，和需要跑个循环的CPU

序章：

第一章：人脑的黑盒——“直觉"真的免费吗？

第二章：两种解法——机器的"翻译困境"

第三章：哲学的深渊——计算机在"表达"什么？

第四章：外星文明的启示——如果真有 O(1) 解法？

尾声：我们都是"串行时代的化石"

leetcode3731 逃课逮捕令：从 list 遍历到 Set 精准锁头

逃课逮捕令：从 list 遍历到 Set 精准锁头