标题 先定不变量与契约，再写实现：Evans/Fowler 实战法 副标题 / 摘要 很多人理解“先定不变量与契约”时，会觉得只是“多写几行校验”。这篇文章给出更精确的答案：它的本质是固定责任归属，让调用方可以依赖行为语义，而不是猜测实现细节。 目标读者 正在做业务系统设计、代码评审的工程师 觉得“代码能跑，但改需求总出坑”的团队 想把 DDD/契约思想落到日常开发的人 背景 / 动机 常见开发顺序是“先把功能跑通，再补规则”。短期看速度快，长期会出现三个问题： 业务规则散落在多个 service/controller 里 调用方只能通过读实现猜行为 改一个需求会牵动大量分支判断 Evans/Fowler 这一脉的核心不是“写得更学术”，而是先明确系统必须成立的事实，再让实现为这些事实服务。 核心概念 不变量（Invariant）：无论任何路径，始终为真的业务规则。 例如：已支付订单不能再次支付。 契约（Contract）：对外可依赖的行为承诺，至少包含前置条件、后置条件、失败语义。 例如：cancel(order) 只接受可取消状态，成功后状态必须是 CANCELLED，否则抛明确异常。 接口 vs 契约：接口是签名，契约是语义保证。 同一个函数签名，可以有强契约，也可以完全没有契约。 契约分层（建议团队统一术语） 前面的 cancel(order) 示例主要覆盖了行为契约与失败契约。 在真实项目里，建议把契约至少拆成下面 6 类，一起设计： 数据契约：输入/输出的数据形状、类型、取值范围、单位、精度、是否可空。 例：金额必须 > 0，币种必须是 ISO 4217，时间必须是 UTC。 状态契约：状态机允许哪些迁移，不允许哪些迁移。 例：订单只能 CREATED -> PAID -> SHIPPED，不能 SHIPPED -> CREATED。 不变式契约：跨方法、跨状态始终成立的事实。 例：订单总额 = 明细金额之和 + 运费 - 优惠；库存不可为负。 行为契约：调用成功时，调用方可以依赖什么结果与语义。 例：reserve_stock() 成功后，一定返回预留记录 ID，且库存已被占用。 失败契约：违约/异常时返回什么错误、错误是否可重试、是否有副作用残留。 例：重复请求返回 409；超时返回 503 且标记 retryable=true。 副作用契约：方法会修改哪些外部状态（DB、缓存、消息、文件），顺序如何，失败如何补偿。 例：先写 DB 再写 outbox；缓存删除失败不影响主事务提交。 实践指南 / 步骤 先写目的，不写实现 明确本次功能要改变什么业务结果。 列不变量清单 逐条写出“绝对不能被破坏”的规则。 定义契约 为核心行为定义前置条件、后置条件、失败语义，并补齐数据/状态/副作用契约。 再落实现 数据库、框架、缓存、消息等实现细节后置。 用测试锁契约 测试验证的是契约，不是某一版实现细节。 可运行示例 示例 1：无契约（可运行，但语义模糊） class Order: def __init__(self, status): self.status = status def cancel(order: Order) -> Order: if order.status != "CREATED": return order order.status = "CANCELLED" return order if __name__ == "__main__": order = Order("PAID") after = cancel(order) print(after.status) 问题：失败是“静默返回”，调用方必须自己猜“这次到底算成功还是失败”。 ...

