心种子的技术日志站点，主要记录日常建站过程中遇到的各类问题，包括MediaWiki、WordPress、Limesurvey等开源系统的点滴教程。
本文转载自https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README-zh_CN.md，实在是觉得太经典了。声明许多项目在他们的使用协助/说明网页中链接了本指南，这么做很好，我们也鼓励大家都这么做。但如果你是负责管理这个项目网页的人，请在超链接附近的显著位置上注明：本指南不提供此项目的实际支持服务！我们已经深刻领教到少了上述声明所带来的痛苦。因为少了这点声明，我们不停地被一些白痴纠缠。这些白痴认为既然我们发布了这本指南，那么我们就有责任解决世上所有的技术问题。如果你因寻求某些帮助而阅读本指南，并在离开时还觉得可以从本文作者这里得到直接帮助，那你就是我们之前说的那些白痴之一。别问我们问题，我们只会忽略你。我们在这本指南中是教你如何从那些真正懂得你所遇到软件或硬件问题的人取得协助，而 99% 的情况下那不会是我们。除非你确定本指南的作者之一刚好是你所遇到的问题领域的专家，否则请不要打扰我们，这样大家都会开心一点。简介在黑客的世界里，当你拋出一个技术问题时，最终是否能得到有用的回答，往往取决于你所提问和追问的方式。本指南将教你如何正确的提问以获得你满意的答案。不只是黑客，现在开源（Open Source）软件已经相当盛行，你常常也可以由其他有经验的使用者身上得到好答案，这是件好事；使用者比起黑客来，往往对那些新手常遇到的问题更宽容一些。然而，将有经验的使用者视为黑客，并采用本指南所提的方法与他们沟通，同样也是能从他们身上得到满意回答的最有效方式。首先你应该明白，黑客们喜爱有挑战性的问题，或者能激发他们思维的好问题。如果我们并非如此，那我们也不会成为你想询问的对象。如果你给了我们一个值得反复咀嚼玩味的好问题，我们自会对你感激不尽。好问题是激励，是厚礼。好问题可以提高我们的理解力，而且通常会暴露我们以前从没意识到或者思考过的问题。对黑客而言，"好问题！"是诚挚的大力称赞。尽管如此，黑客们有着蔑视或傲慢面对简单问题的坏名声，这有时让我们看起来对新手、无知者似乎较有敌意，但其实不是那样的。我们不讳言我们对那些不愿思考、或者在发问前不做他们该做的事的人的蔑视。那些人是时间杀手 —— 他们只想索取，从不付出，消耗我们可用在更有趣的问题或更值得回答的人身上的时间。我们称这样的人为 失败者（撸瑟） （由于历史原因，我们有时把它拼作 lusers）。我们意识到许多人只是想使用我们写的软件，他们对学习技术细节没有兴趣。对大多数人而言，电脑只是种工具，是种达到目的的手段而已。他们有自己的生活并且有更要紧的事要做。我们了解这点，也从不指望每个人都对这些让我们着迷的技术问题感兴趣。尽管如此，我们回答问题的风格是指向那些真正对此有兴趣并愿意主动参与解决问题的人，这一点不会变，也不该变。如果连这都变了，我们就是在降低做自己最擅长的事情上的效率。我们（在很大程度上）是自愿的，从繁忙的生活中抽出时间来解答疑惑，而且时常被提问淹没。所以我们无情的滤掉一些话题，特别是拋弃那些看起来像失败者的家伙，以便更高效的利用时间来回答赢家（winner）的问题。如果你厌恶我们的态度，高高在上，或过于傲慢，不妨也设身处地想想。我们并没有要求你向我们屈服 —— 事实上，我们大多数人非常乐意与你平等地交流，只要你付出小小努力来满足基本要求，我们就会欢迎你加入我们的文化。但让我们帮助那些不愿意帮助自己的人是没有效率的。无知没有关系，但装白痴就是不行。所以，你不必在技术上很在行才能吸引我们的注意，但你必须表现出能引导你变得在行的特质 —— 机敏、有想法、善于观察、乐于主动参与解决问题。如果你做不到这些使你与众不同的事情，我们建议你花点钱找家商业公司签个技术支持服务合同，而不是要求黑客个人无偿地帮助你。如果你决定向我们求助，当然你也不希望被视为失败者，更不愿成为失败者中的一员。能立刻得到快速并有效答案的最好方法，就是像赢家那样提问 —— 聪明、自信、有解决问题的思路，只是偶尔在特定的问题上需要获得一点帮助。（欢迎对本指南提出改进意见。你可以 email 你的建议至 esr@thyrsus.com 或 respond-auto@linuxmafia.com。然而请注意，本文并非网络礼节的通用指南，而我们通常会拒绝无助于在技术论坛得到有用答案的建议）。在提问之前在你准备要通过电子邮件、新闻群组或者聊天室提出技术问题前，请先做到以下事情：尝试在你准备提问的论坛的旧文章中搜索答案。尝试上网搜索以找到答案。尝试阅读手册以找到答案。尝试阅读常见问题文件（FAQ）以找到答案。尝试自己检查或试验以找到答案。向你身边的强者朋友打听以找到答案。如果你是程序开发者，请尝试阅读源代码以找到答案。当你提出问题的时候，请先表明你已经做了上述的努力；这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。如果你能一并表达在做了上述努力的过程中所学到的东西会更好，因为我们更乐于回答那些表现出能从答案中学习的人的问题。运用某些策略，比如先用 Google 搜索你所遇到的各种错误信息（搜索 Google 论坛和网页），这样很可能直接就找到了能解决问题的文件或邮件列表线索。即使没有结果，在邮件列表或新闻组寻求帮助时加上一句 我在 Google 中搜过下列句子但没有找到什么有用的东西 也是件好事，即使它只是表明了搜索引擎不能提供哪些帮助。这么做（加上搜索过的字串）也让遇到相似问题的其他人能被搜索引擎引导到你的提问来。别着急，不要指望几秒钟的 Google 搜索就能解决一个复杂的问题。在向专家求助之前，再阅读一下常见问题文件（FAQ）、放轻松、坐舒服一些，再花点时间思考一下这个问题。相信我们，他们能从你的提问看出你做了多少阅读与思考，如果你是有备而来，将更有可能得到解答。不要将所有问题一股脑拋出，只因你的第一次搜索没有找到答案（或者找到太多答案）。准备好你的问题，再将问题仔细的思考过一遍，因为草率的发问只能得到草率的回答，或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力，你越有可能得到实质性的帮助。小心别问错了问题。如果你的问题基于错误的假设，某个普通黑客（J. Random Hacker）多半会一边在心里想着蠢问题…， 一边用无意义的字面解释来答复你，希望着你会从问题的回答（而非你想得到的答案）中汲取教训。绝不要自以为够格得到答案，你没有；你并没有。毕竟你没有为这种服务支付任何报酬。你将会是自己去挣到一个答案，靠提出有内涵的、有趣的、有思维激励作用的问题 —— 一个有潜力能贡献社区经验的问题，而不仅仅是被动的从他人处索取知识。另一方面，表明你愿意在找答案的过程中做点什么是一个非常好的开端。谁能给点提示？、我的这个例子里缺了什么？以及我应该检查什么地方比请把我需要的确切的过程贴出来更容易得到答复。因为你表现出只要有人能指个正确方向，你就有完成它的能力和决心。当你提问时慎选提问的论坛小心选择你要提问的场合。如果你做了下述的事情，你很可能被忽略掉或者被看作失败者：在与主题不合的论坛上贴出你的问题。在探讨进阶技术问题的论坛张贴非常初级的问题；反之亦然。在太多的不同新闻群组上重复转贴同样的问题（cross-post）。向既非熟人也没有义务解决你问题的人发送私人电邮。黑客会剔除掉那些搞错场合的问题，以保护他们沟通的渠道不被无关的东西淹没。你不会想让这种事发生在自己身上的。因此，第一步是找到对的论坛。再说一次，Google 和其它搜索引擎还是你的朋友，用它们来找到与你遭遇到困难的软硬件问题最相关的网站。通常那儿都有常见问题（FAQ）、邮件列表及相关说明文件的链接。如果你的努力（包括阅读 FAQ）都没有结果，网站上也许还有报告 Bug（Bug-reporting）的流程或链接，如果是这样，链过去看看。向陌生的人或论坛发送邮件最可能是风险最大的事情。举例来说，别假设一个提供丰富内容的网页的作者会想充当你的免费顾问。不要对你的问题是否会受到欢迎做太乐观的估计 —— 如果你不确定，那就向别处发送，或者压根别发。在选择论坛、新闻群组或邮件列表时，别太相信名字，先看看 FAQ 或者许可书以弄清楚你的问题是否切题。发文前先翻翻已有的话题，这样可以让你感受一下那里的文化。事实上，事先在新闻组或邮件列表的历史记录中搜索与你问题相关的关键词是个极好的主意，也许这样就找到答案了。即使没有，也能帮助你归纳出更好的问题。别像机关枪似的一次"扫射"所有的帮助渠道，这就像大喊大叫一样会使人不快。要一个一个地来。搞清楚你的主题！最典型的错误之一是在某种致力于跨平台可移植的语言、套件或工具的论坛中提关于 Unix 或 Windows 操作系统程序界面的问题。如果你不明白为什么这是大错，最好在搞清楚这之间差异之前什么也别问。一般来说，在仔细挑选的公共论坛中提问，会比在私有论坛中提同样的问题更容易得到有用的回答。有几个理由可以支持这点，一是看潜在的回复者有多少，二是看观众有多少。黑客较愿意回答那些能帮助到许多人的问题。可以理解的是，老练的黑客和一些热门软件的作者正在接受过多的错发信息。就像那根最后压垮骆驼背的稻草一样，你的加入也有可能使情况走向极端 —— 已经好几次了，一些热门软件的作者从自己软件的支持中抽身出来，因为伴随而来涌入其私人邮箱的无用邮件变得无法忍受。Stack Overflow搜索，然后 在 Stack Exchange 问。近年来，Stack Exchange 社区已经成为回答技术及其他问题的主要渠道，尤其是那些开放源码的项目。因为 Google 索引是即时的，在看 Stack Exchange 之前先在 Google 搜索。有很高的机率某人已经问了一个类似的问题，而且 Stack Exchange 网站们往往会是搜索结果中最前面几个。如果你在 Google 上没有找到任何答案，你再到特定相关主题的网站去找。用标签（Tag）搜索能让你更缩小你的搜索结果。Stack Exchange 已经成长到超过一百个网站，以下是最常用的几个站：Super User 是问一些通用的电脑问题，如果你的问题跟代码或是写程序无关，只是一些网络连线之类的，请到这里。Stack Overflow 是问写程序有关的问题。Server Fault 是问服务器和网管相关的问题。网站和 IRC 论坛本地的使用者群组（user group），或者你所用的 Linux 发行版本也许正在宣传他们的网页论坛或 IRC 频道，并提供新手帮助（在一些非英语国家，新手论坛很可能还是邮件列表）， 这些地方是开始提问的好首选，特别是当你觉得遇到的也许只是相对简单或者很普通的问题时。有广告赞助的 IRC 频道是公开欢迎提问的地方，通常可以即时得到回应。事实上，如果程序出的问题只发生在特定 Linux 发行版提供的版本（这很常见），最好先去该发行版的论坛或邮件列表中提问，再到程序本身的论坛或邮件列表提问。（否则）该项目的黑客可能仅仅回复 "用我们的版本"。在任何论坛发文以前，先确认一下有没有搜索功能。如果有，就试着搜索一下问题的几个关键词，也许这会有帮助。如果在此之前你已做过通用的网页搜索（你也该这样做），还是再搜索一下论坛，搜索引擎有可能没来得及索引此论坛的全部内容。通过论坛或 IRC 频道来提供使用者支持服务有增长的趋势，电子邮件则大多为项目开发者间的交流而保留。所以最好先在论坛或 IRC 中寻求与该项目相关的协助。在使用 IRC 的时候，首先最好不要发布很长的问题描述，有些人称之为频道洪水。最好通过一句话的问题描述来开始聊天。第二步，使用项目邮件列表当某个项目提供开发者邮件列表时，要向列表而不是其中的个别成员提问，即使你确信他能最好地回答你的问题。查一查项目的文件和首页，找到项目的邮件列表并使用它。有几个很好的理由支持我们采用这种办法：任何好到需要向个别开发者提出的问题，也将对整个项目群组有益。反之，如果你认为自己的问题对整个项目群组来说太愚蠢，也不能成为骚扰个别开发者的理由。向列表提问可以分散开发者的负担，个别开发者（尤其是项目领导人）也许太忙以至于没法回答你的问题。大多数邮件列表都会被存档，那些被存档的内容将被搜索引擎索引。如果你向列表提问并得到解答，将来其它人可以通过网页搜索找到你的问题和答案，也就不用再次发问了。如果某些问题经常被问到，开发者可以利用此信息来改进说明文件或软件本身，以使其更清楚。如果只是私下提问，就没有人能看到最常见问题的完整场景。如果一个项目既有"使用者" 也有"开发者"（或"黑客"）邮件列表或论坛，而你又不会动到那些源代码，那么就向"使用者"列表或论坛提问。不要假设自己会在开发者列表中受到欢迎，那些人多半会将你的提问视为干扰他们开发的噪音。然而，如果你确信你的问题很特别，而且在"使用者" 列表或论坛中几天都没有回复，可以试试前往"开发者"列表或论坛发问。建议你在张贴前最好先暗地里观察几天以了解那里的行事方式（事实上这是参与任何私有或半私有列表的好主意）如果你找不到一个项目的邮件列表，而只能查到项目维护者的电子邮件地址，尽管向他发信。即使是在这种情况下，也别假设（项目）邮件列表不存在。在你的电子邮件中，请陈述你已经试过但没有找到合适的邮件列表，也提及你不反对将自己的邮件转发给他人（许多人认为，即使没什么秘密，私人电子邮件也不应该被公开。通过允许将你的电子邮件转发他人，你给了相应人员处置你邮件的选择）。使用有意义且描述明确的标题在邮件列表、新闻群组或论坛中，大约 50 字以内的标题是抓住资深专家注意力的好机会。别用喋喋不休的帮帮忙、跪求、急（更别说救命啊！！！！这样让人反感的话，用这种标题会被条件反射式地忽略）来浪费这个机会。不要妄想用你的痛苦程度来打动我们，而应该是在这点空间中使用极简单扼要的描述方式来提出问题。一个好标题范例是目标 —— 差异式的描述，许多技术支持组织就是这样做的。在目标部分指出是哪一个或哪一组东西有问题，在差异部分则描述与期望的行为不一致的地方。蠢问题：救命啊！我的笔记本电脑不能正常显示了！聪明问题：X.org 6.8.1 的鼠标光标会变形，某牌显卡 MV1005 芯片组。更聪明问题：X.org 6.8.1 的鼠标光标，在某牌显卡 MV1005 芯片组环境下 - 会变形。编写目标 —— 差异 式描述的过程有助于你组织对问题的细致思考。是什么被影响了？ 仅仅是鼠标光标或者还有其它图形？只在 X.org 的 X 版中出现？或只是出现在 6.8.1 版中？ 是针对某牌显卡芯片组？或者只是其中的 MV1005 型号？ 一个黑客只需瞄一眼就能够立即明白你的环境和你遇到的问题。总而言之，请想像一下你正在一个只显示标题的存档讨论串（Thread）索引中查寻。让你的标题更好地反映问题，可使下一个搜索类似问题的人能够关注这个讨论串，而不用再次提问相同的问题。如果你想在回复中提出问题，记得要修改内容标题，以表明你是在问一个问题， 一个看起来像 Re: 测试 或者 Re: 新 bug 的标题很难引起足够重视。另外，在不影响连贯性之下，适当引用并删减前文的内容，能给新来的读者留下线索。对于讨论串，不要直接点击回复来开始一个全新的讨论串，这将限制你的观众。因为有些邮件阅读程序，比如 mutt ，允许使用者按讨论串排序并通过折叠讨论串来隐藏消息，这样做的人永远看不到你发的消息。仅仅改变标题还不够。mutt 和其它一些邮件阅读程序还会检查邮件标题以外的其它信息，以便为其指定讨论串。所以宁可发一个全新的邮件。在网页论坛上，好的提问方式稍有不同，因为讨论串与特定的信息紧密结合，并且通常在讨论串外就看不到里面的内容，故通过回复提问，而非改变标题是可接受的。不是所有论坛都允许在回复中出现分离的标题，而且这样做了基本上没有人会去看。不过，通过回复提问，这本身就是暧昧的做法，因为它们只会被正在查看该标题的人读到。所以，除非你只想在该讨论串当前活跃的人群中提问，不然还是另起炉灶比较好。使问题容易回复以请将你的回复发送到……来结束你的问题多半会使你得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都麻烦，我们也觉得花几秒钟思考你的问题更麻烦。如果你的邮件程序不支持这样做，换个好点的；如果是操作系统不支持这种邮件程序，也换个好点的。在论坛，要求通过电子邮件回复是非常无礼的，除非你认为回复的信息可能比较敏感（有人会为了某些未知的原因，只让你而不是整个论坛知道答案）。如果你只是想在有人回复讨论串时得到电子邮件提醒，可以要求网页论坛发送给你。几乎所有论坛都支持诸如追踪此讨论串、有回复时发送邮件提醒等功能。用清晰、正确、精准且语法正确的语句我们从经验中发现，粗心的提问者通常也会粗心的写程序与思考（我敢打包票）。回答粗心大意者的问题很不值得，我们宁愿把时间耗在别处。正确的拼写、标点符号和大小写是很重要的。一般来说，如果你觉得这样做很麻烦，不想在乎这些，那我们也觉得麻烦，不想在乎你的提问。花点额外的精力斟酌一下字句，用不着太僵硬与正式 —— 事实上，黑客文化很看重能准确地使用非正式、俚语和幽默的语句。但它必须很准确，而且有迹象表明你是在思考和关注问题。正确地拼写、使用标点和大小写，不要将its混淆为it's，loose搞成lose或者将discrete弄成discreet。不要全部用大写，这会被视为无礼的大声嚷嚷（全部小写也好不到哪去，因为不易阅读。Alan Cox 也许可以这样做，但你不行）。更白话的说，如果你写得像是个半文盲译注：[小白]，那多半得不到理睬。也不要使用即时通信中的简写或火星文，如将的简化为d会使你看起来像一个为了少打几个键而省字的小白。更糟的是，如果像个小孩似地鬼画符那绝对是在找死，可以肯定没人会理你（或者最多是给你一大堆指责与挖苦）。如果在使用非母语的论坛提问，你可以犯点拼写和语法上的小错，但决不能在思考上马虎（没错，我们通常能弄清两者的分别）。同时，除非你知道回复者使用的语言，否则请使用英语书写。繁忙的黑客一般会直接删除用他们看不懂语言写的消息。在网络上英语是通用语言，用英语书写可以将你的问题在尚未被阅读就被直接删除的可能性降到最低。如果英文是你的外语（Second language），提示潜在回复者你有潜在的语言困难是很好的：[译注：以下附上原文以供使用]English is not my native language; please excuse typing errors.英文不是我的母语，请原谅我的错字或语法。If you speak $LANGUAGE, please email/PM me;I may need assistance translating my question.如果你说某语言，请寄信/私讯给我；我需要有人协助我翻译我的问题。I am familiar with the technical terms,but some slang expressions and idioms are difficult for me.我对技术名词很熟悉，但对于俗语或是特别用法比较不甚了解。I've posted my question in $LANGUAGE and English.I'll be glad to translate responses, if you only use one or the other.我把我的问题用某语言和英文写出来，如果你只用一种语言回答，我会乐意将其翻译成另一种。使用易于读取且标准的文件格式发送问题如果你人为地将问题搞得难以阅读，它多半会被忽略，人们更愿读易懂的问题，所以：使用纯文字而不是 HTML (关闭 HTML 并不难）。使用 MIME 附件通常是可以的，前提是真正有内容（譬如附带的源代码或 patch），而不仅仅是邮件程序生成的模板（譬如只是信件内容的拷贝）。不要发送一段文字只是一行句子但自动换行后会变成多行的邮件（这使得回复部分内容非常困难）。设想你的读者是在 80 个字符宽的终端机上阅读邮件，最好设置你的换行分割点小于 80 字。但是，对一些特殊的文件不要设置固定宽度（譬如日志档案拷贝或会话记录）。数据应该原样包含，让回复者有信心他们看到的是和你看到的一样的东西。在英语论坛中，不要使用Quoted-Printable MIME 编码发送消息。这种编码对于张贴非 ASCII 语言可能是必须的，但很多邮件程序并不支持这种编码。当它们处理换行时，那些文本中四处散布的=20符号既难看也分散注意力，甚至有可能破坏内容的语意。绝对，永远不要指望黑客们阅读使用封闭格式编写的文档，像微软公司的 Word 或 Excel 文件等。大多数黑客对此的反应就像有人将还在冒热气的猪粪倒在你家门口时你的反应一样。即便他们能够处理，他们也很厌恶这么做。如果你从使用 Windows 的电脑发送电子邮件，关闭微软愚蠢的智能引号功能 （从[选项] > [校订] > [自动校正选项]，勾选掉智能引号单选框），以免在你的邮件中到处散布垃圾字符。在论坛，勿滥用表情符号和HTML功能（当它们提供时）。一两个表情符号通常没有问题，但花哨的彩色文本倾向于使人认为你是个无能之辈。过滥地使用表情符号、色彩和字体会使你看来像个傻笑的小姑娘。这通常不是个好主意，除非你只是对性而不是对答案感兴趣。如果你使用图形用户界面的邮件程序（如微软公司的 Outlook 或者其它类似的），注意它们的默认设置不一定满足这些要求。大多数这类程序有基于选单的查看源代码命令，用它来检查发送文件夹中的邮件，以确保发送的是纯文本文件同时没有一些奇怪的字符。精确地描述问题并言之有物仔细、清楚地描述你的问题或 Bug 的症状。描述问题发生的环境（机器配置、操作系统、应用程序、以及相关的信息），提供经销商的发行版和版本号（如：Fedora Core 4、Slackware 9.1等）。描述在提问前你是怎样去研究和理解这个问题的。描述在提问前为确定问题而采取的诊断步骤。描述最近做过什么可能相关的硬件或软件变更。尽可能的提供一个可以重现这个问题的可控环境的方法。尽量去揣测一个黑客会怎样反问你，在你提问之前预先将黑客们可能遇到的问题回答一遍。以上几点中，当你报告的是你认为可能在代码中的问题时，给黑客一个可以重现你的问题的环境尤其重要。当你这么做时，你得到有效的回答的机会和速度都会大大的提升。Simon Tatham 写过一篇名为《如何有效的报告 Bug》的出色文章。强力推荐你也读一读。话不在多而在精你需要提供精确有内容的信息。这并不是要求你简单的把成堆的出错代码或者资料完全转录到你的提问中。如果你有庞大而复杂的测试样例能重现程序挂掉的情境，尽量将它剪裁得越小越好。这样做的用处至少有三点。第一，表现出你为简化问题付出了努力，这可以使你得到回答的机会增加；第二，简化问题使你更有可能得到有用的答案；第三，在精炼你的 bug 报告的过程中，你很可能就自己找到了解决方法或权宜之计。别动辄声称找到 Bug当你在使用软件中遇到问题，除非你非常、非常的有根据，不要动辄声称找到了 Bug。提示：除非你能提供解决问题的源代码补丁，或者提供回归测试来表明前一版本中行为不正确，否则你都多半不够完全确信。这同样适用在网页和文件，如果你（声称）发现了文件的Bug，你应该能提供相应位置的修正或替代文件。请记得，还有许多其它使用者没遇到你发现的问题，否则你在阅读文件或搜索网页时就应该发现了（你在抱怨前已经做了这些，是吧？）。这也意味着很有可能是你弄错了而不是软件本身有问题。编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了 Bug，也就是在质疑他们的能力，即使你是对的，也有可能会冒犯到其中某部分人。当你在标题中嚷嚷着有Bug时，这尤其严重。提问时，即使你私下非常确信已经发现一个真正的 Bug，最好写得像是你做错了什么。如果真的有 Bug，你会在回复中看到这点。这样做的话，如果真有 Bug，维护者就会向你道歉，这总比你惹恼别人然后欠别人一个道歉要好一点。低声下气不能代替你的功课有些人明白他们不该粗鲁或傲慢的提问并要求得到答复，但他们选择另一个极端 —— 低声下气：我知道我只是个可悲的新手，一个撸瑟，但...。这既使人困扰，也没有用，尤其是伴随着与实际问题含糊不清的描述时更令人反感。别用原始灵长类动物的把戏来浪费你我的时间。取而代之的是，尽可能清楚地描述背景条件和你的问题情况。这比低声下气更好地定位了你的位置。有时网页论坛会设有专为新手提问的版面，如果你真的认为遇到了初学者的问题，到那去就是了，但一样别那么低声下气。描述问题症状而非你的猜测告诉黑客们你认为问题是怎样造成的并没什么帮助。（如果你的推断如此有效，还用向别人求助吗？），因此要确信你原原本本告诉了他们问题的症状，而不是你的解释和理论；让黑客们来推测和诊断。如果你认为陈述自己的猜测很重要，清楚地说明这只是你的猜测，并描述为什么它们不起作用。蠢问题我在编译内核时接连遇到 SIG11 错误，我怀疑某条飞线搭在主板的走线上了，这种情况应该怎样检查最好？聪明问题我的组装电脑是 FIC-PA2007 主机板搭载 AMD K6/233 CPU（威盛 Apollo VP2 芯片组），256MB Corsair PC133 SDRAM 内存，在编译内核时，从开机 20 分钟以后就频频产生 SIG11 错误，但是在头 20 分钟内从没发生过相同的问题。重新启动也没有用，但是关机一晚上就又能工作 20 分钟。所有内存都换过了，没有效果。相关部分的标准编译记录如下…。由于以上这点似乎让许多人觉得难以配合，这里有句话可以提醒你：所有的诊断专家都来自密苏里州。 美国国务院的官方座右铭则是：让我看看（出自国会议员 Willard D. Vandiver 在 1899 年时的讲话：我来自一个出产玉米，棉花，牛蒡和民主党人的国家，滔滔雄辩既不能说服我，也不会让我满意。我来自密苏里州，你必须让我看看。） 针对诊断者而言，这并不是一种怀疑，而只是一种真实而有用的需求，以便让他们看到的是与你看到的原始证据尽可能一致的东西，而不是你的猜测与归纳的结论。所以，大方的展示给我们看吧！按发生时间先后列出问题症状问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。因此，你的说明里应该包含你的操作步骤，以及机器和软件的反应，直到问题发生。在命令行处理的情况下，提供一段操作记录（例如运行脚本工具所生成的），并引用相关的若干行（如 20 行）记录会非常有帮助。如果挂掉的程序有诊断选项（如 -v 的详述开关），试着选择这些能在记录中增加调试信息的选项。记住，多不等于好。试着选取适当的调试级别以便提供有用的信息而不是让读者淹没在垃圾中。如果你的说明很长（如超过四个段落），在开头简述问题，接下来再按时间顺序详述会有所帮助。这样黑客们在读你的记录时就知道该注意哪些内容了。描述目标而不是过程如果你想弄清楚如何做某事（而不是报告一个 Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。经常寻求技术帮助的人在心中有个更高层次的目标，而他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。蠢问题我怎样才能从某绘图程序的颜色选择器中取得十六进制的的 RGB 值？聪明问题我正试着用替换一幅图片的色码（color table）成自己选定的色码，我现在知道的唯一方法是编辑每个色码区块（table slot），但却无法从某绘图程序的颜色选择器取得十六进制的的 RGB 值。第二种提问法比较聪明，你可能得到像是建议采用另一个更合适的工具的回复。别要求使用私人电邮回复黑客们认为问题的解决过程应该公开、透明，此过程中如果更有经验的人注意到不完整或者不当之处，最初的回复才能够、也应该被纠正。同时，作为提供帮助者可以得到一些奖励，奖励就是他的能力和学识被其他同行看到。当你要求私下回复时，这个过程和奖励都被中止。别这样做，让回复者来决定是否私下回答 —— 如果他真这么做了，通常是因为他认为问题编写太差或者太肤浅，以至于对其它人没有兴趣。这条规则存在一条有限的例外，如果你确信提问可能会引来大量雷同的回复时，那么这个神奇的提问句会是向我发电邮，我将为论坛归纳这些回复。试着将邮件列表或新闻群组从洪水般的雷同回复中解救出来是非常有礼貌的 —— 但你必须信守诺言。清楚明确的表达你的问题以及需求漫无边际的提问是近乎无休无止的时间黑洞。最有可能给你有用答案的人通常也正是最忙的人（他们忙是因为要亲自完成大部分工作）。这样的人对无节制的时间黑洞相当厌恶，所以他们也倾向于厌恶那些漫无边际的提问。如果你明确表述需要回答者做什么（如提供指点、发送一段代码、检查你的补丁、或是其他等等），就最有可能得到有用的答案。因为这会定出一个时间和精力的上限，便于回答者能集中精力来帮你。这么做很棒。要理解专家们所处的世界，请把专业技能想像为充裕的资源，而回复的时间则是稀缺的资源。你要求他们奉献的时间越少，你越有可能从真正专业而且很忙的专家那里得到解答。所以，界定一下你的问题，使专家花在辨识你的问题和回答所需要付出的时间减到最少，这技巧对你有用答案相当有帮助 —— 但这技巧通常和简化问题有所区别。因此，问我想更好的理解 X，可否指点一下哪有好一点说明？通常比问你能解释一下 X 吗？更好。如果你的代码不能运作，通常请别人看看哪里有问题，比要求别人替你改正要明智得多。询问有关代码的问题时别要求他人帮你调试有问题的代码，不提示一下应该从何入手。张贴几百行的代码，然后说一声：它不能工作会让你完全被忽略。只贴几十行代码，然后说一句：在第七行以后，我期待它显示 <x>，但实际出现的是 <y>比较有可能让你得到回应。最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例（bug-demonstrating test case）。什么是最精简的测试用例？那是问题的缩影；一小个程序片段能刚好展示出程序的异常行为，而不包含其他令人分散注意力的内容。怎么制作最精简的测试用例？如果你知道哪一行或哪一段代码会造成异常的行为，复制下来并加入足够重现这个状况的代码（例如，足以让这段代码能被编译/直译/被应用程序处理）。如果你无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分。总之，测试用例越小越好（查看话不在多而在精一节）。一般而言，要得到一段相当精简的测试用例并不太容易，但永远先尝试这样做的是种好习惯。这种方式可以帮助你了解如何自行解决这个问题 —— 而且即使你的尝试不成功，黑客们也会看到你在尝试取得答案的过程中付出了努力，这可以让他们更愿意与你合作。如果你只是想让别人帮忙审查（Review）一下代码，在信的开头就要说出来，并且一定要提到你认为哪一部分特别需要关注以及为什么。别把自己家庭作业的问题贴上来黑客们很擅长分辨哪些问题是家庭作业式的问题；因为我们中的大多数都曾自己解决这类问题。同样，这些问题得由你来搞定，你会从中学到东西。你可以要求给点提示，但别要求得到完整的解决方案。如果你怀疑自己碰到了一个家庭作业式的问题，但仍然无法解决，试试在使用者群组，论坛或（最后一招）在项目的使用者邮件列表或论坛中提问。尽管黑客们会看出来，但一些有经验的使用者也许仍会给你一些提示。去掉无意义的提问句避免用无意义的话结束提问，例如有人能帮我吗？或者这有答案吗？。首先：如果你对问题的描述不是很好，这样问更是画蛇添足。其次：由于这样问是画蛇添足，黑客们会很厌烦你 —— 而且通常会用逻辑上正确，但毫无意义的回答来表示他们的蔑视， 例如：没错，有人能帮你或者不，没答案。一般来说，避免用 是或否、对或错、有或没有类型的问句，除非你想得到是或否类型的回答。即使你很急也不要在标题写紧急这是你的问题，不是我们的。宣称紧急极有可能事与愿违：大多数黑客会直接删除无礼和自私地企图即时引起关注的问题。更严重的是，紧急这个字（或是其他企图引起关注的标题）通常会被垃圾信过滤器过滤掉 —— 你希望能看到你问题的人可能永远也看不到。有半个例外的情况是，如果你是在一些很高调，会使黑客们兴奋的地方，也许值得这样去做。在这种情况下，如果你有时间压力，也很有礼貌地提到这点，人们也许会有兴趣回答快一点。当然，这风险很大，因为黑客们兴奋的点多半与你的不同。譬如从 NASA 国际空间站（International Space Station）发这样的标题没有问题，但用自我感觉良好的慈善行为或政治原因发肯定不行。事实上，张贴诸如紧急：帮我救救这个毛绒绒的小海豹！肯定让你被黑客忽略或惹恼他们，即使他们认为毛绒绒的小海豹很重要。如果你觉得这点很不可思议，最好再把这份指南剩下的内容多读几遍，直到你弄懂了再发文。礼多人不怪，而且有时还很有帮助彬彬有礼，多用请和谢谢您的关注，或谢谢你的关照。让大家都知道你对他们花时间免费提供帮助心存感激。坦白说，这一点并没有比清晰、正确、精准并合法语法和避免使用专用格式重要（也不能取而代之）。黑客们一般宁可读有点唐突但技术上鲜明的 Bug 报告，而不是那种有礼但含糊的报告。（如果这点让你不解，记住我们是按问题能教给我们什么来评价问题的价值的）然而，如果你有一串的问题待解决，客气一点肯定会增加你得到有用回应的机会。（我们注意到，自从本指南发布后，从资深黑客那里得到的唯一严重缺陷反馈，就是对预先道谢这一条。一些黑客觉得先谢了意味着事后就不用再感谢任何人的暗示。我们的建议是要么先说先谢了，然后事后再对回复者表示感谢，或者换种方式表达感激，譬如用谢谢你的关注或谢谢你的关照。）问题解决后，加个简短的补充说明问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决的，并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注，应该在那里贴一个说明比较恰当。最理想的方式是向最初提问的话题回复此消息，并在标题中包含已修正，已解决或其它同等含义的明显标记。在人来人往的邮件列表里，一个看见讨论串问题 X和问题 X - 已解决的潜在回复者就明白不用再浪费时间了（除非他个人觉得问题 X的有趣），因此可以利用此时间去解决其它问题。补充说明不必很长或是很深入；简单的一句你好，原来是网线出了问题！谢谢大家 – Bill比什么也不说要来的好。事实上，除非结论真的很有技术含量，否则简短可爱的小结比长篇大论更好。说明问题是怎样解决的，但大可不必将解决问题的过程复述一遍。对于有深度的问题，张贴调试记录的摘要是有帮助的。描述问题的最终状态，说明是什么解决了问题，在此之后才指明可以避免的盲点。避免盲点的部分应放在正确的解决方案和其它总结材料之后，而不要将此信息搞成侦探推理小说。列出那些帮助过你的名字，会让你交到更多朋友。除了有礼貌和有内涵以外，这种类型的补充也有助于他人在邮件列表/新闻群组/论坛中搜索到真正解决你问题的方案，让他们也从中受益。至少，这种补充有助于让每位参与协助的人因问题的解决而从中得到满足感。如果你自己不是技术专家或者黑客，那就相信我们，这种感觉对于那些你向他们求助的大师或者专家而言，是非常重要的。问题悬而未决会让人灰心；黑客们渴望看到问题被解决。好人有好报，满足他们的渴望，你会在下次提问时尝到甜头。思考一下怎样才能避免他人将来也遇到类似的问题，自问写一份文件或加个常见问题（FAQ）会不会有帮助。如果是的话就将它们发给维护者。在黑客中，这种良好的后继行动实际上比传统的礼节更为重要，也是你如何透过善待他人而赢得声誉的方式，这是非常有价值的资产。如何解读答案RTFM 和 STFW：如何知道你已完全搞砸了有一个古老而神圣的传统：如果你收到RTFM （Read The Fucking Manual）的回应，回答者认为你应该去读他妈的手册。当然，基本上他是对的，你应该去读一读。RTFM 有一个年轻的亲戚。如果你收到STFW（Search The Fucking Web）的回应，回答者认为你应该到他妈的网上搜索。那人多半也是对的，去搜索一下吧。（更温和一点的说法是 Google 是你的朋友！）在论坛，你也可能被要求去爬爬论坛的旧文。事实上，有人甚至可能热心地为你提供以前解决此问题的讨论串。但不要依赖这种关照，提问前应该先搜索一下旧文。通常，用这两句之一回答你的人会给你一份包含你需要内容的手册或者一个网址，而且他们打这些字的时候也正在读着。这些答复意味着回答者认为你需要的信息非常容易获得；你自己去搜索这些信息比灌给你，能让你学到更多。你不应该因此不爽；依照黑客的标准，他已经表示了对你一定程度的关注，而没有对你的要求视而不见。你应该对他祖母般的慈祥表示感谢。如果还是搞不懂如果你看不懂回应，别立刻要求对方解释。像你以前试着自己解决问题时那样（利用手册，FAQ，网络，身边的高手），先试着去搞懂他的回应。如果你真的需要对方解释，记得表现出你已经从中学到了点什么。比方说，如果我回答你：看来似乎是 zentry 卡住了；你应该先清除它。，然后，这是一个很糟的后续问题回应：zentry 是什么？ 好的问法应该是这样：哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries，而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗？还是我看漏了什么？处理无礼的回应很多黑客圈子中看似无礼的行为并不是存心冒犯。相反，它是直接了当，一针见血式的交流风格，这种风格更注重解决问题，而不是使人感觉舒服而却模模糊糊。如果你觉得被冒犯了，试着平静地反应。如果有人真的做了出格的事，邮件列表、新闻群组或论坛中的前辈多半会招呼他。如果这没有发生而你却发火了，那么你发火对象的言语可能在黑客社区中看起来是正常的，而你将被视为有错的一方，这将伤害到你获取信息或帮助的机会。另一方面，你偶尔真的会碰到无礼和无聊的言行。与上述相反，对真正的冒犯者狠狠地打击，用犀利的语言将其驳得体无完肤都是可以接受的。然而，在行事之前一定要非常非常的有根据。纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔，黑客们自己莽撞地越线的情况并不鲜见。如果你是新手或外人，避开这种莽撞的机会并不高。如果你想得到的是信息而不是消磨时光，这时最好不要把手放在键盘上以免冒险。（有些人断言很多黑客都有轻度的自闭症或亚斯伯格综合症，缺少用于润滑人类社会正常交往所需的神经。这既可能是真也可能是假的。如果你自己不是黑客，兴许你认为我们脑袋有问题还能帮助你应付我们的古怪行为。只管这么干好了，我们不在乎。我们喜欢我们现在这个样子，并且通常对病患标记都有站得住脚的怀疑）。Jeff Bigler 的观察总结和这个相关也值得一读 (tact filters)。在下一节，我们会谈到另一个问题，当你行为不当时所会受到的冒犯。如何避免扮演失败者在黑客社区的论坛中有那么几次你可能会搞砸 —— 以本指南所描述到的或类似的方式。而你会在公开场合中被告知你是如何搞砸的，也许攻击的言语中还会带点夹七夹八的颜色。这种事发生以后，你能做的最糟糕的事莫过于哀嚎你的遭遇、宣称被口头攻击、要求道歉、高声尖叫、憋闷气、威胁诉诸法律、向其雇主报怨、忘了关马桶盖等等。相反地，你该这么做：熬过去，这很正常。事实上，它是有益健康且合理的。社区的标准不会自行维持，它们是通过参与者积极而公开地执行来维持的。不要哭嚎所有的批评都应该通过私下的邮件传送，它不是这样运作的。当有人评论你的一个说法有误或者提出不同看法时，坚持声称受到个人攻击也毫无益处，这些都是失败者的态度。也有其它的黑客论坛，受过高礼节要求的误导，禁止参与者张贴任何对别人帖子挑毛病的消息，并声称如果你不想帮助用户就闭嘴。 结果造成有想法的参与者纷纷离开，这么做只会使它们沦为毫无意义的唠叨与无用的技术论坛。夸张的讲法是：你要的是“友善”（以上述方式）还是有用？两个里面挑一个。记着：当黑客说你搞砸了，并且（无论多么刺耳）告诉你别再这样做时，他正在为关心你和他的社区而行动。对他而言，不理你并将你从他的生活中滤掉更简单。如果你无法做到感谢，至少要表现得有点尊严，别大声哀嚎，也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者，就指望别人像对待脆弱的洋娃娃那样对你。有时候，即使你没有搞砸（或者只是在他的想像中你搞砸了），有些人也会无缘无故地攻击你本人。在这种情况下，抱怨倒是真的会把问题搞砸。这些来找麻烦的人要么是毫无办法但自以为是专家的不中用家伙，要么就是测试你是否真会搞砸的心理专家。其它读者要么不理睬，要么用自己的方式对付他们。这些来找麻烦的人在给他们自己找麻烦，这点你不用操心。也别让自己卷入口水战，最好不要理睬大多数的口水战 —— 当然，这是在你检验它们只是口水战，并且未指出你有搞砸的地方，同时也没有巧妙地将问题真正的答案藏于其后（这也是有可能的）。不该问的问题以下是几个经典蠢问题，以及黑客没回答时心中所想的：问题：我能在哪找到 X 程序或 X 资源？问题：我怎样用 X 做 Y？问题：如何设定我的 shell 提示？问题：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗？问题：我的程序/设定/SQL 语句没有用问题：我的 Windows 电脑有问题，你能帮我吗？问题：我的程序不会动了，我认为系统工具 X 有问题问题：我在安装 Linux（或者 X ）时有问题，你能帮我吗？问题：我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？问题：我能在哪找到 X 程序或 X 资源？回答：就在我找到它的地方啊，白痴 —— 搜索引擎的那一头。天哪！难道还有人不会用 Google 吗？问题：我怎样用 X 做 Y？回答：如果你想解决的是 Y ，提问时别给出可能并不恰当的方法。这种问题说明提问者不但对 X 完全无知，也对 Y 要解决的问题糊涂，还被特定形势禁锢了思维。最好忽略这种人，等他们把问题搞清楚了再说。问题：如何设定我的 shell 提示？？回答：如果你有足够的智慧提这个问题，你也该有足够的智慧去 RTFM，然后自己去找出来。问题：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗？回答：试试看就知道了。如果你试过，你既知道了答案，就不用浪费我的时间了。问题：我的{程序/设定/SQL 语句}不工作回答：这不算是问题吧，我对要我问你二十个问题才找得出你真正问题的问题没兴趣 —— 我有更有意思的事要做呢。在看到这类问题的时候，我的反应通常不外如下三种你还有什么要补充的吗？真糟糕，希望你能搞定。这关我屁事？问题：我的 Windows 电脑有问题，你能帮我吗？回答：能啊，扔掉微软的垃圾，换个像 Linux 或 BSD 的开源操作系统吧。注意：如果程序有官方版 Windows 或者与 Windows 有互动（如 Samba），你可以问与 Windows 相关的问题， 只是别对问题是由 Windows 操作系统而不是程序本身造成的回复感到惊讶， 因为 Windows 一般来说实在太烂，这种说法通常都是对的。问题：我的程序不会动了，我认为系统工具 X 有问题回答：你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与函数库档案有明显缺陷的人，更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据，当你这样声称时，你必须有清楚而详尽的缺陷说明文件作后盾。问题：我在安装 Linux（或者 X ）时有问题，你能帮我吗？回答：不能，我只有亲自在你的电脑上动手才能找到毛病。还是去找你当地的 Linux 使用群组者寻求实际的指导吧（你能在这儿找到使用者群组的清单）。注意：如果安装问题与某 Linux 的发行版有关，在它的邮件列表、论坛或本地使用者群组中提问也许是恰当的。此时，应描述问题的准确细节。在此之前，先用 Linux 和所有被怀疑的硬件作关键词仔细搜索。问题：我怎么才能破解 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 的原因是什么？有谁知道接下来我该做些什么测试才能找出问题？这个家伙，从另一个角度来看，值得去回答他。他表现出了解决问题的能力，而不是坐等天上掉答案。在最后一个问题中，注意告诉我答案和给我启示，指出我还应该做什么诊断工作之间微妙而又重要的区别。事实上，后一个问题源自于 2001 年 8 月在 Linux 内核邮件列表（lkml）上的一个真实的提问。我（Eric）就是那个提出问题的人。我在 Tyan S2464 主板上观察到了这种无法解释的锁定现象，列表成员们提供了解决这一问题的重要信息。通过我的提问方法，我给了别人可以咀嚼玩味的东西；我设法让人们很容易参与并且被吸引进来。我显示了自己具备和他们同等的能力，并邀请他们与我共同探讨。通过告诉他们我所走过的弯路，以避免他们再浪费时间，我也表明了对他们宝贵时间的尊重。事后，当我向每个人表示感谢，并且赞赏这次良好的讨论经历的时候， 一个 Linux 内核邮件列表的成员表示，他觉得我的问题得到解决并非由于我是这个列表中的名人，而是因为我用了正确的方式来提问。黑客从某种角度来说是拥有丰富知识但缺乏人情味的家伙；我相信他是对的，如果我像个乞讨者那样提问，不论我是谁，一定会惹恼某些人或者被他们忽视。他建议我记下这件事，这直接导致了本指南的出现。如果得不到回答如果仍得不到回答，请不要以为我们觉得无法帮助你。有时只是看到你问题的人不知道答案罢了。没有回应不代表你被忽视，虽然不可否认这种差别很难区分。总的来说，简单的重复张贴问题是个很糟的点子。这将被视为无意义的喧闹。有点耐心，知道你问题答案的人可能生活在不同的时区，可能正在睡觉，也有可能你的问题一开始就没有组织好。你可以通过其他渠道获得帮助，这些渠道通常更适合初学者的需要。有许多网上的以及本地的使用者群组，由热情的软件爱好者（即使他们可能从没亲自写过任何软件）组成。通常人们组建这样的团体来互相帮助并帮助新手。另外，你可以向很多商业公司寻求帮助，不论公司大还是小。别为要付费才能获得帮助而感到沮丧！毕竟，假使你的汽车发动机汽缸密封圈爆掉了 —— 完全可能如此 —— 你还得把它送到修车铺，并且为维修付费。就算软件没花费你一分钱，你也不能强求技术支持总是免费的。对像是 Linux 这种大众化的软件，每个开发者至少会对应到上万名使用者。根本不可能由一个人来处理来自上万名使用者的求助电话。要知道，即使你要为这些协助付费，和你所购买的同类软件相比，你所付出的也是微不足道的（通常封闭源代码软件的技术支持费用比开源软件的要高得多，且内容也没那么丰富）。如何更好地回答问题态度和善一点。问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。对初犯者私下回复。对那些坦诚犯错之人没有必要当众羞辱，一个真正的新手也许连怎么搜索或在哪找常见问题都不知道。如果你不确定，一定要说出来！一个听起来权威的错误回复比没有还要糟，别因为听起来像个专家很好玩，就给别人乱指路。要谦虚和诚实，给提问者与同行都树个好榜样。如果帮不了忙，也别妨碍他。不要在实际步骤上开玩笑，那样也许会毁了使用者的设置 —— 有些可怜的呆瓜会把它当成真的指令。试探性的反问以引出更多的细节。如果你做得好，提问者可以学到点东西 —— 你也可以。试试将蠢问题转变成好问题，别忘了我们都曾是新手。尽管对那些懒虫抱怨一声 RTFM 是正当的，能指出文件的位置（即使只是建议个 Google 搜索关键词）会更好。如果你决定回答，就请给出好的答案。当别人正在用错误的工具或方法时别建议笨拙的权宜之计（workaround），应推荐更好的工具，重新界定问题。正面的回答问题！如果这个提问者已经很深入的研究而且也表明已经试过 X 、 Y 、 Z 、 A 、 B 、 C 但没得到结果，回答 试试看 A 或是 B 或者 试试 X 、 Y 、 Z 、 A 、 B 、 C 并附上一个链接一点用都没有。帮助你的社区从问题中学习。当回复一个好问题时，问问自己如何修改相关文件或常见问题文件以免再次解答同样的问题？，接着再向文件维护者发一份补丁。如果你是在研究一番后才做出的回答，展现你的技巧而不是直接端出结果。毕竟授人以鱼不如授人以渔。相关资源如果你需要个人电脑、Unix 系统和网络如何运作的基础知识，参阅 Unix 系统和网络基本原理。当你发布软件或补丁时，试着按软件发布实践操作。鸣谢Evelyn Mitchel 贡献了一些愚蠢问题例子并启发了编写如何更好地回答问题这一节， Mikhail Ramendik 贡献了一些特别有价值的建议和改进。
2015年，我突发奇想要弄一个网站，为的是方便自己做知识管理。至此，折腾之路开启……我以为找到方法、找到工具就能管理好知识，而这恰恰是我这么多年进步不大的思维误区——过分迷信“工欲善其事必先利其器”和“磨刀不误砍柴工”，而忘了自己磨刀是为砍柴的（磨刀磨出个工匠也行 ::aru:speechless:: ）。如果你对故事（个人的絮叨）不感兴趣可以直接跳到后面的章节。序曲最初，我试过自己设计网站页面，从互联网档案馆中甚至能看到最初简陋的首页。学习了一段时间的php后我放弃了。然后是WordPress，我再一次地重复了上面的老路，企图自己开发一个适合自己的插件，结局可想而知。再然后就到了MediaWiki，还是没怎么吸取教训，唯一有进步的可能就是终于学会总结了。2023年2月，站点条目一千七百多，近八成都是图书信息方面的，还有部分是从维基搬运过来的，自己创建的只有零星几条。作为一个没什么学术背景和编程能力的人来说，一个人搞维基是极其痛苦的，甚至有点自不量力的意味。借用灰机WIKI的学习地图来说，玩维基的三大问题：维基内容建设（内容向）、前端样式设计（美术向）和数据整理（编程向），基本上我——都不擅长。图片来源：https://www.huijiwiki.com/wiki/帮助:学习地图弯路选用MediaWiki时的设想很简单，把维基百科里跟心理学有关的内容搬运过来。白嫖谁不会啊？况且它的导出导入又那么好用。可真到实行的时候才发现问题远没有想象的简单，俄罗斯套娃般的模板但凡缺少一个，页面就各种红字报错。所以要么把所有的模板一并导入，要么就得修改搬运来的条目。前者我已经试过了，除非全部靠搬运，但凡自己开始编写，抄的模板能让人晕头转向——同样功能的模板可能因为不同人使用又重写了一遍还改了名，加之各种的重定向，还有在英文模板上套个中文翻译的壳，以及各种配套的Lua模块和CSS样式表。一旦开始自己写条目，面对成百上千的模板，无从下手很正常，最终还是要把所有模板都大致梳理一遍，明白目的和原理。其间之痛苦，相信很多新手维基站长都品尝过。最最不幸的可能这个新手站长还有那么点点完美倾向，那个场面……说到底，模板也只是为条目服务的，真正核心的也就那么几个，所以完全可以先从常用模板（比如信息框）下手，有针对地搬运，该合并的合并，该修改的修改，上千个模板也就只剩下几十个了。可惜这道理我用了两三年才明白。这里分享一个个人的经验，你可以先从搬运维基百科的帮助以及项目（Wikipedia:开头）内容入手，一则熟悉整个维基的格式要求、编辑方式等，另一方面可以通过逐步添加模板的方式进行学习，维基百科的模板说明通常还是比较清楚的，哪些适合自己的站点而哪些不适合也能做到心中有数。另外还有一个惨痛的教训，就是抄模板一定要“专一”，也就是内容如果从维基百科上来的，模板也最好用它的，千万不要因为其他站点同名的模板更漂亮就轻易转换阵营（我就常常同时浏览好几个维基站点，然后这儿抄一点，那儿抄一点），到最后显示效果一塌糊涂你都不知道问题出在哪里。毕竟各家的模板可能有各家的不同代码和样式表。说实话，维基百科的模板很多看上去虽然老土，还动不动就要配合Lua模块，但你要真领会了精髓，改漂亮点还是比较现实的。还有，一定记得备注从哪里抄来的。自从维基百科国内被禁之后，大部分人（包括我）可能都没有真正体验过维基写作，既不清楚方针原则，也不明白方式方法，而更要命的是我总希望跳过这些学习而进入到直接生产过程。走弯路也就不足为奇了。老路等我明白没有内容光有架子也不行的道理时，又过去了很久。百科注重的还是条目数量和质量——糊弄数量还是比较容易的，各种搬运肯定最方便（也别太指望维基百科，中文词条大量缺失，英文词条直接照搬也没用）；但是最怕的还是没有质量的胡抄乱写，岂不是违背了维基本身的意义？所以我终于痛下决心，企图通过边学习边完善条目的方式进行，权当将MediaWiki当笔记工具了（貌似我终于想起来我要砍柴来着）——而这又再一次地证明了我的自不量力。本以为新的开始会在眼前徐徐铺开，我能走上一条康庄大道。结果死性不改的我，还是走歪了。面对我浩如烟海的书，我竟不知从何下手。刷知乎、刷豆瓣，收集各种书单，然后……我花了大把时间搞了一套图书信息的模板，也花了大把时间录入了很多图书信息，甚至考虑增加藏书的功能。总而言之，我还是没能好好看书。我还是在“利其器”，只是砍刀变成了斧子——貌似磨刀真的比砍柴轻松。反馈陆陆续续创建了些图书的条目之后，我开始向百度、谷歌和必应提交站点信息，检验收录效果。而事实也证明，收录效果还是有一点的。这也是为什么我一直就在忙着弄图书条目的另一个原因，因为建条目最方便（虽然豆瓣上的信息已经很全了，不过还是有很多错误和缺失的，比如书籍目录）。没准哪一天还指着它们提高搜索权重呢~不过我内心并不清楚自己到底期待什么，也许只是希望有人搜到之后能够给自己些反馈甚至是加入我的工作（也确实有几位朋友从百科站转到主站给我留了言）。一个人搞网站真的太寂寞了！根本啰啰嗦嗦地介绍完这么多年的“无用功”，重新梳理一下权当给各位朋友看个热闹。结合最近几天的思考，总结一下吧。一、明确方向我属于干很多事都糊里糊涂的，貌似有方向又貌似没方向；看似游离在外，但一只脚呢却又常常踏在某个领域没松开。是固执还是坚持，我自己也不太明了，所以很难有长足的进步。如果你跟我一个德行，那么最好在开干前还是好好思考一下。说实话，我刚开始想弄网站也是带着点“野心”的，总幻想着哪一天能靠着网站解决温饱问题，所以这就面临一个是为自己还是为他人服务的困境中。为自己还好说，你在互联网上的絮絮叨叨可以完全不考虑他人的感受，你所借助的无非是其便利、自由和可控感。一旦你站在他人角度来考虑自己的网站，那么压力就会在无形中占据了你的头脑，输入的每一个字都可能会让你犹豫再三。抛开中立不说，文字的专业性和成熟度还是一目了然的，被人喷总归是不爽的，尤其是对方喷的有理有据。维基站的盈利很难，从国内几个成熟的站点来看基本上都差不多，除非你有其他衍生产品或服务。所以每年花少则上百多则上千来维系你的站点是否值得，也是需要权衡的。至于网站的方向，游戏和动漫还是主流，而学术性的只可能在小范围内被知晓。还是套用灰机百科的学习地图，找到自己擅长的领域，或者找到自己希望发展的领域。放下自己的全能感，干好学好自己所设想的就已经成功了一半。像我这种磨了砍刀就忘了劈柴的人，就纯属没想明白自己要什么？或许在潜意识中我还是觉得自己能干好技术。二、知识管理现在大家都在讲知识管理，尤其是个人知识管理。可到底有多少人真的弄明白了呢？我买了一堆的书，保存了一堆的PDF和电子书，又收藏了一堆的文章，可结果呢？我无非还是停留在信息收集阶段，亦如我自己开发的模板其目的还是为了信息，跟知识半毛钱关系没有。每个人对知识的定义和用途是不一样的。不管书上或者是某个教程怎么说，最终还是却决于我们自己。如果我就是希望可以快速检索到我需要的资料，思不思考并不重要，那也未尝不可。维基站并不是否定信息的收集，因为有些人只需要信息（如某本书是哪一年出版的？某人哪年哪月出生的？某某大学出过有哪些名人？等等……）。当然，你可能并不满足于只是收集和搬运信息，你希望的是更进一步地转化甚至是与他人的分享与交流，让信息为你所用，帮助你达到一定的目标和目的，那就更棒了。维基天生就是为这而生的。你希望知识是以什么样的方式来存储呢？树状还是网状？还是说根本就无所谓。是形似论文大段大段的文字，还是一张一张满是要点的卡片？这些都与维基无关，只与你的理念有关。三、选对工具当你理解了你想要的知识管理之后，工具的选择就会有的放矢。如今互联网上的知识管理工具（或者更狭隘地说是笔记工具）多如牛毛，每一款都有其独到之处，如何找到适合自己的是需要一定的实践来验证的。大而全意味着学习路径很长，配置和操作都很复杂，比如MediaWiki；轻量意味着迅速和便捷，但你可能要忍受某些功能的缺失，比如TiddlyWiki。没有完美的工具，只有合适的工具。就比如我在《同样是内链——Obsidian和MediaWiki的简易对比》中提到的，同样是内链，你可能只需要Obsidian（甚至是一个html文件的TiddlyWiki也能实现）。如果你能看到这篇文章，并且已经读到了这里，那么我相信你多多少少可能还是对MediaWiki或者是对以其为核心的站点感兴趣的。表达一下个人观点：虽然它很繁琐，但是它很“灵活”，而这种灵活在前期是很难被体会到的，很矛盾不是吗？补充一句，想玩MediaWiki真的不一定非要自己搞个网站，在本地搭建或者使用维基农场同样可以。四、百科意识其实这更像是知识管理的一个分支或一种实践，并不是每个人都需要。但我觉得还是有必要了解一下的。所谓百科意识，就是对百科全书的性质从感性到理性的深化的认识，是对百科全书与非百科全书从形式到内容的明晰的辨识能力。概括来说，百科意识包括框架意识、条目意识、体例意识、平衡意识。我之所以这么多年还是没舍得放弃，主要原因就是维基所带来的思维上的变化，尤其是作为一个没什么学术能力却又希望提高自己知识层次的人来说，它会促进知识管理的理解以及科学严谨性的认识，倒逼你持续学习。科学就是在不断推翻前人的基础上建立起来的，你的知识或者说百科条目也不可能一成不变。注：有兴趣的可以读一读《百科全书编纂中的百科意识——以《中国大百科全书》第三版为例》（链接就不放了，百度能搜到）。五、借鉴与实践不管从思想、工具或者是内容，都有太多现成的。所以如何在纷繁复杂的信息流中截取到自己所需要的，而不是再往信息流中投入重复的垃圾。我们不具备自己开发一套体系，那就承认自己能力有限，毕竟创新不是人人都可以的。就百科全书而言，国内的大百科全书第三版就是很好的一个参照模板，框架、体例都清清楚楚、相当规范。又或者参透维基百科的方针原则，同样受益无穷。再或者一些另类的玩法，我们也可以从同类中汲取经验。所以你要是没有把上面几点搞明白也无所谓，开干就是了，大不了将来就是修改、移动、重定向或者是删除。要知道，维基的最大乐趣就在于折腾。至于折腾到最后的结果么，要么持续精进，要么弃坑。这样想来我还是挺“积极”的，自恰了，也释然了。最后先写到这里吧，以后想到了再补上，否则时间一长我又会忘了当初为啥写这些了。其实回过头来想想，道理好像都懂，就是做不到。 ::aru:crying::
解决上传文件时出现“413 Request Entity Too Large”错误
今天在MediaWiki中上传一张稍大的图像时出现了“413 Request Entity Too Large”错误。虽然以前也上传过大图片，但用的是OneinStack一键脚本，所以一直没有出过错。之所以出现该问题，其实就在于没有对Nginx默认的request body大小进行调整，所以打开配置文件nginx.conf，在http、server或location块中，添加或修改以下参数：client_max_body_size 10M; # 根据需求调整大小（如10MB） 然后重新加载nginx的配置，问题解决。关于其他文件上传的限制，请参见《修改网站的文件上传限制》一文。
就在刚才，发了一篇关于CloudFlare接管后邮箱设置问题的文章，贴了两张图，结果一张顺利上传并显示，另一张则没有成功。因为边写边设置，也不知道是配置出了问题，还是CloudFlare和阿里云的DCDN配合不好，总之情况就是这么个情况。打开OSS的文件列表，能显示的图片已经存在，而另一张却不在列表中。在网上搜索了半天，没能找到合适的答案，在阿里云上提交工单，给出的解决方案也并不让人满意，让我还是在CloudFlare设置上想想办法。放弃CloudFlare转换成阿里云的DNS记录，之前的问题仍然存在，上传的图片只有名称但却没有真正上传到OSS中，这也就意味着之前的判断是错误的，原因不在CloudFlare，而在阿里云的设置中。由于主站和子站使用不同的系统也有不同的OSS配置，目前来看最顺利的反而是心百科（使用MediaWiki），图像上传和显示都正常。一则它单独使用一台服务器，其他站点都共用另一台服务器；二则只有MediaWiki使用OSS是没有回源功能的，因为它使用的AWS插件并不支持这么做。所以无论我如何将参数调整成一致都可能是无用功。还有一点是，BookStack在后台清理图像时会出现524错误，也无法生成sitmaps.xml文件，这些很难说是跟CloudFlare一点关系都没有。好吧，先解决图片回源的问题。从网上有限的资料中找到一个，是关于源站SNI的，之前阿里工单中也同样提到这个。SNI（Server Name Indication）是对SSL/TLS协议的扩展，允许服务器在单个IP地址上承载多个SSL证书，可解决一个HTTPS服务器拥有多个域名但是无法预知客户端到底请求的是哪一个域名的服务问题。开启SNI后，在CDN节点向源站发起TLS握手请求时，源站会根据TLS握手请求中携带的SNI信息来确认被请求的业务域名，返回正确的SSL证书给CDN节点。如今出问题的这几个网站，就是单个IP上有多个子域名，而且每一个网站都开启了强制跳转HTTPS，所以如果想使用HTTPS不开SNI就有可能会在HTTP和HTTPS之间强制来回跳转而找不到真正的源站，最终无法回源。选择OSS的Bucket对象，在数据管理->镜像回源中创建或修改规则，勾选携带SNI选项。记得在DCDN中的回源设置中，创建默认回源SNI。上述方法在BookStack和WordPress中正常了，但在Typecho中还是存在问题，会报“424 Failed Dependency”错误。半夜提交阿里云工单，结果第二天早上的时候，图片恢复正常了。不过另一张同一时间上传的还是一样存在问题。工程师还是建议我去Cloudflare看一下，是否是因为waf将回源给拦截了。隔一天之后，BookStack站点和Typecho两个站点又都不行了，而WordPress那个无论我怎么修改设置，上传文件都一点问题没有。而且就算我在Cloudflare中将OSS的代理打开，上传图片也一点问题都没有。不过真要说有问题就是，即便是我把图片删除后，本地和OSS上都没有了，由于Cloudflare的缓存关系，在浏览器中能够浏览。参考资料https://blog.xgblack.cn/alioss-image-back-to-the-source-failure-solution/
什么是命名空间以及如何在MediaWiki中管理它们为了使MediaWiki更便于页面管理，所有页面根据其在网站上的目的和功能都可以按照命名空间的方式进行分组。也就是说，每个页面都属于一个命名空间。例如，所有常规内容页面（也称为文章、条目或词条）都是主（Main）命名空间的一部分，而所有个人用户页面都存储在用户（User）命名空间中。而“心理学”即可以放入主（Main）命名空间中（属于一个条目），也可以放入用户（User）命名空间中（某个用户名叫心理学），也可以放入Project命名空间中（网站名叫心理学），甚至放入某个自定义的命名空间。正是通过这些不同的命名空间，网站可以区分同一个名称的不同功能和显示内容。那么MediaWiki有哪些默认命名空间？又该如何创建自定义命名空间以及如何进行其他设置呢？默认命名空间MediaWiki内置18个命名空间。其中有两个命名空间（属于系统级别的，具体见下文）是用户无法修改的，这意味着用户无法新建和编辑其页面。而其他16个命名空间中的页面可以新增也可以编辑，且都是成对设置。也就是说，总共有8个通用命名空间以及它们对应的讨论命名空间。每个命名空间都有一个用于标识的ID号和常量名。常量名为大写，它们都以NS_开头，后跟命名空间的名称。默认命名空间的ID号和常量名在Defines.php文件中定义。该文件位于MediaWiki根目录下的includes文件夹中。当想要对命名空间的选项进行一些更改时，需要使用到ID号。下面将列出并描述每个默认命名空间以及每个命名空间的ID号（括号中是该命名空间的常量名），其中部分命名空间支持中文。-2 （NS_MEDIA） - Media命名空间。这是两个虚拟命名空间之一，用户无法修改。该命名空间的目的是提供上传文件的直接链接。-1 （NS_SPECIAL） - 特殊（Special）命名空间是另一个虚拟命名空间，其中包含用户无法编辑的页面，所有工具和统计信息的页面都属于该命名空间。可以通过单击“工具”菜单中的“特殊页面”按钮来访问和使用这些页面。0 （NS_MAIN） - 主（Main）命名空间。顾名思义，这是用于大部分页面的命名空间，即网站用户创建和编辑的条目页面。它也是唯一一个在URL中不需要输入前缀的命名空间。这意味着，与其他命名空间中的页面不同，主命名空间中的页面在URL地址中直接显示名称。1 （NS_TALK） - 条目页面中进行讨论的讨论（Talk）命名空间。主命名空间中的每个页面都可以有一个讨论页面，用户可以在该页面上发布有关文章的评论。2 （NS_USER） - 用户（User）命名空间用于保存和显示个人用户信息。每个用户都可以创建自己的页面，其中包含该用户的用户名、个人信息或他们认为合适的任何其他信息。有关用户的详细信息，请查看《如何在MediaWiki中管理用户、用户组和权限》一文。3 （NS_USER_TALK） - 每个用户页面都可以有一个相关的讨论页面——即用户讨论（User_talk）命名空间，其他用户可以在该讨论页面上向特定用户发表评论。当用户打开站点并且该用户的讨论页已被其他人编辑（即已发表评论）时，所有页面的站点顶部都会显示一条消息。该消息在用户访问其讨论页后被删除。用户也可以开启相应的选项，然后通过电子邮件收到有关其用户讨论页更改的通知。4 （NS_PROJECT） - Project命名空间的用途是存储有关网站本身相关的页面。相对于与主（Main）命名空间区，它没有任何特殊选项或功能，只是为了方便区分和管理。默认情况下，它不包含任何页面，但在网站的页脚中，有指向可以创建的页面链接，其中包括关于、免责声明和隐私政策，这些页面都使用Project命名空间。请注意，在Project命名空间的前端上所使用的标签实际上可能不一定是Project。默认情况下是使用网站提供的wiki名称进行标识，在最初应用程序安装时就会要求填写wiki名称（默认项目名称与wiki名称相同，但可以设置为不同）。如果没有更改或编辑相应的选项，则项目命名空间实际上就是网站的名称。例如，如果已将网站名设置为“心百科”，则该Project命名空间的名称就是心百科（这也是该命名空间中页面URL所使用的前缀，如心百科的网站中，关于页面就是心百科:关于）。但请记住，在搜索或打开该命名空间中页面URL时，Project仍可用作前缀。它们将被重定向到实际名称（除非你将网站名设为Project）。如果我们使用心百科作为网站名，则可以使用wiki.mindseed/心百科:关于和wiki.mindseed/project:关于打开网站的关于页面。安装应用程序后，可以通过修改文件LocalSettings.php中的相应选项来更改站点名称和Project命名空间的名称（也称为元名称）。单维基百科中，站点名称和项目（Project）名称通常是同一个，维基农场中则会有所区别。5 （NS_PROJECT_TALK） - Project_talk与其他讨论命名空间一样，它用于存储与项目命名空间关联的讨论页面。命名空间的确切名称取决于项目命名空间的名称。例如，如果项目名称是心百科，则讨论命名空间的相应名称将是心百科讨论。6 （NS_FILE） - 文件（File）命名空间用于上传文件的页面。例如，当用户上传图像等文件时，这会自动为该图像创建一个页面。上面会列出该文件（如果是图像，则显示预览图）并且还会显示一些附加信息（例如，文件的上传时间、上传文件的用户、链接到它的页面等）。可以通过以与任何其他页面相同的方式编辑页面来向页面添加更多内容和信息。另外，如果在URL中使用Media作为前缀将会跳转到文件（File）前缀，而如果在页面内容中插入 和，前者将直接显示图片，后者仅显示图片的链接。7 （NS_FILE_TALK） - 文件讨论（File_talk）命名空间与其他讨论命名空间类似；它仅包含与特定命名空间关联的讨论页。8 （NS_MEDIAWIKI） - MediaWiki命名空间用于用于配置站点的页面。基本上，它们主要用于更改网站的外观。例如，用于设置所有或部分皮肤CSS（级联样式表）的页面，像MediaWiki:Common.css（用于整个站点）、MediaWiki:Vector.css（用于更改Vector皮肤）等。该命名空间中还存储了用于编辑网站界面文本和消息的页面。当然，你还可以通过该命名空间增加一些JS代码用于实现某些特定功能，比如MediaWiki:Common.js（用于整个站点）。9 （NS_MEDIAWIKI_TALK） - MediaWiki讨论（MediaWiki_talk）命名空间与其他讨论命名空间没有什么不同。它适用于与MediaWiki命名空间中的页面关联的讨论。10 （NS_TEMPLATE） - 模板（Template）命名空间用于存储模板页面。使用模板页面，你可以创建模板或编辑现有模板。创建和编辑模板页面的方式与创建/编辑常规页面相同。页面的内容是模板。模板可以添加到其他页面（也称为嵌入）。这可用于在许多页面上添加一些标准消息，而无需每次都键入整个消息。11 （NS_TEMPLATE_TALK） - 模板讨论（Template_talk）适用于模板（Template）页面关联的讨论。12 （NS_HELP） - 帮助（Help）命名空间主要是为提供帮助信息而创建的。就其功能和选项而言，它与主命名空间没有任何不同。你可以使用它向其添加包含有用信息的页面、与站点相关的任何说明或者想要的任何内容。默认情况下，它不包含任何预配置的页面。13 （NS_HELP_TALK） - 帮助讨论（Help_talk）用于评论帮助（Help）命名空间关联的页面。14 （NS_CATEGORY） - 分类（Category）命名空间包含所有分类页面，用于对在内容或处理主题方面具有相似之处的页面进行分组。分类中的页面可以来自不同的命名空间。每个类别页面都列出了该类别中的页面。将页面添加到类别时，该类别也会自动列在页面底部。有关类别的更多信息，请查看《如何在 MediaWiki中创建和管理分类》。15 （NS_CATEGORY_TALK） - 分类讨论（Category_talk）用于讨论分类（Category）关联的页面。更多常用命名空间请参看《MediaWiki的命名空间列表》一文。命名空间的URL地址页面的URL地址是由站点的基本URL加上页面所属命名空间的前缀，后跟英文冒号和页面名称所构成。所以更准确地说，页面的全名实际上是由命名空间的前缀加上页面名称组成的，比如特殊:特殊页面。命名空间的名称用于其前缀（在中文系统中，中英文皆可，见上文中的斜体部分）。如果名称由多个单词组成，请在前缀中在单词之间添加下划线。例如，用户讨论命名空间的前缀是用户讨论（User_talk）。页面标题中的单词在URL地址中也用下划线分隔，但即使输入的URL在单词之间带有空格，MediaWiki也会自动为其添加下划线。因此，例如，如果文件命名空间中的页面名为Example file.jpg，则带有命名空间前缀的完整页面名称将为文件:Example file.jpg或File:Example file.jpg。如果网站的主URL是wiki.mindseed.cn，则该页面的URL将会是wiki.mindseed.cn/File:Example_file.jpg。请注意，唯一不向其页面添加前缀的是主（Main）命名空间。因此，所有主条目的URL都没有命名空间前缀，只是将页面名称添加到基本URL中。限制命名空间的编辑在MediaWiki中，可以阻止特定用户组的用户编辑特定页面，也可以对网站上的所有页面进行编辑。还可以限制用户编辑特定命名空间中的所有页面。例如，希望阻止所有未注册的用户编辑用户讨论命名空间中的页面。可以通过修改配置文件LocalSettings.php来实现此类限制。有一个选项$wgNamespaceProtection专门用于限制命名空间的编辑。使用该选项可以指定可以编辑所选命名空间中页面的用户。在LocalSettings.php末尾的新行上，必须添加具有以下形式的行：$wgNamespaceProtection[NS_NAMESPACE] = array( 'permission' ); 你必须将NS_NAMESPACE替换为命名空间的实际常量，并将权限替换为用户权限。可以在上文第一部分中找到所有命名空间的ID/常量名。具有指定用户权限的所有用户都可以编辑特定命名空间中的页面。其余用户将不被允许这样做。你可以使用仅分配给要允许编辑命名空间中页面的用户组的现有权限，也可以创建新权限，将其分配给所需的组，然后使用该权限。例如，将以下内容添加到LocalSettings.php文件中：$wgNamespaceProtection[NS_USER_TALK] = array( 'editinterface' ); 只有管理员/管理员才能编辑用户讨论命名空间的页面。editinterface权限是默认情况下仅分配给管理员的核心权限。你也可以创建新权限，然后使用它来限制命名空间的编辑。例如，使用以下内容：$wgGroupPermissions['user']['editusertalk'] = true; $wgNamespaceProtection[NS_USER_TALK] = array( 'editusertalk' ); 这将创建一个名为EditUserTalk的新权限，将其分配给用户组（即所有注册用户的组），并且只允许具有该权限的用户编辑用户讨论（User talk）命名空间中的页面。这意味着只有访问者/未注册用户才能向用户的讨论页添加评论。创建自定义命名空间除了默认命名空间之外，还可以创建自定义命名空间。例如，可能希望有一个命名空间来存储包含特定主题内容的页面和/或一个只能由选定的用户组编辑的命名空间，比如心百科中最常用的图书（Book）命名空间就是用于对图书条目进行分组的；又比如维基百科中的主题（Portal）命名空间是提供特定领域百科内容的页面，每个主题以所涵盖的领域命名，比如主题:心理学。正如前文所提到的，命名空间通常是成对创建的：一个用于内容页面，一个用于内容关联的讨论页面。因此，如果要决定创建一个命名空间，那么最好是也为它创建一个讨论（Talk）命名空间。可以通过在LocalSettings.php配置文件末尾添加几行来创建命名空间。一行用于定义命名空间的ID和常量名。然后使用另一行添加命名空间，这是通过选项$wgExtraNamespaces完成的。使用该选项和在上一行定义的命名空间的常量，你可以指定要在前端使用的命名空间的名称。例如，将以下内容添加到LocalSettings.php文件中：define("NS_BOOK", 3000); define("NS_BOOK_TALK", 3001); $wgExtraNamespaces[NS_BOOK] = "图书"; $wgExtraNamespaces[NS_BOOK_TALK] = "图书讨论"; 上述代码将创建图书（Book）命名空间及其关联的图书讨论（Book_talk）命名空间。使用define函数可以指定每个命名空间的ID和常量名。但需要记住以下几个要点：常量全部为大写，应以NS_开头，后跟名称；单词用下划线分隔。在我们的示例中，常量是NS_BOOK和 NS_BOOK_TALK。内容命名空间的ID号应为偶数，讨论命名空间的编号应为奇数。在上述示例中，它们分别为3000和3001。在为新命名空间选择ID数字时请务必注意，它们不应与现有命名空间或扩展可能创建的命名空间相同。默认命名空间的编号从-2到15，但有许多扩展在安装时，会自动创建具有某些指定ID号的功能所需的新命名空间。大多数扩展名使用100到3000之间的数字，因此保险的方法是使用3000及以上的数字。使用$wgExtraNamespaces选项使用使用 define 选项指定的命名空间的常量，并将要在前端使用的相应名称放置。在我们的示例中，命名空间NS_BOOK的名称为图书，NS_BOOK_TALK命名空间的名称为图书讨论；该名称用作属于命名空间的页面URL中的前缀（比如：https://wiki.mindseed.cn/图书:心理学名词或者是https://wiki.mindseed.cn/Book:心理学名词）。如果名称由多个单词组成，请用下划线分隔它们（例如Example_talk），避免在单词之间留空格。
因为在路由器中内置了clash，所以只要联上网就能畅通无阻地浏览各大网站。但总有外出的时候，如果是windows，使用Trojan-Qt5，设置简单占用资源又少，这么多年也一直没放弃它。但是linux就比较麻烦，可视化界面的应用比较少，比如ubuntu的应用商店中的shadowsocks-electron，虽然配置后测速通过，但就是不知道为什么不能打开网站。那就用命令行的trojan试试，反正也是偶尔才会用到。首先，下载源码并解压：wget https://github.com/trojan-gfw/trojan/releases/download/v1.16.0/trojan-1.16.0-linux-amd64.tar.xz tar xf trojan-1.16.0-linux-amd64.tar.xz -C /opt/ 然后复制一份客户端的配置模板：cd /opt/trojan cp examples/client.json-example client.json 修改配置文件中的基本设置："run_type": "client", // 运行类型 "local_addr": "127.0.0.1", // 本地监听地址 "local_port": 1080, // 本地监听端口 "remote_addr": "", // 服务端的ip或域名 "remote_port": 443, // 对应服务端的端口 "password": [ "passwd" // 对应服务端设置的密码 ], 如果没有ssl，可关闭验证，修改如下："verify": false, "verify_hostname": false, "cert": "", "sni": "", 其余保持不变。运行如下命令以验证配置是否成功：/opt/trojan/trojan -t /opt/trojan/client.json 正常情况下是不会有什么问题的，即便有也会生成相关日志。可以通过systemd进行管理，编写服务文件trojan.service（保存于/usr/lib/systemd/system/目录下），内容如下：[Unit] Description=trojan Documentation=man:trojan(1) https://trojan-gfw.github.io/trojan/config https://trojan-gfw.github.io/trojan/ After=network.target syslog.target [Service] Type=simple StandardError=journal User=nobody AmbientCapabilities=CAP_NET_BIND_SERVICE ExecStart=/usr/local/share/trojan/trojan -c /usr/local/share/trojan/client.json ExecReload=/bin/kill -HUP $MAINPID Restart=on-failure RestartSec=60s [Install] WantedBy=multi-user.target 执行如下命令启动trojan服务：systemctl daemon-reload systemctl enable trojan systemctl start trojan 最后，在浏览器的网络设置中修改手动配置代理，具体如下：打开谷歌，顺利显示。
因为要帮网友搞网站备份（见《在群晖NAS上通过Hyper Backup备份网站》一文），不得不把之前的黑群晖虚拟机翻出来。打开vmware，运行虚拟机。同时，打开Synology Assistant，搜索服务器，结果在状态栏中显示无法联机。IP地址应该是之前设置的，但我现在用的笔记本IP地址通常为192.168.50.x，跟原有的192.168.72.x不在一个网段中。首先，重新设置群晖的ip地址。选中服务器并点击设置按钮，出现Synology Assistant设置向导，点击下一步。输入用户名和密码，再次点击下一步。在网络设置界面中选择手动设置，并分别填入希望设置的IP等信息，点击完成。系统会检验该IP是否被占用，如果没有的话将会把上述设置写入群晖服务器，一切顺利的话，会弹出“网络设置完成”的对话框，并重新扫描服务器。通常情况，状态会显示已就绪。如果还是存在联机失败的话，可以考虑从以下两方面入手：1、尝试将虚拟机的网络设置有NAT改为桥接；2、禁用无关的网络适配器，比如VMware Network Adapter VMnet1之类的（见下图）重新搜索服务器，如果还是显示联机失败，可以多试几次，至少我一圈折腾下来终于连上了。
还是关于在群晖NAS上安装BookStack的后续，网友希望我能帮他把服务器端升级到最新版。老样子，还是现在虚拟机上先测试一下。打开黑群晖，然后连上SSH，进入BookStack的安装目录，按照官方文档的说明，在命令行中运行如下：git pull origin release 系统提示找不到git命令。虽说群晖属于linux系统，但它毕竟是定制化的，常用的apt或者apt-get、yum、akg等方法一律无法使用。而网上给出的解决方案有几种：一种是在套件中心中直接安装git，可惜我的DSM 7.2版中并没有这一项，只有git server；另一种是直接下载安装包手动安装（下载地址：https://synocommunity.com/package/git），但列表中没有7.2的选项，因此暂且放弃。还有另一种方法其实跟上述后者比较相似，但更加简便，步骤如下：以管理员身份登录NAS，然后转到主菜单→套件中心→设置。在“套件来源”选项卡中，单击“新增”，键入“SynoCommunity”作为“名称”，键入“https://packages.synocommunity.com/”作为“位置”，然后按“确定”进行验证。回到套件中心界面，此时在左侧会多出一个社群的链接，点击后在右侧会出现社群中的各种第三方套件，找到git并点击安装套件即可。回到控制台中，重新执行上述的命令行，运行成功。注意：如果安装git的是某一特定用户，使用其他用户运行该命令可能会提示“/bin/git: No such file or directory”错误，切换会安装用户即可。另外，安装git客户端之后在NAS的管理界面中是找不到的，也无法进行任何设置。
之前帮忙安装bookstack的网友又联系我，说是希望能够定期备份网站。因为他们的应用是安装在群晖NAS上（有兴趣的可以参看《在群晖NAS上安装BookStack（一）——使用Container Manager》《在群晖NAS上安装BookStack（二）——使用Web Staion套件》），所以使用传统的linux命令方式恐怕比较困难（登陆ssh后，无法使用crontab命令）。幸运的是，群晖自带的备份系统提供了一个更加简便的备份方始，以下操作通过虚拟机进行，系统为DSM 7.2。一、新建共享目录在开始前，我们需要先新建一个共享目录用于放置备份内容。打开File Station应用，点击右侧指令栏中的新增按钮，并选择创建共享文件夹。填写共享文件夹的名称（为方便管理可以添加适当的描述），并一路点击下一步。如果没有特殊的权限要求，则最终点击应用。二、安装套件Hyper Backup及备份设置进入NAS的应用中心，找到Hyper Backup并点击“安装套件”按钮。稍等片刻，打开该应用。点击左上角的加号标志，在“选择备份类型”界面中保持默认（即文件夹和套件选项），然后点击下一步。在“选择备份目的地”中选择“本地共享文件夹或USB”（这里只考虑本地备份），点击下一步。在“选择备份版本类型”中选择“单一版本”（多个版本和单一版本的文件保存方式有所不同，后者可以方便转移到任何其他设备或直接查看），点击下一步。在“备份目的地设置”中选择第一步中新创建的共享文件夹，然后点击下一步。“数据备份”界面中选择网站的安装目录，在本例中为web目录下的bookstack，点击下一步。在“应用程序备份”中选择数据库程序，在本例中为MariaDB 10，点击下一步。在“备份设置”中设置任务名称以及给备份目录起一个方便管理的名称（可以保持默认），并且根据自己的需要设置备份的周期和时间（这里保持默认）。其中有一项“保留目标端已备份文件”可以根据自己的需要进行勾选（一旦勾选，那么当源目标中的文件删除，如网站中某张图片被删，备份时仍保留该删除的文件，但会浪费一定的空间），点击下一步。最后是备份的摘要，如果没有问题就直接点击完成。即便是设置有问题，后面还是可以进行修改的，所以尽可放心。系统会提示是否立即备份，点击是。系统会回到主页面，并显示备份进度。根据备份内容的多少，时间不等。因为虚拟机上没什么内容，几分钟就搞定了。而那位网友的网站内容差不多有10个G左右，加之有其他应用在使用，所以整个备份时间还是很长的（在进行到100%的时候停留了十几分钟，一度以为系统出问题了）。打开备份目录，检验一下结果。其中@app目录是应用的备份（在本例中为MariaDB 10），web即网站文件。如果想修改备份设置，点击立即备份右侧菜单中的编辑即可。至此，整个备份的设置便已完成。三、备份还原还原的过程比较简单，基本上就是一路下一步即可（其中在数据还原和应用程序还原中需进行勾选）。这里还是简单记录一下。在还原数据库时，系统会提示应用将被禁用，是否确定继续，点击是。最后点击完成。系统会显示还原进度，在此过程中网站可能会打不开，因为数据库程序MariaDB被暂时禁用了。全部完成后，网站又还原到备份时的样子，所有删除或新增的内容均已恢复。
本来以为只要照搬阿里云的域名解析到CloudFlare就可以了，没想到发送测试邮件后竟然报错了。点击其中的帮助链接，说是MX解析错误。可我明明已经原样复制了阿里云的解析记录，怎么会不行呢？帮助文档中说的，可以使用：解析的域名记录类型优先级解析记录值@MX5mx1.qiye.aliyun.com@MX10mx2.qiye.aliyun.com@MX15mx3.qiye.aliyun.com当然它也提到可以使用另一种：解析的域名记录类型优先级解析记录值@MX5mxn.mxhichina.com@MX10mxw.mxhichina.com不过当初设置的时候第一种方式一直好用也就没想过换。登陆邮箱管理员账号，在企业定制->域名管理中，点击检查MX解析，如果一切正常应该出现如下的结果：从最初反馈的结果来看，少了一个TXT记录(DKIM)，顺带把MX记录也一起改了。等待几分钟后，发送测试邮件，一切正常。像这种多少年都不修改的解析记录，在重新配置时可能会出现状况，最好还是按照最新的来，阿里云自家知道兼容，但CloudFlare未必知道。另外，第三方邮件客户端（比如网易邮箱大师）中，POP3和SMTP的设置还是使用阿里云的地址为好，原本我使用了pop.mindseed.cn在这次重新托管后出错了，切换回阿里云的就好了。协议服务器地址服务器端口号（常规）服务器端口号（加密）POP3pop3.mxhichina.com110995IMAPimap.mxhichina.com143993SMTPsmtp.mxhichina.com25465
雷池安装使用有好几个月了，虽然被爬虫搞死机的情况是少了，但流量也是一落千丈，为了确保前者就不得不开始BOT防护，而这却是导致后者的重要原因。毕竟误伤的可能性还是存在的，或者是点击页面就出现个雷池的加载页面还是挺让人恼火的，不知道的还以为点错网站了。忍无可忍的情况下还是打算先尝试一下CloudFlare，之前一直听说它是减速器，所以就没打算用它，现在被爬虫搞得服务器都快奔溃了，网站慢一点总好过网站打不开吧。登陆CloudFlare控制台，输入现有的网站域名后，使用快速扫描DNS记录（之后会返回扫描到的结果，也可以根据实际情况可以自行增删），然后点击继续按钮。为域名选择计划中选择free即可，之后返回扫描结果，暂时可以不用管，点击继续按钮。登陆域名服务商（比如阿里云），在域名基本信息中修改DNS记录，比如将dns2.hichina.com、dns3.hichina.com替换成fatima.ns.cloudflare.com、harley.ns.cloudflare.com（由CloudFlare提供）。回到CloudFlare控制台，过一段时间之后就会通知你现在已经可以由它接手了。此时在浏览器中输入域名，可能会提示ERR_SSL_VERSION_OR_CIPHER_MISMATCH错误，那是因为网站使用的仍然是之前由acme申请的证书，而非CloudFlare提供的SSL证书。点击SSL/TLS中的边缘证书，其中证书状态显示待验证（TXT），点击后将证书验证的TXT名称和TXT值复制到域名解析记录中（主机厂商的，比如阿里云，而不是CloudFlare的DNS解析）。一共有两个记录，一个主域名，一个通配符的（适合子域名）。稍等一段时间，待验证通过后，CloudFlare会自动申请证书。重新刷新网站，此时应该就可以正常浏览网页了。点击证书，颁发者变为Cloudflare TLS Issuing ECC CA 1。值得注意的是，如果之前使用了CDN，那么CloudFlare的DNS中如果没有添加CDN的记录，那么图片是无法显示的，此时就需要将这部分添加进去。如果有免费的域名邮箱，同样记得添加记录。好了，今天暂时就这样，明天再继续折腾。
心百科的证书到期了，打开雷池的管理界面，在通用设置中尝试手动上传证书进行更新。但让人恼火的是，控制台中显示的证书有效期并没有随之更新。而此前类似操作却是可以的。径默认的证书保存在/data/safeline/resources/nginx/certs下，查看证书的修改日期确实是最新的，并且打开后与上传的证书内容一致，也就是说证书上传没有问题。尝试重新启动雷池，使用官方给出的命令如下：container_id=$(docker ps -n 1 --filter name=.*safeline-mgt.* --format '{{.ID}}') SAFELINE_PATH=$(docker inspect --format '{{index .Config.Labels "com.docker.compose.project.working_dir"}}' $container_id) cd $SAFELINE_PATH && docker compose down && docker compose up -d 证书信息仍然维持在过期状态，没有任何效果。雷池的升级日志中对于9.2.2的记录就是修复部分情况证书无法续期的问题，显然我的问题并没有得到有效解决。尝试卸载最新版的雷池，改装9.1.0-lts版。由于卸载后所有配置均被删除，只能重新创建应用。再次手动上传证书，结果还是显示证书过期。进行到这里，感觉只有等雷池的更新版本出来或许才可以解决问题。在技术群和论坛中都提交了问题，可惜迟迟没有回应。既然雷池方面没办法，那就从证书方面考虑了。在使用雷池前，所有证书都是通过网站服务器中的acme生成。在测试和配置雷池时，因为不确定是否能使用长久，所以所有的证书文件都是从网站服务器中下载后再手动上传到雷池中。每次升级证书同样是下载新证书再上传，直到这一次出现状况。既然手动上传的有问题，那就直接在雷池服务器中生成证书，然后直接替换掉原有的证书（比如/data/safeline/resources/nginx/certs目录下的cert_1.crt和cert_1.key，表示的是雷池第一个创建的应用）。根据acme的教程，使用DNS的方式生成证书，然后复制安装新证书，命令如下：acme.sh --install-cert -d example.com \ --key-file /data/safeline/resources/nginx/certs/cert_1.key \ --fullchain-file /data/safeline/resources/nginx/certs/cert_1.crt \ --reloadcmd "docker exec safeline-tengine nginx -s reload" 刷新雷池控制台，问题依旧。但过了一段时间之后，无意中再次刷新控制台，证书终于正常了。用群里网友的说法，用雷池还是有一定的玄学意味在的，所以整个过程中我并不确定到底是哪个环节使得问题最终得到了解决，只能说运气使然。