题目要求 给你一个整数数组 nums 和一个整数 k。一个恰好包含 k 个连续元素的窗口从 nums 最左端开始，每次向右移动一位。请按窗口从左到右的顺序，返回每个窗口中 的最大值。 窗口中的元素必须连续，其原有顺序和位置不会改变，相邻窗口可以重叠。数组中的值 可以重复，也可以是负数。 LeetCode 接口约定 LeetCode 会调用 maxSlidingWindow(nums, k)。该方法接收整数数组和一个合法的窗口 大小，返回一个整数数组，其中依次包含每个完整窗口的最大值。输入保证满足下面的 约束。 示例 示例 1： 输入：nums = [1,3,-1,-3,5,3,6,7], k = 3 输出：[3,3,5,5,6,7] 示例 2： 输入：nums = [1], k = 1 输出：[1] 约束 1 <= nums.length <= 10^5 -10^4 <= nums[i] <= 10^4 1 <= k <= nums.length 第 1 步：窗口什么时候才完整？ 在示例 1 中，当窗口右端到达索引 2 时，窗口由哪些索引组成？右端继续到达索引 3 时，又会发生什么变化？ 目前我们只知道一个大小为 k 的窗口会向右移动。要枚举所有输出时，这个描述还 不够：它既没有准确说明窗口的左端，也没有说明第一个完整窗口会在哪个位置出现。 使用从零开始的索引，把当前结束位置记为 right。如果窗口从 left 开始，并且 恰好包含 k 个元素，那么： ...

副标题 / 摘要 这是 Hot100 专栏第 1 篇：和为 K 的子数组。本文用“前缀和 + 频次哈希表”把 O(n^2) 降到 O(n)，并按 ACERS 模板给出工程场景与多语言实现。 预计阅读时长：12~15 分钟 标签：Hot100、前缀和、哈希表 SEO 关键词：Subarray Sum Equals K, 和为K的子数组, 前缀和, 哈希表, O(n) 元描述：和为 K 的子数组计数问题的前缀和解法，含工程迁移、复杂度对比与多语言代码。 目标读者 正在刷 Hot100，希望建立稳定算法模板的初学者 需要把计数类算法迁移到业务数据统计的中级工程师 准备面试，想掌握“前缀和 + 哈希表”核心套路的人 背景 / 动机 “统计和为 K 的子数组数量”是最经典的计数类问题之一。 它广泛出现在日志分析、风控阈值命中、交易序列统计等场景。 朴素的两层遍历虽然直观，但一旦数据规模增大就会明显卡顿，因此需要可扩展的 O(n) 解法。 核心概念（必须理解） 子数组：数组中连续、非空的片段 前缀和：prefix[i] = nums[0..i] 的和 差分关系：若 prefix[r] - prefix[l-1] = k，则 nums[l..r] 的和为 k 频次哈希表：统计某个前缀和出现的次数，以 O(1) 均摊时间查询 A — Algorithm（题目与算法） 题目还原 给你一个整数数组 nums 和一个整数 k，请统计并返回 和为 k 的子数组 的个数。 子数组是数组中元素的连续非空序列。 ...

标题 Git 入门教程：从零开始管理代码版本 副标题 / 摘要 一篇面向新手的 Git 基础使用指南，从初始化仓库、提交版本到远程协作， 用最少命令完成日常开发流转。 目标读者 初学者：第一次接触 Git，希望快速上手基本命令。 转岗工程师：从单机开发转为团队协作，需要熟悉版本管理流程。 学生：做课程项目或实验，需要规范保存代码历史。 背景 / 动机 没有版本管理时，常见的做法是： “先复制一份目录，改完再看看哪个好用。” 这种方式很快会失控：文件版本混乱、无法回退、多人协作冲突频发。 Git 的价值在于记录每一次变更，让你随时回到过去的任意状态， 并支持多人同时开发而不互相覆盖。 核心概念 仓库（Repository）：一个包含代码与历史记录的目录。 工作区（Working Directory）：你当前编辑的文件。 暂存区（Staging Area）：等待提交的文件清单。 提交（Commit）：一次可追溯的版本快照。 远程仓库（Remote）：托管在服务器上的仓库，用于协作和备份。 实践指南 / 步骤 1️⃣ 初始化仓库 git init 2️⃣ 查看当前状态 git status 3️⃣ 把文件加入暂存区 git add . 4️⃣ 提交一次版本 git commit -m "init: first commit" 5️⃣ 绑定远程仓库并推送 git remote add origin https://example.com/your/repo.git git branch -M main git push -u origin main 协作流程（从克隆到提交） 这一部分是团队协作的核心，决定了你能否安全、稳定地和他人同步代码。 掌握这些命令，能避免覆盖同事的提交，减少冲突和返工。 ...

