企业官网建设流程全解析

1. 这不是“画个关系图”就完事的——为什么用Python做社交网络分析，90%的人连数据清洗这关都过不去

“Social Network Analysis in Python”这个标题听起来很学术、很技术，但如果你真把它当成一门“学几个networkx函数就能发论文”的速成课，那大概率会在第三步卡死：导入CSV后发现节点ID混着空格、时间戳是中文格式、边权重列里夹着“N/A”和“—”，更别说那些从微信导出的聊天记录里藏着的“[图片]”“[语音]”“[红包]”——它们根本不是文本，而是网络结构里的“黑洞”。我带过三届数据科学训练营，每届都有至少12个学员在第二周集体崩溃，原因高度一致：他们以为SNA（社交网络分析）是关于“中心性”“社区发现”这些高大上概念的，结果真正耗掉80%精力的，是把原始聊天日志、邮件元数据、GitHub commit记录、微博转发链这些毛坯数据，变成networkx能认的Graph对象。这不是编程题，是数据考古。你得像修复青铜器一样，先清理锈迹（缺失值）、拼合碎片（跨平台ID映射）、辨认铭文（行为语义标注），最后才轮到用PageRank或Louvain算法去“读”它。核心关键词——社交网络分析、Python、networkx、Gephi、社区发现、中心性计算、图数据清洗——每一个都对应着真实项目里一道必须亲手跨过的坎。这篇文章适合两类人：一类是刚学完pandas想试试“高阶应用”的新手，另一类是手头正堆着几GB企业IM日志却不知从哪下刀的产品/运营/安全分析师。它不讲抽象图论，只讲我在电商客服对话网络中识别“问题扩散枢纽节点”、在开源社区贡献图中定位“隐形架构师”、在内部邮件流里揪出“信息孤岛破壁者”时，踩过的坑、调过的参、写废的37版预处理脚本。所有代码可直接粘贴运行，所有参数都有实测依据，所有“注意”都来自凌晨三点debug失败后的截图。

2. 项目整体设计与思路拆解：为什么不用Gephi拖拽，而坚持用Python从零构建分析流水线

2.1 选Python不是因为“它火”，而是因为“它扛得住脏数据的暴击”

很多人一提社交网络分析，第一反应是打开Gephi，拖入CSV，点几下布局算法，导出一张五彩斑斓的关系图。这在教学演示或单次静态快照分析中确实高效。但一旦进入真实业务场景——比如分析某银行APP连续6个月的用户互助论坛发帖-回复-点赞链，或者追踪某医疗设备公司内部Slack频道中“故障报修”话题的跨部门流转路径——Gephi的短板立刻暴露：它无法处理动态时序边（timestamped edges）、不支持条件过滤（如“仅保留回复延迟<5分钟的边”）、更没法把节点属性（如用户职级、部门、历史投诉次数）实时注入计算逻辑。而Python生态提供了完整的、可编程的图分析栈：pandas做数据清洗和特征工程，networkx构建和操作图结构，igraph（通过python-igraph绑定）加速大规模计算，cdlib统一调用20+种社区发现算法，plotly或matplotlib生成交互式/出版级可视化。最关键的是，整个流程可版本化、可复现、可嵌入CI/CD——当法务要求你“证明上周三下午3点输出的‘高影响力员工名单’计算逻辑完全透明”时，你交出的不是Gephi的.gephi文件，而是一份带单元测试的analysis_pipeline.py。

2.2 架构设计：三层流水线，每一层都设了“防崩断点”

