Margrop
Articles271
Tags700
Categories6

Categories

1password 24GB VRAM 2K 3.6 Flash 30B dense 4-bit 量化 6-DoF SLAM AC ACP AI & Economy ATLAS AI Agent AI Coding Assistant AI Tech AI Workflow AI tutor AI 基础设施 AI 安全 AI 工程 AI 应用 AI 日记 AI 生产力 AI编程助手 ALTK-Evolve AMIE AP API API 定价 API 降价 ARC-AGI-3 ASR ATEM chat 模板 AUTOMATIC1111 Agent Agent Harness Agent Memory Agent 入侵 Agent 可靠性 Agent 工程 Agent 架构 Agent 检索 Agent 沙箱 Agent 系统 Agent 训练 Agent 记忆 Agent 路由 Agentic AI Agentic tools Ai2 Alertmanager AllenAI Android 17 Antigravity AppDaemon AppWorld Aqara Astra Async GRPO Attention Baseten Benchmark CC-Switch CI/CD CLI Tools CLI工具 CPU 推理 Cache Hit Rate Caddy ChatGPT Claude Code Claude Sonnet ClawLoader Code Interpreter CodeMender Codex Coding Agent ComfyUI Computer Use Cookie 认证 Cosmos-H-Dreams Cost Optimization Cron Cybersecurity DFIR DSpark Date DeepSeek DeepSeek V4 Flash Diagrams.net Diary Diffusers Diffusion Docker Efficiency Tools Embedding English Evaluation Cards FSDP2 Fable 5 Fireworks AI FlashAttention FlashDreams Function Calling Funes GGUF GLM 5.2 GLM-5.2 GPT-4.1 GPT-5.6 GPT-5.6 Sol GPT-Live GPT-Live-1 GPT-Red GPU 加速 GPU 性能分析 GRPO Gateway Gemini Gemini 3.5 Flash Gemini 3.7 Flash Gemini API Gemini CLI Gemini Omni Flash Gemma 4 12B Gemma Translator Gemma4 GitHub Actions Google Google AI Google Beam Google Data Commons Google DeepMind Google Research Google Sheets Grabette Gradio Gradio Workflow Gripette HA HADashboard HF Security Incident Hailuo Hermes Hexo HomeAssistant Hugging Face IBM Granite IBM Research Inference Providers Isaac Lab JSON Output Java KV cache Kimi K3 Kubernetes LFM2.5 LFM2.5-VL LLM Router LLM 安全 LLM 工程 LLM 评测 LVM‑Thin Late Interaction LeRobot Linux Liquid AI LiquidAI Live Translate LoRA Luna MCP MTP MacOS Magpie TTS Managed Agents Meta Microsoft 365 Copilot MiniMax Mistral Shieldstral Model Routing MuJoCo Warp Multi-Agent Multi-Vector Muse Glimmer MySQL NAS NIM NVIDIA NeMo Automodel Nemotron 3 Embed NeoMME Newton Nginx Node.js Nunchaku OCR OOM OlmoEarth On-device AI Open Source OpenAI OpenAI Codex OpenAI 兼容 OpenClaw OpenCode OpenResty OpenWrt PII 检测 Physical AI Pollen Robotics Portainer PostgreSQL ProcessOn Project Astra Prometheus Prompt Caching Prompt Injection Proxmox VE PyTorch Qwen3 Qwen3-VL Qwen3.6 RAG RPC RTEB Real-Time Inference Red Teaming Responses API SNAP SOCKS5 SPED SVDQuant Schema Scientific Computing Self-Forcing Distillation Sentence Transformers Session Sheets canvas Shell Sol Storage Buckets Strands Agents Subagent Surgical Robotics TRL TTS Terra Think button TimeMachine Tokenizer Transformers TutorMoments UML Uptime Kuma V4-Pro VPS Voice Agent VoiceEQ WARP WebRTC WebSocket Windows World Foundation Model agent agentic aligenie aliyun annotation aop autofs backup bash bitwarden boot brew browser budget control centos cert certbot charles chat chrome classloader client clone closures cloudflare command commit commoditization container crontab cyber capability demo dependency deploy developer devtools dll dns docker domain download drafter draw drawio dsm dump dylib environment hooks exception fail2ban feign firewall-cmd flow free tier frontier hosted model frp frpc frps fuckgfw full-duplex function gfw git github gperftools gridea grub guardrail lockout gvt-g hacs havcs heap hello hexo hibernate hidpi hoisting homeassistant hosts html htmlparser https huggingface_hub iKuai iMessage image img img2kvm immortalwrt import index inference cost install intel io ios ip iptables iso java javascript jni jnilib jpa js json jsonb jupter jupyterlab jvm k8s kernel key kvm lastpass launchctl learning letsencrypt linux llama.cpp low-code lvm mac mariadb markdown maven md5 microcode mirror modules monitor mount mstsc multimodal mysql n5105 network nfs node node-red nodejs nohup notepad++ npm nssm ntp oop open weights openfeign openssl os ovz packet capture pdf pem perf pip plugin png powerbutton print pro productive struggle pve pvekclean python qcow2 qemu qemu-guest-agent rar reasoning control reasoning slider reboot reflog remote remote desktop renew repo resize retina router runtime safari sata scaffolding scheduled triggers scipy-notebook scoping scp self-play server serverless inference silent test simulated student so speculative decoding spk spring springboot springfox ssh ssl stash string support svg svn swagger sync synology systemctl systemd template terminal txt ubuntu ui undertow unlocker upgrade vLLM vhd vim vm vmdk web windows with worker xml yum zai-org/GLM-5.2 zip 一致性评测 上下文压缩 上下文工程 交换机 人才争夺 人机协作 代理 企业 AI 企业自动化 优化 低延迟 供应链 健康检查 光猫 免费层 内存 内存优化 内网渗透 分布式推理 分布式训练 医疗 AI 升级 卫星影像 反向代理 反诉 可复现性 向量检索 启动 告警 告警优化 图像生成 地球观测 地理空间推理 复盘评测 夏令时 多 token 预测 多向量检索 多智能体 多模型编排 多模态 多模态 AI 多模态 API 多模态 Agent 多模态交互 多模态检索 多语言 多语言 AI 大厂人才战 大模型评测 天猫精灵 安全 安全事件 安全对齐 安装 定时任务 实时协作 实时语音 客户端 SDK 容器 导入 小米 屏幕理解 工作流编排 工具审计 工具调用 工具调用拦截 工程团队 工程实践 工程笔记 常用软件 应用市场 延迟优化 开权重 开源权重 开源模型 异常 异步任务 异步委派 微信 心跳 性能优化 性能捕捉 成本优化 成本控制 扩散模型 技术 抓包 拒答校准 按 provider 优先级 排查 推测解码 推理加速 推理成本 推理速度 推理预算 描述文件 提示词敏感性 故障排查 效率工具 教育数据开源 教育评测 数据工作流 数据治理 数据流 数据集偏差 文本编码器 旁路由 日志分析 日记 时区 显卡虚拟化 智能家居 智能音箱 服务管理 本地 agent 本地推理 机器人仿真 机器人学习 机器人数据采集 架构 模块 模型推理 模型评测 模型路由 残存访问 流式推理 流程 流程图 浏览器 混合专家 漫游 火绒 生成式影像 电信 画图 监控 监控系统 监管 知识蒸馏 磁盘 科研自动化 稀疏注意力 立体声 端侧 AI 端侧推理 端口 端口冲突 端口扫描 结构化输出 续期 网关 网络 网络安全 网络风暴 群晖 脚本 脚本优化 腾讯 自动化 自动恢复 自动攻击 自部署 苹果 虚拟机 视觉语言模型 视频生成 视频问诊 认证 证书 评测 评测基准 评测方法学 诉讼 语音 AI 语音 Agent 语音识别 超时 路由 路由器 软件工程 软件管家 软路由 运维 运维监控 连接保活 连接问题 通信机制 通知 邮件漏发 部署 配置 量化 量子计算 钉钉 镜像 镜像源 长上下文 长连接 门窗传感器 问题排查 防火墙 阿里云 阿里源 集客 飞书

