副标题 / 摘要 社区发现不是“把图分几堆”这么简单，而是要在准确性、可解释性、速度和可维护性之间做平衡。本文按 ACERS 结构拆解两种工程最常见算法：Louvain（模块度优化） 与 Label Propagation（标签传播）。 预计阅读时长：12~16 分钟 标签：社区发现、Louvain、Label Propagation、图分区 SEO 关键词：community detection, Louvain, Label Propagation, modularity, graph partition 元描述：社区发现工程入门：Louvain 与 LPA 的原理、复杂度、选型与落地模板，覆盖群体识别、图分区、冷启动分析。 目标读者 做社交图、风控图、推荐系统图分析的工程师 想把“社区发现”从论文概念落到生产实践的开发者 需要在“图分区/冷启动”场景做群体结构建模的人 背景 / 动机 社区发现在工程里很常见： 群体识别：识别强关联账号簇、异常团伙、兴趣圈层 图分区：把高连通子图放在同一分片，减少跨分片通信 冷启动分析：新用户/新实体通过邻域社区快速归类 痛点在于： 全局最优通常不可得（NP-hard 相关目标） 数据规模大、更新快，离线算法难以频繁重跑 不同业务对“稳定性/速度/解释性”优先级不同 所以工程上最常见的两类方法是： Louvain：追求较高质量社区（模块度） Label Propagation (LPA)：追求速度与简单实现 核心概念 概念 含义 工程影响 Community 内部边密、外部边疏的节点集合 影响分区与推荐质量 Modularity(Q) 度量社区划分质量的指标 Louvain 优化目标 Label Propagation 节点迭代采用邻居主流标签 速度快、结果有随机性 Graph Partition 按社区切分存储/计算 降低跨机通信成本 Cold Start 用邻域结构给新节点快速归群 提升启动期召回 A — Algorithm（题目与算法） 题目还原（工程抽象版） 给定无向图 G=(V,E)，输出每个节点所属社区 ID，并支持以下用途： ...

副标题 / 摘要 子图匹配是图查询里的硬骨头：理论上 NP-hard，但工程里并不是“只能慢”。本文按 ACERS 模板讲清 VF2 / Ullmann 的核心思路，并把重点放在真正决定性能的地方：候选生成与剪枝策略。 预计阅读时长：15~20 分钟 标签：子图匹配、VF2、Ullmann、图数据库 SEO 关键词：Subgraph Isomorphism, VF2, Ullmann, candidate pruning, 图模式匹配 元描述：从 NP-hard 的子图同构问题出发，解释 VF2/Ullmann 机制与工程剪枝实践，覆盖图数据库常见受限模式查询。 目标读者 需要在图数据库做模式查询、规则检测、风险关系识别的工程师 已掌握 BFS/DFS/连通分量，希望进阶图匹配能力的开发者 需要在“可解释规则匹配”与“性能约束”之间做权衡的算法同学 背景 / 动机 你在图数据库里会经常遇到这种需求： 找出“一个人-两家公司-同一设备”的可疑结构 找出“作者-论文-机构”的特定模式 找出“交易链中的环形洗钱模板” 这类查询本质是 Subgraph Isomorphism（子图同构）： 给模式图 Q，在数据图 G 中找结构与约束都满足的嵌入映射。 理论上它是 NP-hard，意味着最坏情况很难避免指数爆炸。 但工程上大多数查询是受限模式（有标签、有方向、有属性、有小模式规模），因此性能核心变成： 先把候选压到很小，再做匹配搜索。 核心概念 Subgraph Isomorphism：模式图节点到数据图节点的单射映射，保边关系成立 受限模式（constrained pattern）：标签、方向、度数、属性谓词限制 候选集（candidate set）：每个模式节点可能映射到的数据节点集合 剪枝（pruning）：在搜索树早期排除不可能映射，减少回溯分支 VF2：基于状态扩展与可行性检查的深度优先匹配框架 Ullmann：基于候选矩阵与邻域一致性迭代收缩的经典方法 A — Algorithm（题目与算法） 题目还原（工程化） 给定： 数据图 G=(V_G,E_G)（通常很大） 模式图 Q=(V_Q,E_Q)（通常较小） 节点/边约束（标签、方向、属性谓词） 目标： ...