任务编排为什么要放后端：让流程可控、可变、可回放 副标题 / 摘要 在多步骤、可中断、可回放的业务流程中，把“流程顺序与状态机”放在后端，是系统长期可演进的关键。本文从真实工程痛点出发，解释为什么前端不应硬编码流程顺序，并给出一套可落地的后端 Pipeline 编排思路与最小实现。 目标读者 正在设计多步骤流程 / 向导式产品的后端工程师 需要支撑 Web / App / Admin 多端一致流程的技术负责人 在 AI / LLM 产品中处理“模型自动 + 人工确认”混合流程的团队 背景 / 动机：问题通常是怎么爆出来的？ 很多系统一开始都很简单： 前端：第 1 步 → 第 2 步 → 第 3 步 后端：校验 + 存数据 但随着业务演进，以下需求几乎一定会出现： 步骤 变多：从 3 步变成 10+ 步 步骤 可选：根据条件跳过 / 插入新步骤 步骤 可中断：需要用户确认、补充信息、人工审核 步骤 可重试 / 可回放：失败后从中间继续，而不是全部重来 步骤 多端一致：Web / App / 内部工具共享同一流程 如果此时流程顺序仍然写在前端： 每次流程变更 = 多端发版 出问题时无法准确回答：现在卡在哪一步？ 想加监控、审计、回放，发现无从下手 根因只有一个： ...

摘要 很多团队做 AI 应用时会陷入一种痛苦：业务逻辑写了一堆，却始终看不到“算法到底抽出了什么”。根因往往不是代码能力，而是把算法阶段的探索，过早塞进业务工程。本文用“投标写作工具里的事实抽取（FactMention）”作为例子，讲清楚算法与业务的边界、如何用 JupyterLab 快速验证、以及何时进入工程化。 目标读者 正在做 LLM/RAG/信息抽取的工程师（初级到中级） 负责 AI 产品落地的技术负责人 / 架构师 经常在“写了半天流程，结果不知道抽取效果如何”的同学 背景与动机：为什么这个问题重要？ 在传统系统里，大家习惯把“算法”理解为一个函数或模型文件，把“业务”理解为接口与流程。但在 LLM 时代，这个界限变得更模糊： 算法不仅是模型，还包括 prompt、schema、抽取策略、规则归一、置信度与去重策略 算法输出往往是 不确定、需要人类直觉评估 的 如果你把这些“不确定”的东西直接嵌进业务链路（router/service/db/cache），你会遇到： 调试成本爆炸：只看到最后 response，不知道中间发生了什么 逻辑迭代极慢：改一行抽取策略，要跑完整流程 团队协作困难：大家在黑箱里争论“到底准不准” 因此，需要一个更清晰的边界：算法负责收敛中间态，业务负责稳定交付。 核心概念：算法与业务到底分别是什么？ 1）算法（Algorithm）的工程定义 算法负责把“模糊世界”压缩成“可用的结构化中间态”。 关键词：不确定性、探索、需要“看结果”、需要收敛。 在投标写作场景中，算法阶段的问题长这样： LLM 抽取出来的 payload 字段应该有哪些？ norm_key 怎么设计才代表“同一事实”？ 同一人多条命中（mentions）要不要合并？ confidence 到底有没有意义？怎么校准？ 这些问题的共同特点是：你必须看中间结果才能判断对不对。 2）业务（Business）的工程定义 业务负责在中间态稳定之后，把事情编排起来：什么时候取什么数据、走哪条链路、如何返回给用户。 关键词：确定性、可维护、可测试、可复用。 在投标写作场景中，业务阶段的问题长这样： retrive_type = personnel 时走事实检索，否则走原文档检索 接口响应结构固定，前端按协议渲染 存储从 MemoryTable 换成 DB，不影响上层调用 这些问题的共同特点是：输入输出清晰，错误是边界情况，而不是“我也不知道会不会抽出来”。 一条“贴墙上”的分界线 凡是你还说不清“中间结果长什么样”的阶段 → 用 JupyterLab。 凡是你能画出输入/输出 JSON 形态并写出测试用例的阶段 → 进工程。 实践指南：什么时候用 JupyterLab，什么时候用工程代码？ 阶段 1：事实抽取建模期（强制用 JupyterLab） 适用信号： ...

