初闻不知曲中意，再闻已是曲中人。 既然已是曲中人，何必再听曲中曲。 曲中轻忆梦中人，梦醒时分叹红尘。 曲终人散梦已醒，何处再寻梦中人。 梦中合唱凤求凰，梦醒独奏离别赋。 即知曲人存于梦，何故执于曲外人。 多少痴梦多少等，难诉痴情曲中人。 一萧一页红尘事，一弦一曲了人生。 既然已是曲中人，何必再悟曲中意。 不愿再做曲中人，奈何越听越沉沦。初闻不知曲中意，再听已是曲中人。曲中思念今犹在，不见当年梦中人。但愿还能再入梦，梦里相思缠绵情。缠绵缱绻心头炽，曲终人散早成空。

名称：VMware 大小：0 MB 语言：英语 授权：共享软件 版本：V0 官网：http://www.vmware.com 平台：WindowsVersion 1.x：1.1.0.1-372 本地下载2.1.0.2-452 本地下载Version 2.x

名称：VMware 1.0-294 大小：2.93 MB 语言：英语 授权：共享软件 版本：V1.0.294 官网：http://www.vmware.com 平台：Windows for Windows NT and Windows 2000介绍： VMware 现在大家没有谁不知道了吧，但它的第一个版本我想很多人应该都没见过吧预览图片：下载：镜像下载点   本地下载

[Image]

近日，在备份一些资料到文件服务器上时，突然收到提示“0X8007003B：发生了意外的网络错误” 查询谷歌，搜索到大量结果，主要为：1.停用Windows Firewall 服务（如果需要连接到共享打印机，千万不要禁用，该服务会导致共享打印机提示错误） 2.禁用防病毒程序  3.删除注册表项（HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels.） 4.停用Windows Search服务 5.安装SMBv1协议  6.怀疑网线问题，但测试ping并没有任何问题                 然而以上的方法试完了，问题仍然存在，且也发现主要问题出在于大文件上，随后在知乎上找到一篇文章，按其所述关闭后问题消失，链接地址：https://zhuanlan.zhihu.com/p/41030548 ，所以如果有人也碰上了，可以尝试下以上的方案看是否可以解决最近发现我的笔记本电脑复制大文件时就出现网卡掉线中断连接失败，网卡图标上会出现惊叹号。必须要重启电脑（偶尔禁用再激活网卡可以）才可以，但再复制大文件还是会断线。 后来尝试了各种解决办法，后来发现是 大量传送减负这个设置导致的 在网卡属性面板配置中 高级中 更改网卡的设置。 将以下各属性关闭（默认是开启的） Large Send Offload ipV4 关闭 Large Send Offload ipV6 关闭 Large Send Offload ipV4 v2 关闭 Large Send Offload ipV6 v2 关闭 这几个属性 中文名称为“大量传送减负”，把这些相关的全部关闭。 这个应该是Window和网卡驱动之间的一个Bug。原本用意是减少网卡传输大量数据时对cpu的占用。你关闭这些“大量传送减负”属性后，网卡会自动重新连接，发现问题解决了。

近日，在更新系统至1803，突然发现一直使用的便签，突然提示感叹号，无法同步数据，一番查找后现将方法分享 众所周知，某度无法查询到需要的信息，故在谷歌搜索后，明白了原因 “是metro app本身默认设置导致的问题，大部分代理软件都采用的是IE的代理设置，而win8 metro app默认不允许访问本地环回地址（诸如127.0.0.1之类的），所以就导致各种毛病。参考：https://www.v2ex.com/t/178882，4Lhttps://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx?f=255&MSPPError=-2147217396，关于loopbackexempt的描述根本解决问题的方法是允许APP访问环回地址，管理员权限运行Power Shell或者CMD“ 有人可能会问了，这里说的是metro app啊，但其实现在Win10的UWP就是从Win8的metro app演化过来的，那么既然知道原因了，该怎么解决呢 首先，微软自己肯定是提供了相关的解决方案的（点击访问），但可能会有人说，这些我都看不懂，你就告诉我怎么操作就好了，那么，下面我们就来说说该怎么处理 第一，首先，我们需要明白自己有问题的UWP在Windows中的名称是什么（可通过任务管理器展开该进程后右键该进程，点击属性，即可看到看到） 如上图中，画红框的就是UWP的名字 第二步，我们知道了名字，下一步就是去注册表中找到对应的SID值 右键开始按钮，运行，然后在窗口中输入“regedit”,点击确定，然后会看到一个窗口，这个窗口左边有很多的项，我们不用去管它，把这个复制到地址栏中：HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Mappings 回车以后，就会自动跳转到我们要的地方 第三步，到这里了以后，我们点击编辑，然后查找，在窗口中把第一步获得的名字复制过来，点击查找下一个，然后注册表就会自动定位到你所想找的那个应用的SID上， 这里我们只需要把画红框的地方里的SID记录下来即可 第四步，重新打开运行，然后输入cmd，回车，可以看到一个黑底的窗口，在那个窗口中，我们输入CheckNetIsolation.exe loopbackexempt -a -p=*** （***替换成我们前面获取到的SID值），然后回车以后看到“完成”字样，重新运行相关软件即可。                

大家都知道Windows10主要分为专业版、家庭版和企业版三个版本，一般用户都是给电脑安装专业版或家庭版。一些用户反馈说Win10家庭版中不包含组策略，导致一些操作无法使用，比如用家庭组来优化维护系统。遇到Windows10家庭版没有组策略的问题怎么解决，有什么办法可以让win10家庭版也可以使用组策略呢？我们可以参照下文教程来设置。 首先在Win10桌面建立一个记事本文件，然后将以下代码粘贴到记事本中：@echo off pushd "%~dp0" dir /b C:\Windows\servicing\Packages\Microsoft-Windows-GroupPolicy-ClientExtensions-Package~3*.mum >List.txt dir /b C:\Windows\servicing\Packages\Microsoft-Windows-GroupPolicy-ClientTools-Package~3*.mum >>List.txt for /f %%i in ('findstr /i . List.txt 2^>nul') do dism /online /norestart /add-package:"C:\Windows\servicing\Packages\%%i" pause 然后操作选择 文件-另存为，如下图所示。 另存为操作时，在名称后面加一个 .bat ,然后下方的文件类型选择为“所有文件”，之后点击“保存”即可，如下图所示。 接下来在桌面上就可以看到一个 .bat 命令运行文件，点击打开运行，就可以为Win10家庭版新加入组策略功能了。 最后验证一下，首先使用 Win+R 打开运行对话框，然后输入打开组策略命令 gpedit.msc 然后点击“确定”就可以成功打开组策略了。 如果不会操作也可以直接下载以下文件，然后右键以管理员身份运行即可 文件：Win10家庭版安装组策略