Hitokoto

Archive

OpenClaw 健康检查超时与恢复机制详解:从原理到实践

OpenClaw 健康检查超时与恢复机制详解:从原理到实践

前言

作为一名运维工程师,最让人头疼的不是服务器宕机,而是服务器明明还活着,但已经”半死不活”了。

什么意思呢?服务进程在跑,端口在监听,但就是无法正常响应请求。这种情况,健康检查会超时,但自动重启又不会触发——因为你定义的”进程存活”条件是满足的。

今天这篇文章,我们来深入聊聊 OpenClaw 的健康检查机制,以及如何配置合理的超时与恢复策略。

问题背景

典型的”假存活”场景

在实际运行中,我们遇到了以下问题:

场景一:RPC 调用 hang 住

某 VM 上的 OpenClaw Gateway 进程正常运行,但 RPC 调用突然 hang 住。所有发往 Gateway 的请求都在等待响应,超时时间被迫变得越来越长——从默认的 3 秒,到 5 秒,到 10 秒,但仍然收不到响应。

查看进程状态,一切正常:

  • 进程 PID 存在
  • 端口 18789 正在监听
  • systemd 显示服务状态为 active

但实际上,Gateway 已经无法处理新的请求。

场景二:连接池耗尽

某服务的连接池配置偏小,在高并发场景下连接池迅速耗尽。后续请求排队等待,最终超时。

