如果刚开始整理知识体系，建议先选一个综合站点作为主线，再用题库查漏补缺。项目源码更适合在掌握基础语法、CMake 和调试工具后动手。

1 一、系统知识库：用来建立主线

1.1 编程指北：C++ 面试题库

覆盖 C++ 基础、面向对象、内存管理和现代 C++ 等模块。分类清楚，适合先快速浏览目录，建立“还需要学什么”的整体地图。

1.2 huihut：C/C++ 技术面试知识库

除了 C/C++，还包含 STL、数据结构、操作系统、网络与链接装载等内容。适合把语言知识和计算机基础串起来。

• 对应的 GitHub 开源仓库

1.3 卡码笔记：面试知识库

覆盖语言、操作系统、网络和并发等常见方向，适合按模块复习，并顺着题目继续追问底层机制。

1.4 小林 coding：C++ 面试题

以问题为入口，配有较多图解。遇到内存管理、STL 或语言特性等问题时，可以用来辅助理解。

2 二、逐题练习：用来查漏补缺

2.1 面试鸭：C++ 基础面试题库

适合快速检查基础题覆盖情况。使用时不要只背结论，可以继续追问：为什么这样设计、底层如何实现、边界在哪里。

2.2 拾光小舟：C++ 基础面试集

按“回答重点”和扩展内容组织，适合把零散知识整理成能在面试中表达的答案。

2.3 程序厨：C++ 面试题库

题目覆盖面较广，可以当作复习清单使用。遇到没有完整展开的题目，再回到系统知识库补原理。

2.4 guaguaupup：C++ 后台开发面经

内容覆盖 C++、Linux、操作系统、网络、数据库和设计模式等方向，适合准备后端岗位时补齐关联知识。

3 三、作者公开资料：用来交叉验证

下面几处资料来自同一作者或同一资料体系，适合互相对照，不必重复通读。

• 程序喵大人的公开知识库入口
• C++ 高级面试题答案合集
• 面试鸭公开答题记录
• cpp-learning 公开资料导航

部分入口可能要求登录。公开仓库与网站内容可以作为补充，但不代表其他配套内容也全部开放。

4 四、开源项目：从“会答”走到“会做”

4.1 BuriedPoint：埋点上报 SDK

仓库包含库实现、服务端、示例、测试和 CMake 配置，适合观察一个小型 C++ SDK 如何组织。阅读时可以沿着“初始化 → 启动 → 上报 → 持久化或发送”的调用链推进。

几个值得优先看的入口：

• 核心初始化与启动逻辑：buried_core.cc
• 上报处理逻辑：buried_report.cc
• 构建与依赖配置：src/CMakeLists.txt

这个项目偏向 Windows/MSVC 环境。阅读源码时，可以重点检查对象生命周期、线程安全、失败重试，以及接口被错误调用时的边界处理。

5 五、推荐使用顺序

1. 从“编程指北”或“huihut”选一个作为主线，先搭知识地图。
2. 用面试鸭、拾光小舟和程序厨检查遗漏，但不要同时刷多个重复题库。
3. 每遇到一道高频题，整理成“结论 → 机制 → 边界与取舍”三层回答。
4. 最后选一个小项目跟调用链、编译运行，再脱离源码重写最小版本。

资料会变化或失效；如果某个入口打不开，可以优先检查它对应的 GitHub 仓库或站点首页。

不是什么高大上的方法论，就是自己踩坑踩出来的几条，一条一条列给你看。

1 先说说心态

• 遇到问题，多去搜索，别硬憋。
• 非阻塞的问题不要陷进去，卡住半天出不来最亏。
• 什么东西都学点，得到一个程序员的思维，就很好了。

2 学习路上最大的阻碍

• 知识枯燥，容易陷入细节出不来。
• 知识其实分场景、原理、细节三层。
• 基础薄弱的时候，重点看场景和原理，之后再回归细节——顺序很重要。

3 怎么对抗打断

• 自驱力有限？那就别硬扛。手机放一边，网络关掉。
• 现实打断多？去图书馆，物理隔离最有效。
• 给自己及时的奖励，用番茄钟，学 25 分钟歇 5 分钟。
• 找个队友，加个群，有人一起走才走得远。
• 目标要明确：可衡量、具体、可实现、有时限。