文章摘自：看雪学院1998年2月，陈盈豪编写出了破坏性极大的Windows恶性病毒CIH-1.2版，并定于每年的4月26日发作破坏，然后，悄悄地潜伏在网上的一些供人下载的软件中。1998年8月26日，CIH-1.4病毒首先发作，中国内地部分地区遭到袭击，但损害面积不大。事后，为了必免更大灾害，中国公安部发出了通缉三种CIH病毒的通告。可是，使用正版杀毒软件的意识不被一些用户重视，又不经常保持升级杀毒软件，CIH-1.2病毒又经过一年的传播，已传遍全世界，世界性的巨大杀机潜伏下来，1999年4月26日，信息大劫难终于暴发。反病毒厂商一时打破以久沉寂，大大红火了一把。　　刹那间，全世界防、查、杀CIH病毒的呼声昏天黑地......CIH（英语又称为Chernobyl或Spacefiller）其名称源自它的作者，当时仍然是台湾大同工学院学生陈盈豪的名字拼音（Chen Ing-hau）缩写。它被认为是最有害的广泛传播的病毒之一，会破坏用户系统上的全部信息，在某些情况下，会重写系统的BIOS。因为CIH病毒的1.2和1.3版发作日期为4月26日（第一版病毒创造出来的时间），正好是前苏联（位于今日乌克兰）核电厂灾害“切尔诺贝利核事故”的纪念日，故曾被认为病毒作者撰写动机和切尔诺贝利事件有关，因此CIH病毒也被称作切尔诺贝利（Chernobyl）病毒。看雪论坛的版主zmworm 在2013年的时候有幸采访到CIH，这里在这个特殊的日子，让我们一起再与新的小伙伴分享一下CIH当年的风采！PS：大家不要担心，只要正确地使用杀毒软件、及时升级病毒库、全面彻底地对电脑杀毒，就可轻松度过4.26这一天。这次去HITCON有幸遇到CIH的作者陈盈豪，中国第一代黑客 coolfire。还是收获不少的。这是CIH在HITCON2013的演讲，花了两个晚上整理的，并由CIH亲自校对。现经CIH同意，放在看雪论坛上。CIH说这些东西对大家有帮助就好，另外专门准备了他和看雪的合照:)======================================================================= HITCON  演讲稿兴趣执着和专注力让我与众不同By CIH我在高中一年级，开始学习BASIC和C语言。那时候我一点都不懂，我的电脑启蒙是从电脑游戏开始的。那时候玩游戏时，过到下一关卡，就会提示插第二片，第二片插进去玩到结束，再把第二片拔出来，插入第三片。所以我的电脑兴趣是从游戏开始。那时候我告诉自己，这一辈子我要变成游戏的设计者。 那时候，我只想成为这样的人。所以从高一开始写程式，到考大学的时候，我觉的我写的程式不完美。我就想学高职的资讯系。当时我妈很头大，然后他们和我说你到大学一样可以去考咨讯系。所以我才去考大学，因为当时电脑对于我来说就是一切。 现在讲一下CIH病毒。高一的时候第一次碰到电脑病毒，那时候资讯不像现在这么发达。那时候看到病毒感觉好恐怖。当时我第一个反映就是“啊，会不会被传染。”。真是这样的。 第一次碰电脑，是去同学他们家去换游戏，那是25年前第一次碰电脑。然后后来，大概是高二时开始写游戏。大一的时候开始碰Windows 3.1。然后Windows 95才开始出现。当Win 95出现时，兴趣开始有转移，当时最大的兴趣就是组合语言，每天都要写。因为他可以控制所有要控制的东西。在DOS时代，只能寻址1MB，而在Window世界他可以寻址4GB。所以那时候我写的组合语言不并是很简单，我用组合语言写了一个简单的作业系统，他不是真正的作业系统，他只是在处理作业系统中的虚拟机部分。 大二的时候开始研究Windows的Kernel，怎么去处理虚拟机，怎么处理Exception，这些都是Win95机制。后来开始虚拟化的文章，特别是候捷，他的著作对系统理解非常深。 大二自己每天都在做一件事，挂上系统进行DEBUG，那时使用的调试器是SoftICE。每天都按下一步，下一步。有些人问我学DEBUG有什么技巧。其实就是遵循一个逻辑，按“下一步”，然后用眼睛看，没什么技巧。但是要一直这样按，要按24小时，因为一但你睡觉，隔天就会忘记昨天你追到哪里了。在大二我一直都在做这样事情。 最后，你会发现Win95跟本就是个大垃圾。对！微软是个垃圾！从头到尾Win95他根本就不是个作业系统，在我的定义里。 Win 95他是个有大BUG的系统。所以呢，他的BUG会很多。Windows 95 宣称是32 bit作业系统，他底层很多事实上很多的Kernel会使用16 bit作业系统。甚至有些东西会呼叫DOS的API。所以Win 95 有三个作业系统：32bit作业系统、16bit作业系统，再加上16bit DOS作业系统。 有人说我怎么厉害入侵一个Win95的Kernel，让自己从User Mode 取得 Kernel Mode。CIH怎么那么厉害。 错！因为从头到尾就一两个字节就做到了。因为大门就这么大，一进去就到了Kernel Mode。在Win95，你只要通过一行C的程式就可以让你的系统Crash掉。因为一行C的程式就可以毁掉中断向量表。他没有做检查。因为Win95要向兼容16 bit Windows和DOS。所以才有这个奇怪的现象。而当时真正稳定的系统就是NT--另外系列的作业系统，真正的32bit OS。 后来我在大四，我看到一些病毒，还听说病毒绝对是不可以毁掉BIOS。我在想真的不可以毁掉吗？那时很多人很难想象BIOS会被毁掉，而事实上是可以毁掉的。 为什么？ 因为那时候有可以用工具去升级BIOS，既然工具可以把BIOS升级，那么病毒也可以把BIOS升级。升级完之后，屏幕打开黑黑的看不到。软体可以做到的，病毒都可以做到。那当然了，你会发现这些病毒在爆掉世界之前，我的电脑先暴了。所以我会买两颗BIOS，这颗坏掉后，再烧另外一颗。当时我对烧BIOS不熟，BIOS虽然只有几百K，但把他变成组合指令还是很难追的。最后我以一种极土的方式。就是每天一直按下一步，然后找到可疑的地方停下，看他在什么地方更新BIOS。 如果没有更新，下一次就再多按几下，最终会有一次，一旦执行这个Function就会擦除BIOS为空。然后跟进这个function继续追，没日没夜的测，靠的就是坚强的毅力。 当时从User mode 取得Kernel mode时，我就想就可以为所欲为了。不过我喜欢做一个技术高超的程式员。所以那个时候，我的病毒感染之后，执行文件一个Byte都不会变大，因为我去找执行档里面破碎的空间。所以感染之后的病毒体被切成几块，分开到不同的破碎的地方，然后病毒在执行的时候，再像变形金刚组合起来，就是从执行档里找这几个不同的破碎地方组合起来变为一个病毒。就是因为这样的技术，执行档感染起来后，完全不会增加一个Byte。而同时用一些技巧，去减小function的大小。当时我在测试的时候，每找一个地方我就改一个。优化这个东西，是因为我从高中的时候，我就喜欢玩酷的东西。后来就越玩越火，居然我花6成到7成的时间，每天在做什么事情呢?一个Byte一个Byte的减，能少一个Byte就少一个Byte，检查每一个组合指令能否用更短的方式去替代。对我来说这也是个成就感。这样我的病毒不到1024Byte，就可以做到所有功能。 接下来，因为全班的同学都知道我在写这个病毒。那时候又要毕业了，就开始有人找我要这东西了。 主持人：“我问一句，因为我很好奇，你的同学你怎么找到你写病毒？” 很我兴奋呀，我就告诉全班，这东西写出来可以做的到现有的技术，包括防火墙，杀毒软件完全都看不到他。 主持人：“如果当时有HITCON大会你会否发表？” 如果当时会。 回到之前那里，因为有些老师太压榨学长，所以等学长们毕业后，CIH就会爆了。当时没想那么多。我在写的时候，所有的同学都知道我在写。因为实验室是跟宿舍相连的。所以后来的结果是超出我想像，传播到了全世界，因为那是一年以后。当时看到相关资讯后，我在想。“哇，我捅了大事情了！”一个月之后各大杀毒软件发布的清除程式，然后我想应该没有问题了。想不到一年后又爆炸了。这个事情是无意中发生的事情。 主持人：“我问一下，如果有学生正想写virus你有什么建议？” 如果有人对这块极度感兴趣，我的建议就是除了一直debug外，你还是要把底子打好呀。如果你确定要写BIOS，在Kernel Mode做事情，那就乖乖的花很多时间去写程式，我写了很多年，每天一直在写，研究Windows Kernel 的东西。只有对他很了解，才会知道哪些地方有问题，这些都是基本功。如果你确定真的要写这方面的东西，你要想一想，你可能去创造一个之前没有的东西，但是东西写完之后，同时必须提供相对应的方式去把问题Fix掉。然后写文章纯粹发表技术，这样对资讯安全有更大的贡献。 后来因为CIH，我一直和国安局，资讯局都还有交流。一说交流，就是被叫过去喝茶。那时候真的以为自己这辈子完蛋了。后来呢，如果某些小朋友在这方面出了的问题，他们会问一下我的想法。不过有一次，他们打电话给我：“CIH恭喜你呀，因为你的关系，立法院通过资讯相关犯罪条例！”。我当时想，小弟终于有贡献了。所以呢，站在我的立场，我们可以研究一些攻击方法，但是必须把这些技术或是咨讯安全的问题转换成对科技的贡献。 主持人：“因为我发现你从高中开始，从完全不会电脑，只花了五六年时间，就做出了CIH病毒。这一点让我蛮佩服的。我认识的许多高手，绝大部分是从小学开始。我想问的是说，你究竟花了多少时间，你有在睡觉吗？” 有睡觉。这里问到一点，为什么同样的时间，结果却不同。因为我只做一件事情，就是focus，专注于一件事情。事实上我只会按“下一步”。因为我只专注研究Kernel，其他的我完全不会，写网站不会， Java不会。如果你确定有兴趣，就把所有的时间就投入到这块。所以我和别人不一样，别人总是东碰西碰，而我没有。我每天总是在写组合指令，而且没觉的很烦。有时写累了，就换点做其他的，休息完再继续写。你看到台上的人技术力很强，其实背后花的时间，是你想象不到的。所以兴趣，执着和专注力才能把事情做好。 其中有一点，造就我在Kernel这块与众不同。因为我高中和大学英文成绩不好。怎么样不好？那时候英文全班倒数第一。强迫去参加一个特殊的英文发音课程，而我大二大三就强迫就被抓去过上这个班。因为这样，你会说有这么多技术，是不是从社区或者网上的技术文献看到的。因为我英文不好，所以不可能从这方面获得。我是接触到SoftICE这个32bit Debuger，我每天一直按，才知道作业系统是怎么做的，虚拟机是怎么做的。我知道大部分黑客是混社群的，而我是比较特别，就是关起门来，自己学，每天和SoftICE相处，看到的都是汇编指令。