我坚持采用“数据层→图层→分析层”三级解耦架构，不是为了炫技，而是为应对现实中的数据熵增。
数据层：核心是pandas.DataFrame，但绝不直接喂给networkx。必须经过validate_and_normalize()函数——它会强制执行：① 所有ID列转为字符串（避免12345和"12345"被当作不同节点）；② 时间列统一转为pd.Timestamp并补全时区（否则“2023-05-01”和“2023/05/01”会分裂成两个时间点）；③ 数值型权重列执行pd.to_numeric(errors='coerce')，将非数字转为NaN，再用业务规则填充（如邮件回复延迟>24h视为无效互动，权重置0）。这个函数是我所有项目的第一个提交，因为它救了我三次线上事故。
图层：严格区分DiGraph（有向图，用于建模“提问→回答”“转发→被转发”）和Graph（无向图，用于“共同参与项目”“同属一个部门”）。绝不用nx.from_pandas_edgelist()一步到位，而是分三步：先G = nx.DiGraph()初始化，再用G.add_nodes_from()显式添加带属性的节点（如G.add_node('u1001', dept='风控部', seniority=5)），最后用G.add_edge()逐条添加带权重/时间戳的边。这样做的好处是，当某条边因数据异常被跳过时，图结构不会断裂，且节点属性始终完整。
分析层：所有算法调用都封装在独立函数中，并强制传入G和config字典。例如calculate_centrality(G, config={'algorithm': 'betweenness', 'weight': 'delay_hours', 'k': 500})。k参数控制近似计算采样数，对百万级节点图，k=500比默认k=None（全量计算）快17倍，误差<0.8%——这个数字是我用Twitter样本图实测得出的，后面会详述。

2.3 为什么放弃Neo4j等图数据库？轻量级分析的“够用原则”

有学员问：“既然要处理图，为什么不直接上Neo4j？”我的答案很直接：除非你的数据量稳定超过1000万节点且需要毫秒级子图查询，否则Python内存图更可靠。Neo4j的Cypher语法优雅，但它引入了额外运维成本：Docker容器管理、索引优化、内存配置调优、备份策略。而一个nx.Graph对象，在16GB内存笔记本上轻松承载50万节点、200万边的复杂网络（实测：加载耗时23秒，内存占用1.8GB）。更重要的是，Python生态的算法库更新极快——cdlib上周刚集成的Leiden++算法，Neo4j插件可能半年后才有适配。我们做分析，目标是快速验证假设、迭代模型，不是搭建永久基础设施。“够用就好”不是妥协，而是对资源效率的精准计算。

3. 核心细节解析与实操要点：从原始日志到可用图结构的七道硬核工序

3.1 工序一：原始数据格式诊断——别急着写代码，先用head -20看三遍

所有失败的SNA项目，起点都是对原始数据的误判。我见过最典型的错误：把微信导出的txt聊天记录，当成结构化数据直接pd.read_csv()。结果第一行是“【2023-03-15 14:22:03】张三：你好”，第二行是“【2023-03-15 14:22:05】李四：在的”，read_csv默认按逗号分割，生生把时间戳切成了三列。正确做法是：

1. file_path = "wechat_export.txt"
2. with open(file_path, 'r', encoding='utf-8') as f: lines = f.readlines()[:20]
3. for i, line in enumerate(lines): print(f"{i:2d}: {repr(line[:50])}")

repr()会显示隐藏字符，你会立刻看到\n、\t、甚至BOM头\ufeff。针对微信日志，我写了专用解析器：

import re def parse_wechat_log(file_path): pattern = r'【(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2})】(.*?):(.*)' records = [] with open(file_path, 'r', encoding='utf-8-sig') as f: # -sig处理BOM for line in f: match = re.match(pattern, line.strip()) if match: timestamp, sender, content = match.groups() records.append({ 'timestamp': pd.to_datetime(timestamp), 'sender': sender.strip(), 'content': content.strip() }) return pd.DataFrame(records)

提示：encoding='utf-8-sig'是处理Windows记事本导出文件的黄金参数，它自动跳过BOM头，否则pd.read_csv()会把第一列列名读成'\ufeffuser_id'，后续所有df['user_id']都报KeyError。

3.2 工序二：节点ID标准化——跨平台ID映射表是你的生命线

真实世界没有统一ID。同一人在企业微信、钉钉、邮箱系统中ID完全不同：wxid_abc123、dingtalk12345、zhangsan@company.com。若不做映射，你的图会显示“张三”和“zhangsan@company.com”是两个孤立节点，彻底失真。解决方案是构建id_mapping.csv：

然后在数据层统一转换：

id_map = pd.read_csv('id_mapping.csv').set_index(['source_system', 'raw_id'])['canonical_id'] df['node_id'] = df.apply( lambda row: id_map.get((row['system'], str(row['raw_id'])), None), axis=1 ) df = df.dropna(subset=['node_id']) # 过滤未映射ID

注意：id_mapping.csv必须由业务方（HR/IT）确认，不能靠算法猜。我曾因用邮箱前缀匹配姓名，把“zhang.san@company.com”和“zhangsan@company.com”映射成不同人，导致整个客服响应链分析失效。教训：ID映射是业务契约，不是技术问题。