副标题 / 摘要 中心性不是论文概念，而是图系统里的“节点重要性排序器”。本文按 ACERS 结构讲透 Degree / Betweenness / Closeness，并给出一条务实结论：线上大多数系统只稳定支持 Degree + 近似 Betweenness。 预计阅读时长：12~16 分钟 标签：图论、中心性、Degree、Betweenness、Closeness SEO 关键词：图中心性, Degree Centrality, Betweenness, Closeness, 近似 Betweenness 元描述：图中心性工程指南：三大指标定义、复杂度、近似算法与落地策略，附可运行代码。 目标读者 做关系图分析、知识图谱、图数据库查询优化的工程师 需要把“节点重要性”从概念变成上线指标的开发者 想知道为何 Betweenness 工程上昂贵、如何做近似替代的同学 背景 / 动机 你在图系统里迟早会遇到这类问题： 哪些节点是“社交大 V”或“交易枢纽”？ 哪些节点是关键桥梁，断开就会让图显著分裂？ 哪些节点整体上离其他节点更近，适合作为入口/缓存热点？ 对应到中心性指标： Degree Centrality：连接数多不多（本地重要性） Betweenness Centrality：是否位于大量最短路径中（桥梁重要性） Closeness Centrality：到全图平均距离是否更短（全局接近性） 现实里最大的坑不是“不会定义”，而是“算不动”： Degree 非常便宜，几乎所有系统都能实时支持 Betweenness 精确计算很贵，通常只能离线或近似 Closeness 需要大量最短路，图一大就难在线 核心概念 1) Degree Centrality 无向图中节点 v 的度中心性常写为： C_D(v) = deg(v) / (n - 1) 含义：节点局部连接活跃度。 ...

副标题 / 摘要 连通性告诉你“图怎么分块”，而 PageRank 告诉你“块里谁更重要”。这正是图数据库区别于关系数据库的关键能力之一：不仅能做连接，还能做结构化重要性传播。本文按 ACERS 结构讲清 PageRank / PPR 的算法原理与工程落地。 预计阅读时长：15~20 分钟 标签：PageRank、PPR、图数据库、稀疏矩阵 SEO 关键词：PageRank, Personalized PageRank, 稀疏矩阵, 增量更新, 图数据库 元描述：从经典 PageRank 到 Personalized PageRank，覆盖迭代计算、稀疏矩阵优化与增量更新策略，并给出多语言可运行实现。 目标读者 需要在图数据库做排序、推荐、影响力分析的工程师 已掌握 BFS/DFS/连通分量，想进阶“图上评分”方法的开发者 关注大图线上迭代性能与更新延迟的算法工程师 背景 / 动机 你前面已经把图分成了连通分量和 SCC，但工程里还有一个更难的问题： 同一个分量里，谁更关键？ 给定一个用户或种子节点，谁与它“结构上更相关”？ 这就是 PageRank / Personalized PageRank（PPR） 的职责。 这也是图数据库和关系数据库的关键差异之一： 关系数据库强在 Join 与过滤（行/列视角） 图数据库强在拓扑传播（边结构视角） PageRank 本质是“在图上做概率质量传播”，它把局部连边和全局结构合成一个可排序分值。 核心概念 PageRank：全局重要性分数，和入链质量相关，不仅是入度多少 Personalized PageRank（PPR）：在随机游走中偏向某个种子集合，得到“个性化重要性” 阻尼系数 d/alpha：控制继续沿边游走还是回到随机跳转/种子分布 稀疏矩阵：大图邻接矩阵极稀疏，必须用 CSR/CSC 或邻接表实现乘法 增量更新：图边/节点变化后，尽量局部修正而非全量重算 A — Algorithm（题目与算法） 题目还原（工程化） 给定有向图 G=(V,E)，计算每个节点的重要性分数： PageRank：输出全图统一重要性 PPR：给定种子分布 s，输出相对该种子的个性化重要性 输入输出 名称 类型 描述 n int 节点数量 edges List[(u,v)] 有向边 u -> v d / alpha float 阻尼系数，通常 0.85 左右 s vector PPR 的种子分布（和为 1） 返回 vector 每个节点的 rank 分数 示例 1（PageRank） n = 4 edges = [(0,1),(1,2),(2,0),(2,3)] 输出: rank[0..3] 特点: 0/1/2 构成循环，3 只入不出，分数受结构影响而非简单入度 示例 2（PPR） 同上图，种子节点设为 2（s[2]=1） 输出: ppr[0..3] 特点: 与节点 2 路径近、可达性强的节点得分更高 思路推导（从朴素到可用） 朴素想法 1：按入度排序 问题： ...

围绕 k-hop 与可达性查询，讲清 BFS+hop 限制、传递闭包取舍、以及位图索引/2-hop labeling 的工程落地路径。