本文首发于 vivo互联网技术 微信公众号 https://mp.weixin.qq.com/s/E51lKQOojsvhHvACIyXwhw 作者：黄文佳常见错误的分类对于用户在访问页面时发生的错误，主要包括以下几个类型：1、js运行时错误JavaScript代码在用户浏览器中执行时，由于一些边界情况、本地环境的不可控等因素，可能会存在js运行时错误。而依赖客户端的某些方法，由于兼容性或者网络等问题，也有概率会出现运行时错误。e.g: 下图是当使用了未定义的变量"foo"，导致产生js运行时错误时的上报数据：2、资源加载错误这里的静态资源包括js、css以及image等。现在的web项目，往往依赖了大量的静态资源，而且一般也会有cdn存在。如果某个节点出现问题导致某个静态资源无法访问，就需要能够捕获这种异常并进行上报，方便第一时间解决问题。e.g: 下图是图片资源不存在时的上报数据：3、未处理的promise错误未使用catch捕获的promise错误，往往都会存在比较大的风险。而编码时有可能覆盖的不够全面，因此有必要监控未处理的promise错误并进行上报。e.g: 下图是promise请求接口发生错误后，未进行catch时的上报数据：4、异步请求错误（fetch与xhr）异步错误的捕获分为两个部分：一个是传统的XMLHttpRequest，另一个是使用fetch api。像axios和jQuery等库就是在xhr上的封装，而有些情况也可能会使用原生的fetch，因此对这两种情况都要进行捕获。e.g: 下图是xhr请求接口返回400时捕获后的上报数据：各个类型错误的捕获方式1、window.onerror与window.addEventListener('error')捕获js运行时错误使用window.onerror和window.addEventListener('error')都能捕获，但是window.onerror含有详细的error堆栈信息，存在error.stack中，所以我们选择使用onerror的方式对js运行时错误进行捕获。window.onerror = function (msg, url, lineNo, columnNo, error) { // 处理错误信息 } // demo msg: Uncaught TypeError: Uncaught ReferenceError: a is not defined error.statck: TypeError: ReferenceError: a is not defined at http://xxxx.js:1:13 window.addEventListener('error', event => (){ // 处理错误信息 }, false); // true代表在捕获阶段调用，false代表在冒泡阶段捕获。使用true或false都可以，默认为false2、资源加载错误使用addEventListener去监听error事件捕获实现原理：当一项资源（如<img>或<script>）加载失败，加载资源的元素会触发一个Event接口的error事件，并执行该元素上的onerror()处理函数。这些error事件不会向上冒泡到window，不过能被window.addEventListener在捕获阶段捕获。但这里需要注意，由于上面提到了addEventListener也能够捕获js错误，因此需要过滤避免重复上报，判断为资源错误的时候才进行上报。window.addEventListener('error', event => (){ // 过滤js error let target = event.target || event.srcElement; let isElementTarget = target instanceof HTMLScriptElement || target instanceof HTMLLinkElement || target instanceof HTMLImageElement; if (!isElementTarget) return false; // 上报资源地址 let url = target.src || target.href; console.log(url); }, true);3、未处理的promise错误处理方式实现原理：当promise被reject并且错误信息没有被处理的时候，会抛出一个unhandledrejection。这个错误不会被window.onerror以及window.addEventListener('error')捕获，但是有专门的window.addEventListener('unhandledrejection')方法进行捕获处理。window.addEventListener('rejectionhandled', event => { // 错误的详细信息在reason字段 // demo:settimeout error console.log(event.reason); });4、fetch与xhr错误的捕获对于fetch和xhr，我们需要通过改写它们的原生方法，在触发错误时进行自动化的捕获和上报。改写fetch方法：// fetch的处理 function _errorFetchInit () { if(!window.fetch) return; let _oldFetch = window.fetch; window.fetch = function () { return _oldFetch.apply(this, arguments) .then(res => { if (!res.ok) { // 当status不为2XX的时候，上报错误 } return res; }) // 当fetch方法错误时上报 .catch(error => { // error.message, // error.stack // 抛出错误并且上报 throw error; }) } }对于XMLHttpRequest的重写：xhr改写 // xhr的处理 function _errorAjaxInit () { let protocol = window.location.protocol; if (protocol === 'file:') return; // 处理XMLHttpRequest if (!window.XMLHttpRequest) { return; } let xmlhttp = window.XMLHttpRequest; // 保存原生send方法 let _oldSend = xmlhttp.prototype.send; let _handleEvent = function (event) { try { if (event && event.currentTarget && event.currentTarget.status !== 200) { // event.currentTarget 即为构建的xhr实例 // event.currentTarget.response // event.currentTarget.responseURL || event.currentTarget.ajaxUrl // event.currentTarget.status // event.currentTarget.statusText }); } } catch (e) {va console.log('Tool\'s error: ' + e); } } xmlhttp.prototype.send = function () { this.addEventListener('error', _handleEvent); // 失败 this.addEventListener('load', _handleEvent); // 完成 this.addEventListener('abort', _handleEvent); // 取消 return _oldSend.apply(this, arguments); } }关于responseURL 的说明需要特别注意的是，当请求完全无法执行的时候，XMLHttpRequest会收到status=0 和 statusText=null的返回，此时responseURL也为空string。另外在安卓4.4及以下版本的webview中，xhr对象也不存在responseURL属性。因此我们需要额外的改写xhr的open方法，将传入的url记录下来，方便上报时带上。var _oldOpen = xmlhttp.prototype.open; // 重写open方法,记录请求的url xmlhttp.prototype.open = function (method, url) { _oldOpen.apply(this, arguments); this.ajaxUrl = url; };其他问题1、其他框架，例如vue项目的错误捕获vue内部发生的错误会被Vue拦截，因此vue提供方法给我们处理vue组件内部发生的错误。Vue.config.errorHandler = function (err, vm, info) {  // handle error  // `info` 是 Vue 特定的错误信息，比如错误所在的生命周期钩子  // 只在 2.2.0+ 可用}2、script error的解决方式"script error.”有时也被称为跨域错误。当网站请求并执行一个托管在第三方域名下的脚本时，就可能遇到该错误。最常见的情形是使用 CDN 托管 JS 资源。其实这并不是一个 JavaScript Bug。出于安全考虑，浏览器会刻意隐藏其他域的 JS 文件抛出的具体错误信息，这样做可以有效避免敏感信息无意中被不受控制的第三方脚本捕获。因此，浏览器只允许同域下的脚本捕获具体错误信息，而其他脚本只知道发生了一个错误，但无法获知错误的具体内容。解决方案1：（推荐）添加 crossorigin="anonymous" 属性。<script src="http://another-domain.com/app.js" crossorigin="anonymous"></script>此步骤的作用是告知浏览器以匿名方式获取目标脚本。这意味着请求脚本时不会向服务端发送潜在的用户身份信息（例如 Cookies、HTTP 证书等）。添加跨域 HTTP 响应头：Access-Control-Allow-Origin: *或者 Access-Control-Allow-Origin: http://test.com注意：大部分主流 CDN 默认添加了 Access-Control-Allow-Origin 属性。完成上述两步之后，即可通过 window.onerror 捕获跨域脚本的报错信息。解决方案2难以在 HTTP 请求响应头中添加跨域属性时，还可以考虑 try catch 这个备选方案。在如下示例 HTML 页面中加入 try catch：<!doctype html> <html> <head> <title>Test page in http://test.com</title> </head> <body> <script src="http://another-domain.com/app.js"></script> // app.js里面有一个foo方法，调用了不存在的bar方法 <script> window.onerror = function (message, url, line, column, error) { console.log(message, url, line, column, error); } try { foo(); } catch (e) { console.log(e); throw e; } </script> </body> </html> // 运行输出结果如下： => ReferenceError: bar is not defined at foo (http://another-domain.com/app.js:2:3) at http://test.com/:15:3 => "Script error.", "", 0, 0, undefined可见 try catch 中的 Console 语句输出了完整的信息，但 window.onerror 中只能捕获“Script error”。根据这个特点，可以在 catch 语句中手动上报捕获的异常。总结上述的错误捕获基本覆盖了前端监控所需的错误场景，但是第三部分指出的两个其他问题，目前解决的方式都不太完美。对于有使用框架的项目：一是需要有额外的处理流程，比如示例中就需要单独为vue项目进行初始化；二是对于其他框架，都需要单独处理，例如react项目的话，则需要使用官方提供的componentDidCatch方法来做错误捕获。而对于跨域js捕获的问题：我们并不能保证所有的跨域静态资源都添加跨域 HTTP 响应头；而通过第二种包裹try-catch的方式进行上报，则需要考虑的场景繁多并且无法保证没有遗漏。虽然存在这两点不足，但前端错误捕获这部分还是和项目的使用场景密切相关的。我们可以在了解这些方式以后，选择最适合自己项目的方案，为自己的监控工具服务。—— —— 参考文档 —— ——1.Using XMLHttpRequest： https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Using_XMLHttpRequest2.script error 产生的原因和解决办法： https://www.alibabacloud.com/help/zh/faq-detail/88579.htm3.JavaScript执行错误： https://docs.fundebug.com/notifier/javascript/type/javascript.html4.betterjs的script error： https://github.com/BetterJS/badjs-report/issues/35.Vuejs的errorHandler： https://cn.vuejs.org/v2/api/index.html#errorHandler6.React的componentDidCatch： https://reactjs.org/blog/2017/07/26/error-handling-in-react-16.html