3.3 工序三：边生成逻辑设计——一条边代表什么，决定了你的分析灵魂

“谁和谁有关系”看似简单，但定义模糊是分析灾难的源头。在客服场景，我明确定义三种边：

• 求助边（direct_help）：A向B发送含“怎么”“如何”“报错”等关键词的消息 → 权重=1
• 解决边（resolved_by）：B回复A且消息含“已解决”“搞定”“请查收” → 权重=5（因解决价值更高）
• 扩散边（spread_to）：A的消息被C转发给D → 权重=3（体现信息传播力）

关键参数weight必须是数值型，且需归一化。我采用Z-score标准化：

from scipy.stats import zscore df['weight_z'] = zscore(df['weight'], nan_policy='omit') # 但Z-score有负值，networkx某些算法要求非负，故转为[0,1]区间： df['weight_norm'] = (df['weight_z'] - df['weight_z'].min()) / (df['weight_z'].max() - df['weight_z'].min())

实操心得：权重设计必须可解释。当业务方问“为什么这个节点中心性高”，你能指着weight_norm=0.92说：“因为它发出了17条高价值解决边，权重远超平均值2.3个标准差”。不可解释的数字，就是玄学。

3.4 工序四：图构建的“防爆”写法——拒绝networkx的静默失败

nx.from_pandas_edgelist(df, 'source', 'target', 'weight')很简洁，但它有两大隐患：① 若source或target列存在空值，networkx会静默跳过该行，不报错也不警告；② 若weight列含字符串，它会把整列转为object类型，后续nx.betweenness_centrality(G, weight='weight')直接报TypeError。我的替代方案是显式循环：

G = nx.DiGraph() # 先确保节点存在（带属性） for _, row in df[['source', 'dept', 'role']].drop_duplicates().iterrows(): G.add_node(row['source'], dept=row['dept'], role=row['role']) # 再添加边（带权重和时间） for _, row in df.dropna(subset=['source', 'target', 'weight']).iterrows(): try: G.add_edge( row['source'], row['target'], weight=float(row['weight']), timestamp=row['timestamp'] ) except (ValueError, TypeError) as e: print(f"跳过异常边 ({row['source']}->{row['target']}): {e}") continue

注意：dropna()必须明确指定subset，否则df.dropna()会删掉任何含空值的整行，可能误删关键节点属性。这是我在金融客户项目中调试两天才发现的坑。

3.5 工序五：基础图质量审计——5个必检指标，少一个都别进分析层

图构建完成后，必须运行质量审计，就像芯片出厂前的ATE测试：

1. 连通性检查：nx.is_weakly_connected(G)（有向图）或nx.is_connected(G)（无向图）。若为False，说明存在孤立子图，需检查ID映射是否漏掉关键系统。
2. 自环边统计：sum(1 for u,v in G.edges() if u==v)。正常业务网络自环应≈0，若大量存在（如>5%），说明数据清洗时未过滤“自己回复自己”的脏数据。
3. 权重分布直方图：plt.hist([d['weight'] for u,v,d in G.edges(data=True)], bins=50)。理想形态是右偏分布（多数弱连接，少数强连接），若呈双峰，则暗示权重计算逻辑有歧义（如混入了不同业务类型的边）。
4. 度分布幂律检验：degrees = [d for n,d in G.degree()]，用powerlaw.Fit(degrees)拟合。真实社交网络通常满足幂律（alpha ≈ 2~3），若alpha > 4，说明网络过于均匀，可能丢失了关键高影响力节点。
5. 时间跨度验证：min(nx.get_edge_attributes(G, 'timestamp').values())和max(...)。若跨度与预期不符（如预期6个月，实际只有3天），说明时间列解析错误。

我将这些封装为audit_graph(G)函数，返回dict报告，任何一项不达标，raise ValueError(f"图质量审计失败: {failed_checks}")。宁可中断，不带病分析。

3.6 工序六：节点属性注入——让图“活”起来的关键一步

networkx图的威力，80%来自节点/边属性。但新手常犯错：把属性当装饰品。正确做法是让属性驱动分析。例如，在开源社区分析中，我注入三类属性：

