京公网安备11010502063487号真实实现 K 个一组翻转链表:递归版结果和 8 组边界用例(整除、有余数、k=1、k 等于链表长度、k 超过链表长度、空链表)跟暴力法交叉验证全部一致;真实踩坑——20 万节点、k=7 时递归版真实触发 Python RecursionError 爆栈;改成迭代版后同样数据 15.9 毫秒跑完,和递归版结果逐一交叉验证一致。
真实验证合并区间的排序贪心算法:嵌套区间、部分重叠、共享端点三种情况和暴力覆盖标记法结果完全一致;真实踩坑发现“端点相邻但不共享点算不算重叠”这个边界情况,连暴力验证法本身都有盲区,必须先分清连续实数语义和离散整数语义;真实实现差分数组版本作为第二种解法,和排序贪心版交叉验证,值域有限时明显更快。
真实验证差分数组处理“区间批量加”的正确性:4 次区间加操作,和暴力遍历逐个位置累加的结果完全一致;50 万长度数组、2 万次随机区间加,真实测出差分数组比暴力遍历快 72.9 倍;真实把差分数组接上高峰在线人数的例子,验证结果一致——这正是之前那几篇“线性扫描”算法背后真正在用的数据结构。
真实验证并发写日志时,物理写入顺序和事件真正发生的顺序对不上(200 个并发写入,3503 对逆序);真实量化对称随机抖动几乎不影响峰值统计,但登录登出两条写入路径存在系统性延迟差(比如登出走异步清理)时,峰值会被稳定地系统性算高,真实登录潮场景下延迟 30 秒能把峰值算高 5.39%;真实构造一个从未发生过的“幽灵峰值”,证明这不是理论担忧。
真实验证高峰在线人数的“持续时长”该怎么算:排序事件版按分段起止时间累加、差分数组版逐秒累加,两种算法结果完全一致;真实构造用例证明人数下降只是暂停累加,回到(不超过)当前峰值会接着累加,不会清零;真实构造用例证明已经累计的 9 秒峰值时长,会在后来出现更高峰值时被完全作废;30 万条真实数据交叉验证两种算法。
真实实现外部排序(分块落盘+堆多路归并),结果与 sorted() 完全一致;真实踩坑并修复了一个“归并阶段整块读进内存”的隐藏 bug,200 万条数据峰值内存从 310MB 降到 33.3MB;真实测出数据能装进内存时外部排序反而慢 5 倍;真实把排序结果接上高峰在线人数的扫描线算法,验证整条流水线结果一致。
真实实现扫描线算法求一天内登录登出日志的高峰在线人数和持续时长,和暴力按秒计数交叉验证结果一致;真实构造同一秒退出又登录的用例,证明退出事件必须排在登录事件前面,否则峰值会被多算;30 万条模拟记录真实测出算法耗时。
按行填 dp 表求出 LCS 长度,再从右下角回溯重建出真正的子序列,三种独立方式交叉验证结果。
把边按权重排序后依次用并查集判断成环,含提前终止与从未被检查过的边,和 Prim 算法交叉验证总权重。
SUNDAY 变成 SATURDAY 的经典例子,dp 表三选一填法与回溯还原真实编辑操作,三种独立方式交叉验证。
在有重复值的数组上分步演示 lower_bound/upper_bound,lo/hi 是插入点而非下标,与 bisect 模块交叉验证。
容量 3 的 LRU 缓存跑 10 次 get/put,手写双向链表演示命中、未命中、淘汰时哈希表与链表如何同步更新。