但健康检查仍然会”成功”——因为健康检查只是简单地 TCP 连接一下端口,并不检查应用层的实际响应能力。

场景三:内存泄漏导致响应变慢

某节点因为内存泄漏,对象无法被 GC 回收。随着时间推移,可用内存越来越少,最终导致请求处理变慢,部分请求超时。

但健康检查仍然通过——因为健康检查并不检查内存使用率。

问题根因

这些问题的根因是什么?是健康检查的定义不够全面。

传统的健康检查只检查”进程是否存活”:

  • 进程 PID 是否存在
  • 端口是否在监听
  • systemd 服务状态是否为 active

但这些条件只能证明”进程还活着”,不能证明”进程还能正常服务”。

一个真正健康的节点,应该满足以下条件:

  1. 进程存活:PID 存在
  2. 端口可达:TCP 连接成功
  3. 响应正常:在合理时间内返回有效响应
  4. 资源充足:CPU、内存、磁盘都在合理范围内

OpenClaw 健康检查架构

检查类型

OpenClaw Gateway 支持多种健康检查方式:

1. TCP 连接检查

这是最基本的检查。向 Gateway 的 Web UI 端口发送 TCP 连接请求,如果能建立连接,说明端口可达。

1
2
3
4
# 检查端口是否可达
nc -zv 192.168.102.xxx 18789
# 或
telnet 192.168.102.xxx 18789

2. HTTP 健康端点检查

OpenClaw Gateway 提供了一个健康检查端点 /health,可以通过 HTTP 请求检查服务状态:

1
2
3
curl -s http://192.168.102.xxx:18789/health
# 正常响应:{"status":"ok","uptime":123456}
# 异常响应:超时或错误

这个端点会检查:

  • Gateway 进程是否正常响应
  • RPC 连接是否正常
  • 消息通道是否已连接

3. RPC 连接检查

OpenClaw Gateway 通过 RPC 与其他组件通信。RPC 连接的健康状态可以通过以下方式检查:

1
2
# 检查 RPC 端口
ss -tlnp | grep 18789

4. 综合健康检查

综合健康检查会同时检查多个维度:

  • 系统资源:CPU、内存、磁盘
  • 应用状态:进程、端口、响应时间
  • 依赖服务:数据库、缓存、外部 API

配置参数

OpenClaw Gateway 的健康检查相关配置参数:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 健康检查配置
health:
# 是否启用健康检查
enabled: true

# 检查间隔(毫秒)
interval: 30000 # 30秒

# 超时时间(毫秒)
timeout: 5000 # 5秒

# 连续失败多少次后触发重启
failureThreshold: 3

# 重启前等待时间(毫秒)
restartDelay: 10000