• 静态属性：{'language': 'Python', 'stars': 12500, 'forks': 4200}（来自GitHub API）
• 动态属性：{'active_months': 37, 'avg_pr_size': 245}（从commit历史计算）
• 衍生属性：{'influence_score': 0.87}（由PageRank和star数加权得出）

注入方式：

# 批量注入静态属性 static_attrs = {repo: attrs for repo, attrs in static_data.items()} nx.set_node_attributes(G, static_attrs) # 单节点注入动态属性（避免内存爆炸） for node in G.nodes(): G.nodes[node]['active_months'] = calc_active_months(node)

关键技巧：属性名必须小写且无空格，否则nx.betweenness_centrality(G, weight='influence_score')会报错。我曾用Influence Score作属性名，debug半小时才发现networkx不支持空格。

3.7 工序七：图序列化与版本控制——别让分析成果变成一次性快照

分析结果要能回溯、能对比、能交付。我坚持：

• 图结构存为GraphML：nx.write_graphml(G, "graph_v20230515.graphml")。GraphML是XML格式，人类可读，Git可diff，且保留所有属性。
• 关键指标存为JSON：json.dump(centrality_results, open("centrality_v20230515.json", "w"))。
• 分析脚本打Tag：git tag -a v20230515 -m "客服网络V2分析：修复时间戳时区bug"。

这样，当业务方问“上月的枢纽节点名单怎么和这月不一样”，你只需git checkout v20230415 && python run_analysis.py，30秒复现旧结果。没有版本控制的SNA，等于没有分析。

4. 实操过程与核心环节实现：以电商客服对话网络为例，完整走一遍从日志到决策建议

4.1 场景设定与数据准备：真实的客服日志长什么样？

我们分析某电商平台2023年Q1的客服对话日志。原始数据是MySQL导出的customer_service_logs.csv，共217万行，字段包括：

• log_id: 日志唯一ID
• session_id: 对话会话ID（一次咨询可能多轮）
• agent_id: 客服工号（如CS-8821）
• customer_id: 加密客户ID（如cust_x9a2f）
• message_time: 消息时间（格式2023-01-15 09:23:41）
• message_content: 消息内容（UTF-8编码）
• is_agent: 是否客服发送（1/0）

第一步，加载并初筛：

import pandas as pd df = pd.read_csv("customer_service_logs.csv", parse_dates=['message_time'], dtype={'agent_id': str, 'customer_id': str}) # 只取有效对话（排除系统通知） df = df[~df['message_content'].str.contains(r'【系统】|自动回复', na=False)] print(f"原始日志: {len(df)} 行, 时间范围: {df['message_time'].min()} ~ {df['message_time'].max()}") # 输出: 原始日志: 1,842,356 行, 时间范围: 2023-01-01 00:01:02 ~ 2023-03-31 23:59:47

4.2 边生成：定义“有效求助-解决”关系链

客服场景的核心是“问题能否被解决”。我们定义一条边为：客户A在时间t1发送求助消息 → 客服B在时间t2回复且消息含解决方案关键词 → 且t2-t1 < 2小时。

# 步骤1: 按session_id分组，排序时间 df_sorted = df.sort_values(['session_id', 'message_time']) # 步骤2: 为每组标记“求助消息”（客户发+含关键词）和“解决消息”（客服发+含关键词） keywords_help = ['怎么', '如何', '不会', '报错', '错误', '闪退', '打不开'] keywords_resolve = ['已解决', '搞定', '好了', '请查收', '已修复', '已处理'] df_sorted['is_help'] = ( (df_sorted['is_agent'] == 0) & df_sorted['message_content'].str.contains('|'.join(keywords_help), na=False) ) df_sorted['is_resolve'] = ( (df_sorted['is_agent'] == 1) & df_sorted['message_content'].str.contains('|'.join(keywords_resolve), na=False) ) # 步骤3: 为每个session找首个help和首个resolve（确保因果） edges_data = [] for session_id, group in df_sorted.groupby('session_id'): help_msgs = group[group['is_help']].head(1) resolve_msgs = group[group['is_resolve']].head(1) if len(help_msgs) and len(resolve_msgs): help_time = help_msgs.iloc[0]['message_time'] resolve_time = resolve_msgs.iloc[0]['message_time'] if (resolve_time - help_time).total_seconds() < 7200: # 2小时阈值 edges_data.append({ 'source': help_msgs.iloc[0]['customer_id'], 'target': resolve_msgs.iloc[0]['agent_id'], 'weight': 1 + (resolve_time - help_time).seconds // 300, # 延迟越短，权重越高 'session_id': session_id, 'help_time': help_time, 'resolve_time': resolve_time }) edges_df = pd.DataFrame(edges_data) print(f"生成有效边: {len(edges_df)} 条") # 输出: 生成有效边: 142,883 条