4 学习方法

• 不了解的模块直接上手，先跑起来再说。
• 学一个东西先问四件事：是什么？解决什么问题？有哪些重要特性？面试重点是什么？
• 先有整体思路，再深入某个点，别一上来就钻。

5 刷题技巧

• 核心就一个字：坚持。
• 前期像乌龟，慢慢来；中期像兔子，速度起来；后期龟兔切换，稳中带快。

6 两个"不要"

• “抓大放小"不是很好——进度 > 细节，原理 > 源码，但不是啥都不看。
• 学完就忘？很正常，所有人都是。

7 忘光了怎么办

• 三遍学习法：第一遍鸟瞰式（看全貌），第二遍牛耕式（慢慢啃），第三遍消化式（输出内化）。
• 费曼学习法：把学到的讲给别人听，讲不明白的地方就是你没懂的地方。

8 最后

• 上面这些不一定全对，但都是我自己试过的。
• 学习是场长跑，别急着一天跑完，跑得久比跑得快重要。

针对"AI 时代自学新知识"的场景，逐条整理我的六条自学经验。

1 一、先搞明白"学的东西是什么"

学东西之前，先搞明白它底层到底是干什么的，再接触知识会更轻松。

以 AI 产品为例，每发布一个产品：

• 去看它的官网（定位、宣传口径）
• 看它的 GitHub（代码、star、issues）
• 看它的 HuggingFace（模型、榜单、评测）
• 看它的发布说明/文档（release notes、用法）

把"蒸馏、开源、性能"这类关键词搞明白——即它为了解决什么问题而生——再学具体知识，效率完全不同。

2 二、选方向要功利，扣细节要纯粹

选方向跟着主流走（功利），但深入了解时对细节要纯粹。

• 选方向功利：现在主流在搞 Agent，就选 Agent 方向，别逆着趋势。
• 扣细节纯粹：自己去了解它的时候，把细节钻研透彻，不掺功利心。
• 例子：你是搞 Java 的，但学习计算机底层的时候，要像纯粹研究它一样去学，别想"这对我 Java 有没有用"。

3 三、战略上藐视，战术上重视

第一次认识一个技术时，战略上把它看成一个很小的东西，把它的"壳"去掉；但不要走极端——它发展过程中一定有自己特色，战术上还是要重视。

反过来说：把技术看得太高上大，人会畏难不敢碰。

我的一个思考：有没有可能通过看一个产品的迭代过程（它最开始是为了实现什么目的，后来加了什么）来了解一个东西是干什么的？——用"演进史"当认知路径。

4 四、自下而上 × 自上而下，两条路交替走

学东西有两个方向，上下交替走，路才通。

• 自下而上：从原理/底层往上，疏通这个东西发展的逻辑。
• 自上而下：从产品/应用往下，补充它的细节。

⚠️ 陷阱：一直自下而上会很快遇到边际效益——投入大量时间但回报很少。这时应该直接接触它的产品，看它具体在干什么，快速获取细节上的认识。

一开始随便选一条路就行，不必纠结起点。

5 五、尝试把别人教会（费曼学习法）

教别人是最好的教程。给别人讲不清楚的地方，就是自己没搞明白的地方。

• 讲解过程会暴露逻辑断层：讲着讲着卡住 = 没真正理解。
• 过程中还能遇到很多同频的人（讲的人、听的人互相筛选）。

6 六、不要太急功近利：绕弯路有时就是捷径

把时间线拉长，不计较当下得失。在当下埋下种子，等待它发芽。

• 有些弯路其实是在积累关联知识，将来会连成网。
• 但战线不要拉得太远——种子可以埋，不要种到看不见希望的地方。

7 自测清单

• 学一个新东西前，能说出"它底层是干什么的"
• 能区分"选方向"和"扣细节"两种心态
• 出现边际效益时，知道切换方向去接触产品
• 能主动给同频的人讲一遍所学

LLM API 对请求的 前缀（prefix） 做自动缓存。两次请求的 prompt 开头部分完全相同时，相同部分的 token 不再重新计算，只付缓存价（通常低 100 倍以上）。