副标题 / 摘要 LeetCode 148 的核心不是“会排序”，而是“在链表结构里选对排序算法”。数组可随机访问适合快排/堆排，而单链表最匹配的是归并排序：找中点、递归分治、线性归并。 预计阅读时长：12~16 分钟 标签：Hot100、链表、归并排序、分治 SEO 关键词：Sort List, 排序链表, 链表归并排序, LeetCode 148, Hot100 元描述：用链表归并排序在 O(n log n) 内完成排序，覆盖思路推导、工程迁移、复杂度分析和多语言可运行实现。 目标读者 正在刷 Hot100，想把链表题模板系统化的同学 做链表题经常在“切分和拼接”环节出错的开发者 想搞清楚“为什么链表排序优先用归并”而不是快排的人 背景 / 动机 链表排序在工程里并不罕见： 合并来自多个来源的链式任务队列 对按时间追加的链式日志做离线整理 对内存敏感结构进行“尽量少拷贝”的重排 如果把数组排序思维直接搬过来，往往会遇到： 链表不支持 O(1) 随机访问，分区/堆操作代价高 频繁节点移动容易写出复杂且脆弱的代码 所以这题本质是：为链表选择正确的数据结构友好算法。 核心概念 分治（Divide & Conquer）：把链表二分到最小子问题，再向上合并 快慢指针找中点：slow 每次 1 步，fast 每次 2 步 链表归并：两个有序链表线性拼接成一个有序链表 稳定排序：相等元素相对次序可保持 A — Algorithm（题目与算法） 题目还原 给你链表头节点 head，请将其按升序排序并返回排序后的链表。 要求时间复杂度为 O(n log n)。 输入输出 名称 类型 描述 head ListNode 单链表头节点（可能为空） 返回 ListNode 升序排序后的头节点 示例 1 输入: 4 -> 2 -> 1 -> 3 输出: 1 -> 2 -> 3 -> 4 示例 2 输入: -1 -> 5 -> 3 -> 4 -> 0 输出: -1 -> 0 -> 3 -> 4 -> 5 思路推导（从朴素到最优） 朴素做法：转数组再排序 遍历链表把值放到数组 调库排序后重建链表 问题： ...

副标题 / 摘要 这题本质是“k 路归并”。如果直接一条条串行并入，性能会退化；用分治按二叉树方式两两合并，能把复杂度优化到 O(N log k)。本文按 ACERS 模板把思路推导、工程映射和多语言实现一次讲透。 预计阅读时长：12~16 分钟 标签：Hot100、链表、分治、归并 SEO 关键词：Merge k Sorted Lists, 合并K个升序链表, 分治归并, LeetCode 23, O(N log k) 元描述：从串行归并到分治归并，系统讲解 LeetCode 23 的最优复杂度解法与工程实践。 目标读者 正在刷 Hot100，已经掌握 LeetCode 21 的同学 想把“双链表归并”升级为“k 路归并模板”的开发者 在服务端做多路有序流合并（日志、时间线、分片结果）的工程师 背景 / 动机 LeetCode 23 是 LeetCode 21 的自然升级版： 21：2 路归并 23：k 路归并 核心挑战不在“能不能合并”，而在“如何把复杂度控制在可接受范围”。 如果每次把结果链表继续和下一条链表做串行归并，早期节点会被反复遍历，实际性能很容易退化。 核心概念 N：所有链表节点总数 k：链表条数 串行归并：从左到右不断把当前结果和下一条链表合并 分治归并：像归并排序一样，两两合并，按层收敛 最小堆方案：维护 k 个当前头节点，每次弹出最小值并推进其所在链表 A — Algorithm（题目与算法） 题目还原 给你一个链表数组 lists，每个链表都按升序排列。 请将所有链表合并到一个升序链表中，并返回合并后的头节点。 输入输出 名称 类型 描述 lists ListNode[] k 条升序链表，元素可为空 返回 ListNode 合并后的升序链表头节点 示例 1 输入: lists = [[1,4,5],[1,3,4],[2,6]] 输出: [1,1,2,3,4,4,5,6] 示例 2 输入: lists = [] 输出: [] C — Concepts（核心思想） 思路推导：从朴素到最优 朴素法 A：拉平到数组后排序 ...

副标题 / 摘要 LeetCode 25 是“整链反转（206）”与“区间反转（92）”的组合升级：你要按组切分、组内反转、组间拼接，并正确处理不足 k 的尾组。本文用 ACERS 模板给出工程可复用解法。 预计阅读时长：14~18 分钟 标签：Hot100、链表、分组反转、哑节点 SEO 关键词：Reverse Nodes in k-Group, K 个一组翻转链表, 分组反转, LeetCode 25, Hot100 元描述：K 组链表原地反转模板：分组扫描 + 区间反转 + 安全拼接，含复杂度分析、常见坑与多语言代码。 目标读者 已掌握 206 / 92，希望攻克“多区间连续反转”的 Hot100 学习者 链表题常在边界和拼接步骤出错的中级开发者 需要构建稳定“链表分段处理”模板的工程师 背景 / 动机 在工程里，链式结构的批处理并不少见： 任务链按固定批次重排执行 流水线节点按批回滚或重放 数据清洗链表按批次做原地变换 这类场景的核心诉求是： 组内变换（例如反转） 组间保持顺序 尾部残组按规则保留（不足 k 不反转） LeetCode 25 正是这个能力的典型建模。 核心概念 哑节点（dummy）：统一处理头节点参与反转的场景 组前驱（groupPrev）：指向当前组前一个节点 组尾探针（kth）：从 groupPrev 出发找第 k 个节点，判断是否够一组 组后继（groupNext）：当前组反转后要接回的后半链头 组内原地反转：只反转 [groupStart, kth] 区间 A — Algorithm（题目与算法） 题目还原 给你链表头节点 head 和整数 k，每 k 个节点一组进行翻转，返回修改后的链表。 若剩余节点数不足 k，则保持原顺序不变。 要求只能改节点指针，不允许只改节点值。 ...