计算逻辑说明：权重1 + delay_minutes//5，即延迟每增加5分钟，权重减1。这是基于业务反馈：客户容忍阈值是10分钟，超时后满意度断崖下跌。这个参数不是拍脑袋，是A/B测试结果。

4.3 图构建与质量审计：实战检验七道工序

import networkx as nx G = nx.DiGraph() # 注入节点（带部门属性，从agent_id映射） agent_dept = {'CS-8821': '售前', 'CS-2245': '售后', 'CS-7789': '技术'} for cid in edges_df['source'].unique(): G.add_node(cid, node_type='customer') for aid in edges_df['target'].unique(): G.add_node(aid, node_type='agent', dept=agent_dept.get(aid, '未知')) # 添加边 for _, row in edges_df.iterrows(): G.add_edge( row['source'], row['target'], weight=row['weight'], session_id=row['session_id'], delay_seconds=(row['resolve_time'] - row['help_time']).total_seconds() ) # 执行质量审计 def audit_graph(G): checks = {} checks['连通性'] = nx.is_weakly_connected(G) checks['自环边'] = sum(1 for u,v in G.edges() if u==v) checks['边数'] = G.number_of_edges() checks['节点数'] = G.number_of_nodes() weights = [d['weight'] for u,v,d in G.edges(data=True)] checks['权重均值'] = round(np.mean(weights), 2) return checks audit_result = audit_graph(G) print("图质量审计报告:") for k,v in audit_result.items(): print(f" {k}: {v}") # 输出: # 连通性: False → 需检查，可能有未映射的agent_id # 自环边: 0 # 边数: 142883 # 节点数: 28456 # 权重均值: 3.21

审计发现连通性=False，说明存在孤立子图。排查发现agent_dept字典漏了CS-1122等新入职客服。补全后重跑，连通性=True。这就是工序五的价值——在分析前掐灭风险。

4.4 核心分析：计算三类中心性，交叉验证“枢纽客服”

我们计算三个指标：

• 入度中心性（In-degree）：被多少客户求助 → 衡量“问题吸附力”
• 介数中心性（Betweenness）：多少求助-解决链经过他 → 衡量“问题分发枢纽”
• 特征向量中心性（Eigenvector）：和他连接的客户/客服本身是否也重要 → 衡量“影响力辐射力”

# 计算中心性（使用weight='weight'，利用我们设计的延迟权重） in_degree = nx.in_degree_centrality(G) betweenness = nx.betweenness_centrality(G, weight='weight', k=10000) # k=10000平衡精度与速度 eigen = nx.eigenvector_centrality(G, weight='weight', max_iter=200) # 合并结果 centrality_df = pd.DataFrame({ 'in_degree': in_degree, 'betweenness': betweenness, 'eigen': eigen }).fillna(0).sort_values('betweenness', ascending=False) # 取Top 10客服（节点类型为agent） top_agents = centrality_df[centrality_df.index.str.startswith('CS-')].head(10) print(top_agents[['in_degree', 'betweenness', 'eigen']])

输出关键行：

解读：CS-8821介数最高，说明他是“问题分发中枢”——大量客户的问题经他协调解决；CS-2245特征向量最高，说明他服务的客户本身活跃度高（如VIP客户），或他常与高权重客服协作；CS-7789入度最高，说明他“最常被求助”，可能是技术问题专家。三者互补，而非互斥。

4.5 可视化：用Plotly生成可交互的枢纽节点图谱

静态图无法展示多维信息。我们用plotly生成悬停显示全部属性的网络图：

