一、简单介绍一下什么是浏览器内核。
浏览器最重要或者说核心的部分是“Rendering Engine”，可大概译为“解释引擎”，不过我们一般习惯将之称为“浏览器内核”。负责对网页语法的解释（如HTML、JavaScript）并渲染（显示）网页。
所以，通常所谓的浏览器内核也就是浏览器所采用的渲染引擎，渲染引擎决定了浏览器如何显示网页的内容以及页面的格式信息。
不同的浏览器内核对网页编写语法的解释也有不同，因此同一网页在不同的内核的浏览器里的渲染（显示）效果也可能不同，这也是网页编写者需要在不同内核的浏览器中测试网页显示效果的原因。
实际上这是一个动态内核，与前面几个内核的最大的区别就在脚本处理上，Presto有着天生的优势，页面的全部或者部分都能够在回应脚本事件时等情况下被重新解析。
此外该内核在执行Javascrīpt的时候有着最快的速度，根据在同等条件下的测试，Presto内核执行同等Javascrīpt所需的时间仅有Trident和Gecko内核的约1/3（Trident内核最慢，不过两者相差没有多大）。 那次测试的时候因为Apple机的硬件条件和普通PC机不同所以没有测试WebCore内核。
限于Mac OS X的使用不广泛和Safari浏览器曾经只是Mac OS X的专属浏览器，这个内核本身应该说市场范围并不大；但似乎根据最新的浏览器调查表明，该浏览器的市场甚至已经超过了Opera的Presto了——当然这一方面得益于苹果转到x86架构之后的人气暴涨，另外也是因为Safari 3终于推出了Windows版的缘故吧。
Mac下还有OmniWeb、Shiira等人气很高的浏览器。
google的chrome也使用webkit作为内核。
WebKit 内核在手机上的应用也十分广泛，例如 Google 的手机 Gphone、 Apple 的 iPhone， Nokia’s Series 60 browser 等所使用的 Browser 内核引擎，都是基于 WebKit。
目前微软的Trident在移动终端上主要为WP系统内置浏览器，Webkit内核的适用范围则较为广泛，Android原生浏览器、苹果的Safari、谷歌的Chrome(Android4.0使用)都是基于Webkit开源内核开发的。
从实际情况出发：
对于Android手机而言，使用率最高的就是Webkit内核，我们看到很多手机浏览器厂商都宣称有着自主内核，比如手机UC就号称采用了U3内核、而华为也经常标榜自己的天天浏览器采用了T9内核，事实上，他们都是基于开源内核Webkit进行二次开发的，并不是完全的自主内核。
而在iOS以及WP7平台上，由于系统封闭，不允许除系统自带浏览器内核以外的浏览器内核进入，因此各家浏览器的开发均为在Safari或者IE内核的基础上进行二次开发，优化功能和自制UI。
比如海豚、遨游等浏览器就是直接采用系统自带浏览器的内核，这点从这几款浏览器的HTML5评分与系统自带浏览器评分结果完全一致就可以看出。
内核并无手机与PC的区分，手机浏览器的内核与PC浏览器类似，例如：
- IE手机版和PC版都是Trident内核的；
- Opera手机版和PC版都是Presto内核的（自从2013年2月13日Opera宣布放弃Presto内核转向Webkit内核后，已出现部分Webkit内核的Opera手机浏览器测试版）；
- Firefox手机版和PC版都是Gecko内核的；
- Chrome、Safari手机版和PC版都是Webkit内核的。
至于国内的UC和QQ等手机浏览器也都是根据Webkit修改过来的内核。
一、排版引擎
首先厘清一下浏览器内核是什么东西。
英文叫做：Rendering Engine，中文翻译很多，排版引擎、解释引擎、渲染引擎，现在流行称为浏览器内核，至于为什么流行这么称呼，请自行领悟。
Rendering Engine，顾名思义，就是用来渲染网页内容的，将网页的内容和排版代码转换为可视的页面。因为是排版，所以肯定会排版错位等问题。为什么会排版错位呢？有的是由于网站本身编写不规范，有的是由于浏览器本身的渲染不标准。
现在有几个主流的排版引擎，因为这些排版引擎都有其代表的浏览器，所以常常会把排版引擎的名称和浏览器的名称混用，比如常的说IE内核、Chrome内核。其实这样子是不太合理的，因为一个完整的浏览器不会只有一的排版引擎，还有自己的界面框架和其它的功能支撑，而排版引擎本身也不可能实现浏览器的所有功能。下面罗列一下几款主流的排版引擎和浏览器。
1、Trident（Windows）
IE浏览器所使用的内核，也是很多浏览器所使用的内核，通常被称为IE内核。基于Trident内核的浏览器非常多，这是因为Trident内核提供了丰富的调用接口。老的Trident内核（比如常说的IE6内核）一直是不遵循W3C标准的，但是由于它的市场份额最大，所以后果就是大量的网站只支持老的Trident内核，依据W3C标准写的网页在老的Trident内核下面又出现偏差。目前可供调用的最新版的Trident内核是IE9所用的内核，相较之前的版本对W3C标准的支持增强了很多。
Trident内核的浏览器：
IE6、IE7、IE8（Trident 4.0）、IE9（Trident 5.0）、IE10（Trident 6.0）；
世界之窗1、世界之窗2、世界之窗3；
360安全浏览器1、360安全浏览器2、360安全浏览器3、360安全浏览器4、360安全浏览器5；
傲游1、傲游2；搜狗浏览器1；腾讯TT；阿云浏览器（早期版本）、百度浏览器（早期版本）、瑞星安全浏览器、Slim Browser；
GreenBrowser、爱帆浏览器（12 之前版本）、115浏览器、155浏览器；
闪游浏览器、N氧化碳浏览器、糖果浏览器、彩虹浏览器、瑞影浏览器、勇者无疆浏览器、114浏览器、蚂蚁浏览器、飞腾浏览器、速达浏览器、佐罗浏览器；
2、Gecko（跨平台）
Netscape6启用的内核，现在主要由Mozilla基金会进行维护，是开源的浏览器内核，目前最主流的Gecko内核浏览器是Mozilla Firefox，所以也常常称之为火狐内核。因为Firefox的出现，IE的霸主地位逐步被削弱，Chrome的出现则是加速了这个进程。非Trident内核的兴起正在改变着整个互联网，最直接的就是推动了编码的标准化，也使得微软在竞争压力下不得不改进IE。不过比较可惜的是，虽然是开源的，也开发了这么多年，基于Gecko的浏览器并不多见，除了一些简单的改动（坑爹的X浏览器）或者是重新编译（绫川ayakawa、tete009），深度定制或者增强型外壳的还比较少见。另外就是有一些其它软件借用了Gecko内核，比如音乐管理软件SongBird。
常见的Gecko内核的浏览器
Mozilla Firefox、Mozilla SeaMonkey
Epiphany（早期版本）、Flock（早期版本）、K-Meleon
3、KHTML（Linux）
KDE开发的内核，速度快捷，容错度低。这个内核可能不见得很多人知道，但是后面再看下去你就明白了。
常见的KHTML内核的浏览器：Konqueror
4、WebKit（跨平台）
由KHTML发展而来，也是苹果给开源世界的一大贡献。是目前最火热的浏览器内核，火热倒不是说市场份额，而是应用的面积和势头。因为是脱胎于KHTML，所以也是具有高速的特点，同样遵循W3C标准。
常见的WebKit内核的浏览器：Apple Safari、Symbian系统浏览器
5、Chromium（跨平台）
维基百科里面并没有将Chromium从WebKit分出来，这个区分完全是基于我个人的恶趣味。记得以前看过一个大牛的博文说过，Chromium把WebKit的代码梳理得可读性提高很多，所以以前可能需要一天进行编译的代码，现在只要两个小时就能搞定。这个我自己也没有考究过，但是估计可信。这个也能解释为什么Gecko和WebKit出来了这么久，第三方编译、定制的版本并不多，但是由Chromium衍生出来的浏览器早就满坑满谷了。
常见的Chromium内核的浏览器：Chromium、Google Chrome、SRWare Iron、Comodo Dragon
6、Presto（跨平台）
Opera的内核，准确地说，是Opera 7.0及以后版本的内核，Opera 3.5-6.1版本使用的内核叫做Elektra。不用说，Presto对W3C标准的支持也是很良好的。虽然我很喜欢Opera，但是我对Presto的渲染速度一直有保留态度。之前在OperaChina论坛看见有人说过，Presto优先解析文字，保证可阅读性，媒体资源的渲染放后。
常见的Presto内核的浏览器：Opera
7、其它
http://zh.wikipedia.org/wiki/排版引擎
二、JavaScript引擎
说完了排版引擎，接下来说说JavaScript引擎。顾名思义，JavaScript引擎就是用来渲染JavaScript的。
为什么要单独拿出来说呢？因为它涉及到跑分。经常看见很多文章在报道说哪个浏览器更快，其实大部分说的就是JavaScript的渲染速度，而不是页面的载入速度。在网速许可的情况下，其实各个浏览器的页面载入速度差别不大（Opera逊色一些）。那是不是说对比JavaScript的渲染速度其实没有意义？也不是这么说，因为现在JavaScript在页面中的比重会越来越大，越来越多的动态页面开始大量借助JavaScript，比如现在主流的SNS、邮箱、网页游戏，所以JavaScript的渲染速度也是一个很重要的指标。
JavaScript的渲染速度越快，动态页面的展示也越快。Opera在JavaScript引擎的跑分上面一直都是很牛逼的，一般来说最新测试版之间PK，Opera基本都会夺冠。
1、Chakra
查克拉，IE9启用的新的JavaScript引擎。
2、SpiderMonkey/TraceMonkey/JaegerMonkey
SpiderMonkey应用在Mozilla Firefox 1.0-3.0，TraceMonkey应用在Mozilla Firefox 3.5-3.6版本，JaegerMonkey应用在Mozilla Firefox 4.0及后续的版本。
3、V8
应用于Chrome、傲游3。
4、Nitro
应用于Safari 4及后续的版本。
5、Linear A/Linear B/Futhark/Carakan
Linear A应用于Opera 4.0-6.1版本，Linear B应用于Opera 7.0～9.2版本，Futhark应用于Opera 9.5-10.2版本，Carakan应用于Opera 10.5及后续的版本。
6、KJS
KHTML对应的JavaScript引擎。
三、几个测试
1、V8引擎
http://v8.googlecode.com/svn/data/benchmarks/v6/run.html
现在很多“双核”浏览器都用它来跑分测试JavaScript引擎，分数越高越好。
2、Acid3
标准支持测试，分数越高越好，满分是100分。
3、HTML5
测试浏览器对HTML5标准的支持，分数越高越好。
四、几个奇葩
1、IETab
在没有第三方编译版本的时候，IETab一直是Mozilla Firefox、Chrome等非Trident内核的浏览器的安装量最大的扩展之一，方便用户在不开启IE的情况下调用Trident内核访问一些兼容性比较差的网站。
2、Trident/Gecko双核浏览器
虽然IETab能实现部分需求，但是深度订制的毕竟还是不一样，所以Trident/Gecko双核浏览器就诞生了，Sleipnir、Avant 12（Orca）是这类里面比较常见的。Avant 12因为有Orca的前期积累，所以轻车熟路，后面还打算加入Chromium，变成三核浏览器，但是偏偏现在Mozilla Firefox和Chrome都在疯狂刷版本号，肯定有一部分精力要花在跟进版本上。
3、Trident/WebKit双核浏览器
现在国内最主流的“双核”浏览器基本都是这个架构，360极速浏览器、世界之窗浏览器极速版、傲游3搜狗浏览器3、QQ浏览器、枫树浏览器、快快浏览器、百度浏览器、阿云浏览器（后期版本）、太阳花浏览器，其中最奇葩的是傲游3。其它双核浏览器都是基于Chromium的，而傲游是基于WebKit的，但是偏偏又用的是V8引擎。
4、Trident/Gecko/WebKit三核浏览器
目前能见的应该就是日本的Lunascape，Avant增加了WebKit内核之后也会归类到这里。说实话，Lunascape真的很难用，真的很奇葩。各个内核相对独立，外壳本身不够强化，稳定性不高，所以还不如用回单核浏览器。
五、几个小点
1、Chrome/Chromium
很多人都会说自己用的双核浏览器是Chrome/IE双核的，或者说是基于Chrome的。其实这种说法并不正确，因为Chrome本身并不开源，其它厂商是不能去定制Chrome的。能被修改、定制的是Chromium，Chrome的开源开发版本，代码和Build都提供下载。Chromium/Chrome两个单词都是铬，分别是拉丁文和英文，除了名字之外，很有很多不同，你可以自己对比一下。
Chromium一天最多可以更新十几二十个版本，实验性的新特性都会现在这里放出，但是Chromium本身其实并不稳定。
Chrome总共有四个更新分支：Canary、Dev、Beta、Stable，稳定性依次增强。
2、MyIE、MyIE2、傲游、GreenBrowser
自行搜索，一段历史。
3、页面兼容性判断
在确保IE浏览器没有损坏的基础上，搭配一款非Trident内核的浏览器进行判断，如果可以的话，最好所有内核都配齐了。
控制变量就能找到问题所在，是浏览器本身的问题，还是页面编码有问题。对于用户来说就能更好地去选择自己该用什么浏览器访问什么页面，对于开发者来说应该要写出无差别代码。
4、一直被模仿，一直被超越的Opera
Opera其实很好看也很好用，而且极度创新，但是市场占有率一直很低。很多很好用的新特性总是被抄袭，所以大家笑称Opera“一直被模仿，一直被超越”。坊间传闻多标签页浏览器就是Opera发明的，但是貌似有人考究了这个传闻其实不属实。不过快速拨号、Turbo浏览等功能就是扎扎实实Opera首创的。你可以不用Opera，但是你会损失很多乐趣。
5、这年头流行刷版本号
现在版本号最高的浏览器是Chrome，稳定版的版本号是14，也是现在主流浏览器里面诞生时间最短的，真是一个刷版本号高手。早期的Chrome版本更迭还会增加一些比较重要的新特性，比如扩展支持，现在的版本更迭基本上并没有伴随什么大的更新。现在很多伪高端用户就会整天追着第三方编译版本赶紧跟进版本号，但是其实真正的意义并不大。
多亏了Chrome的“提携”，今年Firefox也在猛刷版本号，年初还是3.x，现在正式版已经是7.0.1，每夜版已经到了10.0。Opera积累了多年才到11.50，测试版是12.0。IE的正式版是9，平台预览版是10。
6、查看源代码、开发者工具
一般来说，查看源代码和使用开发者工具是比较实用的，可能用的机会并不多，但是在判断一些问题的时候其实是很有用的。通过查看源代码或者使用开发者工具，可以大致了解这些网站里面的一些元素或者加载的脚本或者是规则，对于判断兼容性问题有一定的帮助，也可以用来准确捕捉页面元素。
7、几个主要的浏览器官网以及版本下载
（1）Internet Explorer
官网：
http://windows.microsoft.com/zh-CN/internet-explorer/products/ie/home
IE7下载：
IE8下载：
http://windows.microsoft.com/zh-CN/internet-explorer/downloads/ie-8
IE9下载：
http://windows.microsoft.com/zh-CN/internet-explorer/downloads/ie-9/worldwide-languages
（2）Mozilla Firefox
官网：
7.x Release：
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/latest/win32/zh-CN/
8.x Candidates：
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/8.0b1-candidates/build1/win32/zh-CN/
9.x Aurora：
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/
10.x Nightly：
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
（3）Apple Safari
官网：
http://www.apple.com.cn/safari/
下载：
http://www.apple.com.cn/safari/download/
（4）Chromium
官网：
下载：
http://build.chromium.org/f/chromium/snapshots/Win_Webkit_Latest/
（5）Google Chrome
官网：
http://www.google.com/chrome?hl=zh-cn
Stable在线安装包：
http://www.google.com/chrome/eula.html?hl=zh-cn
Beta在线安装包：
http://www.google.com/chrome/eula.html?hl=zh-CN&extra=betachannel
Dev在线安装包：
http://www.google.com/chrome/eula.html?hl=zh-CN&extra=devchannel
Canary在线安装包：
http://www.google.com/chrome/eula.html?hl=zh-CN&extra=canarychannel
Stable离线安装包：
http://www.google.com/chrome/eula.html?hl=zh-CN&standalone=1
Beta离线安装包：
http://www.google.com/chrome/eula.html?hl=zh-CN&standalone=1&extra=betachannel
Dev离线安装包：
http://www.google.com/chrome/eula.html?hl=zh-CN&standalone=1&extra=devchannel
Canary离线安装包：
http://www.google.com/chrome/eula.html?hl=zh-CN&standalone=1&extra=canarychannel
（6）Opera
官网：
正式版：
http://www.opera.com/download/
测试版：
Web页面运行在各种各样的浏览器当中，浏览器载入、渲染页面的速度直接影响着用户体验简单地说，页面渲染就是浏览器将html代码根据CSS定义的规则显示在浏览器窗口中的这个过程。
先来大致了解一下浏览器都是怎么干活的：
1. 用户输入网址（假设是个html页面，并且是第一次访问），浏览器向服务器发出请求，服务器返回html文件；
2. 浏览器开始载入html代码，发现<head>标签内有一个<link>标签引用外部CSS文件；
3. 浏览器又发出CSS文件的请求，服务器返回这个CSS文件；
4. 浏览器继续载入html中<body>部分的代码，并且CSS文件已经拿到手了，可以开始渲染页面了；
5. 浏览器在代码中发现一个<img>标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码；
6. 服务器返回图片文件，由于图片占用了一定面积，影响了后面段落的排布，因此浏览器需要回过头来重新渲染这部分代码；
7. 浏览器发现了一个包含一行Javascript代码的<script>标签，赶快运行它；
8. Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个（style.display=”none”）。杯具啊，突然就少了这么一个元素，浏览器不得不重新渲染这部分代码；
浏览器每天就这么来来回回跑着，要知道不同的人写出来的html和css代码质量参差不齐，说不定哪天跑着跑着就挂掉了。
好在这个世界还有这么一群人——页面重构工程师，平时挺不起眼，也就帮视觉设计师们切切图啊改改字，其实背地里还是干了不少实事的。
说到页面为什么会慢？那是因为浏览器要花时间、花精力去渲染，尤其是当它发现某个部分发生了点变化影响了布局，需要倒回去重新渲染，内行称这个回退的过程叫reflow。
reflow几乎是无法避免的。现在界面上流行的一些效果，比如树状目录的折叠、展开（实质上是元素的显示与隐藏）等，都将引起浏览器的 reflow。
鼠标滑过、点击……只要这些行为引起了页面上某些元素的占位面积、定位方式、边距等属性的变化，都会引起它内部、周围甚至整个页面的重新渲染。
通常我们都无法预估浏览器到底会reflow哪一部分的代码，它们都彼此相互影响着。
reflow问题是可以优化的，我们可以尽量减少不必要的reflow。
比如开头的例子中的<img>图片载入问题，这其实就是一个可以避免的reflow——给图片设置宽度和高度就可以了。
这样浏览器就知道了图片的占位面积，在载入图片前就预留好了位置。
另外，有个和reflow看上去差不多的术语：repaint，中文叫重绘。
如果只是改变某个元素的背景色、文字颜色、边框颜色等等不影响它周围或内部布局的属性，将只会引起浏览器repaint。
repaint的速度明显快于 reflow（在IE下需要换一下说法，reflow要比repaint 更缓慢）。
三、从浏览器的渲染原理讲CSS性能
平时我们几乎每天都在和浏览器打交道，写出来的页面很有可能在不同的浏览器下显示的不一样。苦逼的前端攻城师们为了兼容各个浏览器而不断地去测试和调试，还在脑子中记下各种遇到的BUG及解决方案，而我们好像并没有去主动地关注和了解下浏览器的工作原理。
如果我们对此做一点了解，我想在项目过程中就可以根据它有效的避免一些问题以及对页面性能做出相应的改进。
今天我们主要根据浏览器的渲染原理对CSS的书写性能做一点改进（当然还有JS本篇文章暂不考虑，后面的文章会做介绍），下面让我们一起来揭开浏览器的渲染原理这一神秘的面纱吧：
最终决定浏览器表现出来的页面效果的差异是：渲染引擎 Rendering Engine（也叫做排版引擎），也就是我们通常所说的“浏览器内核”，负责解析网页语法（如HTML、JavaScript）并渲染、展示网页。相同的代码在不同的浏览器呈现出来的效果不一样，那么就很有可能是不同的浏览器内核导致的。
我们来看一下加载页面时浏览器的具体工作流程（图一）：
（图一）
1、解析HTML以重建DOM树（Parsing HTML to construct the DOM tree ）：渲染引擎开始解析HTML文档，转换树中的标签到DOM节点，它被称为“内容树”。
2、构建渲染树（Render tree construction）：解析CSS（包括外部CSS文件和样式元素），根据CSS选择器计算出节点的样式，创建另一个树 —- 渲染树。
3、布局渲染树（Layout of the render tree）: 从根节点递归调用，计算每一个元素的大小、位置等，给每个节点所应该出现在屏幕上的精确坐标。
4、绘制渲染树（Painting the render tree） : 遍历渲染树，每个节点将使用UI后端层来绘制。
主要的流程就是：构建一个dom树，页面要显示的各元素都会创建到这个dom树当中，每当一个新元素加入到这个dom树当中，浏览器便会通过css引擎查遍css样式表，找到符合该元素的样式规则应用到这个元素上。
注意了：css引擎查找样式表，对每条规则都按从右到左的顺序去匹配。
看如下规则：
|
1
|
#nav li {}
|
看起来很快，实际上很慢，尽管这让人有点费解#_#。
我们中的大多数人，尤其是那些从左到右阅读的人，可能猜想浏览器也是执行从左到右匹配规则的，因此会推测这条规则的开销并不高。
在脑海中，我们想象浏览器会像这样工作：找到唯一的ID为nav的元素，然后把这个样式应用到直系子元素的li元素上。
我们知道有一个ID为nav的元素，并且它只有几个Li子元素，所以这个CSS选择符应该相当高效。
事实上，CSS选择符是从右到左进行匹配的。了解这方面的知识后，我们知道这个之前看似高效地规则实际开销相当高，浏览器必须遍历页面上每个li元素并确定其父元素的id是否为nav。
|
1
|
*{}
|
额，这种方法我刚写CSS的也写过，殊不知这种效率是差到极点的做法，因为*通配符将匹配所有元素，所以浏览器必须去遍历每一个元素，这样的计算次数可能是上万次！
|
1
|
ul#nav{} ul.nav{}
|
在页面中一个指定的ID只能对应一个元素，所以没有必要添加额外的限定符，而且这会使它更低效。同时也不要用具体的标签限定类选择符，而是要根据实际的情况对类名进行扩展。例如把ul.nav改成.main_nav更好。
|
1
|
ul li li li .nav_item{}
|
对于这样的选择器，之前也写过，最后自己也数不过来有多少后代选择器了，何不用一个类来关联最后的标签元素，如.extra_navitem，这样只需要匹配class为extra_navitem的元素，效率明显提升了
对此，在CSS书写过程中，总结出如下性能提升的方案：
- 避免使用通配规则 如 *{} 计算次数惊人！只对需要用到的元素进行选择
- 尽量少的去对标签进行选择，而是用class 如：#nav li{},可以为li加上nav_item的类名，如下选择.nav_item{}
- 不要去用标签限定ID或者类选择符 如：ul#nav,应该简化为#nav
- 尽量少的去使用后代选择器，降低选择器的权重值 后代选择器的开销是最高的，尽量将选择器的深度降到最低，最高不要超过三层，更多的使用类来关联每一个标签元素
- 考虑继承 了解哪些属性是可以通过继承而来的，然后避免对这些属性重复指定规则
选用高效的选择符，可以减少页面的渲染时间，从而有效的提升用户体验（页面越快，用户当然越喜欢^_^）,你可以看一下CSS selectors Test，这个实验的重点是评估复杂选择符和简单选择符的开销。
也许当你想让渲染速度最高效时，你可能会给每个独立的标签配置一个ID，然后用这些ID写样式。那的确会超级快，也超级荒唐！这样的结果是语义极差，后期的维护难到了极点。
但说到底，CSS性能这东西对于小的项目来讲可能真的是微乎其微的东西，提升可能也不是很明显，但对于大型的项目肯定是有帮助的。而且一个好的CSS书写习惯和方式能够帮助我们更加严谨的要求自己。
--------------------------- 原文 -----------------------------