| Subcribe via RSS
一开始看大家的评论感觉可能言过其实.
一本讲正则的书,在我看来一般都会很枯燥
因为正则实在太复杂了,一般越复杂越枯燥
和讲HTML和CSS的书一样,能写活的没几本.
但是读起来之后
发现实在是不错
像类似”环顾断言”之类”莫名其妙”的东西
都能讲解的很清晰
而且例子也特别详细
虽然骆驼书里面有过.但是我根本没注意到那本书里讲的这个
还有翻译也很好.连TIVO这种录像机的比喻都会把这东西译注一下
真的很认证
印刷也不错
强烈推荐(根据网友建议,加上链接和图片)
http://product.dangdang.com/product.aspx?product_id=20028613
成就系统工程师的职业生涯
转 http://www.cnblogs.com/ryanxue/archive/2006/09/09/499792.html
题外话
从家长到老师、从学生到职场精英，每个人都在说中国是应试教育，不是素质教育；中国是发展中国家，没有职业市场，一个人能成就什么，靠的是运气、胆量而不是技能、创造力。是这样么？历史有惊人的相似性，一句最具代表性的名言是：这个世界最不可思议的事情是它能够被人理解。同样的事情，在世界上的发达国家、在地球的其他角落，曾经发生或者正在发生，也可能即将发生。作为一名中国人，非常骄傲于中国近三十年来取得的成绩，中国成功地实施了经济转型，国家的角色从生存向发展转变，尽管这个时间看起来迟到了整整20年，但似乎是必不可少的经历，让人再一次感到“天地不仁，视万物为绉狗”的无奈。希望信息技术可以超越于历史上曾经出现的其他革命，最终成就一个新的时代。我曾经写过另一段文字，闲聊IT是否需要职业人士，可以把本人算作一个续篇吧。另外本文缘起于有感另一篇网络文章：成就DBA的职业生涯。在此感谢原作者的思想，尽管我无意抄袭，可是不知不觉被文章的思路所左右，希望作者原谅，原文讲述已经非常全面、透彻，尽管我们方向不同，一软一硬，却依然隐隐有些遗憾，该说的都已经说了，那么，只好继续说那些不太该说的。
我应该成为一名系统工程师么？
我曾问过许多人，也曾经被许多人询问：我应该从事系统工程师这样的职业么？我学习什么有更好的发展机会？甚至是如何学习？为什么学了很久没有丝毫进展？这几个问题确实不容易回答，或者根本就没有正确答案，甚至最佳答案也没有。因为它不仅因人而异，因时而异，而且因境遇而异。每个人有不同的秉性，有不同的天赋；在他人生最有价值的一段时间之内，有许多重要事情，执业发展只是其中一件“比较重要”的事情；他所生活的环境也对他的人生观、价值观有着潜移默化的影响，在不知不觉中，左右着他的行为。所有这一切，最终要由一个问题的答案所反映出来，甚至答案只是是、否两个选择之一！如果能认识到这些，大概就不会有人再提这个问题了。不过，即便不提这个问题，疑惑还是存在的。授业有先后，术业有专攻。每个人都有自己的超越于别人的天性，只是是否选择了正确的方向将蛰伏在体内潜质激发出来而已。疑可以答，惑却需要自己解，作者则希望本文能帮助你早日解惑。由于这个原因，本文中处处都是问题，而没有直接答案，毕竟疑惑需要你自己领悟，别人的答案不但不一定适合你，甚至可能会误导你，所以希望你自己能早日找到自己的职业之路。
从事IT职业的原因几乎相同：薪水高，充满新挑战，而且可以有一个舒适的办公环境，不同于出租车“禁闭室”，不同于噪音轰鸣的厂房，每天坐在冬暖夏凉的机房、办公室内，好不惬意。更重要的是职业名望，想起一则笑话：蚊子妈妈问蚊子女儿，为什么要嫁给蜘蛛。蚊子女儿说：蜘蛛丑是丑一点，可他是搞网络的啊！由此可见IT业界在世人眼中的“名望”。IT行业有很多职业可以选择，如何选择也是一个大问题！但不是本文要讨论的内容，如果希望对此有了解，只能等待以后的文章。简要来说，系统工程师是个“纯粹”的技术职业，而且需要脚踏实地地工作，能够亲自动手进行软件、硬件操作，对于那些充满激情，喜欢了解新技术，既不甘于象程序员一样进行千篇一律的工作（实际并非如此），也不想如同IT咨询、架构师总是“玩虚的”（实际并不是如此，我们以后再谈罗这个话题），那么系统工程
师正是你的最佳选择。单凭这一句解释，还不足以让你作出终生无悔的最后选择，而且也绝对不希望你现在就做出选择，为什么在这一个关系到你从此之后半生幸福快乐的重要问题面前如此草率？想起了莎翁借哈姆雷特名句：To be or not to be, this is the question! 我喜欢这句话，也一直在找这句话的答案。下面让我们一起来找到内心深处的答案，如何？
什么是系统工程师？
说了好久，你应当提出了第一个伟大的问题了：什么是系统工程师？对于这个问题，有多种答案。你可以认为系统工程师是一个大杂烩：一点服务器技术、一点操作系统知识、一点数据库概念、一点中间件结构、一点编程能力、一点网络基础、一点存储原理，还要一点IT素质和经验积累。从这些名词你就能预感到系统工程师职业道路上充满了挫折和令人头痛的问题（似乎所有的职业都是如此）。
系统工程师要解决所有的“系统”问题，是的，所有的问题。对于一个IT系统，什么不是系统问题呢？如果一个报表程序，计算的结果冲突，数据不平，似乎这是一个“非系统”的问题，但你依然要小心，如果这个程序是由于某些数据无法获取而因此得到了错误的结果，作为“系统工程师”的你依然逃脱不了干系。当然，你不需要知道所有的“系统”知识，但是知道得越多，显然对你越有帮助，也会帮助你成为更成功的系统工程师。作为一个IT系统，各方面紧密耦合，而你需要在这错综复杂的关系中理清头绪，抓住核心点，并为其他人提供技术支持。
记住，别人是使用工具的力工，而你，是系统工程师，是制造、维护工具的技师。在IT系统中，每个人所处的层面不同，关注的细节不同。系统工程师所要关注的是洗去铅华的赤裸裸的肉身，如同外科手术大夫，他的刀下可能是燕语莺声的超级女声，可能是拔山举鼎的动作明星，但现在，都不过是肝胆脾肺肾的组合。声带，不过是短短的一条肌肉，鬼才知道它震动起来会如何涅人心魄；胸大肌，就是那么两团红肉，止血钳一上，立刻是惨白一片。这既是系统工程师的成就，也是系统工程师涅磐之前的坟场。在后面，你会了解到具体原因，在这里简单的一个解释是如果在咽喉发现了癌变，你因为切除它，使这个人技术上能多活20年，但也可能会使她在手术清醒后就立刻自杀。作为系统工程师如果没有能超越于系统工程师的角色看待这个系统，你永远只能是一个系统工程师，也许这样就足够了，但至少我不这么认为，为什么不在成为一名合格的系统工程师后再向前一步，成为出色的系统工程师，或者是系统架构师呢？当然，你也要为此付出代价，你是否已经做好准备开始学习直到你感到已经无法再学下去了？
————–
作系统工程师并不是一件复杂的事情，但绝对不简单，特别是想作为出色的系统工程师。诚然，如果你在一个大公司里，你可以庸庸碌碌，按照手册或者前人的指点，每天做一些机械的工作，可是作为中国的杰出青年，你当然不像如此终了此生，你想有所作为，你在寻找“芝麻，开门！”。如果你在一个发展中的企业，你的机会就来了，你会深陷老板的威逼、业务部门的重压之下，自己殚精竭虑又身处求学无门的困顿之中，如果你能坚持过去，并经常保持思考的好习惯，成为资深的系统工程是指日可待，只是作为一个过来人，建议你今后小心太过于拘泥细节，缺乏全局和战略眼光，这会限制你进一步发展，更重要的是使你的工资止步不前。如果你是幸运儿，刚入道就混进IT名企，你可能在短短的几个月的时间内被（需要）填鸭进一堆产品、技术、Best Practice、认证，这些是你的幸运，也是你的不幸，能否消化得了，是不是造成你“消化不良”暂且不说，眼高手低、下盘发虚，或者被锁事缠身，每天搞那些看似高深，其实毫无独创价值，仅仅follow执行指令是一定的结局，而在繁忙的工作和同僚的敬仰中，你意识不到这一点，这是最大的遗憾。经过多年以后，当你青春不再，想再追寻回你的人生价值的时候，你还能自由驾驭你的人生么？
我们暂且抛开10年之后的话题，先看看眼下的艰难困苦。每个新人遇到的困难，往往都是在尝试着吸收大量系统工程师信息的时候发生的，而这也是必然的结果。系统工程师需要至少了解一种硬件平台，如果你供职于原厂商，你懂得某一种产品线就好了。实际上，即使这样，你也需要了解高、中、低端十几种产品、管理平台、配置设备接口卡、操作系统、群集管理软件。对，没错，是软件，在现在的Unix平台，还没有如同Mainframe那样进行透彻的专业化分工，你需要身兼数职，不过，这种专业分工现象正在加剧。如果你不幸身处集成厂商，你要做的事情更复杂。不同的产品线包括从服务器到存储，甚至不同厂商的产品都需要你一一精通。如果更加不幸，你任职于甲方，也就是IT产品的用户，别期望什么系统工程师、网络工程师、DBA、Helpdesk的区分，从你领导的理解，这些都被称为“搞计算机的”，而你，就是被聘用来“搞计算机”。无论怎样，做系统工程师绝对是个挑战。你是喜欢挑战的人么？
做系统工程师也需要随时待命。他们会在白天去安装设备，晚上去对生产系统进行调整，24小时随时准备着收到应急维修电话去修复致命的系统崩溃（术语叫做System Down——宕机）。计算机系统是为了支持业务运转，随着IT技术的普及和深入，IT系统提供了业务运转的动力和效率，同时也造成了IT系统中断，业务随之中断的事实。想象一下，你刷卡的时候被告知系统不能使用；你的手机欠费之后无法交费；你在网上浏览本文的时候，忽然收到“网络页面无法找到”的信息。这些都是作为系统工程师需要去解决的问题。你需要7天x24小时随时待命，你会在凌晨3点接到请求应急支持的电话，你会“一饭三吐哺，一沐三渥发”，不定时的饮食，饕餮快餐盒饭等垃圾食品，没有锻炼的时间，焦虑的心情会让你或者体重暴增，或者身形憔悴，总之，你俊朗的体形伴随着你的青春一起消逝在无限的为系统服务之中。你能容忍这样的生活么？
系统工程师的职责包括安装、调整、维修（其实是查找故障，更换部件）硬件设备，为硬件升级微码，为操作系统打补丁。通常，这些操作不能在公司正常营业的时候进行，因为以上这些操作或者必须要中断设备服务，或者可能造成服务中断的风险，因此你有机会见习一下（也许是长期体验）吧台女郎的生活方式，午夜、凌晨、周末是你法定工作时段。如果你向往朝九晚五的生活方式，至少你要有充足的心理准备，在短时间内你不得不向你的理想说再见了，或者短期（这个时间根据你成长的速度不同，可能两三年，也可能要十年）接受它，或者换个朝九晚五的工作，但千万别去抱怨它，生活就是如此，no pain, no gain，不是么？
对系统工程师而言，在初级阶段，你会被资深人士指使来指使去，做一些令人刺激的工作——轰轰作响的风扇，闪烁迷离的指示灯，拿着几张光盘，一把螺丝刀，一个烂笔记本电脑装载着一堆PDF文件就冲向了一个完全未知的世界。你不得不坐在计算机前面一次又一次敲着似乎相同的命令，确惊异于得到了不同的结果。你完全没有准备好就被拉上了前台，还要面无惧色，试图让领导、客户、同事认为你具有足够的能力去战胜任何困难，一本红皮书，一把螺丝刀可以搞定任何问题。也许你比较谦逊，总是站在老鸟身后，拿着厚厚的笔记本，记录着屏幕上快速闪现的字符，回家整理天书一般的笔记。你还需要与业务人员、网络管理员、DBA、应用程序开发人员、项目经理和最重要的人物：你的领导配合。理解别人要你做的事情，也要让别人理解你需要他们做或者配合的事情，最重要的是，你需要向别人解释发生了什么，即将要发生什么，还有这些事情会对他们造成什么影响。沟通技巧，当然还有所谓的谈判技巧，这些都被称为专业技能（Professional Skills），你的这些专业技能如何？
以法律语言来说，系统工程师的工作“包含但不限于”下面的列表，不过这也是系统工程师的典型职责：
· 每天检查系统运行情况，及时发现系统的报警信息，并进行处理。
· 收集系统统计和性能数据，进行分析。
· 配置和调整数系统参数，以便实现应用程序的特定要求和最佳性能。
· 分析和管理系统安全，控制和监视用户对系统的访问、资源使用。
· 定期对系统进行备份，在必要时提供恢复。测试备份与恢复是否正常。
· 升级操作系统软件（补丁）和硬件微码，必要时升级或者迁移系统、数据（物理层面迁移）。
· 对应用程序开发人员、数据库管理人员、网络管理人员提供支持。。
· 评估产品和技术，为IT管理、规划者提供有效的数据。
· 实现系统规划、设计，均衡设计问题以优化性能。
· 逐步提高系统可用性，降低管理复杂性（这一条对于甲方人员，纯粹是自宫的条款，但却有助于你升级，实际你主动，则可以是操刀手，而不被动等待成为别人的鱼肉）。
· 诊断、定位故障，执行故障检测检测，解决任何系统相关问题。必要时联系厂商支持人员以便使问题得到较好的解决。
· 参与制定、执行系统管理流程、系统设计规划/实施方案。
现在你是否对系统工程师的职位有了深入地了解？以上信息尽管不是业界的标准，只是我个人杜撰，但无论你身处甲方还是乙方，无论你是招聘者还是应聘者，还是恳请您的首肯和认可，我也相信这些介绍至少能涵盖80%的内容，如果你心中的目标据此只是有少量偏差，这个无关紧要，哪有那么严格的定义呢？都是先有了生物，才有对此类和类似生物的物种定义。如果你心目中的要求严重与此内容相背离，那么我劝您最好改个方向或者描述，否则招聘者可能招不到人，应聘者可能觉得与心中的理想大相径庭。但这些目标也仅仅是告诉你作为一个“系统工程师”通常会发生什么，别人是怎么要求你的，你需要为别人做什么而换取赏识（更重要的是工资），你自己来决定这是不是适合你的职业。我个人也认为这个职业非常有价值，至少作为一个前期的基础工作非常有价值，他是进入IT行业的三大基础工作之一：系统工程师（服务器、网络、存储、操作系统）、数据库管理员（数据库、中间件、Web Service）、程序员（编程语言、业务逻辑）。如同戏班学徒，一切要从0开始，而今后的路很长，也很惊险。以上这一段帮助你决定这是不是你希望从事的职业（至少在现阶段），假如它是，那么尽你所有去得到它！
所有的失败千差万别，所有的成功都一样：你需要掌握很多硬技术、软技术以及更重要的——运气。当然，你的技能越强，软技术越
高，你的运气也就越好。你的软技术怎么样？
我怎样得到第一份系统工程师工作？
相信你已经阅读了前面的文字，并且认为系统工程师是一个很好的职业，祝贺你！我希望你能从中受益，并感受到工作的乐趣。那么
，你如何找到第一份系统工程师工作？这个问题我已经听别人问了许多许多遍，这是一个众所周知的鸡和蛋的问题。
即使经过了Internet泡沫爆裂，IT技术依然没有停滞其在世界各个角落渗透的步伐，大量的IT投入需要众多的IT技术人员，包括各种
硬件、软件工程师、架构师，咨询专家，其中系统工程师就是其中重要的一个角色。系统工程师在规划、建设、维护阶段，都处于重
要的位置。能真正“精修电脑，专业架设网络”的人其实并不多，真正合格的系统工程师更少。早些时候，也许由于你在学校的实验
室用过2天Sun/Solaris，或者知道IBM除了个人计算机（已经卖给了Lenovo），更大的业务在于大型主机（Mainframe/zSeries），集
成的应用服务器（AS/400 iSeries），小型机（RS/6000 pSeries），当然也有PC服务器（xSeries），以及软件、服务、芯片制造、
专利等，甚至对于这些你一无所知，但可以说流利的洋文，也可以作为potential的种子堂而皇之地进入到IT领域，那个时候，你所
要做的是选择去那一家公司，而不用考虑哪一家会接受你。现在，各个公司都开始谨慎起来，大量的真假系统工程师都下岗了，主动
的或者被动的，原因千奇百怪，有不合格开除的，有公司倒闭的，有机构精简的，有小庙养不起大神的，当然也有换个活法的。众多
的劳动力大军在人力市场上一个造成了一个奇怪的现象：想找工作的找不到，想招人的招不到。
从绝对数量来看，IT人才市场是一个买方市场，一个还算像样的公司发出招聘需信息后，简历将会如同雪片一样纷纷而至，从诺大一
个人力资源库中筛选出合适的人选：即能满足工作有求，又不会发生狗窝领养了狮子仔的情况，这对于人力资源和IT领导都是个难题
。得到第一份系统工程师工作的最艰难的部分在于每一个职位都要求有一些工作经验。除了几家大公司，希望从小用公司文化同化刚
入职的大学生，其它公司都希望找一个熟手。从公司角度考虑，这点很容易理解：假如一个新人没有一点经验，公司会付给这个人高
工资，让他去操作、维护和运行你IT基础组织的最大最重要的一部分么？并且，在等待他成长起来的过程中，可能会损失上百万的收
入（付给他的工资、付给支持人员的工资、付给他学习的费用、一旦他误操作的损失补偿，还有新业务的损失）。对大多数公司而言
，这些问题的答案肯定是‘不’。所以，没有经验，获得你的第一份系统工程师工作是很困难的。
关于这个鸡和蛋问题的难度我们不再讨论，落到实处，这是必须要战胜的障碍，对别人，不过是个难题，对你，这是你的未来。下面
将针对实现你第一个系统工程师工作的目标给你一些建议。
提示#1:接受培训。–尽可能多的学习有关系统硬件、软件的知识。这很可能将占用你正常工作以外的时间、精力和Money。许多培训
机构都举办专业的培训班，唯一遗憾的是中国的职业教育还不够专业，仅仅能把国外某个专题的内容照搬过来，可以说理论有余，实
践不足。理论是非常重要的，可以让你夸夸其谈的时候言之有物；实践同样重要，即使你骗过了面试考官，真的到现场去干活的时候
，都不知道白颜色的是HP、黑颜色的是IBM、紫色的是SUN，你就糗大了。假如你现有的老板不资助你的学习（特别是一些小公司），
那么你可能不得不自己支付这笔费用。这笔投资从长远来讲是值得的，但是短期内，特别是对于一个刚毕业的学生，4位数的投资还
真要好好考虑一下。选择口碑不错的培训班，在参加之前，多问问“过来人”。另外，许多系统工程师职业要求至少为计算机科学或
相关专业本科以上学历，因此你必须至少有那样的文凭。我也遇到了很多由于小时贪玩、大器晚成、经济拮据等原因，没能混到这样
学历的朋友，这很遗憾，但并不是斯芬克斯的难题，只是需要你在别的方面更加努力，现在到了证明你自己的时候了。
提示#2:锻炼成为系统工程师。–许多操作系统都有可以在PC上可以运行的版本或者模拟器，例如Solaris 10, Windows NT，还有一
些有网上可以Telnet（尽管不是root用户）练手的地方，对于AIX系统有一点遗憾，还没有合适的模拟器，刚刚发布的Full System
Simulator PowerPC 970似乎可以做到，但还没有得到验证，不过买一台二手的小机器，也就一台PC的价格，还算公道。在自己的机
器上练习使用操作系统，履行你所能想到的系统工程师的职责，了解硬件、软件的搭配，故意破坏系统，并且尝试修复它。这样既可
以提高你的技能，也可以证明你的能力。
提示#3:获得认证。–许多服务器厂商都提供自己的产品的认证，而聘用公司也会把认证看作是一种support document，只是仅获得
认证是不够的，但有认证总比没有好。通过产品认证测试并不意味着你知道如何管理一个大型系统。它只是告诉你以后可能的老板，
现在你拥有了一定的技术。它还告诉你的老板你对这个工作的态度是很认真的，并且已经有了自己的投资去提升技能。我看到许多人
抱怨他们已经得到了认证但是没有经验，甚至仅仅是靠背考题得到的Paper认证，这当然对帮助他得到第一份系统工程师工作没有十
足的把握，并且这种走捷径的能力说明你不太适合做系统工程师，而更适合做一个销售，为什么去应聘系统工程师呢？再次强调，认
证本身并不能使你得到工作，但它可以督促你学习，可以让你了解到许多不注意的细节，可以让你得到一个更加可判定你自己能力的
证明。即使你没有考过，你同样获得了许多。不要依赖认证来给你带来你要找的工作，你需要的比这还要多，并且认证在最后会帮助
你的。
提示#4:利用你现有的技能。–许多系统工程师都具有网管背景，其他的有应用程序开发背景。假如可能，查看你能否利用现有的技
能来得到工作，即使你仅仅是一个网吧的管理员。现在的目标就是为你和你的老板创造一个双赢的局面。例如，让我们假设你已经是
一名网管，而想进入Unix领域。新工作完全可以用到你的系统管理技能，你不会迷惑于DNS, FTP, Web Service，知道组、用户、安
全控制的概念，了解IP地址和掩码，拆过机器知道硬盘、CPU、内存，具有丰富的故障诊断经验，等等，虽然这些并不足以让你成为
经验丰富的系统工程师，但这些技能对于成为优秀系统工程师很重要。假如你已经了解某个产品平台，但你希望转到其他产品平台，
那么看看你能否找到一份同时接触两个产品平台的工作。这样，公司和你都得到了想要的。在你定位到某个平台后，你可以试着得到
一个能让你全职作它的职位，也许还可以在同一个公司中。实际上，以我自己的经验来看，在初级的时候，涉及太多的平台固然会让
你觉得很辛苦，甚至感觉样样稀松，没有专精，但这些经验在你的今后非常重要，这是让你能超越于普通的系统工程师的宝贵财富。
提示#5:利用现在的机会。–有时候，一个人进入系统工程师领域仅仅需要选择正确的地方和正确的时机。假如你现在的老板有一个
机会让你进行任何系统建设的项目，抓住这个机会！任何经验比没有经验要好。让你的管理者知道你十分积极的在寻找任何可能的机
会，你的能力和态度能让他们在下次机会到来的时候想到你。当你具有足够超越于周围的人的技能的时候，他们可能会决定培训你，
提拔你。许多许多人都是以这种方式获得他的第一个真正的系统工程师工作，在进行了一些相关的项目后不知不觉的成为一名较低级
的系统工程师。另外当一名系统工程师离开公司后，公司将在内部寻找一个候选人，假如他们认为这名候选人是有培养前途的话（更
重要的是听话、好用）。你的道路可能从做网线开始，也可能从搬设备、拆箱子开始。抓住机会！
提示#6:寻找一个引荐人。–这是一个关系社会，酒香也怕巷子深。简历仅仅是第一个广告途径，而圈子里相互之间的推荐是更快捷的途径。同时，你的引荐人会帮助聘用单位更快速地定位你的能力，减少考察期，而且如果你的引荐人具有足够的资历，可以成为你的导师，那么你就赚大了。当然，找合适的引荐人不比找到合适的工作容易，而且往往你已经具有了一定的实力之后，才会为人所知，才会有人愿意推荐你，而这时，其实你已经不需要引荐了。无论怎样，如果你恰好可以有人帮你推荐，对你找到合适的职位非常有帮助。
提示#7:寻找较低级的系统工程师职位。–假如你自知技能不足，看到职位的需求描述说他们正在寻找高级系统工程师，那么就要谨
慎些，不用去浪费时间，你并没有一个高级经验。他们要求找一个第一天上班就可以干活的人，而不是第一天上班就进培训教师的人
。但是他们会在低级的职位上考虑你，因为你具有“培养潜力”，更重要的是你很“廉价”。低级的系统工程师在高级专家指导下完
成工作。他们对系统建设、维护承担责任，同时也获得所有的荣誉。但是不要着急，你是真正的操刀手，所有的键盘字母都是你敲得
，只是你不知道那是为什么，所有的电缆都是你连接的，只是同样也不是到谁应该连谁。而你要记住这些，并回去研究这是为什么。
随着你的事业发展，你将会有越来越多的责任和得到越来越多的信任，以及越来越多的荣誉，最后是越来越多的钱（如果你只得到了
前者，当你无法忍受的时候，你可以决定换个更“均衡”的公司）。现在，因为你没有任何经验，你应该从这里启航，并接受一切“
不公正”待遇，你所能做的最好的选择，就是尽快可以说“不”，在此之前，你的反抗精神不会对你的环境有任何帮助。
有很多公司都“声明”寻找一名高级系统工程师，但是到最后，他们实际想要雇一名低级的系统工程师，虽然看到JD上满是吓人的要
求，你也许没有资格，但他们可能还是会决定雇佣你。但是提前说明你仍然在摸索阶段并且已经是较低级的系统工程师水平。不要试
图欺骗他们让他们认为你是高级专家。这只会降低你得到这项工作的机会。公司就是赌场的庄家，任何人都可以加入，只要给出合适
的赔率。实际上，大部分公司都不会有不需要的员工，只会觉得你的能力与你的开价不匹配。
以上这些提示将帮助你得到第一份系统工程师的工作。祝你在寻找工作时有好运气。当你已经找到了第一份系统工程师工作后，继续
下面的部分来学习如何往下走下去。
实际中写一条简单的重写规则：
源地址：
http://www.example.com/soft/install?ver=1.1
重写地址为：
http://www.example.com/my/soft/report.php
配置文件httpd.conf修改如下：
注意配置中的两个问号的应用，其中QUERY_STRING取得url问号后的查询字符串，这里实际重写应用是需要去掉后面的查询字符，所以需要用到？来终结！
官方文档解释为：
注意：查询字符串
Pattern不会按照查询字符串进行匹配。为了达到这个目的，你必须使用一个带有%{QUERY_STRING}变量的RewriteCond指令。当然，你也可以在替换字符串中创建包含查询字符串的URL：在替换字符串串中使用问号，以标明其后的部分应该被重新注入到QUERY_STRING中。而要删除一个已有的请求串，则可以用问号来终结替换字符串。为了联合新旧查询字符串，请使用[QSA]标志。
写在转载之前:
一般来说我是不会再博客上转载的
如果有东西我觉得很有用
我会放在链接里面
不过这篇文章,实在是我太需要了.所以转载了过来
为什么需要这样一篇文章
因为不会用google的寄生虫实在太多了.
多到我不得不回答诸如
“我怎么清空IE的缓冲”或者”我现在不能访问XXX了.怎么回事啊”
之类愚蠢的浪费时间的问题
并且这种白痴问题之后随之而来的不是问题的解决
而是更多的类似”清空按钮在哪里”或者”怎么看我的IP地址”白痴问题
这种浪费别人时间的蠢蛋为了让自己舒服给别人带来了巨大的压力
所以如果我再碰到这种人
我会直接送他们来这里
这篇文章很长.我使用一个别人的精简版就是
“在提问之前，你需要做以下事情：
尝试搜索互联网以找到答案
尝试阅读手册以找到答案
尝试阅读FAQ(常见问题)文档以找到答案
尝试自己检查或试验以找到答案
尝试请教懂行的朋友以找到答案
如果你是程序员，尝试阅读源代码以找到答案
提问时，请先表述你已经做了上述事情，这将有助于建立你不是寄生虫与浪费别人时间的印象。最好再表述你从中学到的东西，我们喜欢回答那些表现出能从答案中学习的人。”
当然我不期待问我的人会是程序员.
而且如果真是程序员.我也不指望回去阅读源代码
因为真能做到这点的人.基本是我去问他,而不是他来问我了.
那么对于那些认为在请教懂行的朋友的人(当然你们问我认为我很懂行,好吧.我也许懂一点)
请把你们先打开google,把你们的问题先输入里面搜索一下
或者先做一下RTFM的工作(Read The Fucking Manual)
然后再来问我.
如果你直接跑来问我.而且给我的是很白痴的问题
诸如”怎么编译程序”
那么我会视心情
来问候你,或者你的族人
所以觉得我很暴躁或者不耐烦的人
可以先去烦一下不会不耐烦的google或者baidu,yahoo
好了.废话结束
正文开始.
提问的学问
孔子日：敏而好学，不耻下问。其实提问本身是有学问的哟，一个会提问的人学问到底有多高？学习并且问即为学问，即到底提问有哪些学问呢？
作者：Eric Steven Raymond
原文：How To Ask Questions The Smart Way
翻译：王刚
时间：2004年11月2日
一、目录
译文
弃权申明
引言
提问前
提问时
仔细挑选论坛
面向新手的网页论坛和IRC通常响应最快
第二步，使用项目邮件列表
使用明确而有意义的主题
使之更易回复
使用清晰、语法与拼写正确的语句
使用易懂的格式发送问题
描述问题应准确且有内容
多不等于准确
别动辄声称找到臭虫
低声下气不能代替自己应做之事
描述问题症状而不是猜测
按时间先后罗列问题症状
描述目的而不是步骤
别要求私下回复
问题应明晰
别张贴家庭作业
删除无意义的问题
不要刻意标明问题紧急
礼貌总是无害的
问题解决后追加一条简要说明
如何解读回答
RTFM与STFW：如何知道你已完全搞砸
如果还不明白.
对待无礼
别象个失败者那样反应
提问禁忌
好问题与坏问题
如果没有回复
如何更好地回答问题
相关资源
鸣谢
二、内容
译文
译文: 捷克语 丹麦语 爱沙尼 亚语 法语 德语 希伯来语 匈牙利语 意大利语 日语 波 兰语 俄语 西班牙语 瑞典语 土 耳其语. 如果你想复制、镜像、翻译或引用本文，请参阅我的 复制须知.
弃权申明
许多项目的网站在 如何取得帮助的部分链接了本文，这没有关系，也是我们想要的。但如果你是该项目生成此链接的网管，请在链接附近显著位置注明“我们不是此项目的服务部！”
我们已经遭受没有此说明带来的痛苦，不断受到一些白痴的骚扰。他们认为既然我们发表了此文，那么我们就有责任解决世上所有技术问题！
如果你因为需要帮助阅读了本文，然后带着可以直接从作者那取得帮助的印象离开，你就不幸成了那些白痴之一。不要向我们提问，我们不会理睬 的。我们在这只是给你说明如何从那些真正懂得你软硬件问题的人那里取得帮助的方法，99%的时间我们不会是那些人。除非你确信此文作者是你遇到问题方面的专家， 请不要打扰，这样大家都更开心一点。
引言
在 黑客 的世界，你所提技术问题的回答很大程度上取决于你提问的方式与解决此问题的难度，本文将教你如何提问才更有可能得到满意的答复。
开源程序的使用已经很广，你通常可以从其它更有经验的用户而不是黑客那里得到回答。这是好事，他们一般对新手常有的毛病更容忍一点。然尔，使用我们 介 绍的方法象对待黑客那样对待这些有经验的用户，通常能最有效地得到问题的解答。
第一件需要明白的事是黑客喜欢难题和激发思考的好问题。假如不是这样，我们也不会写本文了。如果你能提出一个有趣的问题让我们咀嚼玩味，我们会感激你。 好的 问题是种激励与礼物，帮助我们发展认知，揭示没有注意或想过的问题。在黑客中，“好问题！”是非常真挚的赞许。
除此而外，黑客有遇到简单问题就表现出敌视或傲慢的名声，有时候我们看起来还对新手和愚蠢的家伙有条件反 射式的无礼，但并不真正是这样。
我们只是毫无歉意地敌视那些提问前不愿思考、不做自己该做之事的人。这种人就象时间无底洞──他们只知道获取，不愿意付出，他们浪费了时间，这些时间本可用于其它更值得回答的人和更有趣 的问题。我们将这种人叫做“失败者 (loser)” (由于历史原因，我们有时将“loser”拼为“lusers”)
我们注意到许多人只想用我们写的软件，他们对学习技术细节没有兴趣。对大多数人而言，计算机只是种工具，是种达到目的的手段。他们要生活并且有更要紧的事要做，我们承认这点，也从不指望每个人都对这些让我们着迷的技术问题感兴趣。不过，我们回答问题的风格是为了适应那些真正对此有兴趣并愿意主动参与问题解决的 人，这一点不会变，也不该变。如果这都变了，我们就会在自己能做得最好的事情上不再那么犀利。
我们(多数)是自愿者，从自己繁忙的生活中抽时间来回答问题，有时会力不从心。因此，我们会无情地滤除问题，特别是那些看起来象是失败者的，以 便更有效地把回答问题的时间留给那些“胜利者”
如果你认为这种态度 令人憎恶、以施惠者自居或傲慢自大，请检查你的假设，我们并未要求你屈服──事实上，假如你做了该做的努力使之成为可能，我们中的大多数人非常乐意平等地与你交流并欢迎你接纳我们的文化。试图去帮助那些不愿自救的人对我们简直没有效率，不懂没有关系，但愚蠢地行事不行。
所以，你不必在技术上很在行才能吸引我们的注意，但你必须表现出能引导你在行的姿态──机 敏、思考、善于观察、乐于主动参与问题的解决。如果你 做不到这些使你与众不同的事情，我们建议你付钱跟别人签商业服务合同，而不是要求黑客无偿帮助。
如果你决定向我们求助，你不会想成为一名失败者，你也不想被看成一个失败者。得到快速有效回复的最好方法是使提问者看起来象个聪明、自 信的人，并且暗示只是碰巧在某一特别问题上需要帮助。
(欢迎对本文指正，可以将建议发至 esr@thyrsus.com 。 请注意，本文不想成为一般性的 网络礼仪 指南，我一般会拒绝那些与引出技术论坛中有用的回复不特别相关的建议)
提问前
在通过电子邮件、新闻组或网页论坛提技术问题之前，做以下事情：
尝试搜索互联网以找到答案
尝试阅读手册以找到答案
尝试阅读FAQ(常见问题)文档以找到答案
尝试自己检查或试验以 找到答案
尝试请教懂行的朋友以找到答案
如果你是程序员，尝试阅读源代码以找到答案
提问时，请先表述你已经做了上述事情，这将有助于建立你不是寄生虫与浪费别人时间的印象。最好再表述你从中学到的东西，我们喜欢 回答那些表现出能从答案中学习的人。
使用某些策略，比如用Google搜索你遇到的错误提示(既搜索网页也查查讨论组)，可能就直接找到了解决问题的文档或邮件列表线索。即使没有结 果，在电子邮件或新闻组张贴问题时提一句“我在Google中查过下列句子但没有找到什么有用的东西”也是件好事。
准备你的问题，彻底地思考。轻率的提问只能得到轻率的回答，或者压根没有。在提问时，越是表现出做过思考并在努力解 决问题，你越有可能得到 实际帮助。
注意别提错问题。如果提问基于错误的假设，某黑客多半会一边想”愚蠢的问题……“，一边用按照问题字面的无用答案回复你，并且希望这种只 是得到 字 面回答而不是真正所需的经历给你一个教训。
永远不要假设你有资格得 到解答。你没有这种资格，毕竟你没有为此服务付费。如果你能够提出有内容、有趣和激励思考的问题──那种毫无疑问能够向社 区贡献经验而不仅仅是消极地要求从别人那获取知识的问题，你将“挣到”答案。
另一方面，表明你能够也乐意参与问题的解决是个很好的开端。“有没有 人能指个方向？”、“我这还漏点什么？”、“我应该查哪些网站？”通常要比 “请给出我可以用的完整步骤”更容易得到回复，因为你表明了只要有人能指个方向你就很乐意完成剩下的过程。
提问时
仔细挑选论坛
要对在哪提问留心，如果你做了下 述事情，多半会被一笔勾销或被看成“失败者”：
张贴与论坛主题完全无关的问题
在面向高级技术问题的论坛上提非常 初浅的问题，或者反之。
在太多不同的新闻组同时交叉张贴
给既非熟人也没有义务解决你问题的个人张贴你私人的电子邮件
为保护通信的渠道不被无 关的东西淹没，黑客会除掉那些没有找对地方的问题，你不会想有这种经历的。
所以第一步是找对论坛，Google与其它搜索引擎还是你的朋友，可以用它们搜索与你遇到困难的软硬件问题最相关的项目的网站。那里通常都有项目的FAQ列表、邮件列表及其文档的链接。如果你的努力(包括阅读FAQ)都没有结果，这些邮件列表就是最后能取得帮助的地方。项目的网站也许还有报告臭虫的流程或链接，如果是这样，去看看。
向陌生的人或论坛发送邮件极有可能是在冒险。譬如，不要假设一个富含信息的网页的编写者想充当你的免费顾问，不要对你 的问题是否会受到欢迎做乐 观的 估计──如果你 不确定，向别处发或者根本别发。
在选择网页论坛、新闻组或邮件列表时，不要太相信名字，先看看FAQ或者许可书以明确你的问题 是否与其主题相关。张贴前先翻翻已有的帖 子可 以帮助你感受一下那里行事的方式。事实上，张贴之前在新闻组或邮件列表中搜索与你问题相关的关键词是个很好的主意，也许就找到答案了。即使没有，也能帮助你整理 出 更好的问题。
别象机关枪似的一次性“扫射”所有的帮助通 道，那就象大嚷大叫并使人不快。一个一个地来。
弄清楚你的主题！最典型的错误之一是在某种致立于跨Unix和Windows平台的语言、库或工具的论坛中提关于操作系统程序接口的问题。如果你不 明白为什么这是大错，最好在搞清楚概念前什么也别问。
一般来说，在仔细挑选的公共论坛中提问比在私有论坛中提同样的问题更容易得到有用的回复。有许多理由支持这一点，一是看潜在的回复者有多少，二是看 论 坛的参与者有多少，黑客更愿回答能启发多数人的问题。
可以理解，老练的黑客和一些流行软件的作者正在收到超出他们承受能力的不当消息。就象那根多出来就可以压垮骆驼背的稻草一样，你的加入也可能会使情况走向极端──已经好几次了，一些流行软件的作者退出了对其软件的支持，因为伴随而来的涌向其私人邮箱的大量无用消息变得无法 忍受。
面向新手的网页论坛和IRC通常响应最快
本地的用户组织或者你所用的Linux发行版也许正在宣传新手取得帮助的网页论坛或IRC(互联网中继聊天) (在非英语国家，新手论坛很可能还是邮件列表)，这些 地 方是开始提问的好去处，尤其是当你觉得遇到的也许只是相对简单或者一般的问题时。经过宣传的IRC通道是个公开邀请提问的地方，通常可以得到实时的回复。
事实上，如果出问题的程序来自某发行版(这很常见)，在程序的项目论坛或列表提问前最好先在发行版的论坛或列表中问问，(否则)项目的黑客可能仅仅 回复“用我们的代码”
在任何网页论坛张贴之前，先看看是否有搜索功能。如果有，就试试用问题的几个关键词搜索一下，也许就有帮助。如果在此之前你已做过全面的网页搜索 (你应该这样做)，还是再搜索一下论坛，搜索引擎最近也许还没有索引此论坛的全部内容。
通过网页论坛或IRC频道提供项目的用户支持有增长的趋势，电子邮件交流则更多地为项目开发保留。先在网页论坛或IRC中寻求与项目相关的帮 助。
第二步，使用项目邮件列表
当某项目存在开发者邮件列表时，即使你确信谁能最好地回答问题，也要向列表而不是其中的个体提问。检查项目的文档和主页，找到项目的邮件列表并使 用它。采用这种策略有几个好理由：
任何向单个开发者提的足够好的问题也将对整个项目组有益。相反，如果你认为自己的问题对整个项目组来说太愚蠢，这也不能成为打扰 单个开发者的理由。
向列表提问可以平衡开发者的负担，单个开发者(特别是项目领导)也许太忙以至于无法回答你的问题。
大多数邮件列表有历史文档并被搜索引擎索引，其它人可以通过网页搜索找到你的问题和答案而不用再次在邮件列表中发问。
如果某些问题经常被问到，开发者可以利用此信息改进文档或软件本身以使其更清楚。如果只是私下提问，就没有人能看到最常见问题的完整 场景。
如果一个项目既有“用户”也有“开发者”(或“黑客”)邮件列表或网页论坛，而你又不摆弄那些代码，向“用户”列表或论坛提问。不要假设自己在开发 者列表中会受欢 迎，那些人多半会遭受你的噪音干扰。
然尔，如果你确信你的问题不一般，而且在“用户” 列表或论坛中几天都没有回复，可以试试“开发者”列表或论坛。建议你在张贴前最好先暗暗地观察几天 以了解那的行事方式(事实上这是参与任何私有或半私有列表的好主意)
如果你找不到一个项目的邮件列表，而只能查到项目维护者的地址，只管向其发信。即便在这种情况下，也别假设(项目)邮件列表不存在。在你的电子邮件中陈述你已经试过但没有找到合适的邮件列表，也提及你不反对将自己的邮件转发给他人(许多人认为，即使没什么秘密，私人电子邮件也不应该被公开。通过允许将你的电子邮件 转 发他人给 了相应人员处置你邮件的选择)。
使用明确而有意义的主题
在邮件列表、新闻组或网页论坛中，主题是你在五十个或更少的字符以内吸引有资格的专家注意的黄金机会，不要用诸如“请帮我”(更别提大写的“请帮我！！！！”，这种主题的消息会被条件反射式地删掉)之类的唠叨浪费机会。不要用你痛苦的深度来打动我们，相反，要在这点空间中使用超级简明扼要的问题描述。
使用主题的好惯例是“对象──偏差”(式的描述)，许多技术支持组织就是这样做的。在“对象”部分指明是哪一个或哪一组东西有问题，在“偏差”部分 则描述与期望 行 为不一致的地方。
愚蠢：
救命啊！我的笔记本视频工作不正常！
明智：
XFree86 4.1扭曲鼠标光标，某显卡MV1005型号的芯片组
更明智：
使用某显卡MV1005型号芯片组的XFree86 4.1的鼠标光标被扭曲
编写“对象──偏差”式描述的过程有助于你更具体地组织你的问题。是什么被影响了？仅仅是鼠标光标或者还有其它图形？只在XFree86中出现？或只是在其4.1版中？是针对某显卡？或者只是其MV1005型号的芯片组？一个黑客只需描一眼就能够立即明白什么是你遇到的问题，什么是你自己的问题。
更一般地，想象一下在只显示主题的文档索引中查找。让你的主题更好地反映问题，可以使下一个搜索类似问题的人能够在文档中直接找到答案的线索而不用 再次张贴提问。
如果你想在回复中提问，确保改变主题以表明你是在问一个问题，一个主题象“re: 测试”或“re: 新臭虫”的消息不太可能引起足够的注意。同 时，将回复中与新主题不甚相关的引用内容尽量删除
对于列表消息，不要直接点击回复(按钮)来开始一个新的线索，这将限制你的观众。有些邮件阅读程序，比如mutt，允许用户按线索排序并通过折叠线 索来隐藏消息， 这样做的人永远看不到你发的消息。
仅仅改变主题还不够。mutt和其它邮件阅读程序还要检查主题以外的其它邮件头信息，以便为其指定线索，所以宁可发一 个全 新的邮件。
在网页论坛，因为消息与特定的线索紧密结合并且通常在线索之外不可见，好的提问方式略有不同，通过回复提问并不要紧(一些论坛甚至不允许在回复中出现分离的主题，而且这样做了基本上没有人会去看)。不过通过回复提问本身就是令人怀疑的做法，因为它们只会被正在查看该线索的人读到。所以，除非你只想在该线索当前活跃的人群中提问，还是另起炉灶比较好。
使之更易回复
以“请向……回复”来结束问题多半会使你得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都麻烦，我们也觉得花几秒钟 考虑你的问题更麻烦。如果你的邮件客户端程序不支持这样做，换个好点的。如果是操作系统不支持所有这种邮件客户端程序，也换个好点的。
在网页论坛，要求通过电子邮件回复是完全无礼的，除非你确信回复的信息也许是机密的(而且有人会为了某种未知的原因只让你而不是整个论坛知道答案)。如果 你只是想 在有人回复线索时得到电子邮件提醒，可以要求论坛发送。几乎所有论坛都提供诸如“留意本线索”、“有回复发送邮件”的功能。
使用清晰、语法与拼写正确的语句
经验告诉我们，粗心与草率的作者通常也粗心与草率地思考和编程(我敢打赌)。为这些粗心与草率的思考者回答问题没有什么好处，我们宁可将 时间花在其它地方。
清楚、完整地表达你的问题非常重要。如果你觉得这样做麻烦，我们也觉得注意(你的问题)麻烦。花点额外的精力斟酌一下字句，用不着太僵硬与正式──事实 上，黑客文化很看重能准确地使用非正式、俚语和幽默的语句。但它必须很准确，而且有迹象表明你是在思考和关 注问题。
正确地拼写、使用标点和大小写，不要将“its”混淆为“it’s”，“loose”搞成“lose”或者将“discrete”弄成 “discreet”。不要全部用大写，这会被看成无礼的大声嚷嚷 (全部小写也好不到哪去，因为不易阅读。Alan Cox[注：著名黑客，Linux内核的重要参与者]也许可以这样做，但你不行 )。
一般而言，如果你写得象个半文盲似的傻子，多半得不到理睬。如果象个小孩似地乱写乱画那绝对是在找死，可以肯定没人会理你(或者最多 是给你一大堆指责与挖苦)。
如果在非母语论坛中提问，你的拼写与语法错误会得到有限的宽容，但懒惰完全不会被容忍(是的，我们通常看得出其中的差别)。同时，除非你知道回复者使用 的语言，请使用 英语书写。繁忙的黑客一般会直接删除用他们看不懂语言写的消息。在互联网上英语是工作语言，用英语书写可以将你的问题不被阅读就被直接删除的可能降到最低。
使用易懂的格式发送问题
如果你人为地将问题搞得难以阅读，它多半会被忽略，人们更愿读易懂的问题，所以：
使用文本而不是HTML(超文本标注语言) ( 关闭HTML 并不难)
使用MIME(多用途互联网邮件扩展)附件通常没有问题，前提是真正有内容(譬如附带的源文件或补丁)，而不仅仅是邮件客户端程序 生 成的模板(譬如只是消息内容的拷贝)。
不要发送整段只是单行句子但多次折回的邮件(这使得回复部分内容非常困难)。设想你的读者是在80个字符宽的文本终端阅读邮件， 设置你的行折回点小于80列。
但是，也不要用 任何固定列折回数据(譬如直接传送的日 志文件或会话记录)。数据应该原样包含，使回复者确信他们看到的与你看到的东西一样。
在英语论坛中，不要使用’Quoted-Printable’ MIME编码发送消息。这种编码对于张贴非ASCII语言可能是必须的，但很多邮件代理程序并不支持。当它们分断时，那些文本中四处散布 的 “=20”符号既难看也分散注意力。
永远不要指 望黑客们阅读使用封闭的专用格式编写的文档，诸如微软公司的Word或Excel文件等，大多数黑客对此的反应就象有人将还在冒热气的猪 粪倒在你门口时你的反应一样。即使他们能够处理，他们也很厌恶这么做。
如果你从使用视窗的电脑发送电子邮件，关闭微软愚蠢的“聪明引用”功能，以免在你的邮件中到处散布垃圾字符。
在网页论坛，勿滥用“表情符号”和“html”功能(当它们提供时)。一两个表情符号通常没有问题，但花哨的彩色文本倾向于使人认为你是个无能之辈。过滥地使用表情符号、色彩和字体会使你看来象个傻笑的小姑娘。这通常不是个好主意，除非你只是对性而不是有用的回复更有兴趣。
如果你使用图形用户界面的邮件客户端程序(如网景公司的Messenger、微软公司的Outlook或者其它类似的)，注意它们的缺省配置不一定满足这些要求。大多数这类程序有基于菜单的“查看源码”命令，用它来检查发送文件夹中的消息，以确保发送的是没有多余杂质的纯文本文件。
描述问题应准确且有内容
仔细、清楚地描述问题的症状
描述问题发生的环境(主机，操作系统，应用程序，任何相关的)，提供销售商的发行版和版本号(如：“Fedora Core 2”、“Slackware 9.1”等)
描述提问前做过的研究及其理解。
描述提问前为确定问题而采取的诊断步骤。
描述最近对计算机或软件配置的任何相关改变。
尽最大努力预测黑客会提到的问题，并提前备好答案。
Simon Tatham写过一篇叫 如何有效报告臭虫 的文章，我强烈推荐各位阅读。
多不等于准确
你应该(写得)准确且有内容，简单地将一大堆代码或数据“倾倒”在求助消息中达不到目的。如果你有一个很大且复杂的测试样例让程序崩溃，尝 试将其裁剪得越小越好。
至少有三个理由支持这点。第一，让别人看到你在努力简化问题使你更有可能得到回复。第二，简化问题使你更有可能得到有用的回复。第三，在提纯臭虫 报告的过程中，你可能自己就找到了解决问题的方法或权宜之计。
别动辄声称找到臭虫
当你在一个软件中遇到问题，除非你非 常、非常的有根据，不要动辄声称找到了臭虫。提示：除非你能提供解决问题的源代码补丁，或者对前一版本的回归测试 表现出不正确的行为，否则你都多半不够完全确信。对于网页和文档也如此，如果你(声称)发现了文档的“臭虫”，你应该能提供相应位置的替代文本。
记住，还有许多其它用户未经历你遇到的问题，否则你在阅读文档或网页搜索时就应该发现了(你在报怨前已经做了这些，是吧？)。这也意味着很有可能是你弄错了而不是软件本身有问 题。
编写软件的人通常非常辛苦地使它尽可能完美。如果你声称找到了臭虫，也就暗示他们做错了什么，而这几乎总会使人不快──即使你是对的， 在主题中嚷嚷“臭虫”也是特别不老练的。
提问时，即使你私下非常确信已经发现一个真正的臭虫，最好写得象是你做 错了什么。如果真的有臭虫，你会在回复中看到这点。这么做的话，如果真有虫子，维护者就会向你道歉，这总比你弄 砸了然后欠别人一个道歉要强。
低声下气不能代替自己应做之事
有些人明白他们不应该粗鲁或傲慢地行事并要求得到答复，但他们退到相反的低声下气的极端，“我知道我只是个什么也不是、什么也不懂的失败者， 但……”。这既使人困扰也没有帮助，当伴随着对实际问题含糊的描述时还特别令人反感。
别用低级灵长类动物的策略浪费大家的时间，相反，尽量清楚地表述背景事实和你的问题，这比低声下气更好地摆正了你的位置。
有时，网页论坛设有单独的初学者提问区域，如果你真的认为遇到了初浅的问题，到那去就是了，但一样别低声下气。
描述问题症状而不是猜测
告诉黑客你认为是什么导致了问题是没有用的(如果你的诊断理论是了不起的东西，你还会向他人咨询求助吗？)。所以，确保只是告诉他们问题的原始症状，而不是你的解释和理论，让他们来解释和诊断。如果你认为陈述你的猜测很重要，清楚地说明这只是你的猜测并描述为什么它们不起作用。
愚蠢：
我在编译内核时接连遇到SIG11错误，怀疑主板上的某根电路丝断了，找到它们的最好办法是什么？
明智：
我组装的电脑(K6/233 CPU、FIC-PA2007主板(威盛Apollo VP2芯片组)、Corsair PC133 SDRAM 256Mb内存)最近在开机20分钟左右、做内核编译时频繁地报SIG11错，但在头20分钟内从不出问题。重启动不会复位时钟，但整夜关机会。更换所有内存未解决问题，相关的典型编译会话日志附后。
按时间先后罗列症状
刚出问题之前发生的事情通常包含有解决问题最有效的线索。所以，记录中应准确地描述你及电脑在崩溃之前都做了些什么。在命令行处理的 情况下，有会话日志(如运行脚本工具生成的)并引用相关的若干(如20)行记录会非常有帮助。
如果崩溃的程序有诊断选项(如-v详述选项)，仔细考虑选择这些能在记录中增加排错信息的选项。
如果你的记录很长(如超过四段)，也许在开头简述问题随后按时间先后罗列详细过程更有用。这样做，黑客在读你的记录时就知道该查哪些内容了。
描述目的而不是步骤
如果你想弄清楚如何做某事(而不是报告一个臭虫)，在开头就描述你的目标，此后才描述为此采取的措施所遇到的问题。
经常有这种情况，寻求技术帮助的人在脑袋里有个更高层面的目标，他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但 没有意识到这条路本身有问题，结果要费很大的劲才能通过。
愚蠢：
我怎样才能让某图形程序的颜色拾取器取得十六进制的RGB值？
明智：
我正试图用自己选定数值的颜色替换一幅图片的颜色表，我现在唯一知道的方法是编辑每个表槽，但却无法让某图形程序的颜色拾取器取得十六进 制的RGB值。
第二种提法是明智的，它使得建议采用更合适的工具完成任务的回复成为可能。
别要求私下回复
黑客们认为问题的解决过程应该公开、透明，此过程中如果更有才能的人注意到不完整或者不当之处，最初的回复才能够、也应该被更正。同时，作为 回复者也因为能力和学识被其它同行看到而得到某种回报。
当你要求私下回复时，此过程和回报都被中止。别这样做，让回复者来决定是否私下回答──如果他 真这么做了，通常是因为他认为问题编写太差或者太肤浅 以 至于对其它人无意义。
对这条规则存在一条有限的例外，如果你确信提问可能会导致大量雷同的回复时，那么“给我发电子邮件，我将为小组归纳这些回复”将是神奇的句子。试图 将邮 件列表或新闻组从洪水般雷同的回复中解救出来是非常有礼貌的──但你应信守诺言。
问题应明晰
漫无边际的问题通常也被视为没有明确限制的时间无底洞。最有可能给你有用答案的人通常也是最忙的人(假如只是因为他们承担了大多数工作的话)，这些 人 对于没 有限制的时间无底洞极其反感，所以他们也倾向于讨厌那些漫无边际的问题。
如果你明确了想让回复者做的事(如指点方向、发送代码、检查补丁或其它)，你更有可能得到有用的回复。这可以使他们集中精力并间接地设定了他们为帮 助你需要花费的时间和精力上限，这很好。
要想理解专家生活的世界，可以这样设想：那里有丰富的专长资源但稀缺的响应时间。你暗中要求他们奉献的时间越少，你越有可能从这些真正懂行也真正很 忙的专家 那里得到回答。
所以限定你的问题以使专家回答时需要付出的时间最少──这通常还与简化问题不一样。举个例，“请问可否指点一下哪有好一点的X解释？”通常要 比“请解释一下X”明智。如果你有什么代码不运行了，通常请别人看看哪有问题比叫他们帮你改正更明智。
别张贴家庭作业
黑客们善于发现“家庭作业”式的问题。我们大多数人已经做了自己的家庭作业，那是该你做的，以便从其经历中学习。问一 下提示没有关系，但不是要求完整的解决方案。
如果你怀疑自己碰到了一个家庭作业式的问题，但仍然无法解决，尝试在用户组论坛或(作为最后一招)在项目的“用户”邮件列表或论坛中提问。尽管 黑客们会看出来，一些高级用户也许仍会给你提示。
删除无意义的问题
抵制在求助消息末尾加上诸如“有人能帮我吗？”或“有没有答案？”之类在语义上无任何意义东西的诱惑。第一，如果问题描述还不完整，这些附加的东西最多也只能是多余的。第二，因为它们是多余的，黑客们会认为这些东西烦人──就很有可能用逻辑上无误但打发人的回复，诸如“是的，你可以得到帮助”和“不，没有给你的帮助”
一般来说，避免提“是或否”类型的问题，除非你想得到 “是或否”类型的回答。
不要刻意标明问题紧急
这是你自己的问题，不要我们的。宣称“紧急”极有可能事与愿违：大多数黑客会直接删除这种消息，他们认为这是无礼和自私地企图得到即时与特殊的关 照。
有一点点局部的例外，如果你是在一些知名度很高、会使黑客们激动的地方使用程序，也许值得这样去做。在这种情况下，如果你有期限压力，也很有礼貌 地提到这点，人们也许会有足够的兴趣快一点回答。
当然，这是非常冒险的，因为黑客们对什么是令人激动的标准多半与你的不同。譬如从国际空间站这样张贴没有问题，但代表感觉良好的慈善或政治原因这样做几乎肯定不行。事实上，张贴诸如“紧急：帮我救救这个毛绒绒的小海豹！”肯定会被黑客回避或光火，即使他们认为毛绒绒的小海豹很重要。
如果你觉得这不可思议，再把剩下的内容多读几遍，直到弄清楚了再发贴。
礼貌总是无害的
礼貌一点，使用“请”和“谢谢你的关注”或者“谢谢你的意见”，让别人明白你感谢他们无偿花时间帮助你。
坦率地说，这一点没有语法正确、文字清晰、准确、有内容和避免使用专用格式重要(同时也不能替代它们)。黑客们一般宁可读有点唐突但技术鲜明的臭 虫报告，而不是那种礼貌但含糊的报告。(如果这点让你不解，记住我们是按问题能教我们些什么来评价一个问题的)
然尔，如果你已经谈清楚了技术问题，客气一点肯定会增加你得到有用回复的机会。
(我们必须指出，本文唯一受到一些老黑客认真反对的地方是以前曾经推荐过的“提前谢了”，一些黑客认为这隐含着事后不用再感谢任何人的暗示。我们的 建议是 先说 “提前谢了”，事后再对回复者表示感谢。或者换种方式表达，譬如用“谢谢你的关注”或“谢谢你的意见”)。
问题解决后追加一条简要说明
问题解决后向所有帮助过的人追加一条消息，让他们知道问题是如何解决的并再次感谢。如果问题在邮件列表或新闻组中受到广泛关注，在那里追加此消息比 较恰当。
最理想的方式是向最初提问的线索回复此消息并在主题包含“已解决”、“已搞定”或其它同样意思的明显标记。在人来人往的邮件列表里，一个看见线索 “问题X”和“问题X-已解决”的潜在回复者就明白不用再浪费时间了(除非他个人觉得“问题X”有趣)，因此可以用此时间去解决其它 问题。
你追加的消息用不着太长太复杂，一条简单的“你好──是网线坏了！谢谢大家──比尔”就比什么都没有要强。事实上，除 非解决问题的技术真正高深，一条简短而亲切的总结比长篇大论要好。说明是什么行动解决了问题，用不着重演整个排错的故事。
对于有深度的问题，张贴排错历史的摘要是适当的。描述问题的最终状态，说明是什么解决了问题，在此之后才指明可以避免的弯路。应避免的 弯路部分应放在正确的解决方案和其它总结材料之后，而不要将此消息搞成侦探推理小说。列出那些帮助过你的名字，那样你会交到朋友的。
除了有礼貌、有内容以外，这种类型的追帖将帮助其他人在邮件列表、新闻组或论坛文档中搜索到真正解决你问题的方案，从而也让他们受益。
除上述而外，此类追帖还让每位参与协助的人因问题的解决而产生一种满足感。如 果你自己不是技术专家或黑客，相信我们，这种感觉对于你寻求帮助的老手和专家非常重要。问题叙述到最后不知所终总是令人沮丧的，黑客们痒痒地渴望看到它们被解决。“挠痒痒”为你挣到的好报将对你下次再次张贴提问非常非常的有帮助。
考虑一下怎样才能避免其他人将来也遇到类似的问题，问问自己编一份文档或FAQ补丁有没有帮助，如果有的话就将补丁发给维护者。
在黑客中，这种行为实际上比传统的礼貌更重要，也是你善待他人而赢得声誉的方式，这是非常有价值的财富。
如何解读回答
RTFM和STFW：如何知道你已完全搞砸
有一个古老而神圣的传统：如果你收到了“RTFM”的回复，发信人认为你应该去“读读该死的手册”。他多半是对的，去读一下吧。
RTFM有个年轻的亲戚，如果你收到“STFW”的回复，发信人认为你应该“搜搜该死的网络”。他多半也是对的，去搜一下吧。(更温和一点的说法是 “Google 是你的朋友！”)
在网页论坛，你也可能被要求去搜索论坛的文档。事实上，有人甚至可能热心地为你提供以前解决此问题的线索。但不要依赖这种好心，提问前应先搜索 一下文 档。
通常，叫你搜索的人已经打开了能解决你问题的手册或网页，正在一边看一边敲键盘。这些回复意味着他认为：第一，你要的信息很容易找到。第二，自已找 要比别人喂到嘴里能学得更多。
你不应该觉得这样就被冒犯了，按黑客的标准，他没有不理你就是在向你表示某种尊敬，你反而应该感谢他热切地想帮助你。
如果还不明白
如果你看不懂回复，不要马上回发一个要求说明的消息，先试试那些最初提问时用过的同样工具(手册、FAQ，网页、懂行的朋友等)试着搞懂回 复。如果还是需要说明，展现你已经明白的。
譬如，假如我告诉你：“听起来象是某输入项有问题，你需要清除它”，接着是个不好的回帖：“什么是某输入项？”。 而这是一个好的跟帖：“是 的， 我读了手册，某输入项只在-z和-p开关中被提到，但都没有提及清除某选项，你指的是哪一个还是我弄错了什么？”
对待无礼
很多黑客圈子中看似无礼的行为并不是存心冒犯。相反，它是直接了当、一刀见血式的交流风格，这种风格对于更关注解决问题而不是使别人感觉舒服而混乱 的人 是很自然的。
你如果觉得被冒犯，努力平静地反应。如果有人真的做了过格的事，邮件列表或新闻组或论坛中的前辈多半会招呼他。如果这没有发生而你却发火了，那么你发火对 象的言语 可能在黑客社区中看起来是正常的，而你将 被视为有错的一方，这将伤害到你获取信息或帮助的机会。
另一方面，你会偶而真的碰到无礼和无聊的言行。与上述相反，对真正的冒犯者狠狠地打击、用犀利的语言将其驳得体无完肤都是可以接受的。然尔，在行事之前一定要非常非常的有根据。纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔，黑客们自己莽撞地越线情况并不鲜见。如果你是新手或外来者，避开这种莽撞的机会不高。如果你 想得到的是信息而不是消磨时光，这时最好不要把手放在键盘上以免冒险。http://hi.baidu.com/uniona
(有些人断言很多黑客都有轻度的自闭症或阿斯伯格综合症，一定缺少平滑人类社会“正常”交往所需的脑电路。这既可能是真也可能是假。如果你自己不是黑客，兴许 你认为我 们脑袋有问题还能帮助你应付我们的古怪行为。只管这么干好了，我们不在乎。我们喜欢我们现在这个样子，并且一般都对临床诊断有相当的怀疑。)
在下一节，我们会谈到另一个问题，当你行为不当时会受到的“冒犯”
别象个失败者那样反应
在黑客社区的论坛中有那么几次你会搞砸──以本文详述或类似的方式。你会被示众是如何搞砸的，也许言语中还会带点颜色。
这种事发生以后，你能做的最糟的事莫过于哀嚎你的遭遇、宣称被口头攻击、要求道歉、高声尖叫、憋闷气、威胁诉诸法律、向其雇主报怨、忘了关马桶盖等 等。相 反，你该这样去做：
熬过去，这很正常。事实上，它是有益健康与恰当的。
社区的标准不会自己维持，它们是通过参与者积极而公开地执行来维持的。不要哭嚎所有的 批评都应该通过私下的邮件传送，这不是事情运作的方式。当有人批评你的 一些主张或者其看法不同时，坚持声称个人被侮辱也毫无用处，这些都是失败者的态度。
也有其它的黑客论坛，受太高礼节要求的误导，要求参与者禁止张贴任何对别人帖子挑毛病的消息，并被告知“如果你不想帮助用户就闭嘴”。有思路的参与 者纷纷 离 开 的结果只会使它们变成了毫无意义的唠叨与无用的技术论坛。
是夸张的“友谊”(以上述方式)还是有用？挑一个。
记住：当黑客说你搞砸了，并且(无论多么刺耳地)告诉你别再这样做时，他正在为关心你和他的社区而行动。对他而言，不理你并将你从他的生活中滤除要容易得多。如果你无法做到感谢，至少要有点尊严，别大声哀嚎，也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者，就指望别人象对待脆弱的洋娃娃那样对你。
有时候，即使你没有搞砸(或者只是别人想象你搞砸了)， 有些人会无缘无故地攻击你本人。在这种情况下，报怨倒是真的会把问题搞砸。
这些找茬者要么是什么也不懂但自以为是专家的不中用家伙，要么就是测试你是否真会搞砸的心理学家。其它读者要么不理睬，要么用自己的方式对付他们。 这些找茬者在给自己找麻烦，这点你不用操心。
也别让自己卷入口水战，大多数口水战最好不要理睬──当然是在你核实它们只是口水战、没有指出你搞砸的地方，而且没有巧妙地将问题真正的答案藏于其 中 (这也 是 可能的)之后。
提问禁忌
下面是些典型的愚蠢问题和黑客不回答它们时的想法。
问： 我到哪可以找到程序或X资源？
问： 我怎样用X做Y？
问： 如何配置我的shell提示？
问： 我可以用Bass-o-matic文件转换工具将AcmeCorp文档转为TeX格式 吗？
问： 我的{程序、配置、SQL语句}不运行了
问： 我的视窗电脑出问题了，你能帮忙吗？
问： 我的程序不运行了，我认为系统工具X有问题
问： 我安装Linux或X遇到困难，你能帮忙吗？
问： 我如何才能破解超级用户口令/盗取频道操作员的特权/查看某人的电子邮件？
问：我到哪可以找到程序或X资源？
答：在我找到它的同样地方，笨旦──在网页搜索引擎上。上帝啊，难道还有人不知道如何使用 Google 吗？
问：我怎样用X做Y？
答：如果你想做的是Y，提问时别给出可能并不恰当的方法。这种问题说明提问者不但对X完全无知，也对要解决的Y问题糊涂，还被特定形势禁 锢了思维。等他们把问题弄 好再说。
问：如何配置我的shell提示？
答：如果你有足够的智慧提这个问题，你也该有足够的智慧去 RTFM， 然后自己去找。
问：
我可以用Bass-o-matic文件转换工具将AcmeCorp文档转为TeX格 式吗？
答：
试试就知道了。如果你试过，你既知道答案，又不用浪费我的时间了。
问：
我的{程序、配置、SQL语句}不运行了
答：
这不是一个问题，我也没有兴趣去猜你有什么问题──我有更要紧的事要做。看到这种东西，我的反应一般如下：
你还有什么补充吗？
噢，太糟了，希望你能搞定。
这跟我究竟有什么关系？
问：
我的视窗电脑出问题了，你能帮忙吗？
答：
是的，把视窗垃圾删了，装个象Linux或BSD的开源操作系统吧。
注意：如果程序有官方的视窗版或与视窗有交互(如Samba)，你可以问与视窗电脑相关的问题，只是别 对问题是由视窗操作系统而不是程序本身造成的回复感 到惊讶，因 为视窗一般来说太差，这种说法一般都成立。
问：
我的程序不运行了，我认为系统工具X有问题
答：
你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与库文件有明显缺陷的人，更有可能的是你完全没有根据。不同凡响的说法需 要不同凡响的证据， 当你这样 声称时，你必须有清楚而详尽的缺陷说明文档作后盾。
问：
我安装Linux或X遇到问题，你能帮忙吗？
答：
不行，我需要亲手操作你的电脑才能帮你排错，去向当地的Linux用户组寻求方便的帮助(你可以在 这里 找到用户组列表)
注意：在为某一Linux发行版服务的邮件列表或论坛或本地用户组织中提关于安装该发行版的问题也许是恰当的。此时，应描述问题的准确 细节。在此之前，先用 “linux”和所有被怀 疑的硬件(为关键词)仔细搜索。
问：
我如何才能破解超级用户口令/盗取频道操作员的特权/查看某人的电子邮件？
答：
想做这种事情说明你是个卑劣的家伙，想让黑客教你做这种事情说明你是个白痴。
好问题与坏问题
最后，我将通过举例来演示提问的智慧。同样的问题两种问法，一种愚蠢，另一种明智。
愚蠢：我在哪能找到关于Foonly Flurbamatic设备的东西？
这个问题在乞求得到 STFW 式的回复。
明智：我用Google搜索过“Foonly Flurbamatic 2600”，但没有找到什么有用的，有谁知道在哪能找到这种设备的编程信息？
这个人已经搜索过网络了，而且听起来他可能真的遇到了问题。
愚蠢：我不能编译某项目的源代码，它为什 么这么破？
他假设是别人搞砸了，太自大了。
明智：某项目的源代码不能在某Linux 6.2版下编译。我读了常见问题文档，但其中没有与某Linux相关的问题。这是编译时的记录，我做错了什么吗？
他指明了运行环境，读了FAQ，列出了错误，也没有假设问题是别人的过错，这家伙值得注意。
愚蠢：我的主板有问题，谁能帮我？
某黑客对此的反应可能是：“是的，还需要帮你拍背和换尿布吗？”，然后是敲下删除键。
明智：我在S2464主板上试过X、Y和 Z，当它们都失败后，又试了A、B和C。注意我试C时的奇怪症状，显然某某东西正在做某某事情，这不是期望的。通常 在Athlon MP主板上导致某某事情的原因是什么？有谁知道我还能再试点什么以确定问题？
相反地，这个人看来值得回答。他展现了解决问题的能力而不是坐等天上掉馅饼。
在最后那个问题中，注意“给我一个回复”与“请帮我看看我还能再做点什么测试以得到启发”之间细微但重要的差别。
事实上，最后那个问题基本上源于2001年8月Linux内核邮件列表(lkml)上的真实事件，是我(Eric)当时提了那个问题，我发现 Tyan S2462 主板有神秘的死机现象，邮件列表成员给我提供了解决此问题的关键信息。
通过这种提问方式，我给了别人可以咀嚼玩味的东西。我设法使之对参与者既轻松又有吸引力，也表明了对同行能力的尊敬并邀请他们与我一起协商。通 过告诉 他们我已经走过的弯路，我还表明了对他们宝贵时间的尊重。
事后，当我感谢大家并评论这次良好的经历时，一个Linux内核邮件列表的成员谈到，他认为并不是因为我的名字在列表上，而是因为我正确的提问方式 才 得到了答 案。
黑客们在某种方面是非常不留情面的精英分子。我想他是对的，如果我表现得象个不劳而获的寄生虫，不管我是谁都会被忽略或斥责。他建议将整个事件作为 对其它 人 提问的指导直接导致了本文的编写。
如果没有回复
如果得不到回答，请不要认为我们不想帮你，有时候只是因为小组成员的确不知道答案。没有回复不等于被忽略，当然必须承认从外面很难看出两者的差别。
一般来说，直接将问题再张贴一次不好，这会被视为毫无意义的骚扰。
还有其它资源可以寻求帮助，通常是在一些面向新手的资源中。
有许多在线与本地用户组织，虽然它们自己不编写任何软件，但是对软件很热心。这些用户组通常因互助和帮助新手而形成。
还有众多大小商业公司提供签约支持服务(红帽与Linuxcare是两家最出名的，还有许多其它的)。别因为要付点钱才有支持就感到沮丧！毕竟，如 果你车子的 汽缸垫烧了，你多半还得花钱找个修理店把它弄好。即使软件没花你一分钱，你总不能指望服务支持都是免费的。
象Linux这样流行的软件，每个开发者至少有一万个以上的用户，一个人不可能应付这么多用户的服务要求。记住，即使你必须付费才能得到支持，也比 你还得额外花钱买软件要少得多(而且对封闭源代码软件的服务支持与开源软件相比通常还要贵一点，也要差一点)
如何更好地回答 问题
态度和善一点。问题带来的压力常使人 显得无礼或愚蠢，其实并不是这样。
对初犯者私下回复。对那些坦诚犯错 之人没有必要当众羞辱，一个真正的新手也许连怎么搜索或在哪找FAQ都不知道。
如果你不确定，一定要说出来！一个听 起来权威的错误回复比没有还要糟，别因为听起来象个专家好玩就给别人乱指路。要谦虚和诚实，给提问者与同行都树个好榜样。
如果帮不了忙，别妨 碍。不要在具体步骤上开玩笑，那样也许会毁了用户的安装──有些可怜的呆瓜会把它当成真的指令。
探索性的反问以引出更多的细节。如 果你做得好，提问者可以学到点东西──你也可以。试试将很差的问题转变成好问题，别忘了我们都曾是新手。
尽管对那些懒虫报怨一声RTFM是正当的，指出文档的位置(即使只是建议做个Google关键词搜索)会更好。
如果你决意回答，给 出好的答案。当别人正使用错误的工具或不当 的方法时别建议笨拙的权宜之计，应推荐更好的工具，重新组织问题。
帮助你的社区从问题中 学习。当回复一个好问题时，问问自己 “如何修改相关文件或FAQ文档以免再次解答同样的问题？”，接着再向文档维护者发一份补丁。
如果你的确是在研究一番后才做出的回答，展现你的技巧而不是直接端出结果。毕竟“授人以鱼，不如授人以渔”。
相关资源
如果还需要个人电脑、Unix和互联网如何工作的基础知识，参阅 Unix 和互联网如何工作的基本原理
当你发布软件或补丁时，尝试按 软 件发布实践 指南进行。
鸣谢
Evelyn Mitchell 贡献了一些愚蠢问题样例并启发了编写“如何更好地回答问题”这一节，Mikhail Ramendik 贡献了一些特别有价值的建议和改进。
Powered by MessageSoft SMG
SPAM, virus-free and secure email
http://www.messagesoft.com
整理：联盟志
看到朋友越来越多，心里很是高兴，共享资源，分享快乐，特此奉献上文供朋友们参考。有什么心里话，赶快与朋友们分享吧：）
阅读内文如果某项请求发送到您的服务器要求显示您网站上的某个网页（例如，用户通过浏览器访问您的网页或 Googlebot 抓取网页时），服务器将会返回 HTTP 状态代码以响应请求。
此状态代码提供关于请求状态的信息， 告诉 Googlebot 关于您的网站和请求的网页的信息。
一些常见的状态代码包括：
下面提供 HTTP 状态代码的完整列表。 点击链接可了解详情。 您也可以访问有关 HTTP 状态代码的 W3C 网页以获得更多信息。
1xx（临时响应）
表示临时响应并需要请求者继续执行操作的状态代码。
| 代码 | 说明 |
|---|---|
| 100（继续） | 请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。 |
| 101（切换协议） | 请求者已要求服务器切换协议，服务器已确认并准备切换。 |
2xx（成功）
表示服务器成功处理了请求的状态代码。
| 代码 | 说明 |
|---|---|
| 200（成功） | 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。 如果针对您的 robots.txt 文件显示此状态，则表示 Googlebot 已成功检索到该文件。 |
| 201（已创建） | 请求成功并且服务器创建了新的资源。 |
| 202（已接受） | 服务器已接受请求，但尚未处理。 |
| 203（非授权信息） | 服务器已成功处理了请求，但返回的信息可能来自另一来源。 |
| 204（无内容） | 服务器成功处理了请求，但没有返回任何内容。 |
| 205（重置内容） | 服务器成功处理了请求，但没有返回任何内容。 与 204 响应不同，此响应要求请求者重置文档视图（例如，清除表单内容以输入新内容）。 |
| 206（部分内容） | 服务器成功处理了部分 GET 请求。 |
3xx（重定向）
要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。 Google 建议您在每次请求中使用重定向不要超过 5 次。 您可以使用网站管理员工具查看一下 Googlebot 在抓取重定向网页时是否遇到问题。 诊断下的网络抓取页面列出了由于重定向错误而导致 Googlebot 无法抓取的网址。
| 代码 | 说明 |
|---|---|
| 300（多种选择） | 针对请求，服务器可执行多种操作。 服务器可根据请求者（用户代理）选择一项操作，或提供操作列表供请求者选择。 |
| 301（永久移动） | 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。 您应使用此代码告诉 Googlebot 某个网页或网站已永久移动到新位置。 |
| 302（暂时移动） | 服 务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。 此代码与响应 GET 或 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置，但您不应使用此代码来告诉 Googlebot 某个网页或网站已经移动，因为 Googlebot 会继续抓取原有位置并编入索引。 |
| 303（查看其他位置） | 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。 对于除 HEAD 之外的所有请求，服务器会自动转到其他位置。 |
| 304（未修改） | 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
如果网页自请求者上次请求后再也没有更改过，您应当将服务器配置为返回此响应（称为 If-Modified-Since HTTP 标头）。 由于服务器可以告诉 Googlebot 自从上次抓取后网页没有更改过，因此可节省带宽和开销 。 |
| 305（使用代理） | 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。 |
| 307（暂时重定向） | 服 务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。 此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置，但您不应使用此代码来告诉 Googlebot 某个页面或网站已经移动，因为 Googlebot 会继续抓取原有位置并编入索引。 |
4xx（请求错误）
这些状态代码表示请求可能出错，妨碍了服务器的处理。
| 代码 | 说明 |
|---|---|
| 400（错误请求） | 服务器不理解请求的语法。 |
| 401（未授权） | 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。 |
| 403（禁止） | 服务器拒绝请求。 如果您看到 Googlebot 在尝试抓取您网站上的有效网页时收到此状态代码（可以在 Google 网站管理员工具诊断下的网络抓取页面上看到此信息），可能是您的服务器或主机拒绝 Googlebot 访问。 |
| 404（未找到） | 服务器找不到请求的网页。 例如，如果请求服务器上不存在的网页，服务器通常会返回此代码。
如果您的网站上没有 robots.txt 文件，而您在 Google 网站管理员工具”诊断”标签的 robots.txt 页上看到此状态，那么这是正确的状态。 但是，如果您有 robots.txt 文件而又看到此状态，则说明您的 robots.txt 文件可能命名错误或位于错误的位置 （该文件应当位于顶级域名，名为 robots.txt）。 如果您看到有关 Googlebot 尝试抓取的网址的此状态（在”诊断”标签的 HTTP 错误页上），则表示 Googlebot 追踪的可能是另一个页面的无效链接（是旧链接或输入有误的链接）。 |
| 405（禁用的方法） | 禁用请求中指定的方法。 |
| 406（不可接受） | 无法使用请求的内容特性响应请求的网页。 |
| 407（需要代理授权） | 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。 如果服务器返回此响应，还会指明请求者应当使用的代理。 |
| 408（请求超时） | 服务器等候请求时发生超时。 |
| 409（冲突） | 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。 服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码，同时会附上两个请求的差异列表。 |
| 410（已删除） | 如果请求的资源已永久删除，服务器就会返回此响应。 该代码与 404（未找到）代码相似，但在资源以前存在而现在不存在的情况下，有时会用来替代 404 代码。 如果资源已永久删除，您应当使用 301 指定资源的新位置。 |
| 411（需要有效长度） | 服务器不接受不含有效内容长度标头字段的请求。 |
| 412（未满足前提条件） | 服务器未满足请求者在请求中设置的其中一个前提条件。 |
| 413（请求实体过大） | 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。 |
| 414（请求的 URI 过长） | 请求的 URI（通常为网址）过长，服务器无法处理。 |
| 415（不支持的媒体类型） | 请求的格式不受请求页面的支持。 |
| 416（请求范围不符合要求） | 如果页面无法提供请求的范围，则服务器会返回此状态代码。 |
| 417（未满足期望要求） | 服务器未满足”期望”请求标头字段的要求。 |
5xx（服务器错误）
这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。
| 代码 | 说明 |
|---|---|
| 500（服务器内部错误） | 服务器遇到错误，无法完成请求。 |
| 501（尚未实施） | 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。 |
| 502（错误网关） | 服务器充当网关或代理，从上游服务器收到无效响应。 |
| 503（服务不可用） | 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。 |
| 504（网关超时） | 服务器充当网关或代理，但没有及时从上游服务器收到请求。 |
| 505（HTTP 版本不受支持） | 服务器不支持请求中所用的 HTTP 协议版本。 |