使用软件产品就像开车，难免会遇到抛锚时刻 🚗💨。对于商业产品，我们可以咨询客服寻求帮助。对于公司自己研发的产品，我们可以直接请教专家同事。但对于开源项目，就像突然找不到手机信号，该怎么办？

别慌！开源世界的生存法则是：70%自助排查 + 30%精准提问 = 100%问题解决！（毕竟维护者都是为爱发电的野生程序员🧑💻，不是24小时客服哦~）

🆘 自救指南

1. 先翻翻"说明书"（ 官方文档、常见问题 ）📖

2. 问问搜索引擎和大模型（90%的问题早有答案）🔍

3. 逛逛项目的"问题集锦"（Issues 问题区 和 Discussion 讨论区就像开源版知乎）🗂️

4. 找身边用过的小伙伴请教 （你遇到的问题别人可能也遇到过）👥

   如果这些都不管用————✨立刻马上向社区求助！✨

🤝 鼓励参与社区共建

这是一个开源项目, 我们也有繁忙的业务要做, 是用自己的业余时间在维护, 为爱发电, 精力有限, 所以有时候 issue 响应速度不是那么及时, 如果你遇到了问题, 或者对 Issues 问题区 和 Discussion 讨论区 列表的问题感兴趣, 可以直接认领并尝试修复 ，帮助 G2 变得更好, 而不是一味的埋怨和催促, 我们不是甲方乙方的关系.

💯 如何提交优质 Issue

请先确保你已经完成了自救指南的全部内容。如果是使用问题，不知道怎么用，请移步 Discussion 讨论区。

一个明确、有意义的标题

明确、有意义的标题，可以帮助作者确定问题具体是什么类型、预估需要多少时间解决、是否现在马上解决等。一个好的标题，也有利于社区知识的沉淀和后期搜索。

1. 简洁清晰（表达方式优化）

• ❌："我遇到了一个折线图的问题，提示信息显示不出来了"
  （冗余描述开发场景，未提炼核心）
• ✅："双轴图自定义提示显示undefined"
  （明确错误现象和受影响功能模块，删除非必要状语，保留主干问题）

2. 关键特征（内容完整性要求）

• ❌："使用仪表盘后网页崩溃"
  （未指明环境版本和具体错误类型）
• ✅："vue3 引用 g2 5.1.15 报错index.esm.js:617 Uncaught TypeError: Cannot read properties of undefined (reading 'font') "
  （包含版本、环境、错误类型三重关键信息）

3. 避免情绪化的表达

• ❌："一个很简单的饼图 我居然查了一整天api 没搞出来。。。"
  （情绪化表达，无法解决任何问题）
• ✅："饼图文档相关配置描述错误"
  （详细列出错误的位置，快速定位，方便修改文档）

遵循良好的模板

目前 G2 已经内置了issue模板，遵循这个模板去描述问题，能够为高效的沟通 💬 省下不少时间。如果未按照模板填写，内容缺失且未及时补充，维护者可能会错过你的问题。

Describe the bug / 问题描述

1. 请填写你具体的问题描述，请不要惜字如金，尽可能的多提供一些你能想到的有用信息。
2. 如包含代码块，请使用 Markdown 语法，正确的语法、清晰的格式，可以让读者赏心悦目，也就更有心情帮你一起思考解决问题。
3. 特定场景下触发的问题，请在描述里写明，例如高并发场景下/SSR渲染。

Reproduction link / 复现链接

1. 请不要粘贴你自己的业务代码，或者代码在我本地，不方便分享 。
2. 请提供去除业务意义的最小可复现 Demo，你可以使用 StackBlitz 重现你的问题，或者在官网的图表示例里编写完后，点击右上角工具栏将代码转成 codesandbox 并将对应的链接附上，方便维护者排查问题。
3. 请尽量不要粘贴代码的截图，使用 Markdown 语法是更好的选择。