原文转自：微杂志机场是个很有意思的地方，它是出发地与目的地之间悬浮着的一座孤岛，一个欲言又止的逗号，千万种人生在此汇合，有一些从此变了方向，更多的人短暂相遇又彼此错过。这是个容易让人产生幻觉的地方，你会觉得自己因为这趟旅程或多或少都会有那么点不同。飞机像集装箱一样把乘客投递到他乡的时候，身后托带着的那串纷纷扰扰的无线电信号遮蔽着肉眼可见的天空。你并不真的知道那些信号搭载的信息，就像你无法获知机舱里别人酣睡时做着的梦。这些未知在遭遇恶劣天气的时候会迅速孵化焦虑，喷洒在狭促的机舱内，迄今为止很少有人能对此完全免疫。可怕的是等待，比等待更可怕的是无故浪费的时间以及由此引发的一连串的计划更改、延误。那种广泛散布的不安足以使一个温和的人怒从心头起，一个刚烈的人恶向胆边生。它是所有人，所有焦虑的叠加，或者说等量复制，这些积聚的情绪庞大到机舱都无法隔离，最后都结结实实砸在机长头上，除了不确定的天气，身体的疲累，一个机长的沉稳和酷劲都从这些焦虑中提炼而来。这算是炼金术的一种么？今天推荐的这篇文章几乎算得上一篇成色很好的小说（其实它是作者真正的经历），作者本人是国内某航空公司飞行员，在今年5月经历了职业生涯里历时最长的延误，虽然不是电影里那种惊险的飞行事故，但行文中到处弥散的紧张，时时刻刻的坚持和抉择都让这个故事的张力保持得非常好，飞行员当时比天气还恶劣的情绪如今仍然新鲜。关键是，那些你不知道的戏剧性的情节，那些拥挤的信号搭载的信息，在这篇文章里都有明白的解释，而文明的进步何尝不是对人类普遍经验的清醒认识？==============================================================================延误in北京地服问：“机长咱们没事吧？能不能上客？”管制员给副驾驶的答复是：“准备好才能申请，大约等30分钟。”所以我给地服的答复是：“抓紧！”【19:00】这是我们真正准备好的时间，15分钟前我们向管制员报告了准备好。提前谎报的理由无它：不求占便宜，只求不让我航班上的旅客太吃亏。在我之前已经有数架飞机连续报告了准备好，他们也许已经关好了舱门，也许与我一样报告的同时还在上客，当然还可能是刚刚落地滑入机位⋯⋯一时间扑朔迷离，这注定是一场脑力与运气的竞逐。你永远不知道对方的底牌，唯有妥协去适应当前的局面。【19:30】30分钟后我们并未等到任何消息，频率里异常繁杂，更多的飞机向管制员报告了准备好。管制员不断地回答着：“时间已抄收，等通知！”只要管制员接话稍有停顿，飞行员便会呼叫第二遍、第三遍，生怕管制员遗漏掉自己被别的飞机抢了先，直到传来管制员解释：“准备好已经收到了，刚喝了口水。”从他的声音里不难听出后半口水甚至还没来得及咽下。尽管知道管制员不容易，但在他喝第二口水前，我们还是找了个间歇残忍的插进播道询问了当前状况，答复如下：“排在第十架左右，由于雷雨天气放飞间隔加大，时间预计要两个小时。”听到这个信息后，驾驶舱内三个人的动作很一致：扶额。作为机长，我比他们还多了“掐”这个动作。“排在第十架”这句话本身并不可怕，如果天气好和机场不繁忙的时候30分钟内就能起飞。但是加上“雷雨天气放飞间隔加大”这句话就大大的不妙了：本来每2分钟就能放一架飞机，现在间隔大到5分钟、10分钟都有可能，所以再后面的的“预计两个小时”就只能是一个参考时间。同时两个小时又是一个很尴尬的时间点：如果组织旅客离机，那么呆上1小时就要重新登机，来回折腾不说，到时候有一两名旅客失踪找不回来报警的心都有！由于飞机已经是延误状态，从道义上你还不太好意思减客，凭什么只能你迟到我不能迟到啊？如果不下客就让旅客在飞机上等呢？那你就祈祷这个时间准确吧！不准的话你再祈祷旅客都是好脾气，赶上差脾气旅客再祈祷当前的状况一定是个梦⋯⋯总之，雷雨天气变幻莫测，有可能雷雨云团中突然露出一道缝隙，管制员找准机会连续放出四五架，你的时间就提前了；也有可能雷雨把机场封得越来越牢使得间隔进一步加大，你的噩梦就到来了！我向乘务长大致说明了延误情况，建议她在地面上发餐。乘务长明显有些顾虑，说飞机上100多名旅客，发餐到收餐需要将近1个小时。我向她展现了一个阳光般的笑容说：“1个小时吗？小意思，不用担心！大胆去发吧！”乘务长愣了一下，离开驾驶舱的时候眼神中充满着幽怨。无法预知未来的我还是老老实实做了第一次常规的机长广播：我们抱歉抱歉抱歉……大家辛苦辛苦辛苦……天有不测风云，有具体起飞时间一定通知大家！让我们在守候中期待惊喜！（本来想通过最后一句展示一下我的文学素养，但是现在回想起来，这一句确实不应该说……）【20:00】再次询问管制员，回答：“还需要等待两个小时。”等一下下！！之前半小时白等了吗？管制员这次解释得很详细也很耐心：南下的飞机只有一道缝隙可以穿过雷雨（注：我们的航班由北京飞往杭州，属于“南下”），但往西边去的飞机由于绕不过去也只得飞来一起挤这道缝，所以放飞十分缓慢。滑行道上还压着7、8架无法起飞。担心的事终于发生，最可恨的依旧是“两个小时”这不长不短的时间……这是延误以来第一次需要好好考虑做决策的时候，到底需要不需要全部下客？如果以结果论来反推的话，这一刻让旅客全部离机无疑是最轻松的选择。请注意：我的用词是“最轻松”而不是“最正确”。机组是轻松了，但同为民航一线的地服人员接手了这份“甜蜜的负担”之后，他们的应对情况从微博反映来看并不如想象中的理想。正所谓：楚人失之楚人得之！从旅客角度来说，有些喜欢下机去吸支烟歇歇腿，有些愿意在机上小憩懒得再动。无论哪种选择都不会让所有人满意，我决定赌上一把再等等这两个小时。当然，任何决策都不代表你能忽略旅客的意愿！我要求副驾驶通过现场频率叫来地服人员靠上廊桥，开始第二次的机长广播：“目前雷雨天气的发展很不乐观，预计还要等待很长时间，目前估算为两小时左右！（闭着眼不去想象旅客听到后惊呼失望的样子）这里提醒大家如果有终止旅程的旅客，请提前告知乘务人员。一旦我们有了推出时间，您再提出终止旅程很可能会使我们错过时间，为了大多数旅客的利益，那个时候我也许会拒绝您的下机要求，希望得到您的谅解。”广播之后，陆续有旅客联系了乘务长与地服办理了终止旅程的手续。我也借此机会通知油车再次补进500kg的油量以备后续的等待。这里顺便说明一下：我们的飞机是今年才从德国接回的，空调设备优良。地面空调由辅助动力提供（APU），每小时大约消耗100kg航油。而滑行道上那些启动好发动机等待的飞机每小时至少消耗800kg，想想都心疼。所以那些持有类似“航空公司明知道起飞不了，故意将飞机滑出去等着，然后等很久滑回来欺骗我们。”这种阴谋论的网友，你们可以省省心编点别的内容了。【21:00】由于一直没有起飞时间，飞机始终保持在靠桥状态，地服也偶尔会登上飞机询问当前状况，我糟糕的脸色终于令他放弃问出那句“没事吧？”转而问道：“旅客情绪还好吧？还得等多久？”我答道：“旅客情绪还好，不愿意等的旅客大都办理了终止，机上旅客应该都是迫切想飞往杭州的。只是现在放飞十分缓慢，天气情况仍然不够明朗。”询问管制员，我们的次序已排入了前五。看到一段时间内再没有旅客离机，我们通知了配载部门按照新的旅客数量及油量重新制作舱单，计算配平重心。这样做使得我们的飞机仍然保持着手续齐全随时可以推出的状态，这种状态在延误排续中算得上一种优势，而我有信心把这种优势再维持一个小时。（注：建议旅客们在飞机起飞前不要随意坐到空的座位，特别是前后排数跨度很大的空座位。 尽管现代飞机具有增稳装置和自动配平功能，但这种自动化只限于空中。在起飞前配载部门只能根据旅客的座位来计算起飞重心，飞行员通过人工调整配平轮来保证起飞时的杆量适中。倘若旅客自行更改座位造成重心差异较大，飞行员在操纵飞机抬头的瞬间有可能发生带不动飞机，或者杆量太轻造成仰角过大擦机尾。所以特别是飞机后排比较空的时候，非要换还是等到巡航吧。）此时，整个北京机场开始第一波大面积取消航班：这次取消航班主要由于一些机组上午已经执行过其它航班，由于执勤时间的限制无法继续执行后续航班。这时候如果这家航空公司在北京有驻地，有机组可换的话便会换上新的机组继续坚守等待；如果航空公司没人可换，航班就只剩下取消一途。【22:00】频率里的排队的飞机已达到了恐怖的40架以上，北京这次的雷雨连绵不绝地影响了机场近4个小时仍未消散，持续时间之久远远超出了预期。这真的应了前面机长广播里所说的SURPRISE！更加让人吐血的是：向南起飞的航班停放了！开车的人都知道，高架桥上20-30迈的速度往前移动和开不动停下来完全不是一个概念，假如你车后面还坐着一群领导，你该如何淡定？我继续询问管制员停放状态要持续多长时间？管制员也很无奈地表示要看中低空那边的管制员什么时候能把飞机调开了。我相信管制员所言不虚，这片雷雨不单压住了无数起飞的飞机，而且对落地的飞机影响更甚。在签派频率就能听到空中一些航班的飞行员正在和签派员们商讨着备降事宜。我的后续航班也发生了变化，最后一段“杭-京”由于我延误过多无法回杭，于是公司从杭州调配了其他机组和飞机来执行。遗憾的是他们在杭州苦等了两个小时终于得以推出滑行，但仅仅滑行了3分钟就接到了“北京不再接收飞机”的指令而不得不滑回取消。各个航空公司开始第二波大面积取消航班：这次取消是因为有些航班的目的地机场有关闭时间，例如上海虹桥机场会在24:00前关闭，那么飞机即便现在起飞到目的地也无法落地。倒不如早早取消明早补班！取消得越早，明早补班就能越早！（注：机组需满足《运行手册》的规定休息时间，新闻中所说的航班延误是因为“机长没睡好”专业点的说法应该是“机长还不符合休息时间的规定”。）而我也打算按照原计划开始祈祷旅客好脾气了……此时此刻的我终于有些感觉力不从心，让人忧心的不再是糟糕的天气、也不是自己的精力，而完完全全是旅客的情绪。这次让旅客在飞机上等待这么长的时间在我近些年的飞行经历中绝无仅有，几年前我曾在微博上发过一篇小文《延误时机长会做些什么》，那个时候还没有CDM放行，几乎每班都是在载客中等待，无论是旅客和机组都苦不堪言，即便如此等上3小时至少也能有明确的起飞时间。我曾说如果等待三个小时还没有时间，自己一定去找管制员要个说法！可今天说法就在眼前，我却没把握它能令旅客信服。我怀着无比愧疚地心情准备通知全部旅客离机的时候，突然传来一条消息——西边的雷雨开始消散了。【22:30】频率里再次繁忙起来！管制员们开始尝试能否让南下的飞机从西边离港，他们不停地询问着排队靠前的飞机：“如果起飞后先飞向郑州再回转，油量是否满足？”飞行员们此时也犹如打了一剂强心剂般的计算着、权衡着……我在这个时候拿起话筒做了第三次机长广播：“女士们先生们，我是本次航班机长，我猜可能大家已经厌烦了这个声音，毕竟前两次的广播都没有给大家带来好的消息。在飞机上等待三个小时确实不太容易，大家急躁的心情我们机组非常理解，我把目前的状况向大家交代一下：我们的飞机现在已经排到了前五架，如果正常情况下我们随时可能推出飞机。但是由于南面的雷雨天气持久不散，这个方向近一段时间都没有飞机起飞。北京机场已有很多航班陆续取消，有些因为机组的执勤时间面临超时，有些由于目的地机场将要关闭。我们机组目前没有超时的问题，精力充沛请大家放心，杭州机场拥有双跑道也将保证24小时的开放。我们机组现在所能做的就是陪大家一起等待，等待天气转好后安全的将大家送至杭州。据空中飞行员反应，天气目前已经开始好转，请大家能再坚持一下，我们的乘务员将尽所能为您服务，希望我们的工作能得到您的理解和配合。”广播之后，乘务长说后面有些旅客让她转达理解和谢意。然而，这并没有让我的心情变得轻松。如果我站在乘机人的位置，恐怕更多的心思是郁闷与无奈，随着时间的不断延后，留给理解的空间也将越来越小。西边的雷雨散了，可我依旧不知道那南边的还会久吗？【23:30】就在我们与管制员沟通时，乘务长要求进入驾驶舱。她说：“后面有一名稍胖的旅客说他身体不好，血压高，需要休息，明早7点还要服药。”也许是等得时间太久了脑子僵硬，我一下子没得出要领，“所以？”“所以他说自己需要好好地休息！”乘务长又强调了一遍。“他的气色如何？意思是需要下机休息？”我继续问道。“看他气色正常，安全员也这样问他是否需要下机？那人说安全员这样问是在威胁他。”“你再好好打听一下他的目的，耐心询问一下他的需求，我这边再问下管制员有没有具体时间。”该来的事情迟早会到来，宣泄口一旦找到全部下客清舱就成为了必然，只是我的时间来得及吗？我们再次询问管制员的放飞状况，管制员回答说我们的排序是在前面，但是之前有5架滑行道上的飞机陆续地滑回补油，这5架如果都同意走西线继续执行航班的话，我们必须排在他们后面。这样的安排无可厚非，倘若再把滑回飞机的位置排到队伍后面，显然对他们机上的机组和旅客是不公平的。与此同时我们联系了现场频率，询问了是否能提供医生上机量血压？现场告知可以，不过需要当事人自费，大约200-300元。我急忙将这一信息反馈给乘务长，并通知地服协助我们协调工作。乘务长再次进入驾驶舱时的心情比之前要急迫得多：“机长，您能不能再广播一下。那名旅客带头要求赔偿，很多乘客赞同，闹得很凶！”我无奈地开始做了第四次广播：“虽然南边的雷雨还没有完全退去，但西边已经逐渐晴朗。管制员们已经为我们从西边绕飞努力做着准备，目前我们可以先飞向郑州再转回杭州，尚需等待管制员的指令。有很多旅客询问赔偿问题，毕竟延误了这么久，作为机组我本人也很希望能得到一份赔偿，航空公司有专门的人员负责这件事，我在这里可以把我所知道的向大家介绍一下：针对我们公司的规定，如果由于天气原因造成航班延误并不在赔偿范畴；如果是非天气原因，延误达到4个小时可以进行相关的赔偿。也许有的旅客觉得这并不公平，您有权利和地服人员去交涉，只是这恐怕要花费相当长的时间和精力，也可能为此耽误我们的行程。如果可以，我希望您能够到达杭州后再做此项工作，以免影响目前渴望休息和尽早飞回杭州的旅客。我们机组从下午一点多开始执行航班，从晚上七点一直陪伴大家等到了现在。按照规定，我们的执勤时间最晚可以等到凌晨4点钟起飞，在4点钟前我们都会咬紧牙关等下去。乘务长反应已经有个别旅客出现了身体不适，如您需要下机休息或就医请务必告知我们，如果您可以同我们再坚持一下的话，我一定在半小时内对离场时间给大家一个回馈。对于其它疑问，相信我们的乘务人员也会尽所能去回答让大家满意，谢谢。”我无力地放下话筒，乘务长进来报告：那位客人已经不闹了，说再给我们半个小时的时间。副驾驶问我：“半小时我们能有时间吗？”我回答：“如果没有，就只能下客了。不知道这是否是他们想要的结果。”【24:00】管制员回答滑回的5架飞机均要求从西线离港，所以我们预计至少还要一个小时。这在意料之中又在意料之外，意料之中是5架飞机的决绝，都回来补油了还能不走吗？意料之外的是怎么还要等这么久啊！我意识到“大势已去”，通知了现场人员组织下客，那一刻我的心情低落到了谷底。而此时地服走了进来对我说：“机长，您看能不能不下客？签派说正在帮忙协调马上能走！”我一腔邪火正无处可发，大声地对地服叫嚷着：“之前公司让我赶着回杭州继续执行下一个航班的时候，我请求他们协调，他们答应了却没有任何回应；后来等啊等，我的休息时间快赶不及明天下午航班的时候，我请求他们去协调，他们答应了又没有回应；现在我要求下客了，他们主动要求去协调了？我怀疑他们是否有这个能力！前面五架飞机都补完油滑出了，你告诉我他们怎么协调能把我调到前面去？你转告他们尽快去协调吧，我先下客了，如果协调下来时间我马上把旅客接回来成吗？”地服没再说什么，转身而去。望着她同样劳累的背影，我为自己之前的脾气感到有些后悔，超长延误的重压我们机组已经尽力扛起得够多够多，请谅解吧。在旅客离机之前，我做了最后一次广播：“很抱歉的通知大家，由于具体起飞时间无法敲定，我们还是组织大家离机，希望大家能在候机楼好好休息。后续航班是继续执行或是取消我们要等待签派的通知，但我们的承诺依然存在，只要有希望我们一定会尽力申请保留航班飞回杭州。非常感谢与大家共同度过的这段时间，大家的配合令我们感动，谢谢。”放下电话，我终于长舒了一口气，副驾驶问我：“终于轻松了？”话音未落，乘务长开门进来说：“机长，有7个人不走！”“哦？如果愿意留在飞机上就留着吧，不用过于勉强。”我不以为然。“不走的就是刚才那个‘胖子’和一起闹的几个人啊！”我已苦中带笑：“那你去问问他们有什么要求没有？”一会，乘务员回馈说：“他们担心下了飞机航班就会取消，没地方再去要说法所以不肯走。现在几个人闭眼睡觉了！”“是该好好休息了。”我答到。旅客休息的这段时间，我们机组并未停歇！我先询问了签派对航班的建议，并要求尽量保留航班，我深知这班若取消对旅客意味着什么：一旦这个航班取消，即便按照最短的休息时间去休息，补班也要制定在明天中午左右。由于今晚取消的航班太多，明早补班与正版交织一线势必再次延误，如果本机旅客无法顺利改签的话也许会足足耽误一天。那我到目前所等的5个多小时就变得有违初衷全无意义可言了。另一方面我通知了油车再次补油，这次干脆直接补进5吨油！任你滑行道上再排队等候、任你起飞之后往西绕飞多远，往北往东绕我都不怕了！望着副驾驶略有疲惫的面容，我要过了操纵权：“这么晚了，这个起落还是我来吧，下次换你！”我脑中一遍遍地过着还会有什么因素影响着我飞回杭州，一旦旅客重新登机，那时任何的疏忽与闪失都将造成航班取消。【01:00】同公司最后一架飞往杭州的航班由于排序过于靠后终于也不得不宣布取消，至此唯有我们还在坚守。【01:15】旅客重新登机，不仅人数没少而且还多了很多伙伴（其它被取消航班的旅客改签至此），飞机几近满客。【02:10】等待了7小时后，我们终于冲上云霄。我知趣地没再做机长广播以免更加让人生厌。【04:10】飞机安全于杭州落地。这一天我们飞两段，执勤了14个小时。最后一段的飞行我没有感到任何疲倦，因为我知道机组的使命并未完成。虽然夜色已深，但这一路并不孤独:频率里的每个声音都能让我感受到空中的管制员从容淡定；夜空中的每一点闪烁都令我仿佛看到另一间驾驶舱内飞行员的严谨沉着；飞机脱离跑到后一眼便能望见引导车的守候；到位停稳时客梯车、摆渡车接驳依然准时无误；以及送我们回公寓的机组车师傅脸上还有着真诚的笑容。这大概就是熟睡的旅客所无法得见属于民航世界的另一番景象吧。【05:00】我躺在公寓的床上，透过窗帘的缝隙望着夜色里逐渐透露出的鱼肚白。尽管没有经过第三次的祈祷，我也感到之前所经历的一切宛如梦幻。延误时，在机上与旅客共处5个小时。在此之前对于我来说这是无法想象的且坚信不可完成的任务！而对于自己没有在等待之初就采取下客措施，对此我并不感到后悔与自责。在飞机上等待，我可以在旅客迷惘时第一时间向他们通报最新情况，可以在他们疲惫时递过一杯咖啡或盖上一条毛毯，可以在时间到来的第一刻带着他们冲上云霄。这些都是候机楼里等待所无法实现的。与此同时，我感受着旅客的焦虑，了解着他们的苦衷，这使我对相互理解又有着更深刻的认识和体会。这个时刻，飞早班的机组想必已经开始起床准备了，不知道今天又有哪些经历与故事等待着他们。记录下这一切，也许只愿换回旅客的一份信任吧。