2 详细回答

2.1 命中条件

1. 必须是前缀：缓存只认从 prompt 第 1 个 token 开始的连续相同段
2. 完全匹配：字符级一模一样才命中，多一个空格就失效
3. 至少 N 个 token：大部分模型要求缓存段 ≥ 1024 token
4. TTL 内：缓存有效期通常 5-10 分钟，超时重新计算

2.2 什么最容易命中

• System prompt / 系统指令：每轮对话都一样 → 必中
• 多轮对话（重点）：同一对话框里持续聊天，每轮请求都会把"全部历史"重发给 API。历史部分和上一轮请求完全相同 → 前缀越来越大，缓存命中越来越多
• 反复引用的长文档/代码：同一个文件的 content 放前面
• AGENTS.md：每次都是 system prompt 开头 → 必中

2.2.1 多轮对话为什么自动命中

关键认知：每次发消息，API 收到的是"全部聊天记录 + 你的新消息"，不是只发新的一句。

所以同一个框连聊 20 轮，从第 2 轮起前面绝大部分都是缓存价，真正按输入价算的只有最新一句。

2.3 为什么便宜百倍

Transformer 推理最贵的步骤是 self-attention 的 KV 矩阵计算。如果 prefix 相同，上一轮算好的 KV cache 直接复用，跳过计算，只剩后面新增 token 的增量计算。服务商 GPU 成本大头被消除，所以定价极低。

2.4 实际影响

• 第一次请求：按输入价全额计费
• 后续请求（前缀相同）：前缀部分按缓存价，新增部分按输入价
• AGENTS.md / 项目 context 只有第一次会话贵，之后近乎免费

3 知识扩展

不同模型的缓存定价差异很大：

• DeepSeek V4 Pro：缓存 ¥0.02 → 是输入价的 1/147
• Qwen3.7 Plus：缓存 ¥0.27 → 是输入价的 1/10
• 缓存折扣越大，说明该模型在长对话/大 context 场景越划算

之前对 AI 的底层原理理解很模糊，一堆术语堆在一起分不清。今天从对话里一步步拆明白了。

主要卡点：

1. 模型的"权重"到底是静态的还是动态的 → 两种都有
2. Decoder-only 为什么不需要 Encoder → Decoder 自己就能看自己
3. Attention 里的 Q、K、V 到底是什么 → 每个 token 乘三个矩阵算出来的

2 最终理解

2.1 两种权重别搞混

2.2 Attention 三步（用"今天天气很好"生成"好"为例）

每个 token 变成向量后，乘三个矩阵（W_q、W_k、W_v），得到三样东西：

• Q（查询）：我要找什么信息
• K（键值）：我身上有什么标签
• V（价值）：我身上有什么信息

然后：当前位置的 Q × 每个位置的 K → 得出得分 → softmax 归一化 → 用归一化后的分数加权取 V → 最终输出。

关键是自己在注意力计算时能看自己，不是只看前面的词。

2.3 Transformer = 注意力 + 前馈，叠 N 层

1
2
3
4

输入文字
   → Token Embedding + 位置编码
   → [Self-Attention（看全局）→ 前馈网络（消化信息）] × N 层
   → 线性层 → 预测下一个字

2.4 为什么现在的大模型都是 Decoder-only

原始 Transformer 有 Encoder + Decoder，但聊天场景下输入和输出天然在一条序列里，Decoder 的 self-attention 自己就能回看所有 token，不需要 Encoder 额外"翻译"。

3 联系之前的问题

• 缓存为什么便宜：每个 token 的 K、V 上轮已经算好了，直接复用不用重算
• 多模态为什么多一个编码器：图像被打包成视觉 token 送进同一个 Transformer

文本模型只认识 token（词元）。多模态模型在语言模型外面加了一个视觉编码器（Vision Encoder），把图像切块（patch）变成"视觉 token"，再投影到和文字 token 相同的向量空间，喂进同一个 Transformer。所以图像对它来说也是一串"符号"，只是这个符号来自像素而不是文字。

2 详细回答

2.1 文本模型怎么读文字（基线）