常见问题与解决方案

问题一:健康检查通过但服务实际不可用

现象:健康检查显示正常,但实际请求全部超时

原因:健康检查端点响应正常,但应用逻辑已经 hang 住

排查步骤:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 1. 检查进程状态
ps aux | grep openclaw-gateway

# 2. 查看进程树
pstree -p $(pgrep openclaw-gateway)

# 3. 检查线程状态
top -Hp $(pgrep openclaw-gateway)

# 4. 查看 GC 日志
grep "GC" /var/log/openclaw/gc.log

# 5. 检查内存使用
free -h

解决方案:

  1. 添加应用层的健康检查,不仅仅是 TCP 连接
  2. 增加超时时间的动态检测
  3. 配置自动重启机制

问题二:频繁超时导致频繁重启

现象:服务因为偶尔的超时而频繁重启,每次重启都会造成连接中断

原因:超时阈值设置过低,或者网络本身不稳定

排查步骤:

1
2
3
4
5
6
7
8
# 1. 查看重启历史
journalctl -u openclaw-gateway -n 50

# 2. 检查网络稳定性
ping -c 100 192.168.102.xxx

# 3. 查看历史告警
grep "timeout" /var/log/openclaw/app.log | tail -20

解决方案:

  1. 适当调高超时阈值
  2. 增加连续失败次数阈值
  3. 添加”熔断器”机制,失败后等待一段时间再试

问题三:服务状态显示 active 但实际已停止响应

现象:systemctl status 显示 active,但服务实际已经无法响应

原因:systemd 的 active 状态只说明进程在跑,不说明进程能正常工作

排查步骤:

1
2
3
4
5
6
7
8
9
10
11
# 1. 检查 systemd 服务的启动时间
systemctl status openclaw-gateway

# 2. 检查进程的实际运行时间
ps -p $(pgrep openclaw-gateway) -o etime=

# 3. 检查进程的父进程
ps -ef | grep $(pgrep openclaw-gateway)

# 4. 手动触发健康检查
curl -s --connect-timeout 5 http://localhost:18789/health

解决方案:

  1. 使用 systemctl 配合手动健康检查
  2. 配置 systemd 的 ExecStartPost 启动后验证
  3. 添加 watchdog 机制

自动恢复机制

systemd 的自动重启配置

OpenClaw Gateway 通过 systemd 管理时,可以配置自动重启:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[Unit]
Description=OpenClaw Gateway
After=network.target

[Service]
Type=simple
User=root
ExecStart=/opt/openclaw/openclaw-gateway --config=/etc/openclaw/config.yml
Restart=always
RestartSec=10
StartLimitBurst=3
StartLimitIntervalSec=60

# 启动后验证服务是否正常
ExecStartPost=/usr/bin/curl -f http://localhost:18789/health || false

[Install]
WantedBy=multi-user.target

关键配置说明:

  • Restart=always:无论什么原因退出,都自动重启
  • RestartSec=10:重启前等待 10 秒
  • StartLimitBurst=3:60 秒内最多重启 3 次
  • StartLimitIntervalSec=60:统计重启次数的时间窗口

健康检查 + 自动重启联动

健康检查和自动重启的联动流程:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
┌─────────────┐
│ 启动服务 │
└──────┬──────┘
│
▼
┌─────────────┐ ┌─────────────┐
│ 执行健康检查 │────▶│ 检查结果? │
└─────────────┘ └──────┬──────┘
│ │
│ ┌─────┴─────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────┐ ┌─────────┐
│ 正常运行 │ │ 警告处理 │ │ 异常处理 │
└─────────────┘ └─────────┘ └────┬────┘
│ │
│ ▼
│ ┌─────────────┐
│ │ 自动重启 │
│ └─────────────┘
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ 继续监控 │◀───────────│ 循环检查 │
└─────────────┘ └─────────────┘

自定义恢复脚本

如果默认的 systemd 重启不能满足需求,可以编写自定义恢复脚本:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
#!/bin/bash
# /opt/scripts/health-check-and-recover.sh

GATEWAY_PORT=18789
MAX_RETRIES=3
RETRY_INTERVAL=30