size_t 有什么用？为什么 C++ 循环更偏爱 size_t 而不是 int 副标题 / 摘要 当你写 for 循环遍历容器时，size_t 往往比 int 更安全、更贴合语义。本文用 ACERS 结构讲清楚 size_t 的定义、使用理由、风险点与工程实践，适合写 C++ 的你快速落地。 元信息 阅读时长：8-10 分钟 标签：C++，size_t，类型系统，循环，STL SEO 关键词：size_t 用途，size_t 和 int 区别，C++ 循环初始化，size_t 下溢 元描述：解释 size_t 的定义与用途，说明为什么循环索引常用 size_t，并给出安全写法与工程场景。 目标读者 C++ 初学者：对 size_t、sizeof、容器 size() 的返回类型不熟悉 中级工程师：遇到过 -Wsign-compare 警告或下溢 bug 需要写跨平台/高性能 C++ 代码的人 背景 / 动机 在 C++ 代码里，你经常能看到这样的循环： for (size_t i = 0; i < vec.size(); ++i) { ... } 不少人疑惑： 为什么不用更“直观”的 int？ size_t 到底是什么？为什么是无符号？ 什么时候会踩坑？ 这一篇把这些问题一次讲清楚。 ...

副标题 / 摘要 这是“数据结构基础”系列第 2 题：好数对计数。通过“频次统计 + 组合计数”，把 O(n^2) 直接降到 O(n)，并给出可直接迁移到工程的实现方式。 预计阅读时长：8~10 分钟 标签：哈希表、计数、数组 SEO 关键词：Good Pairs, 好数对, hash map, frequency, 计数 元描述：好数对计数的哈希表解法与工程化应用，含复杂度分析与多语言代码。 目标读者 刚开始学习哈希表与计数思想的初学者 希望把刷题方法迁移到业务统计的中级工程师 准备面试，想掌握基础计数模型的同学 背景 / 动机 “找出相同元素的两两组合数量”是一个常见的计数类问题。 在数据去重、行为分析、错误归因等场景里，这类问题通常会被反复遇到。 若用双重循环计算，复杂度是 O(n^2)；一旦数据规模扩大就会变慢。 因此需要一个可线性扩展的方案。 A — Algorithm（题目与算法） 题目还原 给你一个整数数组 nums。 如果一组数字 (i, j) 满足 nums[i] == nums[j] 且 i < j，就称为一个 好数对。 返回好数对的数目。 输入输出 名称 类型 描述 nums int[] 整数数组 返回 int 好数对数量 基础示例 nums 输出 说明 [1, 2, 3, 1, 1, 3] 4 (0,3) (0,4) (3,4) (2,5) [1, 1, 1, 1] 6 C(4,2) = 6 [1, 2, 3] 0 无重复 直观图示（示例 1） ...

副标题 / 摘要 Two Sum（两数之和）是最经典的数组哈希题：用“补数 + 哈希表”把 O(n^2) 降到 O(n)。本文按 ACERS 结构拆解题意、原理与工程迁移，并给出多语言可运行实现。 预计阅读时长：10~12 分钟 标签：Hot100、哈希表、数组、补数、面试高频 SEO 关键词：Two Sum, 两数之和, hash map, 补数, O(n), LeetCode 1, Hot100 元描述：两数之和的哈希表解法与工程应用解析，含复杂度对比与多语言代码。 目标读者 刚开始刷题，希望建立“补数 + 哈希表”基本模型的初学者 需要把算法思路迁移到工程问题的中级开发者 准备面试、想快速掌握高频题的求职者 背景 / 动机 “在一堆数字里找出两数之和”等价于一个快速配对问题，常见于对账、预算、风控、推荐等场景。 朴素暴力法虽然简单，但在数据量上来后会直接超时；哈希表一遍扫描能把复杂度从 O(n^2) 降到 O(n)，是最工程可行的做法之一。 A — Algorithm（题目与算法） 题目还原 给定一个整数数组 nums 和一个整数目标值 target，请在该数组中找出和为目标值的 两个 整数，并返回它们的数组下标。 每种输入只会对应一个答案，并且你不能使用两次相同的元素。答案可以按任意顺序返回。 输入输出 名称 类型 描述 nums int[] 整数数组 target int 目标和 返回 int[] 满足 nums[i] + nums[j] == target 的下标 基础示例 nums target 输出 [2, 7, 11, 15] 9 [0, 1] [3, 2, 4] 6 [1, 2] 补数图示（示例 1） ...