1

"你好" → 分词器 → [token1, token2] → 嵌入表查表 → 向量 → Transformer

文字本来就有天然的分词方法（中文按字/词，英文按子词），每个 token 对应嵌入表里的一行向量。

2.2 多模态模型怎么读图像

1
2

1024x1024 图片 → 视觉编码器(ViT/CLIP) → 切成 16x16 的 patch → 每个 patch 一个"视觉 token"
→ 线性投影层（Projection Layer）→ 和文字 token 同一向量空间 → 同一个 Transformer

关键点：

1. 图像不是"直接看懂"，而是被转换成视觉 token 序列。一张 1024x1024 的图 ≈ 256~576 个视觉 token
2. 视觉编码器和 LLM 是两个网络，中间靠一层投影矩阵对齐
3. Transformer 对 token 一视同仁——不管是文字 token 还是视觉 token，都走 attention

2.3 和训练方式的区别（多模态要分阶段训）

所以多模态不是"文本模型加了读图功能"，而是从一开始就用图文数据训练，训练数据和计算量都大得多。

2.4 视频怎么读

视频 = 连续帧。处理方式：

1. 抽帧（通常 1~2 fps，即每秒抽 1-2 帧）
2. 每帧走视觉编码器变成视觉 token
3. 按时间顺序拼成超长 token 序列喂给模型
4. 部分模型（如 Gemini、Qwen2.5-VL）还有音频编码器，把声音轨也变成 token 一起处理

这就是为什么视频贵：1 分钟视频 = 60 帧 × 每帧 2561100 token ≈ 1.5万6.6万 token。

2.5 PDF 怎么读

PDF 本身不算独立模态：

• 有文字层的 PDF → 直接抽文字（像文本一样）
• 扫描件/图文混排 → 每页渲染成图像，走视觉编码器读
• 大多数模型实际是"按页转图再读"

3 知识扩展

• 判断一个模型是否多模态，看它有没有视觉编码器，而不是看名字
• 同一模型的多模态版本（如 GPT-4o vs 纯文本 GPT-4）架构差别主要在编码器部分，LLM 主干基本共享
• DeepSeek V4 Flash 是文本模型，所以视频/图片对它 = 不可读；要用多模态功能得换支持视觉的模型

所有插件机制本质相同：宿主留扩展点（接口），插件注册回调函数，宿主在关键时刻调用回调。配置文件覆盖、Obsidian 插件、游戏 Mod 全是这个套路。

2 详细回答

2.1 1. 配置覆盖原理

以 opencode 模型名显示为例：opencode 启动时读取配置并与模型数据合并（数据在 ~/.cache/opencode/models.json），选择器渲染时取合并后的 model.name。所以在 opencode.jsonc 里写：

1

{ "provider": { "opencode-go": { "models": { "deepseek-v4-flash": { "name": "...价格..." } } } } }

就能覆盖显示名。改配置 → 改数据 → UI 自动变，没碰任何程序代码。

2.2 2. 插件机制的通用四步

1. 扩展点：宿主在关键流程留接口（消息发送前、工具执行后、模型显示时…）
2. 注册：插件把函数注册到挂钩点（宿主保存回调列表，不写死行为）
3. 调用：宿主在合适时机遍历回调列表依次调用
4. 公开 API：插件只能通过宿主开放的 API 交互，拿不到内部实现

2.3 3. C++ 类比

• 接口 + 虚函数：class IPlugin { virtual void onLoad() = 0; }，插件实现接口
• Windows：DLL 动态加载（LoadLibrary）
• 设计模式：观察者模式 / 回调函数指针

2.4 4. 插件的写法

1
2
3
4
5
6
7
8

export default (async ({ client, project, $ }) => {
  return {
    config: (cfg) => { /* 配置加载时 */ },
    "tool.execute.before": async (input, output) => { /* 工具执行前 */ },
    "chat.message": (input) => { /* 每来一条消息 */ },
    event: (input) => { /* 所有事件 */ },
  }
})

加载：plugin: ["npm包名", "./本地.ts"]，或放 .opencode/plugin/ 自动发现。宿主启动时调用导出函数拿到 hooks，之后事件发生时调用对应 hook。