副标题 / 摘要 反转链表 II 的关键不在“会反转”，而在“只反转中间一段且不破坏两端连接”。本文用 ACERS 结构讲清哑节点定位、头插法重排与边界处理，给出可复用模板与多语言代码。 预计阅读时长：12~15 分钟 标签：链表、区间反转、哑节点 SEO 关键词：Reverse Linked List II, 反转链表 II, 区间反转, 哑节点, 头插法, LeetCode 92 元描述：单链表区间反转的工程化模板：哑节点 + 头插法，O(n)/O(1)，附推导、常见坑与多语言实现。 目标读者 已会 206 反转链表，想进一步掌握“局部反转”的同学 经常在链表题里卡边界（left=1、right=n）的中级开发者 希望把链表指针操作做成稳定模板的工程师 背景 / 动机 Reverse Linked List（206）是“整条反转”，而 92 要求“只反转一个闭区间”。 这类“局部重排”在工程里非常常见： 任务链中的某个分段要逆序重放 事件日志只对一段做回滚重连 数据结构需要在不重建节点的前提下原地调整 难点并非复杂算法，而是： 找准区间前驱与区间首节点 反转过程中不丢失后续链路 区间反转后把前后两端重新接回去 核心概念 哑节点（dummy）：统一处理 left = 1 场景，避免头节点特判地狱 前驱指针 prev：最终停在第 left-1 个节点（若 left=1 则停在 dummy） 当前指针 cur：初始为区间首节点 prev.next 头插法（head insertion）：每次把 cur 后面的一个节点摘下，插到 prev 后面 A — Algorithm（题目与算法） 题目还原 给你单链表的头节点 head 和两个整数 left、right（1 <= left <= right <= n）， 请你反转从位置 left 到位置 right 的链表节点，返回反转后的链表。 ...

副标题 / 摘要 很多人第一次问 .dao 都会卡在同一个问题：为什么能看到 .dao 名字，却在传统域名平台买不到？本文把历史体系、当前可行路径和工程决策一次讲清，并给出可执行的选择建议。 目标读者 准备做 DAO / Web3 社区品牌命名的团队 想提前占名字（品牌保护、投资、收藏）的人 需要同时兼顾 Web2 用户可访问性和 Web3 身份系统的开发者 背景 / 动机 域名后缀看起来只是一个“字符串后缀”，但背后其实是两套完全不同的体系： 传统 DNS（ICANN 体系） 去中心化命名（ENS / Handshake 等） .dao 的争议，本质是“你要的是哪套体系里的所有权与可访问性”。 如果这个问题没想清楚，常见后果是： 花钱买了一个“看起来像 .dao”的名字，但普通用户根本打不开 只做了 Web3 名称，结果官网访问体验断层 把子域名当作顶级域名，长期品牌资产受制于平台 核心概念（先统一术语） TLD（顶级域名）：如 .com、.org、.cn gTLD：通用顶级域名（如 .com、.net） ccTLD：国家/地区顶级域名（如 .cn、.jp） New gTLD：2012 年后新增大量后缀（如 .xyz、.app、.ai） ENS 名称：以 .eth 结尾的链上名称系统（如 mydao.eth） 子域名：如 xxx.dao.xyz，本质依赖父域名持有方 一、域名后缀是怎么来的？ 在传统互联网里，顶级后缀需要通过 ICANN 体系审批并由注册局运营。 这意味着“一个后缀能否成为主流浏览器原生可访问的顶级域名”，不是随便命名就能生效。 常见分类： 传统 gTLD：.com、.org、.net 国家域名 ccTLD：.cn、.jp 等 新通用域名 New gTLD：.xyz、.club、.app、.ai 等 二、.dao 的现实状态 截至目前的常见实践，.dao 不是 ICANN 体系里的主流正式顶级域名。 因此你通常无法在主流传统注册商直接买到“标准 DNS 意义下的 .dao 顶级域名”。 ...

