我经常使用的标签中的随机示例：
需要php时间戳功能
https ：//stackoverflow.com/questions/6613890/how-to-add-string-to-the-beginning-of-a-string
如何在PHP中编辑二进制图像？
PHP是否可以？是否具有date（）函数的反函数（而不是strtotime（））？
PHP 5.2.8支持goto吗？
https://stackoverflow.com/questions/5880301/variable-string
PHP-要大写吗？
在
元素中添加背景图像
是否可以从这样的日期获取UNIX时间2011-02-27 02:04:46？
/>时间戳的时间字符串
如何创建一个可以接受文件上传的PHP页面？
这些OP需要的是指向正确手册的链接，我们应该给他们提供手册。但是这个问题毫无目的。他们甚至没有可搜索的用处，因为任何理智的搜索查询都将导致实际的手册成为第一本。
Jeff讨论了在此处引入新的关闭原因的可能性。 Scifi.stackexchange.com。根据罗伯特的建议，它可能是这样的：
一般参考：这个问题太基础了；答案可以在任意数量的旨在查找该类型信息的常规Internet参考资源中找到索引。如“在此处输入重复ID”弹出窗口），以供用户建议正确的手动链接：
然后，建议的链接将显示在顶部的方框中。问题，例如重复的链接。
同样，从这些琐碎的问题中获得的声誉也令人震惊。我敢肯定，大多数高级用户的观点（包括我的观点）都来自回答“再次替换字符串的功能是什么？”输入问题。这会大大削弱声誉作为真正专业知识的衡量标准的价值。
我建议将追溯为“通用参考”的问题的答案追溯到社区Wiki，以消除任何获得的声誉。
我们已经完成了评估。有关背景信息，请参阅博客文章：问题是否简单？
特别是：
根据Stack Exchange Podcast＃20中的讨论，并在评估了英语和科幻的接近原因之后，我现在同意Joel的观点：我相信，这种接近原因有很大的潜在滥用和误解的可能。我们不太可能在整个网络范围内采用这种紧密的理由。
我希望评估效果良好。与此相关的源源不断。如果您强迫第一个接近者建议参考网址（如重复），那么包括OP在内的每个人都会很高兴，但是使用此功能将阻止另一个毫无意义的重复项吸引无意义的使用：答案。
– Pekka
2011-4-25 19:37
@pekka Joel非常担心它将被滥用。我也很担心，因为许多程序员都“不能在全能的OCD中遵守一个重复的原子”。
–杰夫·阿特伍德
2011-4-25 20:48
@Jeff是的，我明白了这一点，并且有可能在有效问题上将其用作后门“ RTFM”。但是潜在的好处是巨大的……我很高兴看到它在SO上进行了数周的测试，mod和10ks密切关注即将结束的内容。
– Pekka
2011年4月25日在20:53
我真的希望很快能解决这个问题。我觉得我的利基越来越混乱。
–gnostradamus
2011年5月2日，下午3:21
@Jeff，请让我们把它放在怀疑论者身上...
–Sklivvz
2011年5月3日20:18
@yms，上面链接的几乎每个PHP问题都可以通过在PHP手册中查找有问题的函数来回答。我指望某人至少已经解雇了Google或参考了该手册，这并不是我认为的“精英歧视”。他们都有骗子，但是问题的类别是如此可怕和多产，以至于找不到完全匹配的事物。例如，PHP标记中有将近2000个有关strtotime的问题。能够关闭可以通过简单的手动阅读回答的问题，将是总体问题质量的一个胜利。
–查尔斯
2011年5月17日在18:34
@Sklivvz：那将如何在怀疑论者身上发挥作用？那里的社区有着令人难以置信的强烈的反逻辑/亲参考偏见。我很想看看“具有标准参考源的近距离问题”与“所有答案本质上必须是标准参考源的链接”如何相遇。
–user118150
2011年5月25日18:30
@yms我看不到任何精英人士。我不明白为什么该网站应该迎合那些甚至不愿意阅读其编程语言最基本基础知识的人，也不会迎合那些使用问题标题中确切文字对Google无关紧要的东西的人。另外，OP确实会得到对他们有帮助的答案-手册的链接。但是问题将被关闭（并且最终可以删除），而不是使问题库变得混乱
– Pekka
11年5月29日在18:54
我仍然不同意“您可以用谷歌搜索它”是使用此封闭时间的合理原因。我认为对此存在足够的困惑，以反对实施它。坦率地说，Pekka和Sklivvz想要使用它的方式，为什么不节省时间并称之为“ lmgtfy”关闭原因。
–user118150
2011年5月31日15:13
@user的关闭原因是“ RTFM”和“ Go Google”的礼貌版本。这有什么问题，特别是因为甚至为用户提供了正确的手动链接？
– Pekka
2011年5月31日19:45
我同意，@ Adam一般参考问题的主观性将是最大的危险。但是，可能无法在一开始就切勿在PHP手册中找到字符串大写功能的用户。除了手动链接或教程之外，为这些用户提供其他服务是一项艰巨而艰巨的任务。另外，以我的经验来看，无论问题的基本程度如何，对理解手册的特定部分并进行相应询问（而不是脑筋急转弯的“我想做xyz”）的用户都有很好的SO处理。
– Pekka
2011年5月31日19:59
评估期怎么样？现在有可能在其他任何网站上使用吗？
–杰夫·梅卡多（Jeff Mercado）
2011年8月3日，21：30
@TheGhostofChristmasPast链接腐烂和一般的SEO问题是一个巨大的问题，例如，请参见Dive陷入HTML5 / ect。仅仅因为今天容易找到答案并不意味着该网站将在一个月或一年之内轻松找到。我们至少可以知道，只要... Stack Exchange存在，Stack Exchange就将存在。因此，在此处实际获得答案是使社区受益的最佳方法。更糟糕的是，如果有人开始决定将Experts Exchange作为通用参考书怎么办？
–本·布罗卡（Ben Brocka）
2012年1月4日15:13
@Jeff ping，以防您有兴趣一般参考问题会给Google员工造成低质量的死胡同
– Pekka
2012-12-27 22:22
流程图很棒，对我来说看起来很完美。可惜这一切都被拒绝了。我承认我没有听过播客，但是我没有看到任何有说服力的问题可以令人信服。几乎每个人似乎都想要这个。
–轨道轻度竞赛
2013年1月26日19:21
我做了一个测试，给出了一个例子。我用Google搜索“如何在C＃中连接字符串”，并将文档作为第一个结果。因此，在这种情况下，您的陈述是正确的。
但是，
似乎是基于这样一个假设：每个需要知道如何在C＃中连接字符串的人都知道什么是串联，并了解什么是字符串数据类型。看一眼关于SO的一些问题，将立即证明这种假设是错误的。有各种级别的用户都在使用SO，并且可以从中受益。为了证明这一点，我在Google中搜索了“如何在C＃中将文本的两个变量添加到一个变量中”，并获得了这篇无关的博客文章作为第一个结果。 Google的首页有一些相关的结果，但是结果并没有像SO的搜索页上显示的结果那样接近用户的需求。
事实是，如果有人问以特定方式提出的问题，即使不是正确的提问方式，其他人最终也会同样也会提出。如果SO遵循建议以关闭所有“通用参考”问题，那么它将消除包含这些问题的特别有价值的方面-这是隐式交叉引用术语。
我认为在这种情况下，“重复问题”接近的原因就足够了，因为它将“错误方式”提出的问题指向单个问题，从而教授了正确的术语并回答了问题。
公平点。我也更喜欢将这些封闭在一起，但是根据我的经验，找到一个可以很好回答的原始问题是很多工作，特别是对于琐碎的问题，因为它们通常包含许多通用术语。对于一个琐碎的问题，这种努力通常并不十分值得。我意识到这个新的关闭原因将是礼貌地放置“ RTFM”，但我认为仅由于数字庞大而有必要。另外，如果可以提供手动链接，新手仍会得到他们的答案。
– Pekka
2011-4-5 15:05
如果关闭需要指向一般参考的链接并且仍然可以搜索，那么我认为这个问题几乎可以消除。
–布赖恩
2011年6月8日在20:07
一个使您措辞古怪/理解欠佳的观点：stackoverflow.com/questions/6613890/…我认为它们应该立即关闭并被淘汰，尽管:)
–莫斯科
2011年7月7日在16:47
@fosco，看起来像是。 1小时-11
–smartcaveman
2011年7月7日在17:44
我不喜欢将用户解雇到Web资源上的想法。给社区这种力量，每个人都会开始使用它来轻视。有点像社区Wiki警察（应该是CW !! 1！1）和作业高级调查（这是作业吗？是吗？那么您还没有添加作业标签！）。
我有一项个人政策，即不管答案的正确性或相关性如何，都应否决只是链接的任何答案。 OP认为答案确实在回答，而资源提供背景阅读。不是“是的，这对我来说太琐碎了”。如果您觉得问题太琐碎而无法确定，请在其他地方看看。
我同意我们需要找到一种更好的方法来删除重复项。我不认为是这样。我认识到大量低级别重复项存在问题，我们应该在这个级别上寻找解决方案。一些建议：
搜索
更突出的“这可能是重复的”消息？也许打断答案发布（在发布之前，请考虑是否已问过此问题。如果您对{link}存在的内容有更好的答案，请进行发布）。有点像“发布另一个答案”功能。
+1表示如果问题过于琐碎而您无法看待，请转至其他地方。
– aioobe
11年5月28日在22:44
@aioobe-不是单个琐碎的问题才是问题。当一些琐碎的问题开始淹没该站点时，专家们将把目光投向其他地方，例如StackExchange网络外部，然后整个事情将转移到Yahoo!上。答案。
–布拉德·梅斯（Brad Mace）
2011年6月12日4:04
-1：您将“已经在现有权威文档中明确描述的存在”的概念与“变得简单”的概念混淆了。它们是完全正交的。这是一个非常简单但并非根本的“通用参考”问题，因为它在任何文档中都没有明确说明答案，所以非常好。
–轨道轻度竞赛
2013年1月26日19:13
如果要删除meta上的帐户，请遵循以下步骤：meta.stackoverflow.com/help/user-deletion。谢谢！
–亚当·李尔♦
13年1月31日在16:40
“如果一个问题对您来说太琐碎，您不愿意去看，请找别的地方。”不能同意
–杨敖博
13年7月28日在15:01
我支持一般参考关闭原因，尽管我们需要谨慎对待滥用的可能性。用更近的距离指示参考是最小的障碍。
但是，我不太同意Borror0的流程图。我认为不应将Google用作确定问题是否是合法的Stack Exchange问题的工具。面对Google问题，我愿意接受非Google员工。
将问题作为“一般参考”来结束的动机是，您不需要人来回答这个问题，因为答案可以在明显的地方找到。 （因此，这个问题对于提问者，答题者和未来读者来说都是浪费时间。）
如果我想知道英语单词的意思，我不会看它在Google上，我将去找英语词典。如果这个单词对我的字典来说太晦涩难懂，或者在我找到该单词的上下文中没有任何定义有意义，那么我将寻求其他工具。好的，所以我用google搜索，根据www.urbandictionary.com，我发现它的意思是“阴茎”。嗯，也许我最好问一下英语语言和用法堆栈交换。
如果我想知道科幻人物是谁，我首先要在Wikipedia上查找它。如果找不到所需的内容，则可以使用Google并找到特定SF Universe的Wiki。但是这些Wiki并不总是可靠的，并且通常以一种宇宙的视角来编写，如果您不喜欢该世界，那么它们将很难被遵循。所以我可能会问科幻小说与奇幻小说堆栈交换。
如果我想知道如何游览外国城市，那么我不会先在Google上查找它。在拥有多个运输公司的地方，通过Google搜索可以轻松地使我仅了解其中一个运输公司。因此，我将在Wikitravel上查找城市。如果找不到答案，可以在Travel Stack Exchange上询问。
如果我想知道unix命令的作用，那么我就不会从Google上查找它。我要提出它的手册。 Unix变体和Unix变体之间的命令可能会有所不同，这样我将得到一个对我的系统来说准确的答案。如果命令没有手册，或者我不理解手册中的内容，那么我可能会在Unix＆Linux Stack Exchange上问。找到的答案必须符合许多合格标准：
参考应该是提出此类问题的人应该知道的参考，而不是通过Google找到的一些随机网站。
参考必须足够可信，要求质询者对其可靠性具有一定的信心。 （参考手册，而不是Joe的博客。）
必须在该参考中的明显位置找到所需的信息（即问题是关于X的，答案在参考中X的条目中） 。 （“函数F的功能是什么？”先验性地提出了一个通用参考问题，“我可以使用什么功能来执行X？”。）
所要求的信息必须合理地理解。 （“我已经阅读了有关X的参考文章，却迷失了，是否适合于目的P？”是一个完全合理的问题。）
您一意孤行地拒绝Google作为主要来源，这使您很难认真对待。现实情况是，有99％的人会首先在Google中输入内容。
–杰夫·阿特伍德
2012年1月3日20:57
@JeffAtwood任意吗？您是否尝试阅读我的答案（如果时间太长，请以粗体显示部分）？
–吉尔斯'所以-不再是邪恶的'
2012年1月3日21:00
我虚心地认为您是Homo Logicus，您概述的这些规则是任意拒绝Google作为主要来源的……实际上并不适合大多数人。 codinghorror.com/blog/2004/09/…
–杰夫·阿特伍德
2012年1月3日，21：21
@JeffAtwood当然，我在讽刺。我的大多数Stack Exchange回答都在某个时候涉及到Google（尽管有时只是为了找到用作参考的URL）。但是，我的观点是：仅仅因为问题中有关键字与Google匹配，并不意味着它们是相关，可靠或可理解的。
–吉尔斯'所以-不再是邪恶的'
2012年1月3日21:30
好吧，正确，这就是为什么使用Google搜索是流程图中3个评估步骤中的第一个。但这绝对是而且永远都是第一步...
–杰夫·阿特伍德
2012年1月3日在21:49
@JeffAtwood流程图的主要优点是它没有考虑搜索结果的可靠性（如问询者所感知）。
–吉尔斯'所以-不再是邪恶的'
2012年1月3日22:01
@JeffAtwood Google根据我们之前的搜索来自定义我们的结果。如果我搜索一些我不确定的东西，那么在少数几个排名很高的页面之外（例如Wikipedia，这是真正的一般参考），我很难获得与您相同的结果。因此，对于一个完全相同的搜索，一个人基于Google的General-Reference不是另一个人的参考，这使其变得不可靠。因此，我们就SciFi.SE达成的共识是，如果可以轻松地通过Google进行搜索（而不是GR），那是一个不赞成投票的合理理由-而不是VTC。
–伊兹卡塔
2012年10月28日4:49
为“ +1”作为“一般参考”来结束问题的动机是，您不需要人来回答这个问题，因为答案可以在很明显的地方找到。 （因此，对于提问者，答题者和未来的读者来说，这个问题是浪费时间。）
–轨道轻度竞赛
2013年1月26日19:14
@JeffAtwood：Google是研究的第一步，但这并不是使其成为实际信息的良好主要来源。它是主要来源的索引器。确实，这是其在世界范围内的实际正式工作。
–轨道轻度竞赛
2013年1月26日19:15
至少在计算机科学领域，有一些反复出现的问题，例如证明某种语言不是常规语言，或者如何分析算法。有一些标准技术，将在单独的参考问题中进行讨论和举例说明。当然，在某些情况下，标准技术不适用或需要特殊的修改。但是在我看来，将OP指向他们首先尝试，然后在他们没有帮助的情况下再回来，这是值得的。
– vonbrand
2015年10月25日，2：19
@vonbrand我们通过关闭这些参考问题的副本来解决此问题，我认为这是一个很好的解决方案。这并不总是适用于引用是外部引用的其他情况（字典，手册等），尽管可以通过列出引用字典/解释man / ...的引用问题来完成。
–吉尔斯'所以-不再是邪恶的'
15-10-25在11:36
我还认为SO的目标之一就是自我控制，即对任何SO问题的答案应该是在SO中找到。外部链接中断，页面内容（如Wikipedia）发生变化。带有断开链接的旧答案几乎是没有用的，因此，这种建议在SO上并不罕见，因为这种建议会鼓励外部链接，因此可能使问题变得更糟。无需研究的问题和大多数一般参考问题都已经被提出，因此，新的问题除了被否决外，还应重复进行。这与作为普通引用关闭它具有相同的效果，除了SO仍然是自包含的。
我真的不知道作为引用添加闭包会带来什么价值，除了查找引用比查找更容易重复的。一种简化查找重复项的非常简单的方法是将问题标记为一般参考问题，然后将其关闭为原始一般参考问题的副本。这样，一般参考问题就可以关闭，而无需在社区中引入RTFM的心态。
即是因为您因查找和引用本手册相关部分而付出的努力得到了回报。相比之下，如果您的问题被否决然后结束，您将因不愿为此付出努力而得到反奖励。
–轨道轻度竞赛
2013年1月26日19:16
我还认为，SO的目标之一就是要自给自足，也就是说，任何SO问题的答案都应该在SO中找到。外部链接中断，页面内容（如Wikipedia）发生变化。对于任何给定的软件项目，该手册都是权威性的。试图为SO中的每个软件项目复制手册不仅浪费时间，而且很危险。
–轨道轻度竞赛
2013年1月26日19:16
附录：
SO已经存在一个在输入和建议相关问题时阅读您的问题的引擎。至少对于最常见的有问题的语言（c＃，java，html等），还要链接到官方文档有多难？我确定这个问题在perl，lisp或汇编程序问题中不是什么大问题...
我知道您来自哪里，但是这些特定问题（尤其是琐碎的问题）的涌入太多了，以至于无法使用重复标志来处理-找到好的重复项是一项艰巨的工作。查找正确的RTFM链接通常要快得多。
– Pekka
2011年4月5日15:03
的确是。那么，您对尝试实施自动的（礼貌的）RTFM建议有何看法？另外，如果有具有基本概念的Wiki页面，则可以重复链接到该页面，这将使查找任务变得更加容易。可能会有一张“一般参考”问题表，mod可以访问，一般用户也可以访问。
– Aleadam
2011年4月5日15:14
老实说，我怀疑任何新用户都不会去考虑这些建议，即使他们根本不知道这些建议的存在。
– BoltClock是独角兽
2011年4月5日15:14
-1表示“添加一般参考原因是一个非常好的主意”，因为我认为这将降低SO的总体价值，而+2表示“将其创建为Wiki”，因此+1。
–yms
2011年5月17日17:34
附录+1。如果SO能够自动建议正确的手册，那就太好了。
– Erik B
2011年6月12日下午0:53
专家很难将自己与问题离婚掌握知识并投身为初学者。如果您提供给他们使用大RTFM（和链接）来关闭问题的工具，那么您将最终关闭大量问题，因为流程图的“太难解析”部分根本无法解决向专家传递许多问题。不仅仅是简单的问题即将解决，而是“我无法弄清楚STL向量类存在的问题...”，这将使RTFM变得有些晦涩，新手STL参考。
是的，“一般参考”的关闭理由必须绝对仅适用于手动链接为实际答案的那些问题。出于这个原因，不得关闭任何高于该水平的内容（例如您引用的示例）-答案可能仍在手册中，但正确的方法是引用相应的部分并添加简单的英语解释，一如既往。这是一个明显的当前危险，但是我对正确的沟通持乐观态度，因为所有其他密切的原因，共识也会为“一般性参考”而达成。
– Pekka
2011年5月31日在20:32
@Pekka嗯。我认为这可能可行。如果您可以简单地从参考站点剪切n粘贴而没有任何其他注释，并且知道OP会理解，那么这将是适当的。
– Pollyanna
2011年5月31日20:59
当然，仅指向巨大文档文件的任何链接也必须指定要查看文档的哪一部分。
–加布
2011年5月31日在21:12
我要说的是，只要问题的正文表明发帖人已经找到并尝试阅读该手册，那么它就不是“一般参考”。我个人非常愿意帮助初学者弄清楚文档的含义（并在必要时投票重新提出符合这些原则的问题）；但是“如何将对象添加到数组中？”之间存在很大的差异。和“我尝试在数组上使用addObject：并得到了怪异的结果-addObject：的文档说只允许使用frobs。什么是frob？这是问题吗？”
–jscs
2011年5月31日21:30
复杂单词，或存在细微差别或严格使用准则的情况（例如成语）是该网站的主题，但是如果我可以打开十二个日语-英语词典中的任何一个并几乎立即找到合适的翻译，这不是一个有趣或有益的问题。
社区似乎对此表示同意，因为在几个meta帖子以及站点的定义中，简单的翻译问题被宣布为脱题。同样，简单的翻译问题也正在由社区投票结束。
但是，当投票结束这一问题时，没有一个很好的结束理由可以充分描述问题被关闭的真正原因。 （即，为什么不问字典？）。目前，我们使用的“非构造性”含义并不完全相同。
我认为“通用参考”将更适合这些情况。
您可以（ab）使用“过于本地化”；毕竟，对任何词典中常见单词的定义或翻译的要求都不会帮助问询者，但问问者（下一个要问的人会有不同的单词，答案对他没有帮助）。
–吉尔斯'所以-不再是邪恶的'
2011年8月7日在21:53
我该怎么做XY-通常在原则上是琐碎的，只需要完成工作即可，通常又不是一个单一的问题：例如从数据库中获取数据并以奇数或偶数id显示
PS：还有另一个组，但这不是为了关闭，因为那样可以通过asker进行改进：
plz调试我的通用代码
通常可以通过调试打印来轻松解决
毫不费力地将代码/问题缩小到单个有问题的情况
假设它具有足够的常识，则可以在标签Wiki上引用index，如果使用此标志时弹出的标准下拉列表/类型完整的可接受的“手动答案”，则可以引用该索引。 br />
我认为这没有用。待解决的问题（除了措辞不同的重复项）都将被删除，以免使站点混乱。标记Wiki应该直接引用该手册-如果它引用了每个RTFM问题，那么您将在其中包括整个手册。
–吉尔斯'所以-不再是邪恶的'
2011年4月21日在20:52
@Gil可能是切线的，是单独问题的一部分，但是我遇到了一个有关如何提出问题的问题。这不是由于缺乏对如何在SE上提出问题的理解，而是由于缺乏相应的词汇表。即“串联”；某人可能知道他们要做什么的要旨，并使用了定义中的每个单词，但是如果所有闭合尝试都被删除，则描述级联的尝试将继续产生重复。如果手册的脚注带有2或3个项目符号，则进行简短尝试可能会提高搜索范围。
–mfg
2011年4月21日在22:49
如果由于缺少词汇而问这个问题，那么“如何将两个字符串首尾相连？” “使用[连接功能]（链接）。”是关于SO的完全有效的问答。
–吉尔斯'所以-不再是邪恶的'
2011年4月21日在22:54
@gil并不是关于串联的，但是如果该人还不知道它们被称为字符串变量，但是他们试图在Excel单元格中组合单词，那么它们必然会重复其他问题。这就是我希望出发的地方。
–mfg
2011年4月21日23:10
那只是另一个例子。如果提问者的问题本质上是他们不知道该词，那么他们的问题就不是别人使用完全不同的词的重复。如果您在“已关闭的问题索引”上拥有了全部，那么该问题将由不应关闭的问题组成！
–吉尔斯'所以-不再是邪恶的'
2011年4月21日在23:14
此处提交的URL列表应在整个站点范围内进行整理一些机制。例如，如果我粘贴了
是否可以从这样的日期获取UNIX时间2011-02-27 02:04:46？
/>时间戳的时间字符串
如何创建一个可以接受文件上传的PHP页面？
这些OP需要的是指向正确手册的链接，我们应该给他们提供手册。但是这个问题毫无目的。他们甚至没有可搜索的用处，因为任何理智的搜索查询都将导致实际的手册成为第一本。
Jeff讨论了在此处引入新的关闭原因的可能性。 Scifi.stackexchange.com。根据罗伯特的建议，它可能是这样的：
一般参考：这个问题太基础了；答案可以在任意数量的旨在查找该类型信息的常规Internet参考资源中找到索引。如“在此处输入重复ID”弹出窗口），以供用户建议正确的手动链接：
然后，建议的链接将显示在顶部的方框中。问题，例如重复的链接。
同样，从这些琐碎的问题中获得的声誉也令人震惊。我敢肯定，大多数高级用户的观点（包括我的观点）都来自回答“再次替换字符串的功能是什么？”输入问题。这会大大削弱声誉作为真正专业知识的衡量标准的价值。
我建议将追溯为“通用参考”的问题的答案追溯到社区Wiki，以消除任何获得的声誉。
#1 楼
仅供参考，这个接近的原因已在http://scifi.stackexchange.com和http://english.stackexchange.com上进行测试。我们已经完成了评估。有关背景信息，请参阅博客文章：问题是否简单？
特别是：
根据Stack Exchange Podcast＃20中的讨论，并在评估了英语和科幻的接近原因之后，我现在同意Joel的观点：我相信，这种接近原因有很大的潜在滥用和误解的可能。我们不太可能在整个网络范围内采用这种紧密的理由。
评论
我希望评估效果良好。与此相关的源源不断。如果您强迫第一个接近者建议参考网址（如重复），那么包括OP在内的每个人都会很高兴，但是使用此功能将阻止另一个毫无意义的重复项吸引无意义的使用：答案。
– Pekka
2011-4-25 19:37
@pekka Joel非常担心它将被滥用。我也很担心，因为许多程序员都“不能在全能的OCD中遵守一个重复的原子”。
–杰夫·阿特伍德
2011-4-25 20:48
@Jeff是的，我明白了这一点，并且有可能在有效问题上将其用作后门“ RTFM”。但是潜在的好处是巨大的……我很高兴看到它在SO上进行了数周的测试，mod和10ks密切关注即将结束的内容。
– Pekka
2011年4月25日在20:53
我真的希望很快能解决这个问题。我觉得我的利基越来越混乱。
–gnostradamus
2011年5月2日，下午3:21
@Jeff，请让我们把它放在怀疑论者身上...
–Sklivvz
2011年5月3日20:18
@yms，上面链接的几乎每个PHP问题都可以通过在PHP手册中查找有问题的函数来回答。我指望某人至少已经解雇了Google或参考了该手册，这并不是我认为的“精英歧视”。他们都有骗子，但是问题的类别是如此可怕和多产，以至于找不到完全匹配的事物。例如，PHP标记中有将近2000个有关strtotime的问题。能够关闭可以通过简单的手动阅读回答的问题，将是总体问题质量的一个胜利。
–查尔斯
2011年5月17日在18:34
@Sklivvz：那将如何在怀疑论者身上发挥作用？那里的社区有着令人难以置信的强烈的反逻辑/亲参考偏见。我很想看看“具有标准参考源的近距离问题”与“所有答案本质上必须是标准参考源的链接”如何相遇。
–user118150
2011年5月25日18:30
@yms我看不到任何精英人士。我不明白为什么该网站应该迎合那些甚至不愿意阅读其编程语言最基本基础知识的人，也不会迎合那些使用问题标题中确切文字对Google无关紧要的东西的人。另外，OP确实会得到对他们有帮助的答案-手册的链接。但是问题将被关闭（并且最终可以删除），而不是使问题库变得混乱
– Pekka
11年5月29日在18:54
我仍然不同意“您可以用谷歌搜索它”是使用此封闭时间的合理原因。我认为对此存在足够的困惑，以反对实施它。坦率地说，Pekka和Sklivvz想要使用它的方式，为什么不节省时间并称之为“ lmgtfy”关闭原因。
–user118150
2011年5月31日15:13
@user的关闭原因是“ RTFM”和“ Go Google”的礼貌版本。这有什么问题，特别是因为甚至为用户提供了正确的手动链接？
– Pekka
2011年5月31日19:45
我同意，@ Adam一般参考问题的主观性将是最大的危险。但是，可能无法在一开始就切勿在PHP手册中找到字符串大写功能的用户。除了手动链接或教程之外，为这些用户提供其他服务是一项艰巨而艰巨的任务。另外，以我的经验来看，无论问题的基本程度如何，对理解手册的特定部分并进行相应询问（而不是脑筋急转弯的“我想做xyz”）的用户都有很好的SO处理。
– Pekka
2011年5月31日19:59
评估期怎么样？现在有可能在其他任何网站上使用吗？
–杰夫·梅卡多（Jeff Mercado）
2011年8月3日，21：30
@TheGhostofChristmasPast链接腐烂和一般的SEO问题是一个巨大的问题，例如，请参见Dive陷入HTML5 / ect。仅仅因为今天容易找到答案并不意味着该网站将在一个月或一年之内轻松找到。我们至少可以知道，只要... Stack Exchange存在，Stack Exchange就将存在。因此，在此处实际获得答案是使社区受益的最佳方法。更糟糕的是，如果有人开始决定将Experts Exchange作为通用参考书怎么办？
–本·布罗卡（Ben Brocka）
2012年1月4日15:13
@Jeff ping，以防您有兴趣一般参考问题会给Google员工造成低质量的死胡同
– Pekka
2012-12-27 22:22
流程图很棒，对我来说看起来很完美。可惜这一切都被拒绝了。我承认我没有听过播客，但是我没有看到任何有说服力的问题可以令人信服。几乎每个人似乎都想要这个。
–轨道轻度竞赛
2013年1月26日19:21
#2 楼
我从这个建议中看到的问题是，这些琐碎的问题很有价值-根据询问的方式。我做了一个测试，给出了一个例子。我用Google搜索“如何在C＃中连接字符串”，并将文档作为第一个结果。因此，在这种情况下，您的陈述是正确的。
但是，
似乎是基于这样一个假设：每个需要知道如何在C＃中连接字符串的人都知道什么是串联，并了解什么是字符串数据类型。看一眼关于SO的一些问题，将立即证明这种假设是错误的。有各种级别的用户都在使用SO，并且可以从中受益。为了证明这一点，我在Google中搜索了“如何在C＃中将文本的两个变量添加到一个变量中”，并获得了这篇无关的博客文章作为第一个结果。 Google的首页有一些相关的结果，但是结果并没有像SO的搜索页上显示的结果那样接近用户的需求。
事实是，如果有人问以特定方式提出的问题，即使不是正确的提问方式，其他人最终也会同样也会提出。如果SO遵循建议以关闭所有“通用参考”问题，那么它将消除包含这些问题的特别有价值的方面-这是隐式交叉引用术语。
我认为在这种情况下，“重复问题”接近的原因就足够了，因为它将“错误方式”提出的问题指向单个问题，从而教授了正确的术语并回答了问题。
评论
公平点。我也更喜欢将这些封闭在一起，但是根据我的经验，找到一个可以很好回答的原始问题是很多工作，特别是对于琐碎的问题，因为它们通常包含许多通用术语。对于一个琐碎的问题，这种努力通常并不十分值得。我意识到这个新的关闭原因将是礼貌地放置“ RTFM”，但我认为仅由于数字庞大而有必要。另外，如果可以提供手动链接，新手仍会得到他们的答案。
– Pekka
2011-4-5 15:05
如果关闭需要指向一般参考的链接并且仍然可以搜索，那么我认为这个问题几乎可以消除。
–布赖恩
2011年6月8日在20:07
一个使您措辞古怪/理解欠佳的观点：stackoverflow.com/questions/6613890/…我认为它们应该立即关闭并被淘汰，尽管:)
–莫斯科
2011年7月7日在16:47
@fosco，看起来像是。 1小时-11
–smartcaveman
2011年7月7日在17:44
#3 楼
附带条件“很好问”下的“毫无疑问，太简单了”发生了什么？我不喜欢将用户解雇到Web资源上的想法。给社区这种力量，每个人都会开始使用它来轻视。有点像社区Wiki警察（应该是CW !! 1！1）和作业高级调查（这是作业吗？是吗？那么您还没有添加作业标签！）。
我有一项个人政策，即不管答案的正确性或相关性如何，都应否决只是链接的任何答案。 OP认为答案确实在回答，而资源提供背景阅读。不是“是的，这对我来说太琐碎了”。如果您觉得问题太琐碎而无法确定，请在其他地方看看。
我同意我们需要找到一种更好的方法来删除重复项。我不认为是这样。我认识到大量低级别重复项存在问题，我们应该在这个级别上寻找解决方案。一些建议：
搜索
tag-faq的简便方法？是的，我知道，在搜索框中出现[tag-faq] how do I write hello world in tag，但是.... 更突出的“这可能是重复的”消息？也许打断答案发布（在发布之前，请考虑是否已问过此问题。如果您对{link}存在的内容有更好的答案，请进行发布）。有点像“发布另一个答案”功能。
评论
+1表示如果问题过于琐碎而您无法看待，请转至其他地方。
– aioobe
11年5月28日在22:44
@aioobe-不是单个琐碎的问题才是问题。当一些琐碎的问题开始淹没该站点时，专家们将把目光投向其他地方，例如StackExchange网络外部，然后整个事情将转移到Yahoo!上。答案。
–布拉德·梅斯（Brad Mace）
2011年6月12日4:04
-1：您将“已经在现有权威文档中明确描述的存在”的概念与“变得简单”的概念混淆了。它们是完全正交的。这是一个非常简单但并非根本的“通用参考”问题，因为它在任何文档中都没有明确说明答案，所以非常好。
–轨道轻度竞赛
2013年1月26日19:13
如果要删除meta上的帐户，请遵循以下步骤：meta.stackoverflow.com/help/user-deletion。谢谢！
–亚当·李尔♦
13年1月31日在16:40
“如果一个问题对您来说太琐碎，您不愿意去看，请找别的地方。”不能同意
–杨敖博
13年7月28日在15:01
#4 楼
[TL，DR：一般参考是“ wikipede it”，而不是“ google it”。]我支持一般参考关闭原因，尽管我们需要谨慎对待滥用的可能性。用更近的距离指示参考是最小的障碍。
但是，我不太同意Borror0的流程图。我认为不应将Google用作确定问题是否是合法的Stack Exchange问题的工具。面对Google问题，我愿意接受非Google员工。
将问题作为“一般参考”来结束的动机是，您不需要人来回答这个问题，因为答案可以在明显的地方找到。 （因此，这个问题对于提问者，答题者和未来读者来说都是浪费时间。）
如果我想知道英语单词的意思，我不会看它在Google上，我将去找英语词典。如果这个单词对我的字典来说太晦涩难懂，或者在我找到该单词的上下文中没有任何定义有意义，那么我将寻求其他工具。好的，所以我用google搜索，根据www.urbandictionary.com，我发现它的意思是“阴茎”。嗯，也许我最好问一下英语语言和用法堆栈交换。
如果我想知道科幻人物是谁，我首先要在Wikipedia上查找它。如果找不到所需的内容，则可以使用Google并找到特定SF Universe的Wiki。但是这些Wiki并不总是可靠的，并且通常以一种宇宙的视角来编写，如果您不喜欢该世界，那么它们将很难被遵循。所以我可能会问科幻小说与奇幻小说堆栈交换。
如果我想知道如何游览外国城市，那么我不会先在Google上查找它。在拥有多个运输公司的地方，通过Google搜索可以轻松地使我仅了解其中一个运输公司。因此，我将在Wikitravel上查找城市。如果找不到答案，可以在Travel Stack Exchange上询问。
如果我想知道unix命令的作用，那么我就不会从Google上查找它。我要提出它的手册。 Unix变体和Unix变体之间的命令可能会有所不同，这样我将得到一个对我的系统来说准确的答案。如果命令没有手册，或者我不理解手册中的内容，那么我可能会在Unix＆Linux Stack Exchange上问。找到的答案必须符合许多合格标准：
参考应该是提出此类问题的人应该知道的参考，而不是通过Google找到的一些随机网站。
参考必须足够可信，要求质询者对其可靠性具有一定的信心。 （参考手册，而不是Joe的博客。）
必须在该参考中的明显位置找到所需的信息（即问题是关于X的，答案在参考中X的条目中） 。 （“函数F的功能是什么？”先验性地提出了一个通用参考问题，“我可以使用什么功能来执行X？”。）
所要求的信息必须合理地理解。 （“我已经阅读了有关X的参考文章，却迷失了，是否适合于目的P？”是一个完全合理的问题。）
评论
您一意孤行地拒绝Google作为主要来源，这使您很难认真对待。现实情况是，有99％的人会首先在Google中输入内容。
–杰夫·阿特伍德
2012年1月3日20:57
@JeffAtwood任意吗？您是否尝试阅读我的答案（如果时间太长，请以粗体显示部分）？
–吉尔斯'所以-不再是邪恶的'
2012年1月3日21:00
我虚心地认为您是Homo Logicus，您概述的这些规则是任意拒绝Google作为主要来源的……实际上并不适合大多数人。 codinghorror.com/blog/2004/09/…
–杰夫·阿特伍德
2012年1月3日，21：21
@JeffAtwood当然，我在讽刺。我的大多数Stack Exchange回答都在某个时候涉及到Google（尽管有时只是为了找到用作参考的URL）。但是，我的观点是：仅仅因为问题中有关键字与Google匹配，并不意味着它们是相关，可靠或可理解的。
–吉尔斯'所以-不再是邪恶的'
2012年1月3日21:30
好吧，正确，这就是为什么使用Google搜索是流程图中3个评估步骤中的第一个。但这绝对是而且永远都是第一步...
–杰夫·阿特伍德
2012年1月3日在21:49
@JeffAtwood流程图的主要优点是它没有考虑搜索结果的可靠性（如问询者所感知）。
–吉尔斯'所以-不再是邪恶的'
2012年1月3日22:01
@JeffAtwood Google根据我们之前的搜索来自定义我们的结果。如果我搜索一些我不确定的东西，那么在少数几个排名很高的页面之外（例如Wikipedia，这是真正的一般参考），我很难获得与您相同的结果。因此，对于一个完全相同的搜索，一个人基于Google的General-Reference不是另一个人的参考，这使其变得不可靠。因此，我们就SciFi.SE达成的共识是，如果可以轻松地通过Google进行搜索（而不是GR），那是一个不赞成投票的合理理由-而不是VTC。
–伊兹卡塔
2012年10月28日4:49
为“ +1”作为“一般参考”来结束问题的动机是，您不需要人来回答这个问题，因为答案可以在很明显的地方找到。 （因此，对于提问者，答题者和未来的读者来说，这个问题是浪费时间。）
–轨道轻度竞赛
2013年1月26日19:14
@JeffAtwood：Google是研究的第一步，但这并不是使其成为实际信息的良好主要来源。它是主要来源的索引器。确实，这是其在世界范围内的实际正式工作。
–轨道轻度竞赛
2013年1月26日19:15
至少在计算机科学领域，有一些反复出现的问题，例如证明某种语言不是常规语言，或者如何分析算法。有一些标准技术，将在单独的参考问题中进行讨论和举例说明。当然，在某些情况下，标准技术不适用或需要特殊的修改。但是在我看来，将OP指向他们首先尝试，然后在他们没有帮助的情况下再回来，这是值得的。
– vonbrand
2015年10月25日，2：19
@vonbrand我们通过关闭这些参考问题的副本来解决此问题，我认为这是一个很好的解决方案。这并不总是适用于引用是外部引用的其他情况（字典，手册等），尽管可以通过列出引用字典/解释man / ...的引用问题来完成。
–吉尔斯'所以-不再是邪恶的'
15-10-25在11:36
#5 楼
这个建议让我担心。关于SO的最好的事情之一就是我们在其他地方没有找到RTFM和lmgtfy心态。即是因为您因查找和引用本手册相关部分而付出的努力得到了回报。内置的RTFM工具可能会在SO社区中引入RTFM心态。我还认为SO的目标之一就是自我控制，即对任何SO问题的答案应该是在SO中找到。外部链接中断，页面内容（如Wikipedia）发生变化。带有断开链接的旧答案几乎是没有用的，因此，这种建议在SO上并不罕见，因为这种建议会鼓励外部链接，因此可能使问题变得更糟。无需研究的问题和大多数一般参考问题都已经被提出，因此，新的问题除了被否决外，还应重复进行。这与作为普通引用关闭它具有相同的效果，除了SO仍然是自包含的。
我真的不知道作为引用添加闭包会带来什么价值，除了查找引用比查找更容易重复的。一种简化查找重复项的非常简单的方法是将问题标记为一般参考问题，然后将其关闭为原始一般参考问题的副本。这样，一般参考问题就可以关闭，而无需在社区中引入RTFM的心态。
评论
即是因为您因查找和引用本手册相关部分而付出的努力得到了回报。相比之下，如果您的问题被否决然后结束，您将因不愿为此付出努力而得到反奖励。
–轨道轻度竞赛
2013年1月26日19:16
我还认为，SO的目标之一就是要自给自足，也就是说，任何SO问题的答案都应该在SO中找到。外部链接中断，页面内容（如Wikipedia）发生变化。对于任何给定的软件项目，该手册都是权威性的。试图为SO中的每个软件项目复制手册不仅浪费时间，而且很危险。
–轨道轻度竞赛
2013年1月26日19:16
#6 楼
如果在SO中还没有其他类似的问题，那么添加“一般参考”理由以将其创建为Wiki是一个很好的主意。基础知识对许多人也很有用。但是，如果已经有一个问题（在这种情况下，通常会有很多问题），则“完全重复”标志应该解决这个问题，因此我认为关闭它不方便一个问题。事实是，许多初学者可能会登录SO并提出非常基本的问题，并且再也不会出现，但是其他人可能会从反馈中学习并成为富有成效的成员。拥有这些Wiki问题仍将为他们提供所需的答案，而删除重复的问题应避免出现混乱。附录：
SO已经存在一个在输入和建议相关问题时阅读您的问题的引擎。至少对于最常见的有问题的语言（c＃，java，html等），还要链接到官方文档有多难？我确定这个问题在perl，lisp或汇编程序问题中不是什么大问题...
评论
我知道您来自哪里，但是这些特定问题（尤其是琐碎的问题）的涌入太多了，以至于无法使用重复标志来处理-找到好的重复项是一项艰巨的工作。查找正确的RTFM链接通常要快得多。
– Pekka
2011年4月5日15:03
的确是。那么，您对尝试实施自动的（礼貌的）RTFM建议有何看法？另外，如果有具有基本概念的Wiki页面，则可以重复链接到该页面，这将使查找任务变得更加容易。可能会有一张“一般参考”问题表，mod可以访问，一般用户也可以访问。
– Aleadam
2011年4月5日15:14
老实说，我怀疑任何新用户都不会去考虑这些建议，即使他们根本不知道这些建议的存在。
– BoltClock是独角兽
2011年4月5日15:14
-1表示“添加一般参考原因是一个非常好的主意”，因为我认为这将降低SO的总体价值，而+2表示“将其创建为Wiki”，因此+1。
–yms
2011年5月17日17:34
附录+1。如果SO能够自动建议正确的手册，那就太好了。
– Erik B
2011年6月12日下午0:53
#7 楼
我担心“太难解析”将是非常主观的。即使是简单的手册（例如PHP文档），初学者也常常感到困惑。是的，这是个大问题，我们应该寻找解决的方法，但是这个方法的缺点是没有客观地划定界线的简单方法，每个人都可以就容易解决的问题达成共识，因为太简单了，而其他问题则保留在适合该站点的地方。专家很难将自己与问题离婚掌握知识并投身为初学者。如果您提供给他们使用大RTFM（和链接）来关闭问题的工具，那么您将最终关闭大量问题，因为流程图的“太难解析”部分根本无法解决向专家传递许多问题。不仅仅是简单的问题即将解决，而是“我无法弄清楚STL向量类存在的问题...”，这将使RTFM变得有些晦涩，新手STL参考。
评论
是的，“一般参考”的关闭理由必须绝对仅适用于手动链接为实际答案的那些问题。出于这个原因，不得关闭任何高于该水平的内容（例如您引用的示例）-答案可能仍在手册中，但正确的方法是引用相应的部分并添加简单的英语解释，一如既往。这是一个明显的当前危险，但是我对正确的沟通持乐观态度，因为所有其他密切的原因，共识也会为“一般性参考”而达成。
– Pekka
2011年5月31日在20:32
@Pekka嗯。我认为这可能可行。如果您可以简单地从参考站点剪切n粘贴而没有任何其他注释，并且知道OP会理解，那么这将是适当的。
– Pollyanna
2011年5月31日20:59
当然，仅指向巨大文档文件的任何链接也必须指定要查看文档的哪一部分。
–加布
2011年5月31日在21:12
我要说的是，只要问题的正文表明发帖人已经找到并尝试阅读该手册，那么它就不是“一般参考”。我个人非常愿意帮助初学者弄清楚文档的含义（并在必要时投票重新提出符合这些原则的问题）；但是“如何将对象添加到数组中？”之间存在很大的差异。和“我尝试在数组上使用addObject：并得到了怪异的结果-addObject：的文档说只允许使用frobs。什么是frob？这是问题吗？”
–jscs
2011年5月31日21:30
#8 楼
在相当长的一段时间里，我都赞成这种一般性的参考理由。但是，关于科学幻想小说的一些事件和相关讨论改变了我的想法。我仍然认为关于SO的一些问题是值得的，但是我现在同意它可能……被误用了。不用回答一个问题作为一般参考，而是回答一次该问题，如果确实是普遍参考，则应该是微不足道的，并且您拥有自己的“一般参考”，可以将（相关的）将来的问题作为“直到时间的尽头。这具有明显的优势，即规范答案/一般参考完全位于同一SE网站上。这一直是一个令人担忧的问题，这就是为什么我们鼓励用户不仅发布链接，而且至少提供链接信息的摘要-因此在链接腐烂的情况下，答案仍然有用。#9 楼
我认为这在日语站点以及德语或其他外语站点在处理简单的翻译请求时会很有用。正如罗伯特·卡塔尼奥（Robert Cartanio）在这里提到的那样，这些外语网站不应充当简单单词或短语的基本“为我翻译这个单词”服务。复杂单词，或存在细微差别或严格使用准则的情况（例如成语）是该网站的主题，但是如果我可以打开十二个日语-英语词典中的任何一个并几乎立即找到合适的翻译，这不是一个有趣或有益的问题。
社区似乎对此表示同意，因为在几个meta帖子以及站点的定义中，简单的翻译问题被宣布为脱题。同样，简单的翻译问题也正在由社区投票结束。
但是，当投票结束这一问题时，没有一个很好的结束理由可以充分描述问题被关闭的真正原因。 （即，为什么不问字典？）。目前，我们使用的“非构造性”含义并不完全相同。
我认为“通用参考”将更适合这些情况。
评论
您可以（ab）使用“过于本地化”；毕竟，对任何词典中常见单词的定义或翻译的要求都不会帮助问询者，但问问者（下一个要问的人会有不同的单词，答案对他没有帮助）。
–吉尔斯'所以-不再是邪恶的'
2011年8月7日在21:53
#10 楼
还有另一组琐碎的问题，恕我直说，应该关闭：我该怎么做XY-通常在原则上是琐碎的，只需要完成工作即可，通常又不是一个单一的问题：例如从数据库中获取数据并以奇数或偶数id显示
PS：还有另一个组，但这不是为了关闭，因为那样可以通过asker进行改进：
plz调试我的通用代码
通常可以通过调试打印来轻松解决
毫不费力地将代码/问题缩小到单个有问题的情况
#11 楼
对此有用的后续措施将是用手册回答的未解决问题的索引（按需使用案例，以及将并存视为问题的其他方式）。这样做的价值在于（a）参考了手册（大概回答了这个问题，但是（b）存在是通过wikipedia或其他外部来源强调标签wiki的一种方式）。假设它具有足够的常识，则可以在标签Wiki上引用index，如果使用此标志时弹出的标准下拉列表/类型完整的可接受的“手动答案”，则可以引用该索引。 br />
评论
我认为这没有用。待解决的问题（除了措辞不同的重复项）都将被删除，以免使站点混乱。标记Wiki应该直接引用该手册-如果它引用了每个RTFM问题，那么您将在其中包括整个手册。
–吉尔斯'所以-不再是邪恶的'
2011年4月21日在20:52
@Gil可能是切线的，是单独问题的一部分，但是我遇到了一个有关如何提出问题的问题。这不是由于缺乏对如何在SE上提出问题的理解，而是由于缺乏相应的词汇表。即“串联”；某人可能知道他们要做什么的要旨，并使用了定义中的每个单词，但是如果所有闭合尝试都被删除，则描述级联的尝试将继续产生重复。如果手册的脚注带有2或3个项目符号，则进行简短尝试可能会提高搜索范围。
–mfg
2011年4月21日在22:49
如果由于缺少词汇而问这个问题，那么“如何将两个字符串首尾相连？” “使用[连接功能]（链接）。”是关于SO的完全有效的问答。
–吉尔斯'所以-不再是邪恶的'
2011年4月21日在22:54
@gil并不是关于串联的，但是如果该人还不知道它们被称为字符串变量，但是他们试图在Excel单元格中组合单词，那么它们必然会重复其他问题。这就是我希望出发的地方。
–mfg
2011年4月21日23:10
那只是另一个例子。如果提问者的问题本质上是他们不知道该词，那么他们的问题就不是别人使用完全不同的词的重复。如果您在“已关闭的问题索引”上拥有了全部，那么该问题将由不应关闭的问题组成！
–吉尔斯'所以-不再是邪恶的'
2011年4月21日在23:14
#12 楼
我喜欢这个主意。我知道我的声誉有一部分来自完全回答此类问题，但我认为可以通过此信息来改善整个Internet。此处提交的URL列表应在整个站点范围内进行整理一些机制。例如，如果我粘贴了
linux.die.net联机帮助链接，则最好在linux.die.net出现故障时提供备用联机帮助链接。将所有URL的一个列表用作通用参考可以使查找无效的URL更容易，并且可以更轻松地实现标准化。我喜欢同时使用POSIX和特定于发行版的联机帮助页。标准和实施的内容有时是两回事，使两组详细信息在彼此之间的单击距离之内非常有用。
评论
如果可以的话，+ 2。我们真的需要这个。相关建议：如果通用参考成为迫在眉睫的原因，请为网址添加一个字段，例如重复项
这有一个主要缺陷：Google专门禁止在SE中使用它。
@Bobby有一类问题，需要重新考虑该规则。
@Bobby：嗯，一个月前有一篇关于它的博客文章；从那以后，保持沉默。 blog.stackoverflow.com/2011/02/are-some-questions-too-simple
@Pan yup，这就是为什么我问。杰夫在那篇文章中的主要语录：我们真的是想让用户如此懒惰以至于找不到明显的维基百科页面吗？还是在问之前甚至是最基础的研究？
-1表示建议武器化Community Wiki
最后一句话是一个非常糟糕的主意。一些优秀的回答者可能不知道会关闭什么作为“通用参考”，然后再打勾。您是在要求他们保持通灵。
@兰斯，我不同意。讲这些问题并不需要花很多心思，只需要对编程语言，平台或库有一点经验即可。如果您知道可以通过本手册的链接满意地回答这些问题，则说明它是一个一般参考问题。目前，您可以通过告诉别人如何在jQuery中通过ID选择元素来轻松获得80-100的声誉点，这是该库提供的最基本的操作。 （我也不例外，我也回答了很多这样的问题。）作为某种程度的专业知识的一种衡量，这消除了声誉的全部意义。
@Pekka，我一直在VBA中回答问题，找到MSDN链接是一个很大的痛苦。微软也是死链接的领地，它们总是在改变它们，因此，如果我们提供链接，它们将及时消失。
@Lance指出，如果OP不知道如何执行一些基本操作，则可以指出一个链接。但是它需要赢得声誉吗？我不这么认为。另请参阅对我最后一条评论的编辑。
@Lance和@Pekka，当有人问我已经回答的问题时，我（非常温和）感到烦恼，而不是粘贴我的回答的副本，我将该问题标记为重复，然后其他人来回答我，当然，虽然没有我的好，但他们不知道，因为他们没有看到我对原始问题的回答。我可以看到相同的论点来重复副本，但是我也看到相同的反论点。不管怎样，有人输了。
@以撒是的，都是真的。但是，对于重复项，IMO的反驳更强：识别重复项要困难得多，耗时得多。我倾向于不去做，CW'化通常是非常不公平的。但是如果您有一些知识，参考问题很容易告诉您。
我必须在这里与兰斯联系。一般参考意味着与许多人不同的东西。从技术上讲，RTFM可能会回答90％的问题，但这忽略了SE的全部要点，即要进行线性搜索并将其转换为哈希表。另一方面，在SE上获得“显而易见的”问题的答案有什么害处？
@Catskul re“造成了什么伤害”-伤害是这些问题重复了参考手册中直接提供的信息。他们总是有过时或不完整的危险。这没有道理。从技术上讲，90％的问题可能是RTFM问题，与本提案无关。它仅与通过手动链接完全回答的问题有关。我不反对给提问者一个答案，介意-只是问题库中的长期存储，它们在搜索结果中的弹出等，我认为这会适得其反。