2.5 5. 对照：Obsidian 插件

manifest.json 声明 → Obsidian 扫描插件目录 → 实例化 class extends Plugin 并调用 onLoad() → 在 onLoad 里注册 ribbon 图标、状态栏、命令。和 export default function 是同一件事的两种写法：宿主调用插件注册的回调。

3 知识扩展

• 事件总线：宿主发布事件，插件订阅（event hook 就是这个）
• 生命周期：发现插件 → 加载模块 → 拿 hooks → 绑定事件 → 卸载时清理
• 宿主不直接引用插件类型，通过约定的接口/函数签名解耦——插件和插件之间互不感知

• Codex 能接 DeepSeek，三行配置的事
• Cloud Code（Google）基本不能接，绑定自家生态
• 效果差别：外壳（工具本身）一样，上限由模型决定；GPT-5-Codex 为 coding agent 特调，DeepSeek 是通用模型，复杂任务差距明显、简单任务够用且便宜

2 我的想法 / 卡点

之前一直以为这些工具只能用自己的模型，聊完才知道：

• Codex 2026 年 6 月官方宣布支持第三方模型，从"OpenAI 专用客户端"变成"模型中立的编码代理平台"
• 我的困惑点是"DeepSync 是什么"——其实是语音识别把 DeepSeek 听错了
• “Cloud Code 源码泄露导致 React/Reason 流行"这个说法也记错了：泄露的是 Claude Code（Anthropic），不是 Google 的 Cloud Code

3 详细回答

3.1 Codex 接入 DeepSeek（可行）

~/.codex/config.toml 加 provider 定义：

1
2
3
4