副标题 / 摘要 连通分量是图算法的基础地基：无向图关注“是否连在一起”，有向图关注“是否互相可达”。本文按 ACERS 模板，从朴素做法推导到 Tarjan / Kosaraju，并给出图数据库落地场景与多语言可运行实现。 预计阅读时长：14~18 分钟 标签：图论、连通分量、SCC、Tarjan SEO 关键词：Connected Components, SCC, Tarjan, Kosaraju, 图数据库 元描述：从无向连通分量到有向强连通分量，讲清 Tarjan/Kosaraju 的核心机制、复杂度和工程落地。 目标读者 需要把 BFS/DFS 用到“滚瓜烂熟”的算法学习者 在图数据库场景做子图分析、分片规划的工程师 想建立“无向 CC + 有向 SCC”统一认知框架的中级开发者 背景 / 动机 工程里你会很快遇到这三类问题： 这批节点是否天然分成多个互不相连的群？（无向图连通分量） 哪些节点形成“互相可达”的强闭环？（有向图 SCC） 如何把大图切成更可并行、更易缓存、更易分片的子图？ 如果只会 BFS/DFS 但不会“分量视角”，你会反复做可达性查询，成本高且难维护。 连通分量算法的价值是：一次全图扫描，把局部查询变成 O(1) 的分量 ID 比较。 核心概念 Connected Components（CC）：无向图中，任意两点都可达的最大节点集合 Strongly Connected Components（SCC）：有向图中，任意两点互相可达的最大节点集合 Condensation DAG（缩点图）：把每个 SCC 缩成一个点后得到的有向无环图 Tarjan 核心状态：dfn[u]（时间戳），low[u]（可回溯到的最小时间戳），栈与 in_stack Kosaraju 核心流程：原图按完成时序排序 + 反图二次 DFS A — Algorithm（题目与算法） 题目还原（工程化表述） 给定一个图 G=(V,E)： ...

副标题 / 摘要 最短路径不是一道题，而是一组“按图条件选算法”的工程能力。本文按 ACERS 结构拆解 BFS（无权）/ Dijkstra（非负权）/ A（启发式）*，并给出你在关系图、推荐链路、路径解释里真正会用到的优化模板。 预计阅读时长：14~18 分钟 标签：图论、最短路径、BFS、Dijkstra、A* SEO 关键词：最短路径, BFS, Dijkstra, A*, 双向搜索, 多源 BFS 元描述：最短路径三件套工程指南：算法边界、复杂度、可运行代码、优化策略与实战场景。 目标读者 正在补图算法基础，希望形成可复用工程模板的学习者 做社交关系链路、推荐路径、图查询解释的后端/算法工程师 对 BFS、Dijkstra、A* 都“知道名字”，但选型和优化还不稳定的开发者 背景 / 动机 最短路径问题常见于： 社交网络里的最短关系链路（几跳可达） 推荐系统里的最小代价路径（多目标折中） 可解释系统里的“为什么推荐给你”路径展示 工程里最容易犯的错误是“只会一个算法硬套全部场景”： 用 BFS 跑加权图，结果错但不报错 用 Dijkstra 跑负权边，得到不可靠结果 用 A* 但启发函数不合格，性能退化成 Dijkstra 本质上，最短路径应先做 图条件分类，再做算法选型。 核心概念 算法 适用图 最优性条件 典型复杂度 关键词 BFS 无权图 / 等权图 按层首次到达即最短边数 O(V+E) queue, level Dijkstra 非负权图 堆顶弹出的节点距离已最优 O((V+E)logV) relaxation, min-heap A* 非负权图 + 启发式 h(n) 可采纳（不高估） 最坏同 Dijkstra，平均更快 f=g+h 关键公式： ...

副标题 / 摘要 BFS / DFS 不是“会写就行”，而是要到工程可用、可控成本、可证明正确。本文按 ACERS 模板，把最常用的三类任务（k-hop 查询、子图抽取、路径可达性）拆成可复用模板：迭代实现 + early stop + visited 结构选型。 预计阅读时长：12~16 分钟 标签：图、BFS、DFS、k-hop、子图抽取 SEO 关键词：BFS, DFS, k-hop 查询, 子图抽取, 路径可达性, visited bitmap, bloom filter 元描述：面向工程场景讲解 BFS/DFS：迭代版避免栈溢出、early stop 降低搜索成本、visited bitmap/bloom 优化内存与判重性能。 目标读者 正在做图数据库、风控关系图、调用链分析的工程师 只会“题解式 BFS/DFS”，但还没形成工程模板的同学 希望把图遍历写成“稳定、可观测、可扩展”代码的人 背景 / 动机 在工程里，BFS/DFS 通常不是一次性离线脚本，而是在线请求的一部分： k-hop 邻域查询要控制时延 子图抽取要控制内存与输出规模 路径可达性要快速返回 true/false 如果只停留在教科书递归模板，会很快踩坑： 深图导致递归栈溢出 无剪枝导致无谓扩展 visited 结构选错，内存和吞吐同时恶化 所以这篇文章聚焦一个目标： 把 BFS / DFS 升级到“滚瓜烂熟且能上线”的程度。 核心概念 概念 作用 工程关注点 BFS（队列） 按层扩展、天然支持 hop 层级 适合 k-hop、最短边数、层级子图 DFS（栈） 深入探索、路径存在性高效 适合快速可达性判断与深度剪枝 early stop 提前终止搜索 控制 P99 延迟和资源消耗 visited bitmap 精确判重，内存紧凑 需先做节点 ID 压缩 bloom filter 概率判重/预过滤 有假阳性，不能单独用于“严格正确性”场景 A — Algorithm（题目与算法） 题目还原（LeetCode 风格训练题） 给定一个无权图 G（邻接表），起点 s，最大跳数 K，可选目标点 t： ...