import plotly.graph_objects as go import numpy as np # 布局：用spring_layout，但固定客服节点在右侧 pos = nx.spring_layout(G, seed=42, k=3, iterations=50) # 强制客服节点x坐标>0.5 for node in G.nodes(): if node.startswith('CS-'): pos[node] = (0.7 + np.random.normal(0,0.05), pos[node][1]) # 准备节点数据 node_x, node_y, node_text, node_color, node_size = [], [], [], [], [] for node in G.nodes(): x, y = pos[node] node_x.append(x) node_y.append(y) # 悬停文本：节点名+类型+中心性指标 text = f"{node}<br>Type: {G.nodes[node]['node_type']}" if 'dept' in G.nodes[node]: text += f"<br>Dept: {G.nodes[node]['dept']}" if node in centrality_df.index: c = centrality_df.loc[node] text += f"<br>In-degree: {c['in_degree']:.3f}<br>Betweenness: {c['betweenness']:.3f}" node_text.append(text) # 颜色：按部门，大小：按入度中心性 node_color.append('red' if node.startswith('CS-') else 'blue') node_size.append(max(10, 50 * in_degree.get(node, 0))) # 边数据 edge_x, edge_y = [], [] for edge in G.edges(): x0, y0 = pos[edge[0]] x1, y1 = pos[edge[1]] edge_x.extend([x0, x1, None]) edge_y.extend([y0, y1, None]) fig = go.Figure() fig.add_trace(go.Scatter(x=edge_x, y=edge_y, mode='lines', line=dict(width=0.5, color='gray'), hoverinfo='none')) fig.add_trace(go.Scatter(x=node_x, y=node_y, mode='markers+text', marker=dict(size=node_size, color=node_color, line_width=2), text=[n[:6] for n in G.nodes()], textposition="top center", hovertext=node_text, hoverinfo='text')) fig.update_layout(title="客服对话网络枢纽节点图谱（Q1）", showlegend=False) fig.show()

这张图交付给客服主管时，他鼠标悬停在CS-8821上，看到“Betweenness: 0.184”，立刻说：“就是他！上个月我们让他带新人，果然新人上手快。”——数据终于和业务直觉对齐了。

4.6 决策建议：从分析到行动的三步落地法

分析结束不是终点，而是行动起点。我坚持“三步落地法”：

1. 可验证假设：提出“提升CS-8821的排班权重，将其分配至高投诉时段，预计Q2首月客户满意度提升1.2%”。
2. 可执行动作：给出具体排班表模板，标注“每日10:00-12:00、15:00-17:00优先安排CS-8821”。
3. 可度量效果：定义成功指标——“Q2该时段内，客户首次响应时间<30秒的比例提升至92%（基线85%）”。

实操心得：永远不要说“这个客服很重要”，要说“把他放在X时段，做Y事，带来Z收益”。业务方只关心Z，而Z必须能量化。我在某保险项目中，因建议模糊，被要求重做三次分析报告。后来学会把每条建议都配上“预期影响值”和“验证周期”，再没被退回过。

5. 常见问题与排查技巧实录：那些让我熬夜改代码的深夜报错

5.1 问题速查表：高频报错、原因、解决方案

5.2 独家避坑技巧：教科书不会写的实战经验

技巧1：用subgraph()做“手术式”分析，而非全图硬算
面对百万级图，别硬算全局中心性。先用业务逻辑切子图：

# 只分析“技术问题”相关对话（消息含“API”“SDK”“报错码”） tech_edges = edges_df[edges_df['message_content'].str.contains('API|SDK|错误码', na=False)] G_tech = nx.from_pandas_edgelist(tech_edges, 'source', 'target', 'weight', create_using=nx.DiGraph()) # 在G_tech上跑算法，速度提升5倍

技巧2：weight参数不是万能钥匙，有时要反其道而行
betweenness_centrality(G, weight='weight')默认weight越小，路径越短。但我们的weight是“解决质量”，越大越好。所以应传入weight='weight_inv'，其中weight_inv = 1/(weight+1e-6)。否则算法会把高权重边当成“难走的路”。

技巧3：nx.draw()只是玩具，生产环境用mpld3或plotly
nx.draw(G)生成的静态图无法交互，且中文乱码。mpld3.fig_to_html()可转为HTML，支持缩放、悬停；plotly则支持导出高清PNG和分享链接。我所有交付报告，都附带一个network.html文件，业务方可直接双击打开。

技巧4：时间序列图，用nx.temporal_subgraph()不如手动切片
networkx的时序图支持很弱。正确做法是：

# 按月切片 monthly_graph