这是一页“图算法专题导航”。目标不是把文章堆在一起，而是给你一条从基础遍历到分布式图计算的可执行学习路径。 目录现状（已完成专题化） 图算法系列已迁移到： content/zh/dev/algorithm/graph/ 并采用两位数字前缀（00/10/20...）做阅读顺序标识，方便： 文件系统内按顺序浏览 后续增量插入新文章（可保留编号间隔） 批量维护时快速定位阶段 推荐阅读顺序（按能力建设） 第 0 阶段：遍历基本功（先打地基） BFS / DFS 工程入门：k-hop 查询、子图抽取与路径可达性 最短路径实战：BFS、Dijkstra、A* 的工程化选型 目标： 能稳定写出迭代版图遍历； 能解释什么时候用 BFS、什么时候用 Dijkstra/A*； 习惯加 early stop、visited、预算限制。 第 1 阶段：可达性与连通结构（图查询核心） k-hop 与可达性查询：BFS 限制、Reachability 索引与 2-hop Labeling Connected Components 与 SCC：Tarjan / Kosaraju 目标： 把“能不能到达”从一次搜索升级成系统能力； 理解无向连通与有向强连通是两类不同问题； 建立“在线 BFS + 离线索引”的组合思维。 第 2 阶段：图分析指标（从可达走向洞察） 图中心性：Degree / Betweenness / Closeness PageRank / Personalized PageRank：节点重要性与增量更新 目标： 能解释“重要性”的不同定义与适用边界； 能把中心性与 PageRank 用在推荐/风控/影响力分析； 理解“指标正确”和“平台能跑”是两回事。 第 3 阶段：结构挖掘与匹配（应用层能力） 子图匹配：VF2、Ullmann 与剪枝 社区发现：Louvain 与 Label Propagation 目标： ...

系统讲解 Pregel（BSP）与 GAS（Gather-Apply-Scatter）两大图计算模型，重点落到 PageRank、Connected Components 和并行 BFS 的执行路径、收敛策略与工程取舍。

从 Edge-cut/Vertex-cut 目标函数出发，系统讲解 METIS 多层分区思想与工程落地，重点解释分区如何影响查询延迟和跨机通信量。

副标题 / 摘要 动态图场景里，真正的痛点不是“会不会算法”，而是“更新来了能不能顶住”。本文按 ACERS 模板讲透三件工程必修：增量最短路径、增量 PageRank、连通性维护，以及三条现实策略：局部重算、延迟更新、近似结果。 预计阅读时长：14~18 分钟 标签：动态图、增量计算、最短路径、PageRank、连通性维护 SEO 关键词：动态图, 增量最短路径, 增量 PageRank, 连通性维护, 局部重算, 延迟更新, 近似结果 元描述：动态图工程指南：在高频更新场景下如何用增量算法与工程策略控制时延和成本。 目标读者 做图数据库、关系图、推荐图在线服务的工程师 从离线图计算转向实时增量计算的开发者 想把“全量重算”改造成“可上线更新流水线”的技术负责人 背景 / 动机 静态图算法在论文里很优雅，但真实系统里图是不断变化的： 用户关系新增/删除 交易边持续流入 内容图和知识图谱持续更新 工程上 80% 的痛点就在这里： 全量重算太慢，赶不上更新速率 在线强一致代价太高，P99 失控 业务只要“可用近似”，却在做“昂贵精确” 所以核心问题变成： 不是怎么把答案算出来，而是怎么在更新流下持续算得动。 核心概念 概念 含义 工程关注点 增量最短路径 边/点更新后只修复受影响区域 影响域检测、局部重算 增量 PageRank 图更新后迭代残差局部传播 残差阈值、批量窗口 连通性维护 动态维护是否连通/分量变化 插入快、删除难 局部重算 只对受影响子图重新计算 降低 CPU/内存 延迟更新 把更新合并成批次统一处理 吞吐优先、可控延迟 近似结果 用误差边界换计算成本 SLA 与精度平衡 A — Algorithm（题目与算法） 题目还原（工程化） 给定一个持续更新的图 G_t=(V_t,E_t) 和操作流： ...