副标题 / 摘要 你不需要“每个 commit 都手打重写”，但必须对核心 commit 具备独立实现能力。本文给出一套可落地的 AI 协作流程：让 AI 负责胶水和草稿，你负责领域规则、状态变化与边界裁决。 目标读者 正在大量使用 AI 写代码，但担心自己变成“黑盒工程师”的开发者 想同时提升交付效率和技术判断力的工程师 在做 DDD、业务系统或中后台项目的开发者 背景 / 动机 AI 代码生成越来越强，这不是坏事。真正的风险在于：当你只会“接收实现”，却不能解释“为何这样实现”，系统一复杂就失去控制权。 问题不是“要不要用 AI”，而是“哪些决策必须留在人手里”。 核心概念 责任主线（main）：只保留你愿意为其设计与后果负责的 commit。 AI 草稿（ai/draft-*）：一次性候选实现分支，用于对照、压力测试与发现盲区。 git worktree：在不二次 clone 的前提下，为不同分支创建多个物理目录（一个仓库，多处并行）。 核心 commit：包含领域规则、不变量、状态机、关键边界与失败路径的提交。 胶水 commit：CRUD、DTO、映射、样板接口、注释等可标准化提交。 硬核评价标准：去掉 AI 和网络，你仍能写出该 commit 的核心伪代码，并解释每一步为什么这么做。 实践指南 / 步骤 先分层，再决定谁写 把需求拆成 Domain / Application / Infrastructure。 Domain 核心规则优先自己实现；Infrastructure 优先交给 AI。 先写判断标准，再看 AI 方案 先写不变量、边界条件、错误路径、伪代码或测试，再生成 AI 草稿。 先有你的“尺子”，再拿 AI 代码来量。 为每轮任务创建短生命周期草稿分支 从当前 main 派生 ai/draft-<topic>，让 AI 快速给出候选实现。 草稿分支只做提议，不做长期维护。 ...

副标题 / 摘要 “路径不必从根开始、但必须向下”使得这题无法用简单的根到叶 DP 解决。本文用 ACERS 结构讲透 树上前缀和：把任意向下路径转化为“两个前缀和的差”，用哈希表在线计数，做到 O(n) 一次 DFS 统计所有答案。 预计阅读时长：12~15 分钟 标签：Hot100、二叉树、前缀和、DFS、哈希表 SEO 关键词：Path Sum III, 路径和 III, 树上前缀和, 前缀和哈希, LeetCode 437, Hot100 元描述：前缀和 + 哈希表在线统计二叉树向下路径和等于 targetSum 的条数，包含推导、复杂度对比与多语言实现。 目标读者 刷 LeetCode、希望把“树 + 哈希”题型沉淀成模板的学习者 对“路径不从根开始”的树题容易写成 O(n^2) 的同学 做日志调用链 / 层级数据分析，需要在树结构上做区间统计的工程师 背景 / 动机 很多“树上的路径问题”都有一个坑： 你以为要从根出发、或要到叶子结束，但题目允许 从任意节点开始、到任意节点结束（但方向必须向下）。 这意味着： 你不能只维护“从根到当前”的一种状态就完事； 也不能枚举所有起点（那会退化成 O(n^2)）； 更不能用滑动窗口（节点值可正可负，窗口单调性不存在）。 这题最值得掌握的点是：把“树上任意向下路径”化为“同一路径上的两个前缀和之差”。 一旦你掌握了这个模型，很多树上统计题都会变成“前缀和 + 哈希表”的熟悉配方。 核心概念 向下路径：只能从父到子（不能回头、不能跨分支） 前缀和（prefix sum）：从根到当前节点路径上所有节点值的累加 差分计数：若 curSum - prevSum = target，则 prevSum = curSum - target 路径内哈希表：只统计“当前 DFS 路径上的前缀和”，回溯时必须撤销（否则会把不同分支混在一起） A — Algorithm（题目与算法） 题目还原 给定一个二叉树的根节点 root 和整数 targetSum，求二叉树里 节点值之和等于 targetSum 的向下路径 的数目。 路径不需要从根节点开始，也不需要在叶子节点结束，但路径方向必须向下（只能从父节点到子节点）。 ...