Steps to Reproduce the Bug or Issue / 重现步骤

1. 若问题需特定交互触发，请用有序列表写明操作链路。仅附错误截图而不说明触发路径，可能导致维护者无法定位关键复现条件。
2. 示例：
   a. 先进行slider交互
   b. 再进行brushHighlight交互
   c. 监听brush:end事件
   d. 获得的data里的selection不正确。

Version / 版本

1. 获取真实安装版本

 npm list <package>

3. 检查锁文件，确认依赖树

（yarn.lock/package-lock.json）

Browser / 浏览器和 OS / 操作系统

你用的 windows 还是 macOS, 版本是多少，用的什么浏览器，版本是多少？花上一点点时间填写，可以节省后续的很多重复问答。

其他

还有一些需要注意的是：

1. 提交前搜索：使用搜索栏检查是否已有类似Issue
2. 单Issue单问题：避免在一个Issue中混合多个问题
3. 及时更新：当问题有进展时补充评论说明
4. 礼貌沟通：使用友好语言（如："建议..." 替代 "你们应该..."）

👍 Upvote / 👎 Downvote 机制

当提交问题前，发现同类issue已有讨论但尚未解决时，建议直接在现有issue下参与讨论。
可通过点赞（👍）表达关注并补充有价值的技术细节（如复现环境、日志截图等），这种协作方式既能避免重复提交，又能集中开发者注意力，推动问题解决效率。
下面介绍一下 Github 中的 Upvote 和 Downvote 机制。

在在 GitHub 中，投票是表达态度的重要方式，它能帮助我们：

• 发现最受关注的问题
• 了解社区的真实需求
• 合理分配开发资源

• Upvote (👍) ：表示支持某个问题或建议，帮助提高其优先级。点赞越多，问题的处理优先级通常越高。
• Downvote (👎) ：表示反对某个问题或建议，通常用于标记不相关或低价值的内容。

🩺 Issue 分诊机制

Issue 提交不应是单向的问题提出，而应作为持续追踪的协同工作流程。你需要及时跟进问题状态变更与修复进展，以下将系统说明Issue分诊机制的核心要素与实施规范。

创建 issue

创建成功后，会自动打上waiting for maintainer标签，此时只需要等待维护者回复。

与维护者有效沟通

维护者可能会要求提供更多信息或修改问题描述，此时 issue 会被打上waiting for author标签或者need improvement标签。确保在 7 天内提供所需信息，直到问题被明确标记为 Bug 或 Feature。

关注 Issue 状态

• Bug 类问题
  如果被标记为 todos，表示计划修复。如果被标记为 won’t fix，表示该问题不打算修复。
• Feature 类问题
  如果被标记为 todos，表示该功能在计划中。如果没有 todos 标签，则需要更多支持（👍）来评估是否加入开发计划。
• 关闭 Issue
  当问题被解决并关联到 PR 后，issue 会被关闭，表示已处理。发布新版本后，系统会自动回复，告知该功能或修复已包含在最新版本中。

Issue 标签

最后

在开源世界的星河里，每颗代码的星光都源自开发者赤诚的热爱。你提交的每个issue不仅是问题追踪单，更是推动我们不断改进的动力。我们始终以敬畏之心对待每份反馈，但正如夜航船需要灯塔指引，完善的复现步骤与清晰的表述将让问题定位事半功倍。
开源社区这个由全球开发者共建的伊甸园，既需要严谨的技术探讨，也渴求温暖的人文关怀。维护者在深夜调试的咖啡，贡献者在周末提交的PR，都值得用一句真挚的"感谢"来点亮。当你受惠于开源项目时，不妨将这份善意传递——帮助解答新手疑问，参与文档翻译，或简单地为优质项目点亮Star，都是对开源精神最美的诠释。
延伸阅读：

• 《如何向开源项目提交无法解答的问题》
• 《如何有效地报告 Bug》
• 《提问的智慧》