这是篇周报式的 ARTS 记录，我先把三个话题分别取证。
三个话题的主源都拿到了，我再把 “数据库 = 全局变量” 这个论点校验一下。
这一期三条线索各有落点。算法上，快慢指针找中点是链表题里最便宜的一次遍历方案：快指针两步、慢指针一步，快指针掉出链尾时慢指针正好停在中间 —— 写对只有四行，但 while 里的判断顺序、偶数长度返回 "第一个还是第二个中点"，这两处能决定一半用例过不过。阅读上，把 "数据库是全局变量" 当修辞是低估了它：一个共享关系库在整个系统的尺度上，行为就跟一个全局可变变量没区别，任何模块能读任何表、任何迁移能改任何数据，schema 就是那个隐式、没有版本号、没人 review 的公共契约。分享上，AI 把漏洞发现从 "人工搜猎" 变成了 "工业采矿"，微软单月补丁从约 200 冲到 1400 以上、Chrome 半年修掉前两年的量，而修复端还是按 55 天周期排队的产能 —— 披露到被利用的窗口已经从 745 天压到 44 天，这条缝才是 2026 年安全行业真正的痛点。
一、Algorithm：快慢指针找中点，四行代码三个坑
骨架就这么多：
def middle(head):
slow = fast = head
while fast and fast.next:
slow = slow.next
fast = fast.next.next
return slow
坑一：while 里的顺序不能换。 fast and fast.next 必须先判 fast。偶数长度时 fast 最后一次会走到 None，如果先写 fast.next，就是空指针解引用。C 系语言里靠 && 的短路救你，Python 靠 and 的短路救你，但顺序写反了两边都救不了。
坑二：偶数长度返回的是 "中间偏右" 那个，不是左边那个。
| 链长 | 节点 | while fast and fast.next（第二个中点） | while fast.next and fast.next.next（第一个中点） |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 2 | 1 2 | 2 | 1 |
| 3 | 1 2 3 | 2 | 2 |
| 4 | 1 2 3 4 | 3 | 2 |
| 5 | 1 2 3 4 5 | 3 | 3 |
| 6 | 1 2 3 4 5 6 | 4 | 3 |
奇数长度两边一致（中点唯一），偶数长度差一个节点。这个差别不是美学问题：归并排序切分要第一个中点（保证左半不比右半长），"删除中间节点"（LC 2095）要第二个中点。选错，一半用例过、一半不过，是最难查的那种 bug。
坑三：fast 的起点。 想拿第一个中点，除了改判断条件，也可以让 fast 从 head.next 出发，效果等价。
复杂度对比：
| 方案 | 时间 | 空间 | 遍历次数 | 适合场景 |
|---|---|---|---|---|
| 先数长度再走 L/2 | O(n) | O(1) | 2 次 | 数组、可随机访问结构 |
| 快慢指针 | O(n) | O(1) | 1 次 | 链表、只能顺序读的流 |
| 哈希表记录访问过的节点 | O(n) | O(n) | 1 次 | 需要 "访问过哪些节点" 这类副产品时 |
同一套 2:1 的速度配置还能顺带解决一串问题：判环（相遇即有环）、找环起点（相遇后一个指针回 head，同速再走）、找倒数第 k 个（快指针先走 k 步再同速）。真正要记的不是代码，是那句不变量 ——每轮快指针相对慢指针净赚 1 步。说不出这句话，说明这题不该用快慢指针。
二、Review：数据库是 "全局变量的仓库"
这个说法有三个独立出处，不是一个人拍脑袋：
| 出处 | 原话 |
|---|---|
| Martin Kleppmann（2014） | 开发者早就把全局变量干掉了，但数据库就是一个巨大的全局变量 |
| Allen Holub | 数据库是一个弥漫在你代码里的巨型全局变量 |
| Arpit Bhayani（2026） | 共享关系库在整个系统的尺度上，行为就是一个全局变量 |
为什么成立，理由很具体，不是玄学：
- 谁都能读。 任何模块可以绕开服务层直接查表。分析模块为了省一次调用直连 orders，是常态。
- 谁都能改。 任何一次 migration 可以触碰任何数据、任何结构。改一个列名，等于向所有曾经查过这张表的地方广播了一次 breaking change。
- 契约是隐式的。 微服务里契约是 API schema，有版本、有 review、有兼容性承诺；单体里契约是数据库 schema，没有版本、没有 review、对调用方不可见。
于是就有了那个经典场面：ALTER TABLE orders RENAME COLUMN customer_id TO user_id; 凌晨两点跑的报表任务挂了，你早上九点才知道。
代价清单，逐条对得上：
- 函数签名里看不见的隐形参数（依赖了全局状态，调用方一无所知）
- 变更影响面无法静态分析，只能全文搜，还搜不全
- 测试必须起一个真库，单元测试退化成集成测试
- 时间耦合：A 模块写的字段，B 模块依赖它的格式，谁都不敢先改
但有一件事必须分清，否则会读歪："数据库是细节" 和 "数据是细节" 不是一回事。 Uncle Bob 说的是 Oracle 还是 MySQL 属于最外层的实现细节，业务规则不该被它绑架；而 "一次取消订单必须带原因、退款金额、时间戳"—— 这是业务事实，属于领域模型，不是 DBA 的私事。把前者当后者，就会得到 "用例只改一个 status 字段、剩下的历史靠反查 updated_at 猜" 的架构，然后所有人开始怀疑数据。
减轻的办法，按成本从低到高：
- 表归属明确。 一个模块写一组表，别的模块只能走它的接口读，不许直连。
- schema 变更当 breaking change 处理。 版本化、先加后删（expand-contract）、给下游留迁移窗口。
- 领域事件作为用例的显式输出。 "订单取消" 是业务事实，应该由用例产出，而不是事后从快照里考古。
- 连接别做成全局单例。 用依赖注入把连接显式传进去，测试才能换成 mock。这一条跟第一节其实是同一种思维：让依赖出现在签名里，而不是藏在全局状态里。
三、Share：漏洞发现踩了油门，修复还踩着刹车
先看发现侧这半年的曲线：
| 指标 | 数字 |
|---|---|
| 微软 2026 年 6 月补丁 | 约 200 个（当时的纪录） |
| 微软 7 月 | 570 个 |
| 微软 8 月 | 398 个（含 42 个严重、1 个已在野利用的内核提权 0day） |
| 微软 9 月 | 约 972 个，算上 Edge 内嵌 Chromium 达 997 个，112 个严重、20 个可蠕虫化 |
| 微软 10 月 | 1400 以上，超过 2023 年全年修复总量 |
| 微软 2026 前九个月累计 | 2760 个，是去年同期两倍多；按此节奏年底或超 3700 个，超过 2023+2024+2025 三年之和 |
| Chrome（6 月起用 AI 扫描） | 单轮修掉 1072 个，超过此前两年总和；今年修的严重漏洞已超前八年总和 |
| OpenAI（5 月起扫描开源） | 已发现 1300 多个漏洞 |
| Palo Alto Unit 42 的 NOVA 系统 | 两个月扫 3915 个开源项目，确认 14090 个此前未知漏洞，99.4% 从未被报告过，约 40% 高危或严重 |
| 奇安信 2026 上半年统计 | 新增漏洞 35467 个，同比 +51.9%，高危及极危占 52.1% |
修复侧的数字，放在一起看就很难受：
| 环节 | 现状 |
|---|---|
| 传统修复周期 | 约 55 天，而发现侧已经在按 "天" 计量 |
| Project Glasswing 披露的 1596 个漏洞、281 个项目 | 仅 97 个确认已修复，约 6% |
| 披露到首次被利用 | 2020 年 745 天 → 2025 年 44 天；AI 进场后正从 "天" 压向 "小时" |
| 高危漏洞被利用节奏 | 30.2% 在披露当天就被利用，83.7% 在 21 天内遭攻击 |
| 监管口径 | 美国 CISA 把联邦机构关键漏洞修复窗口从 15 天压到 3 天，理由就是 AI 加速利用 |
| 维护者产能 | 94% 的开源项目由不到 10 人维护；Node.js 今年确认修复 50 个漏洞，超历史任何一年，2 月报告量是平时的 4.6 倍 |
| 赏金计划 | curl 因报告洪流停止支付漏洞赏金；HackerOne 暂停运行十余年的互联网漏洞赏金计划 |
还有一个容易被忽略的坑：AI 生成的补丁本身也不可靠。 1Password 的研究被 SANS 的 Ed Skoudis 引用过 ——AI 生成的补丁有超过一半的概率没真正修掉根因，或者引入新缺陷。这意味着 "用 AI 自动修" 不是发现加速的对等补偿，它只是把风险从一个已知漏洞挪到一个未知回归。
行业现在压的是三条线：
| 项目 | 谁在做 | 干什么 | 定位 |
|---|---|---|---|
| Project Glasswing | Anthropic | 把强能力模型只给受信任的防守方用，去扫自己的系统 | 管 "发现" |
| Patch the Planet / Daybreak | OpenAI＋Trail of Bits＋IBM 与红帽（50 亿美元 Project Lightwell） | 派工程师直接进驻开源项目帮打补丁 | 管 "修复产能" |
| Akrites | Linux 基金会＋14 家机构 | 建立专供 AI 漏洞的统一保密型协同披露（CVD）流程 | 管 "组织方式" |
我的判断只有一句：瓶颈已经从 "找得到" 挪到了 "分得清、发得出去"。 补丁日的正确姿势不是按 CVSS 从高到低排队，而是先修 "已被证实可利用、已公开披露、对应服务对外暴露" 的那一小撮，其余按新常态批量处理。按 CVE 数量分诊，等于把精力均匀浪费在无关紧要的地方。
四、串起来看：三件事都在讲速率和约束
- 快慢指针之所以能替掉 "先数长度"，是因为它用两个不同速率的观察者绕过了 "必须先知道总量" 这个约束。
- 数据库之所以危险，是因为它把一块可变状态放开给所有人，读写速率上去了，约束（契约、版本、可见性）没跟上。
- 漏洞这件事，则是发现速率涨了一个数量级，修复速率几乎没动。
三件事的共同点：系统里真正决定成败的，往往不是峰值能力，而是最慢那一环能不能跟上。 快慢指针里最慢的是慢指针，数据库里最慢的是 schema 变更的沟通成本，安全里最慢的是补丁落地。
【相关 FAQ】
问题 1：用快慢指针找链表中点，为什么偶数长度返回的是第二个中点？能不能改成第一个？
回答 1：因为循环条件是 while fast and fast.next，fast 每次走两步，退出时它要么落在最后一个节点（奇数），要么越过链尾变成 None（偶数）。偶数情况下 slow 已经多走了一步，所以停在偏右那个中点。要拿第一个中点，把条件改成 while fast.next and fast.next.next，或者让 fast 从 head.next 起步。这个选择的实际意义是：链表归并排序切分要用第一个中点（左半不能比右半长），"删除中间节点" 要用第二个中点。找中点的两种约定在奇数长度下结果相同，只在偶数长度下差一个节点。
问题 2：说 "数据库是全局变量"，这个说法是不是太夸张了？
回答 2：不夸张，而且在共享关系库的场景下几乎是字面意思。一个库开放给多个模块之后，任何代码都能读任何表、任何 migration 都能改任何数据，schema 就成了一个隐式、无版本、调用方看不见的公共契约 —— 这跟代码里一个谁都能读写的全局变量，行为完全一致。三个独立出处都这么说：Kleppmann 2014 年那句 "数据库就是一个巨大的全局变量"，Allen Holub 的 "弥漫在你代码里的巨型全局变量"，以及 2026 年那篇讲单体架构的文章直接把 "Database Is A Global Variable" 当小标题。要补一句限定：这里说的是 "数据库这个技术 + 它承载的共享可变状态"，不是说 "数据本身是细节"。业务事实该建在领域模型里，不能靠反查表来考古。
问题 3：AI 让漏洞发现变快，为什么反而成了修复压力？修复不是也能用 AI 吗？
回答 3：因为两端不对称。发现侧的门槛被 AI 直接抹平了 —— 微软单月补丁从约 200 冲到 1400 以上、Chrome 一轮修 1072 个、Unit 42 两个月在 3915 个开源项目里确认 14090 个漏洞，这些量原来是人工审计几年都碰不到的。修复侧的产能没有同比例扩张：传统修复周期约 55 天，Glasswing 披露的 1596 个漏洞里只有 97 个确认修好（约 6%），94% 的开源项目由不到 10 人维护。更麻烦的是 AI 生成的补丁本身也不可信，1Password 的研究显示超过一半没能修掉根因或引入新缺陷。所以 "用 AI 自动修" 不是对等补偿，它把风险从已知漏洞挪到了未知回归。
问题 4：漏洞发现提速之后，企业修漏洞的优先级应该怎么排？
回答 4：按可利用性排，不是按 CVSS 排。理由是数据已经变了：30.2% 的高危漏洞在披露当天就被利用，83.7% 在 21 天内遭攻击，披露到首次利用的中位窗口从 2020 年的 745 天压到 2025 年的 44 天，CISA 甚至把联邦关键漏洞的修复窗口从 15 天压到 3 天。在这个节奏下，CVSS 9.8 但不可达、不可利用的漏洞，优先级应该低于一个 CVSS 7.x 但已进 CISA KEV 目录、且服务对外暴露的漏洞。Tenable 分析 Anthropic 红队结果时还发现过一个反向信号：微软标注 "不太可能被利用" 的 14 个漏洞里，AI 能对 13 个做出可用的 PoC—— 说明人工打的 "可利用性" 标签本身已经可能失真。所以修复压力下最该做的是分诊，不是全量排队。
问题 5：这一期三件事看起来毫不相关，为什么放在一起写？
回答 5：因为它们讲的都是同一个结构问题 —— 最快那环提速了，最慢那环没动。快慢指针找中点的价值，在于用一个恒定速率差绕开 "必须先数清长度" 这个前置约束，本质是拿速率换掉一次遍历；数据库被当成全局变量仓库的问题，在于读写速率很容易提上去，而 schema 契约的沟通、版本化、兼容性这些约束成本没跟上，最后所有变更都变成广播；漏洞发现提速后的修复压力，则是发现速率涨了一个数量级、修复速率停在 55 天周期上。三件事的结论也一致：决定系统上限的通常不是峰值能力，而是最慢那一环，找中点看慢指针、看数据库看 schema 变更、看安全看补丁落地率。
【参考资料】
[2026-11-05]（算法思维系列／双指针技巧）Gitee labuladong/fucking-algorithm
[2026-10-30]（The Database Is a Detail. The Data Is Not.）DEV Community
[2026-10-29]（AI 发现漏洞速度快于修复 谷歌 Chrome 修复 1072 个漏洞 微软 10 月 1461 个补丁 开源维护者承压）凤凰网科技
[2026-10-13]（微软 10 月补丁星期二修复 CVE 再破纪录，AI 加速漏洞挖掘进程）FreeBuf
[2026-09-27]（Global State and Singletons）Nette Documentation
[2026-09-09]（微软一夜修补 972 个漏洞：AI 攻击巨浪前的最后窗口）钛媒体
[2026-08-30]（How Event Sourcing Grows With the Business）Rico Fritzsche
[2026-08-24]（The Widening Gap: AI Discovery Outpaces Patch Capacity）Cloud Security Alliance Lab Space
[2026-08-04]（奇安信 2026 年中漏洞报告："高危 + AI 诱导" 漏洞激增，攻防进入 "小时级" 时代）奇安信集团
[2026-07-09]（Your Monolith Is Already A Distributed System）Arpit Bhayani
[2026-07-01]（Fast & Slow Pointers）Neel Mishra
[2026-06-26]（AI 挖洞踩下油门，14 巨头联手启动 Akrites）钛媒体
[2026-05-02]（Fast & Slow Pointers）Ephizen Wiki
[2024-12-06]（
【数据结构与算法 刷题系列】求链表的中间结点）腾讯云开发者社区
[2021-06-24]（Global Data (base)／Allen Holub 原话转引）Friendgineers
免责声明：本文是个人学习周报性质的整理，不构成任何安全处置建议或采购建议。需要提示五点：其一，文中漏洞数量、补丁条数、修复比例等数据来自不同机构的统计，统计口径并不统一 —— 微软的 CVE 计数会因第三方漏洞归属不同而浮动，奇安信的统计覆盖 CNVD/CNNVD 多源，Glasswing 的 "6% 修复率" 是按已披露条目统计的截面数据、不等于长期最终结果，这些数字宜看趋势、不宜当精确指标；其二，不同信源之间存在口径差异，例如微软 9 月补丁量有 "972" 与 "997（含 Edge/Chromium）" 两说、微软 10 月有 "1400 以上" 与 "1461" 两种表述，本文已尽量并列标注，正式引用请回到原始报告与厂商公告；其三，算法部分给出的代码是示意实现，边界条件（空链表、单节点、fast 与 fast.next 的判断顺序）请按自己语言的求值规则再验一遍，生产代码请补单元测试覆盖奇偶两种长度；其四，安全部分引用的攻击窗口、可利用性比例、AI 生成补丁失败率等，属第三方研究和厂商披露，不能替代针对自身资产的可达性与暴露面评估，任何补丁请先在测试环境验证再上生产；其五，本文对 "数据库是全局变量" 的讨论是架构层面的观点归纳，具体到某个系统是否要拆表归属、是否引入事件溯源，需要结合团队规模、业务变更频率和运维成本判断，多数系统并不需要为此重构，小规模 CRUD 应用强行上版本化事件契约只会增加官僚成本。