NetworkX不直接连接图数据库，需先导出数据再离线计算；从Neo4j导出需规整为(source,target,weight)结构并用nx.from_pandas_edgelist构建图；调优betweenness_centralit需设normalized=False、endpoints=False或k采样；Louvain应使用networkx.algorithms.community.louvain_communities而非旧版best_partition。
NetworkX 本身不对接图数据库，它只处理内存中的图结构；想用图数据库（如 Neo4j、Nebula、TigerGraph）做社交网络分析，得先导出数据，再用 NetworkX 做离线计算——这是最常见也最务实的做法。
从 Neo4j 导出边列表到 NetworkX
Neo4j 的 Cypher 查询结果是节点/关系流，不能直接喂给 nx.Graph()。你需要把它规整成 (source, target) 或 (source, target, weight) 的二维结构。
- 用
neo4j.Driver执行查询，例如：MATCH (a)-[r:FRIEND]->(b) RETURN a.id AS source, b.id AS target, r.weight AS weight - 结果用
pandas.DataFrame接住，确保列名是source、target（加权时还有weight） - 调用
nx.from_pandas_edgelist(df, 'source', 'target', edge_attr='weight')构建图；注意：如果边是无向的，记得传create_using=nx.Graph()，否则默认是nx.DiGraph() - 别忽略 ID 类型：若 Neo4j 返回的是字符串 ID（比如
"user_123"），而你的后续逻辑假设是 int，这里会静默失败或报KeyError
nx.betweenness_centrality 计算慢？关掉 normalized 和 endpoints
对千级节点以上的图，默认参数会让 nx.betweenness_centrality 变成性能瓶颈。它内部要算所有点对最短路径，O(n·m) 复杂度。
- 设
normalized=False：跳过除以理论最大值的归一化步骤，结果仍是可比的相对值，但快 3–5 倍 - 设
endpoints=False（默认值）：不把端点计入路径计数，符合多数社交场景直觉；设为True会显著拖慢 - 小规模验证时可用
k=100参数随机采样 100 个源节点近似计算，适合快速探查 - 若图含孤立节点，
betweenness_centrality会给它们返回 0.0 —— 这不是 bug，是定义使然，但容易误以为“没算出来”
Louvain 社区发现必须用 networkx.algorithms.community.louvain_communities
旧教程里常写 community.best_partition，那是第三方库 python-louvain 的 API，和 NetworkX 2.8+ 内置的不兼容，混用会报 AttributeError: module 'networkx.algorithms.community' has no attribute 'best_partition'。
立即学习“Python免费学习笔记（深入）”；
- 正确导入是：
from networkx.algorithms.community import louvain_communities - 调用示例：
communities = louvain_communities(G, seed=42, resolution=1.0)；resolution>1.0 倾向切出更多小社区， - 返回的是 frozenset 构成的 list，不能直接索引或修改；要转成 list of list 可写：
[list(c) for c in communities] - 该函数不支持有向图，传入
nx.DiGraph会静默转成无向处理——如果你真需要有向社区（如信息流方向），得换directed_louvain等扩展库
真正卡住人的地方往往不在算法本身，而在数据进出的一致性：Neo4j 的 ID 类型、pandas 的列名拼写、NetworkX 对有向/无向的默认假设——这些细节不核对清楚，跑出来的中心性数值或社区划分就不可信。