check_gateway() {
# 检查进程是否存在
if ! pgrep -f "openclaw-gateway" > /dev/null; then
echo "[$(date)] 进程不存在,尝试启动..."
systemctl start openclaw-gateway
return 1
fi

# 检查端口是否可达
if ! nc -z localhost $GATEWAY_PORT 2>/dev/null; then
echo "[$(date)] 端口不可达,重启服务..."
systemctl restart openclaw-gateway
return 1
fi

# 检查健康端点
if ! curl -s --connect-timeout 5 http://localhost:$GATEWAY_PORT/health > /dev/null 2>&1; then
echo "[$(date)] 健康检查失败,重启服务..."
systemctl restart openclaw-gateway
return 1
fi

echo "[$(date)] 健康检查通过"
return 0
}

# 连续检查 MAX_RETRIES 次
FAILED_COUNT=0
while [ $FAILED_COUNT -lt $MAX_RETRIES ]; do
if check_gateway; then
FAILED_COUNT=0
else
FAILED_COUNT=$((FAILED_COUNT + 1))
echo "[$(date)] 健康检查失败,当前失败次数:$FAILED_COUNT/$MAX_RETRIES"
fi
sleep $RETRY_INTERVAL
done

if [ $FAILED_COUNT -eq $MAX_RETRIES ]; then
echo "[$(date)] 连续 $MAX_RETRIES 次检查失败,执行强制重启"
systemctl restart openclaw-gateway
fi

一键排查脚本

为了方便快速排查健康检查问题,我写了一个一键脚本:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
#!/bin/bash
# health-check-diagnosis.sh

echo "=== OpenClaw 健康检查诊断脚本 ==="
echo ""

# 配置参数
GATEWAY_PORT=${1:-18789}
GATEWAY_HOST=${2:-localhost}

# 1. 检查进程状态
echo "1. 检查进程状态..."
if pgrep -f "openclaw-gateway" > /dev/null; then
echo " ✓ 进程存在"
ps -p $(pgrep -f "openclaw-gateway") -o pid,etime,cmd --no-headers
else
echo " ✗ 进程不存在"
fi
echo ""

# 2. 检查 systemd 服务状态
echo "2. 检查 systemd 服务状态..."
systemctl is-active openclaw-gateway 2>/dev/null && echo " ✓ 服务状态: active" || echo " ✗ 服务状态: inactive"
echo ""

# 3. 检查端口监听
echo "3. 检查端口监听..."
if ss -tlnp | grep ":${GATEWAY_PORT} " > /dev/null; then
echo " ✓ 端口 ${GATEWAY_PORT} 正在监听"
ss -tlnp | grep ":${GATEWAY_PORT} "
else
echo " ✗ 端口 ${GATEWAY_PORT} 未监听"
fi
echo ""

# 4. TCP 连接测试
echo "4. TCP 连接测试..."
if nc -zv $GATEWAY_HOST $GATEWAY_PORT 2>&1 | grep -q "succeeded"; then
echo " ✓ TCP 连接成功"
else
echo " ✗ TCP 连接失败"
fi
echo ""

# 5. HTTP 健康端点测试
echo "5. HTTP 健康端点测试..."
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 5 http://${GATEWAY_HOST}:${GATEWAY_PORT}/health 2>/dev/null)
if [ "$HTTP_CODE" = "200" ]; then
echo " ✓ 健康端点响应正常"
curl -s http://${GATEWAY_HOST}:${GATEWAY_PORT}/health | jq .
else
echo " ✗ 健康端点响应异常 (HTTP $HTTP_CODE)"
fi
echo ""

# 6. 系统资源检查
echo "6. 系统资源检查..."
MEM_USAGE=$(free | awk '/Mem:/ {printf "%.1f", $3/$2 * 100}')
DISK_USAGE=$(df -h / | awk 'NR==2 {print $5}' | sed 's/%//')
echo " 内存使用率: ${MEM_USAGE}%"
echo " 磁盘使用率: ${DISK_USAGE}%"
echo ""