XOR 与 RC4：从原理到 Go 实战（含安全替代建议） 副标题 / 摘要 用最少的数学解释 XOR 与 RC4 的工作机制，给出可运行的 Go 示例，并说明 RC4 的安全问题与替代方案。 目标读者 想读懂遗留 RC4 代码的后端工程师 想区分“编码”与“加密”的初学者 需要建立流密码心智模型的中级开发者 背景 / 动机 很多系统仍遗留 RC4 或“自研解密”的逻辑。常见误区是把 Base64 当作加密，或忽视“完整性校验”。理解 XOR 与 RC4，有助于正确评估安全性，并避免把旧方案复制到新系统。 核心概念 XOR（异或）：按位运算，可逆 流密码：用伪随机密钥流与明文逐字节 XOR RC4：经典流密码，但已不推荐 Base64：编码，不是加密 完整性：仅加密不等于防篡改 实践指南 / 步骤 接收 Base64 字符串（通常是 RC4 输出） Base64 解码得到原始字节 用共享密钥初始化 RC4 将密钥流与字节逐字节 XOR 把输出按 UTF-8 转为字符串（若是文本） 可运行示例（Go） package main import ( "crypto/rc4" "encoding/base64" "fmt" ) func rc4XOR(key string, data []byte) ([]byte, error) { c, err := rc4.NewCipher([]byte(key)) if err != nil { return nil, err } out := make([]byte, len(data)) c.XORKeyStream(out, data) return out, nil } func encryptToBase64RC4(key, plaintext string) (string, error) { out, err := rc4XOR(key, []byte(plaintext)) if err != nil { return "", err } return base64.StdEncoding.EncodeToString(out), nil } func decryptBase64RC4(key, encoded string) (string, error) { raw, err := base64.StdEncoding.DecodeString(encoded) if err != nil { return "", err } out, err := rc4XOR(key, raw) if err != nil { return "", err } return string(out), nil } func main() { key := "demo-key" plaintext := "hello rc4" enc, _ := encryptToBase64RC4(key, plaintext) dec, _ := decryptBase64RC4(key, enc) fmt.Println(enc) fmt.Println(dec) } 运行： ...

副标题 / 摘要 ABC 用来“写抽象接口并阻止未实现的类被实例化”；ABCMeta 用来“在创建类时施加规则（自动注入、校验、注册）”。本文用最短可运行例子帮你在两者之间做选择。 目标读者 Python 初学者：了解抽象类怎么用、为啥会报 TypeError 中级开发者：在“接口约束”和“元类自动化”之间做取舍 需要做插件/框架能力的人：统一约束子类结构、自动补齐类级属性 背景 / 动机 你可能遇到过这些痛点： 想规定“子类必须实现某些方法”，但团队里总有人忘写 想让一批子类都有统一的类属性（比如 plugin_name），不想每个子类手写一遍 看到别人写 metaclass=ABCMeta，不确定是不是“更高级/更正确” 结论先说：大多数业务代码只需要 ABC；只有当你真的需要“类创建期的自动化规则”时，才考虑直接使用 ABCMeta（或在它上面做扩展）。 核心概念 1）抽象方法（@abstractmethod） 被标记为抽象的方法/属性，表示“必须由子类提供实现”。只要类里还有抽象成员未实现，它就不能被实例化。 2）抽象基类（ABC, Abstract Base Class） 用于定义一组接口约束：能继承、能被 isinstance/issubclass 判断，并能阻止不完整实现的类被实例化。 3）元类（metaclass） 普通类的“类”是 type；元类决定“类是怎么被创建出来的”。你可以在元类里： 在类创建时自动添加/修改类属性 校验子类是否符合规则（命名、属性、方法签名等） 统一注册子类到某个 registry ABCMeta 就是 abc 模块提供的元类：它把“抽象基类能力”实现为一套类创建/实例化规则。 实践指南 / 步骤 步骤 1：只需要“接口约束”——用 ABC 如果你只关心“子类必须实现哪些方法”，直接继承 ABC 是最简洁的写法。 步骤 2：需要“类创建期自动化规则”——用（或继承）ABCMeta 当你希望“子类不用手写，也能按规则自动拥有某些类属性/被校验/被注册”，再考虑元类。 可运行示例 示例 A：用 ABC 做接口约束（推荐默认选项） from abc import ABC, abstractmethod class Repo(ABC): @abstractmethod def save(self, obj) -> None: ... class MemoryRepo(Repo): def save(self, obj) -> None: print("saved:", obj) # Repo() # 取消注释会抛 TypeError：抽象类不能实例化 MemoryRepo().save({"id": 1}) 你得到的是：强约束（没实现抽象方法就不能实例化），且写法清晰。 ...