[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com/v1"
env_key = "DEEPSEEK_API_KEY"

命令行走 codex --provider deepseek --model deepseek-coder 切换。Kimi、GLM、Qwen、Ollama 同理。

坑：

• Codex 2026 年 2 月起默认走 Responses API，第三方接口大多只有 Chat Completions，需设 wire_api = "chat"，否则报流式/格式错误
• 桌面端接 DeepSeek 需要两层本地代理（模型名映射 + Responses→Chat 转换），社区有现成方案
• provider ID 区分大小写，模型名前缀写错会被静默忽略走 fallback

3.2 Cloud Code 接入 DeepSeek（基本不可行）

• Cloud Code（IDE 插件）绑定 Google 生态，不开放自定义模型
• Gemini CLI（已开源）原生只认 Gemini；需"魔改版"或 LiteLLM 代理才能接 DeepSeek
• 且 Gemini CLI 免费版 2026-06-18 已停用，个人用户迁移到 Antigravity CLI

3.3 效果差别：外壳一样，上限由模型决定

结论：日常小活用 DeepSeek 省钱，大活切回专用模型。Codex 支持多 provider 随时切，opencode 本身 75+ 模型随便换。

3.4 彩蛋：源码泄露事件的真相

• 2026-03-31，Anthropic 的 Claude Code 因 npm 包遗留 59MB source map（cli.js.map），51.2 万行 TypeScript 全曝光（第二次同原因泄露）
• 大家因此看到：终端 UI 用 React+Ink、Bun 运行时、40+ 工具模块、权限分层
• React（2013 年）/ ReAct（2022 年论文）不是泄露"导致"的，泄露只是让大家看到了顶级 Agent 的工程实现，引发讨论和借鉴

4 知识扩展

• DeepSeek API 完全兼容 OpenAI 协议，官方文档有 coding agents 接入指南
• Codex config.toml 三级配置：用户级（~/.codex/config.toml）→ 项目级（.codex/config.toml）→ 命令行参数，优先级递增
• 环境变量方式（OPENAI_BASE_URL）只能配一个 provider，config.toml 支持多 provider 并存切换

题目类型：前缀和

当你发现是在求某个大的集合下一系列具体的子集时，你可以考虑下前缀和，它可以把遍历，变成值相减。

我的写法是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

#include <vector>
#include <algorithm> // for std::max, std::min
using namespace std;

// 二维前缀和类，用于快速计算任意矩形子矩阵的和
class SumMatrix {
public:
    // preSum[i][j] 表示原始矩阵中前 i 行、前 j 列（即区域 [0, i) × [0, j)）所有元素的和
    // 维度为 (m+1) x (n+1)，其中 m、n 为原始矩阵的行数和列数
    vector<vector<int>> preSum;

    // 构造函数：根据原始矩阵 matrix 构建前缀和数组
    SumMatrix(vector<vector<int>>& matrix) {
        int m = matrix.size();          // 原始矩阵的行数
        int n = matrix[0].size();       // 原始矩阵的列数
        // 初始化前缀和数组，多一行一列用于简化边界处理
        preSum.resize(m + 1, vector<int>(n + 1, 0));

        // 计算前缀和：preSum[i][j] = preSum[i-1][j] + preSum[i][j-1] - preSum[i-1][j-1] + matrix[i-1][j-1]
        for (int i = 1; i <= m; i++) {
            for (int j = 1; j <= n; j++) {
                preSum[i][j] = preSum[i - 1][j] + preSum[i][j - 1]
                               + matrix[i - 1][j - 1] - preSum[i - 1][j - 1];
            }
        }
    }

    // 计算原始矩阵中闭区间 [x1, x2] 行、[y1, y2] 列所围成的子矩阵的和
    // 注意：x1, x2, y1, y2 都是原始矩阵的有效索引（0-based）
    int Addmatrix(int x1, int x2, int y1, int y2) {
        // 利用前缀和公式：sum = preSum[x2+1][y2+1] - preSum[x1][y2+1] - preSum[x2+1][y1] + preSum[x1][y1]
        // 因为 preSum 的行/列索引比原始矩阵大 1，所以需要 +1 转换
        return preSum[x2 + 1][y2 + 1] - preSum[x1][y2 + 1]
               - preSum[x2 + 1][y1] + preSum[x1][y1];
    }
};

class Solution {
public:
    // 计算矩阵区域和：对于每个位置 (i, j)，求以该位置为中心、边长为 2k+1 的正方形区域的和
    // （边界超出矩阵时只取有效部分）
    vector<vector<int>> matrixBlockSum(vector<vector<int>>& mat, int k) {
        int m = mat.size();      // 矩阵行数
        int n = mat[0].size();   // 矩阵列数
        // 结果矩阵，大小与原始矩阵相同
        vector<vector<int>> answer(m, vector<int>(n, 0));
        // 构建原始矩阵的前缀和对象
        SumMatrix mt = SumMatrix(mat);
        // 遍历每个位置 (i, j)
        for (int i = 0; i < m; i++) {
            for (int j = 0; j < n; j++) {
                // 计算以 (i, j) 为中心、半径为 k 的矩形区域的边界（需限制在矩阵范围内）
                int x1 = max(i - k, 0);        // 上边界（行最小索引）
                int x2 = min(i + k, m - 1);    // 下边界（行最大索引）
                int y1 = max(j - k, 0);        // 左边界（列最小索引）
                int y2 = min(j + k, n - 1);    // 右边界（列最大索引）

                // 通过前缀和快速得到该区域的和，并填入结果矩阵
                answer[i][j] = mt.Addmatrix(x1, x2, y1, y2);
            }
        }
        return answer;
    }
};

这题说白了就是：给你一个矩阵，对于每个格子 (i,j)，把它周围 k 圈范围内的所有数加起来，填回去。

暴力做法也简单，每个格子都去遍历它的 k 邻域，但那是 $O(m \cdot n \cdot k^2)$，k 一大直接炸。

关键思路就是——前缀和把遍历变成值相减。

二维前缀和的构造其实就一句话：preSum[i][j] 表示从 (0,0) 到 (i-1, j-1) 这片矩形区域的和。多开一圈 m+1 × n+1 是为了省掉边界判空。

构造公式拆开看很直观：

1
2
3
4

preSum[i][j] = preSum[i-1][j]        // 上面那块
             + preSum[i][j-1]        // 左边那块
             + matrix[i-1][j-1]      // 当前这个数
             - preSum[i-1][j-1]      // 左上角被算了两次，扣掉

画个图就是：上加左，减重叠，加自己。

查子矩阵和也一个道理。想求 (x1,y1) 到 (x2,y2) 这个矩形（闭区间，0-index）的和：

1
2
3
4

sum = preSum[x2+1][y2+1]      // 整块从原点到右下
    - preSum[x1][y2+1]        // 砍掉上面
    - preSum[x2+1][y1]        // 砍掉左边
    + preSum[x1][y1]          // 左上角被砍了两次，补回来

就是大减小，补重叠，对称得很。

最后一步，每个格子的 k 邻域怎么定界？用 max/min 把越界的部分夹住就行——左边界不能小于 0，右边界不能超过 m-1，上下同理。这样每个格子 O(1) 就能出结果，总复杂度 $O(m \cdot n)$。

一句话总结：构造一次前缀和，然后每个格子的答案就是四次查表加减。前缀和的本质就是预计算，用空间换掉内层遍历。

题目：给定一个链表的头节点 head，返回链表开始入环的第一个节点。如果链表无环，返回 null。

1 我的想法

最容易踩的坑：以为快慢指针第一次相遇就是答案。第一次相遇点不是环入口——相遇后还要从头再走一遍：让 cur（从 head 出发）和 fast（停在相遇点）同步各走 1 步，两者相遇的位置才是环入口。

2 简要回答

1. fast 每次 2 步、slow 每次 1 步，若 fast 或 fast->next 为空 → 无环，返回 null。
2. 第一次 fast == slow → 有环，记下相遇点。
3. cur = head，cur 与 fast 各走 1 步，直到 fast == cur → 返回该节点（环入口）。

• 时间复杂度：$O(n)$
• 空间复杂度：$O(1)$

3 为什么第一次相遇点不是入口

第一次相遇发生在环内，具体是环内哪个点取决于 a 和 b 的比例，没有任何规律保证它是入口。所以第二阶段必须有。

4 为什么第二轮双指针能在入口相遇

设 head→环入口距离为 a，环入口→第一次相遇点（沿前进方向）距离为 b，环长为 c。

相遇时（fast 走的路程是 slow 的 2 倍）：

1
2
3
4
5

slow 走：a + b
fast 走：2(a + b) = a + b + n·c     （fast 比 slow 多绕了 n 圈）

⇒  a + b = n·c
⇒  a = n·c - b

含义：

• 从 head 走 a 步 → 到达环入口；
• 从相遇点走 a 步 → 绕 n 圈后再退 b 步 → 也到达环入口。

所以 cur（head 出发）和 fast（相遇点出发）同步各走 1 步，恰好都在走 a 步后到达环入口，相遇。

5 代码

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

class Solution {
public:
    ListNode *detectCycle(ListNode *head) {
        ListNode* fast = head;
        ListNode* slow = head;
        while (fast != nullptr) {
            if (fast->next == nullptr) {
                return nullptr;          // 无环
            }
            fast = fast->next->next;     // 走 2 步
            slow = slow->next;           // 走 1 步
            if (fast == slow) {          // 第一次相遇，说明有环
                ListNode* cur = head;
                while (fast != cur) {    // 同步走 1 步
                    cur = cur->next;
                    fast = fast->next;
                }
                return cur;              // 环入口
            }
        }
        return nullptr;                  // fast 走到末尾，无环
    }
};

用 1→2→3→4→5→(3)（3 是环入口，环长 3）验证：第一次相遇点在 5，第二阶段从 head 和 5 同步走，在 3 相遇 → 返回 3 ✓。

6 无环与空指针

• 无环：fast 先到末尾，fast == nullptr 退出循环，返回 null。
• 空链表 / 单节点：fast == nullptr 或 fast->next == nullptr，返回 null。
• fast->next->next 在 fast->next == nullptr 已排除的前提下是安全的（最多为 null，下一轮循环判断）。

7 易错点

• 第一次 fast == slow 直接 return 是错的：那只是环内某个点，不是入口。
• 第二阶段不需要判空：已确认有环，cur 和 fast 必然相遇。
• 无环判断必须覆盖 fast == nullptr 和 fast->next == nullptr 两种。
• 第一阶段别把 slow 写成走 2 步——快慢都走 2 步永远追不上。