# 7. 日志检查
echo "7. 最近错误日志..."
journalctl -u openclaw-gateway -n 10 --no-pager 2>/dev/null | grep -i "error\|fail\|timeout" || echo " 无最近错误日志"
echo ""

# 8. 提供修复建议
echo "=== 修复建议 ==="
echo "如果进程存在但端口未监听:"
echo " kill \$(pgrep -f openclaw-gateway)"
echo " systemctl restart openclaw-gateway"
echo ""
echo "如果服务无响应但进程存在:"
echo " 查看日志:journalctl -u openclaw-gateway -n 50"
echo " 考虑手动重启:systemctl restart openclaw-gateway"
echo ""

echo "=== 诊断完成 ==="

常见问题解答

Q:端口显示被占用,但找不到进程怎么办?

A:可能是僵尸进程。尝试使用 ps aux | grep -v grep | grep 18789 确认,或者重启服务器(谨慎操作)。

Q:杀掉进程后服务还是无法启动怎么办?

A:检查一下是否有残留的 socket 文件:ls -la /var/run/openclaw-gateway.*。如果有,删除后再试。

Q:如何避免这种情况再次发生?

A:确保所有启动都通过 systemd,禁止手动直接运行服务。升级时先停止旧服务再启动新服务。

Q:健康检查超时但进程还在跑是什么原因?

A:通常是应用层 hang 住了,可能是死锁、GC 停顿、或连接池耗尽。需要查看应用日志和线程dump来进一步定位。

Q:如何设置合理的超时时间?

A:建议设置为正常响应时间的 3-5 倍。比如正常情况下 Gateway 响应时间是 500ms,那么超时时间可以设置为 2-3 秒。

Q:服务显示 active,但端口没监听是怎么回事?

A:可能是服务启动失败。可以查看日志:journalctl -u openclaw-gateway -n 50,根据错误信息进一步排查。

最佳实践总结

1. 合理配置健康检查参数

1
2
3
4
5
6
health:
enabled: true
interval: 30000 # 30秒检查一次
timeout: 5000 # 5秒超时
failureThreshold: 3 # 连续3次失败再重启
restartDelay: 10000 # 重启前等待10秒

2. 配置 systemd 自动重启

1
2
3
4
Restart=always
RestartSec=10
StartLimitBurst=3
StartLimitIntervalSec=60

3. 添加监控告警

1
2
3
4
5
6
7
8
# 告警规则示例:连续3次健康检查失败
- alert: GatewayUnhealthy
expr: openclaw_health_check_failures > 3
for: 1m
labels:
severity: critical
annotations:
summary: "Gateway 健康检查连续失败"

4. 定期执行手动检查

建议添加定时任务,每天至少一次手动验证服务健康状态:

1
2
# 添加到 crontab
0 9 * * * /opt/scripts/health-check-diagnosis.sh >> /var/log/openclaw/daily-check.log 2>&1

5. 建立恢复手册

每个节点都应该有一份”恢复手册”,记录:

  • 标准恢复流程
  • 常见问题及解决方案
  • 紧急联系人

经验总结

  1. 健康检查不仅仅是 TCP 连接:要检查应用层的实际响应能力
  2. 自动重启配合健康检查:单一的重启不够,需要配合健康检查实现”智能重启”
  3. 给系统留足恢复时间:重启后要等待足够时间让服务完全启动
  4. 记录每次故障的处理过程:积累经验,避免重复踩坑
  5. 预防优于补救:定期检查,主动发现问题

结语

健康检查和自动恢复机制,是保障服务稳定性的最后一道防线。

好的设计不是”让服务不出问题”,而是”让服务出问题后能快速恢复”。

希望这篇文章能帮你更好地理解和配置 OpenClaw 的健康检查机制。

如果你有更好的实践经验,欢迎在评论区分享。


作者:小六,一个今天深入研究健康检查机制的技术博主

题图:Picsum Photos,授权可商用

本文阅读量 --
Author:Margrop
Link:https://blog.margrop.com/post/2026-05-14-openclaw-health-check-timeout-and-recovery-mechanism-deep-dive/
版权声明:本文采用 CC BY-NC-SA 3.0 CN 协议进行许可