正在调度页面内容…
常见问题
学会提问
整理问题信息，让排障沟通更有效率。
✨ 提问的智慧 (HyperFRP 社区版)
前言: 本文根据 Eric S. Raymond 的经典文章 How To Ask Questions The Smart Way 改编，旨在帮助 HyperFRP 用户更有效地提出技术问题，从而更快地获得高质量的解答。一个好的问题，是开启高效沟通的金钥匙。
原作信息:
- 英文原作: How To Ask Questions The Smart Way by Eric S. Raymond, Rick Moen
- 原文网址: http://www.catb.org/~esr/faqs/smart-questions.html
- 中文翻译参考: https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way
声明
许多开源项目（包括我们 HyperFRP）都鼓励在其文档或社区指南中链接本指南。我们对此表示欢迎。但如果您是其他项目的维护者，请在链接旁明确注明：
“本指南不提供您所链接项目的实际支持服务！”
我们已经深刻体会到缺少上述声明所带来的痛苦。因为总有一些人认为，既然我们发布了这篇指南，我们就有责任解决世界上所有的技术问题。
如果您正在阅读本指南是因为需要帮助，并且最终因为无法从本文作者这里直接得到帮助而感到失望，那么您就是我们试图点醒的人之一。请不要直接向本指南的作者或改编者提问，我们只会忽略您。
我们在这篇指南中，是教您如何从那些真正了解您所遇到的软硬件问题的人（例如 HyperFRP 的社区专家和贡献者）那里获得帮助。在99%的情况下，那个人不会是我们。除非您能确定本指南的作者之一恰好是您所遇到问题领域的专家，否则请不要打扰我们，这样大家都会更轻松。
简介
在技术世界里，当你提出一个技术问题时，最终能否得到有用的回答，往往取决于你提问的方式。本指南将教你如何正确地提问，以最大化你获得满意答案的可能性。
现在，随着开源软件的普及，您常常可以从其他有经验的用户那里获得很好的答案，而不仅仅是开发者。这是一件好事。有经验的用户通常对新手常遇到的问题更为宽容。尽管如此，将他们（以及项目贡献者）当作专家来对待，并采用本指南中描述的方法与他们沟通，依然是从他们那里获得有效解答的最佳方式。
首先您应该明白，社区专家们喜爱有挑战性的问题，或是能激发他们思维的好问题。如果我们并非如此，我们也不会成为您想咨询的对象。如果您给我们的问题值得咀嚼和玩味，我们自会对您感激不尽。好问题是激励，是厚礼。好问题可以提高我们的理解力，而且通常会暴露我们以前从没意识到或者思考过的问题。
尽管如此，社区专家们有时会对简单问题表现出不耐烦，这有时会让我们看起来对新手不太友好，但其实并非如此。
我们不讳言我们对那些不愿思考、或者在提问前不愿自己动手尝试的人感到蔑视。这些人是“时间杀手”——他们只想索取，从不付出，消耗了我们本可以用于回答更有趣问题或者帮助更值得帮助的人的时间。我们称这样的人为“伸手党”。
我们理解，许多人只想使用我们开发的 HyperFRP 软件，而对学习技术细节没有兴趣。对大多数人而言，软件只是一个工具。他们有自己的生活，有更重要的事情要做。我们明白这点，也从不指望每个人都对这些技术问题抱有和我们一样的热情。尽管如此，我们回答问题的风格是为那些真正对此有兴趣并愿意主动参与解决问题的人准备的，这一点不会改变。
我们（在很大程度上）是自愿抽出时间来解答疑惑的，而且我们时常被大量问题淹没。所以我们会无情地过滤掉一些问题，特别是那些来自看起来像“伸手党”的人，以便更高效地利用我们的时间来回答“赢家”的问题。
如果您对我们的态度感到不适应，不妨设身处地想一想。我们并没有要求您屈服——事实上，我们中的大多数人非常乐意与您平等地交流，只要您付出小小的努力来满足基本要求，我们就会欢迎您加入我们的社区文化。但让我们帮助那些不愿自助的人是低效的。无知没有关系，但假装无知就是不行。
所以，您不必在技术上有多精通才能吸引我们的注意，但您必须表现出能引导您变得精通的特质——机敏、有想法、善于观察、乐于主动。如果您做不到这些，我们建议您考虑付费的技术支持服务，而不是向社区的志愿者们寻求免费帮助。
如果您决定向我们求助，当然不希望被看作“伸手党”。能立刻得到有效答案的最好方法，就是像“赢家”那样提问——聪明、自信、有思路，只是在某个特定问题上需要一点小小的帮助。
在提问之前
在你通过电子邮件、论坛或者聊天室提出技术问题前，请务必做到以下几点：
- ✅ 尝试在 HyperFRP 的官方文档中搜索答案。
- ✅ 尝试在我们的社区论坛或相关的技术社区（如 V2EX、Stack Overflow）中搜索答案。
- ✅ 尝试使用搜索引擎（如 Google、Bing、DuckDuckGo）寻找答案。
- ✅ 尝试阅读项目的《常见问题解答》(FAQ) 列表。
- ✅ 尝试自己动手实验、排查和解决问题。
- ✅ 询问你身边略懂技术的朋友。
- 如果你是开发者，✅ 请尝试阅读源码来理解程序的行为。
当你提出问题的时候，请首先表明你已经做过了上述的努力。这会帮助建立你的声誉，让你看起来不是一个懒人，不是一个只想索取而不愿付出的人。如果你能一并表达在这些过程中学到了什么，那就更好了，因为我们更乐于帮助那些表现出能从答案中学习的人。
💡 专业提示 (Pro-Tip)
运用一些搜索技巧，例如使用 Google 搜索你遇到的完整错误信息，通常能直接定位到问题根源。即使没有直接结果，在提问时附上一句：“我用 Google 搜索了‘
[完整的错误信息]’但没有找到有用的线索”，也是一个极好的习惯。这不仅能帮助他人，也能让搜索引擎将你的提问索引给后来遇到同样问题的人。
当你提问时
1. 慎选提问的渠道
提问前，请花点时间选择一个正确的渠道。如果你这样做，很可能会被忽略或被视为“小白”。
- ❌ 不要在与主题无关的论坛或版块提问。
- ❌ 不要在探讨高阶技术问题的社区里问非常初级的问题，反之亦然。
- ❌ 不要在多个不同的渠道重复发送同一个问题。
- ❌ 不要随意给社区专家或项目贡献者发送私人邮件求助。
社区专家们会主动过滤掉那些发错地方的问题，以保护沟通渠道的信噪比。你不会想让这种事发生在自己身上。
如何找到正确的渠道？
- 第一步：官方文档与社区
- 首先查看 HyperFRP 的官方网站。通常那里会有指向社区论坛、FAQ、邮件列表和问题反馈（Bug Report）流程的链接。
- 第二步：专业问答社区
- Stack Overflow: 是询问编程相关问题的最佳场所。
- Server Fault: 是询问服务器管理和网络配置相关问题的最佳场所。
- Super User: 适合询问通用的电脑技术问题，如果你的问题与代码或服务器管理无关。
- 第三步：项目的邮件列表或论坛
- 如果项目有自己的邮件列表或论坛，请优先在那里提问。提问前，请务必搜索历史存档，并花几天时间“潜水”观察社区的氛围和沟通方式。
- 如果项目有“用户”和“开发者”两个列表，而你不是在修改代码，请发到“用户”列表。
2. 使用有意义且描述明确的标题
在邮件列表或论坛里，一个好的标题是抓住专家注意力的黄金机会。不要用“救命啊！”、“求助！”或者“紧急！”这类毫无信息量的词语来浪费它。
一个好标题通常采用“目标 - 差异”的格式。
- 目标：你想要达成的目的。
- 差异：当前遇到的与预期不符的情况。
糟糕的标题: 救命啊！我的 frpc 连不上了！
聪明的标题: frpc 在使用 token 认证时，无法连接到节点。
更聪明的标题: frpc v0.51.3 启动后日志显示 "login to server failed: authorization failed"，但 token 与后台配置完全一致。
一个精心构思的标题，能让社区专家在几秒钟内就理解你的问题核心，这大大增加了你获得高质量回复的几率。
3. 用清晰、准确、语法正确的语言提问
我们发现，漫不经心的提问者通常在思考和写代码时也一样漫不经心。回答他们的问题毫无意义，我们宁愿把时间花在别处。
- 注意拼写、标点和大小写。不要全部用大写，这很无礼。也不要全部用小写，这很难阅读。
- 不要使用“火星文”或网络俚语。清晰地表达自己，而不是为了省几个按键而让别人去猜你的意思。
- 如果你不擅长英语，但不得不在英文社区提问，请明确说明。例如：
"English is not my native language; please excuse typing errors." (英语不是我的母语，请原谅我的拼写错误。)
4. 使用易于阅读的纯文本格式
如果你人为地让问题变得难以阅读，它多半会被忽略。
- 使用纯文本：不要发送 HTML 格式的邮件或帖子。
- 附件需谨慎：只在附件确实包含必要信息（如源码、配置文件）时才使用。
- 日志和代码要用代码块：在论坛或支持 Markdown 的地方，请将代码、配置文件和日志信息用代码块包围起来。这能保持格式，并且通常会带语法高亮。
CODE /MARKDOWN
```toml # 这是我的 frpc.toml 配置文件 serverAddr = "node1.hyperfrp.com" serverPort = 7000 [auth] method = "token" token = "YourSecretToken" [[proxies]] name = "ssh-tunnel" type = "tcp" localIP = "127.0.0.1" localPort = 22 remotePort = 6001 ``` - 不要发送 Word 或其他专有格式的文档。社区对此的反应，就像有人把热气腾腾的垃圾倒在你家门口一样。
5. 精确地描述问题并言之有物
这是提问环节中最重要的一环。如果你不能清晰地描述问题，没人能帮得了你。
5.1 仔细、清楚地描述问题的症状
不要只是简单地说“我的程序不工作了”或者“我连不上了”。这毫无信息量。请提供问题发生时的所有细节。
- 发生了什么？ 程序是崩溃了、挂起了、还是打印了错误信息？
- 预期是什么？ 你原本期望程序做什么？
- 实际是什么？ 它实际上做了什么？
5.2 描述问题发生的环境
软硬件环境的差异是导致问题的重要原因。请务必提供你所使用的完整环境信息：
- 软件版本: 你正在使用的 frpc 客户端的确切版本号 (例如,
v0.51.3)。 - 操作系统: 你在哪种操作系统上运行它 (例如,
Windows 11,macOS Sonoma,Ubuntu 22.04 LTS)。 - 相关软件: 如果问题与其他服务有关，请提供它们的名称和版本 (例如,
本地的 Nginx 1.20,MySQL 8.0)。 - 配置文件: 提供与问题相关的、最小化的配置文件内容。请务必脱敏处理，删除密码、密钥等敏感信息！
5.3 描述你为解决问题做过什么
分享你在提问前所做的研究和诊断步骤。这能证明你不是一个懒惰的“伸手党”，并且你提供的线索可能正是解决问题的关键。
我已经检查了 frpc 的日志，发现有
login to server failed: authorization failed错误。我尝试使用telnet命令连接节点的7000端口，确认网络是通的。
5.4 描述最近的相关变更
你最近对系统做了什么可能相关的改动？例如：
- 升级了操作系统或某个软件库？
- 修改了防火墙规则或安全软件设置？
- 更新了 HyperFRP 面板上的隧道配置？
5.5 提供一个可重现的最小化示例 (如果可能)
如果你报告的是一个 Bug，没有什么比提供一个能让开发者快速重现问题的最小化测试用例 (Minimal, Reproducible Example) 更有效的了。
- 最小化: 剔除所有与问题无关的代码和配置，只留下刚好能触发问题的部分。
- 可重现: 确保其他人使用你提供的示例能100%复现问题。
这样做有三大好处:
- 赢得尊重: 表明你为简化问题付出了努力。
- 提高效率: 开发者能更快定位问题，你也可能更快得到答案。
- 自我诊断: 在精简问题的过程中，你很可能自己就找到了原因。
6. 话不在多，而在精
你需要提供精确且有内容的信息。但这不意味着要把所有调试日志或代码都扔出来。
- 要点突出: 如果日志很长，只贴出与问题最相关的几行，并在前后附带少量上下文。
- 总结归纳: 如果可能，用简洁的语言总结一下日志或错误信息的核心内容。
- 避免噪音: 不要贴上成百上千行的无关信息，这只会让人望而却步。
7. 别动辄声称找到了 Bug
当你在使用软件中遇到问题时，除非你非常、非常有根据，否则不要轻易声称找到了一个 Bug。
💡 提示: 除非你能提供解决问题的源代码补丁（Patch），或者对不同版本间的行为差异做出精确的回归测试分析，否则你多半不够资格百分之百确定那是一个 Bug。
记住，成千上万的用户没有遇到你发现的问题，这通常意味着问题很可能出在你的配置或环境上。
如果你声称找到了 Bug，就是在挑战开发者的工作成果。即使你是对的，这种方式也容易冒犯到别人。一个更礼貌、也更有效的方式是：
❌ 错误的方式: “你们的软件有 Bug，这里不工作！”
✅ 正确的方式: “我似乎遇到了一个问题，我的操作步骤是 A、B、C，预期结果是 X，但实际结果是 Y。这看起来像是一个潜在的 Bug，或者是我哪里理解错了吗？”
如果真的有 Bug，你会在回复中看到。维护者会感谢你的发现，这远比你冒犯了别人之后再道歉要好得多。
8. 可以低声下气，但必须先做功课
有些人知道不该傲慢，于是选择了另一个极端——过度谦卑。
“我知道我只是个可怜的新手，一个小白，但我想我遇到了一个问题……”
这种方式同样令人困扰，且毫无用处，尤其是在问题描述含糊不清的时候。
不要浪费你我的时间。 取而代之的是，尽可能清楚地描述背景和问题。这比低声下气更能赢得尊重。
在 HyperFRP 社区，我们设有专门的新手问答区或频道。如果你真的认为遇到了一个初学者问题，可以去那里提问，但同样，请保持自信和清晰。
9. 描述问题症状，而非你的猜测
告诉社区专家你认为问题是怎样造成的，这通常没什么帮助。因为如果你的推断是正确的，你就不需要求助了。所以，请务必告诉他们问题的原始症状，而不是你的解释和理论。让专家们来进行诊断。
如果你认为陈述自己的猜测很重要，请明确说明这只是你的猜测，并简要解释你为何会这么认为。
糟糕的提问: 我的 frpc 总是断线重连，我怀疑是我的路由器有问题。我该怎么设置路由器？
聪明的提问: 我的 frpc 客户端（Windows 11, frpc v0.51.3）每隔大约5分钟就会断线并自动重连。日志显示
[W] [service.go:303] login to server failed: dial tcp 1.2.3.4:7000: i/o timeout。我检查了本地防火墙，并尝试 ping 节点地址，网络看起来是稳定的。这是我的配置文件...
密苏里州的名言：“让我看看”
对于诊断者而言，他们需要看到与你看到的尽可能一致的原始证据，而不是你的转述和总结。这源于一句美国俗语：“我来自密苏里州，你必须让我看看。” (I'm from Missouri. Show me.) 这代表了一种务实、求证的精神。所以，请大方地展示给他们看。
10. 按时间顺序列出问题症状
问题发生前的一系列操作，以及操作后系统和软件的反应，是找出问题最有价值的线索。因此，你的说明里应该包含：
- 你做了什么：按时间顺序列出你的操作步骤。
- 发生了什么：按时间顺序列出机器和软件的反应。
- 提供日志：在处理命令行问题时，提供一段终端的操作记录（包含你的输入和程序的输出）会非常有帮助。引用其中最关键的20行左右通常就足够了。
如果程序有诊断选项（例如 -v 或 --verbose 详细模式），请尝试使用它们来获取更丰富的调试信息。
💡 记住：多不等于好。 尝试选取恰当的调试级别，以便提供有用的信息，而不是让回复者被信息的海洋淹没。
如果你的说明很长（例如超过4个段落），建议在开头先用一句话简述问题，然后再按时间顺序展开详述。这样，社区专家们在阅读时就能立刻抓住重点。
11. 描述你的目标，而不是过程
如果你想弄清楚如何做某事（而不是报告一个Bug），请在开头就清晰地描述你的最终目标。然后再陈述你卡在哪个具体步骤上。
很多时候，寻求帮助的人心中有一个更高层次的目标，但他们却卡在了自以为能够达成目标的某条特定路径上。他们跑来问该怎么走通这条路，却没有意识到这条路本身可能就是错的。结果，他们不仅自己费劲，也让帮助他们的人很费劲。
糟糕的提问: 我怎样才能让 frpc 的
custom_domains参数接受一个通配符？聪明的提问: 我想用一个
http类型的隧道来代理我本地的多个开发站点 ，例如site1.localhost和site2.localhost。我希望能通过*.mydomain.com这样的方式将它们全部映射出去，而不是为每个站点都创建一个新的隧道。请问在 HyperFRP 中实现这个目标的最佳实践是什么？
第二种提问方式更聪明，因为它揭示了真实的需求。你很可能会得到一个你没想到的、但更合适的工具或方法的建议。
12. 别要求私下回复
社区专家们认为，问题的解决过程应该公开、透明。在这个过程中：
- 如果最初的答案不完美，其他人可以补充和修正。
- 帮助者能因为其能力和学识被同行看到而获得声誉。
- 其他人遇到类似问题时，可以通过搜索找到解决方案。
当你要求私下回复时，这个开放、共享的过程和奖励机制就被破坏了。所以，别这么做。 让回复者自己决定是否要私下联系你。如果他们这么做了，通常是因为他们觉得问题太初级或太无聊，不值得在公共场合浪费大家的时间。
唯一的例外: 如果你确信你的问题可能会引来大量内容相似的回复，那么说一句“请通过邮件回复我，我会为大家总结并发布最终结果”是得体的。这是一种有礼貌的行为，可以避免邮件列表或论坛被大量重复信息淹没。
13. 清楚明确地表达你的需求
漫无边际的提问，就像一个无底洞，会消耗掉大量的时间和精力。
- 最可能给你答案的人，通常也是最忙的人。 他们对这种无节制的时间消耗非常反感。
- 明确你的需求，能帮助专家快速判断他们需要投入多少时间和精力，从而更愿意帮助你。
糟糕的提问: 请问谁能解释一下 frpc 的
stcp代理是怎么工作的？聪明的提问: 我想更好地理解 frpc 的
stcp代理，可否请您指点一下相关的官方文档或配置示例？更聪明的提问: 我正在尝试配置一个
stcp代理来安全地访问我的家庭 NAS，但访客端总是连接失败。我阅读了官方文档，但还是没弄明白sk(密钥) 是应该在访客端还是服务端配置。谁能帮我看看我的这份frpc.toml配置文件哪里出了问题？
将“请帮我解决”转化为“请帮我看看哪里错了”或“请给我一个方向”，是获得高质量回复的关键。
14. 询问有关代码的问题
不要只贴出几百行代码，然后说一句“它不工作了”，这会让你被直接忽略。只贴出几十行代码，然后说一句“在第七行之后，我期望它输出 <x>，但实际输出的是 <y>”，这样你更有可能得到回复。
描述程序问题的最有效方法是提供一个最精简的可重现 Bug 的测试用例 (bug-demonstrating test case)。
- 什么是“最精简的测试用例”？ 它是一个问题的缩影；一小段代码刚好能完整地展示程序的异常行为，而不包含任何无关内容。
- 如何制作？ 如果你知道哪段代码是问题所在，复制它并加入足够使其能够独立运行的代码即可。如果你不确定，就复制一份源码，然后不断地删除不影响问题重现的部分。这个过程越精简越好。
制作一个精简的测试用例并不总是那么容易，但这是你应该努力尝试的好习惯。这个过程能帮助你理清思路，很可能让你自己就解决了问题。即使失败了，社区专家们也会看到你为此付出的努力，这会让他们更愿意与你合作。
如果你只是想让别人帮忙审查 (Review) 一下你的代码，请在提问的开头就明确说明，并一定要提到你认为哪一部分特别需要关注，以及你为什么这么认为。
15. 别把你的家庭作业贴上来
社区专家们能非常精准地分辨出哪些是“家庭作业”式的问题。我们中的大多数人都做过这些作业，它们应该由你自己来解决，这样你才能真正学到东西。你可以请求一些提示，但别指望我们会给出完整的解决方案。
如果你怀疑自己遇到了一个家庭作业式的问题，但仍然无法解决，可以尝试在用户群组论坛，或者（作为最后一招）在项目的“用户”邮件列表或论坛中提问。虽然社区专家们还是会看出来，但一些有经验的普通用户也许仍会给你一些提示。
16. 去掉无意义的客套话
避免在结尾加上一些毫无意义的客套话，例如：
“有人能帮我吗？”
“有答案吗？”
首先，如果你对问题的描述不够好，这样问更是画蛇添足。其次，由于它画蛇添足，社区专家们会觉得这很烦人，并且通常会用逻辑上正确但毫无帮助的回答来表达他们的蔑视，例如：
“是的，有人能帮你。”
“不，现在还没有答案。”
一般来说，请避免用“是/否”来提问，除非你真的只想得到一个“是/否”的答案。
17. 即使你很急，也别在标题里写“紧急”
这是你的问题，不是我们的。
宣称“紧急”极有可能事与愿违：大多数社区专家会直接删除这种无礼和自私的企图。更严重的是，“紧急”、“URGENT” 这类词是垃圾邮件过滤器的常见关键词，你满怀希望的问题可能永远不会到达你期望的收件人那里。
唯一的例外: 如果你是在一个很高调、能让专家们兴奋的地方使用这个词，也许可以。在这种情况下，如果你有时间压力，可以礼貌地提及它，大家也许会有兴趣快点回答。
当然，这风险很大。因为能让专家兴奋的点，多半和你的不一样。例如，从国际空间站发一个标题为“紧急：飞船氧气泄漏”的求助帖是没问题的，但用“紧急：帮我救救这个毛绒绒的小海豹！”的名义来搞慈善或政治宣传，肯定会让你被忽略或惹恼大家。
18. 礼多人不怪，而且有时还很有帮助
多说“请”和“谢谢您的帮助”或“感谢您的时间和关注”。让大家知道你对他们花时间免费提供帮助心存感激。
坦白说，这一点不如写得清晰、准确、有条理来得重要，但它绝对是一个加分项。
💡 一个文化观察: 自从本指南发布后，我们从一些社区专家那里收到的唯一严重反馈，就是关于“预先感谢”的。一些人觉得“先谢了”意味着事后就不用再感谢任何人了。我们的建议是：要么先说谢谢，事后再对提供帮助的人再次感谢；要么换一种方式表达，比如“感谢您的时间和关注”，事后再具体感谢帮助你的人。
19. 问题解决后，加个简短的补充说明
问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决的，并再次向他们表示感谢。如果问题在邮件列表或论坛上引起了广泛关注，在那里贴一个说明是比较恰当的。
最理想的方式是回复最初提问的那个主题，并在标题中包含“[已解决]”、“[FIXED]”或其他类似含义的明确标记。这能让其他人在浏览时，一眼就知道这个话题已经可以跳过了，从而节省大家的时间。
补充说明不必很长，一句简单的“解决了，原来是配置文件里的一个拼写错误！谢谢大家！”就比什么都不说要好得多。一个简洁、可爱的小结比一篇长篇大论更能让人满意。
对于有深度的问题，张贴调试过程的摘要是很有帮助的。描述问题的最终状态，说明是什么解决了问题，并指出那些可能让人走弯路的“死胡同”。
这种补充说明的好处是巨大的：
- 带来满足感: 帮助过你的人会因为问题得到解决而感到满足，这是他们付出的回报。
- 积累声誉: 这种行为能让你在社区中赢得声誉，这是一种非常有价值的资产。
- 帮助后来者: 其他人可以通过搜索引擎找到你的解决方案，避免重复提问。
如何解读答案
RTFM 和 STFW：如何知道你已完全搞砸了
有一个古老而神圣的传统：如果你收到 RTFM (Read The Fucking Manual) 的回复，回答者认为你应该去读该死的手册。当然，基本上他是对的，你应该去读一读。
RTFM 有一个年轻的亲戚。如果你收到 STFW (Search The Fucking Web) 的回复，回答者认为你应该去搜该死的网页。那人多半也是对的，去搜索一下吧。（一个更温和的说法是：Google 是你的朋友！）
通常，用这两个词之一回复你的人会附上你需要阅读的手册或网址，并且他们自己也正在看那个链接。这些回复意味着，他们认为：
- 你需要的信息非常容易获得。
- 你自己去搜索这些信息，比让他们灌输给你，能让你学到更多。
你不应该因此不高兴。按照社区的标准，他已经对你表现出了最起码的关注，而没有完全忽略你。你应该对他这种“祖母般”的慈祥表示感谢。
如果还是搞不懂
如果你看不懂回复，不要立刻要求对方解释。像你之前尝试自己解决问题时那样（利用手册、FAQ、网络、身边的高手），先试着去搞懂他给出的回复。如果你真的需要对方解释，记得表现出你已经从中学到了点什么。
糟糕的后续提问: “zentry 是什么东西？”
聪明的后续提问: “哦，我看过手册了，但是只在
-z和-p两个参数中提到了 zentries，而且都没有清楚地解释如何清除它。您是指这两个中的哪一个吗？还是我理解错了什么？”
处理无礼的回应
很多技术社区中看似无礼的行为，并非存心冒犯。相反，它是一种直接、就事论事的交流风格，这种风格更注重解决问题，而不是让人感觉舒服。
如果你觉得被冒犯了，试着保持冷静。如果有人真的做得过火，社区里的前辈多半会指出来。如果这没有发生而你却大发雷霆，那么你发火的对象所说的话，可能在社区文化中是正常的，而你将被视为有过错的一方。
另一方面，你偶尔真的会碰到无礼和无聊的言行。此时，对真正的冒犯者狠狠地回击，用犀利的语言将其驳得体_完肤，是可以接受的。然而，在行事之前一定要非常有把握。纠正无礼言论与挑起一场毫无意义的口水战仅一线之隔。如果你是新手或外人，最好不要轻易尝试。
💡 记住：你想得到的是信息，而不是消磨时光。
如何避免扮演失败者
在技术社区的论坛中，你总有几次可能会搞砸。而你会在公开场合被告知你是如何搞砸的。
发生这种事后，你能做的最糟糕的事莫过于：
- 哀嚎自己的遭遇
- 宣称被口头攻击
- 要求道歉
- 威胁要诉诸法律
- 向其雇主抱怨
- 忘了关马桶盖等等
相反，你该这么做：
熬过去。这很正常。事实上，它对你有益无害。
社区的标准不会自行维持，它们是通过参与者积极而公开地执行来维持的。不要哭诉说所有的批评都应该通过私下邮件传送，它不是这样运作的。当有人评论你的一个说法有误或者提出不同看法时，坚持声称受到个人攻击也毫无益处，这些都是失败者的态度。
一个夸张的讲法是：你要的是友善（以上述方式）还是有用？两个里面挑一个。
记住：当社区专家说你搞砸了，并且（无论多么刺耳）告诉你别再这样做时，他正在为关心你和他的社区而行动。对他而言，不理你并将你从他的生活中过滤掉会更简单。如果你无法心存感激，至少要表现得有点尊严，别大声哀嚎。
不该问的问题
以下是几个经典蠢问题，以及专家们没回答时心中所想的：
问题：我能在哪找到 X 程序或 X 资源？
心中所想：就在我找到它的地方啊，笨蛋——搜索引擎的那一头。天哪！难道还有人不会用 Google 吗？
问题：我怎样用 X 做 Y？
心中所想：如果你想解决的是
Y，提问时就别给出可能并不恰当的方法。这种问题说明提问者不但对X完全无知，也对Y要解决的问题糊里糊涂，还被特定思维禁锢了。最好忽略这种人，等他们把问题搞清楚了再说。
问题：我的 HyperFRP 配置文件/隧道/程序不工作了。
心中所想：这不算是问题吧，我对要我问你二十个问题才找得出你真正问题的问题没兴趣——我有更有意思的事要做呢。我的反应通常不外乎：“你还有什么要补充的吗？”或者“真糟糕，希望你能搞定。”
问题：我的 Windows 电脑有问题，你能帮我吗？
心中所想：能啊，扔掉微软的垃圾，换个像 Linux 或 BSD 的开放源代码操作系统吧。 注意：如果问题与 HyperFRP 在 Windows 上的特定行为有关，你可以问，只是别对“问题是 Windows 造成的”这类回答感到惊讶。
问题：我怎么才能破解 root 账号/窃取 OP 特权/读别人的邮件呢？
心中所想：想要这样做，说明你是个卑鄙小人；想找个专家帮你，说明你是个白痴！
好问题与蠢问题的对比
最后，我将通过举一些例子，来说明怎样是聪明的提问。同一个问题的两种问法，一种是愚蠢的，另一种才是明智的。
蠢问题:
我可以在哪儿找到关于 Foonly Flurbamatic 的资料？
这种问法无非是想得到 STFW 这样的回答。
聪明问题:
我用 Google 搜索过 "Foonly Flurbamatic 2600"，但是没找到有用的结果。谁知道上哪儿去找对这种设备编程的资料？
这个问题已经 STFW 过了，看起来他真的遇到了麻烦。
蠢问题:
我从 foo 项目找来的源码没法编译。它怎么这么烂？
他觉得都是别人的错，这个傲慢自大的提问者。
聪明问题:
foo 项目代码在 Nulix 6.2 版下无法编译通过。我读过了 FAQ，但里面没有提到跟 Nulix 有关的问题。这是我编译过程的记录，我有什么做的不对的地方吗？
提问者已经指明了环境，也读过了 FAQ，还列出了错误，并且他没有把问题的责任推到别人头上，他的问题值得被关注。
蠢问题:
我的主机板有问题了，谁来帮我？
某专家对这类问题的回答通常是：“好的，还要帮你拍拍背和换尿布吗？”，然后按下删除键。
聪明问题:
我在 S2464 主机板上试过了 X、Y 和 Z，但没什么作用，我又试了 A、B 和 C。请注意当我尝试 C 时的奇怪现象。显然 florbish 正在 grommicking，但结果出人意料。通常在 Athlon MP 主机板上引起 grommicking 的原因是什么？有谁知道接下来我该做些什么测试才能找出问题？
这个家伙，从另一个角度来看，值得去回答他。他表现出了解决问题的能力，而不是坐等天上掉答案。
如果得不到回答
如果仍得不到回答，请不要以为我们觉得无法帮助你。有时只是看到你问题的人不知道答案罢了。没有回应不代表你被忽视，虽然不可否认这种差别很难区分。
总的来说，简单的重复张贴问题是个很糟的点子，这将被视为无意义的喧闹。请保持耐心，知道你问题答案的人可能生活在不同的时区，可能正在睡觉。
你可以通过其他渠道获得帮助，这些渠道通常更适合初学者的需要。有许多网上的以及本地的用户群组，由热情的软件爱好者（即使他们可能从没亲自写过任何软件）组成。通常人们组建这样的团体来互相帮助并帮助新手。
另外，你也可以向很多商业公司寻求帮助，不论公司大还是小。别为要付费才能获得帮助而感到沮ช! 毕竟，假使你的汽车发动机汽缸密封圈爆掉了，你还得把它送到修车铺，并且为维修付费。就算软件没花费你一分钱，你也不能强求技术支持总是免费的。
如何更好地回答问题
- 态度和善一点。 问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。
- 对初犯者私下回复。 对那些坦诚犯错之人没有必要当众羞辱。
- 如果你不确定，一定要说出来！ 一个听起来权威的错误回复比没有还要糟。
- 如果帮不了忙，也别妨碍他。 不要在实际步骤上开玩笑，那样也许会毁了用户的设置。
- 试探性的反问以引出更多的细节。 如果你做得好，提问者可以学到点东西——你也可以。
- 帮助你的社区从问题中学习。 当回复一个好问题时，问问自己“如何修改相关文件或常见问题文件以免再次解答同样的问题？”，接着再向文件维护者发一份补丁。
- 如果你是在研究一番后才做出的回答，展现你的技巧而不是直接端出结果。 毕竟“授人以鱼不如授人以渔”。
相关资源
如果你需要个人电脑、Unix 系统和网络如何运作的基础知识，参阅 Unix系统和网络基本原理（此处可替换为相关链接）。
鸣谢
感谢 Evelyn Mitchel 贡献了一些愚蠢问题例子并启发了“如何更好地回答问题”这一节，Mikhail Ramendik 贡献了一些特别有价值的建议和改进。
感谢一诺对本项目的支持与贡献！