为什么很多国内公司不使用 jQuery 等开源 JS 框架（库），而选择自己开发 JavaScript 框架？
实在不明白其意义所在。难道jq的加载速度还值得抱怨吗？应该也不会是版权问题吧？
【的回答(172票)】:
折腾过 KISSY 类库，简单说几点：
1. 开发 KISSY 之前，淘宝使用的是 YUI2 类库。但从 2009 年开始，YUI2 在逐步退出历史舞台，YUI 团队的大部分精力都投入到 YUI3 的开发中去了。从当时的情况来看，YUI2 前途堪忧，YUI3 则还不够成熟，并且 YUI3 的定位（大而全的框架型类库）不适合淘宝的前台业务场景（以浏览型为主的展现页面）。
2. 我自己是力推
的。但由于历史原因，阿里系对 jQuery 的成见很深，认为其接口太灵活，不利于团队协作，以及其插件质量良莠不齐，社区不如 YUI 健壮。2008 年在淘宝前端内部争辩过 jQuery，可惜我没坚持，没推广成功。
3. 但当时不少新人都喜欢 jQuery 的 API 风格，jQuery 社区也发展得越来越好。我自己也是个铁杆 jQuery API fans. 因为前两点原因，2009 年在开发 KISSY Editor 时，底层虽然是基于 YUI2 的，但我逐步已经做了很多替换封装，实现了一个简易的杂糅了 YUI2 和 jQuery API 风格的底层类库，这就是 KISSY 的原型。
4. 接下来是技术驱动的一段时期，2010 年基于 KISSY core 写了 Switchable、Suggest 等在淘宝被大量使用的 UI 组件，一下来就推广开来了。（中间 YUI2 和 KISSY 并存了很长时间）
5. KISSY 进一步发展，得益于核心开发成员承玉的加盟。2011 年后，KISSY 从 KISS 的定位，逐步演化成了立足于淘宝、力争大而全、同时可定制的一个类库。承玉做的非常不错，还有龙藏的 Flash 组件等，以及仿 YUI3 Gallery 的组件贡献模式，这些让 KISSY 成为了适合淘宝业务的最佳类库。
上面说了这么多，总结下与楼主的问题相关的几点：
1. 选择什么类库，抑或自己开发，跟团队的技能倾向有关。如果雅虎和阿里没关系，或许阿里就不会这么雅虎味，或许也就不会对 jQuery 有成见，或许现在压根儿就没 KISSY 什么事。
2. 类库的选择离不开业务场景。如果淘宝不是浏览型为主的网站，而是个个页面都像 GMail 一样复杂，那也许淘宝选择的类库会是 ExtJS 或 Google Closure 或 YUI3 等等。其实淘宝的后台项目中，还真有不少是用 ExtJS 的。
3. 对于商业公司来说，类库的重点不是基础模块，而是业务模块。这里的业务模块包括淘宝的登录注册等模块，也包括 Switchable、Suggest 等泛业务模块（比如淘宝首页的搜索提示，看似是通用的，其实是跟淘宝的业务类型分不开的。YUI2 也有一个 Autocomplete 组件，但其庞大的体积根本不适应淘宝）。
4. 类库的选择，还跟整个业界的环境和团队决策者的眼光相关。比如从去年开始，前端社区越来越意识到了开放共荣的重要性，意识到了规范的重要性。CommonJS、AMD 等等，以及 NodeJS 的兴起，这一切变化，也在悄然改变着大家的抉择。这是我开发 SeaJS 的原因。如今，我们有了更好的、更偷懒、同时更灵活的选择和组合解决方案。
任何路都没什么错，关键是，要知道自己在哪。
【田乐的回答(14票)】:
代码用来解决实际问题，然后经过重构和更高的抽象形成框架。框架应该告诉你不要做什么，输出的是一种如何构建应用的价值理念。
功成名就的开源（js）框架主要是像prototype、jquery、mootools、underscore、backbone.js这样的有自己风格的产品。相比之下历史上出现的巨型以提供widget倾向的框架在口碑上就略逊一筹，如dojo、YUI、ext等等，他们也很成功，但是程序员员往往持有自己不同的看法，认为这种重量级的解决方案限制了他们的发挥。从某一个角度上来说这印证了框架要“告诉你不要做什么”的重要性，前面说的这些有风格的框架都做到了这一点，widget方案告诉你怎样做（因为组件已经提供好了）从长期来说并不讨好。
扯远了，回到这个话题。国内的团队写的偏widget的框架比较多，这很合理，因为它解决了团队协作问题，减少了团队内部重新发明轮子的危险。但是国内的开发者输出的核心库里面风格强烈的好像比较少，做来做去也就是在模块划分上有些不同。从理念上大部分的库都是工具库的集合，它和某一种编程泛型或者模式无关，内化的是对很多具体技术问题的解决方法。我个人觉得这更多的是自底向上的分析实现，而缺少自顶向下的设计。
从我的主观偏见回来。我输出授权宽松的开源框架是绝好的事情，我纠结于他们的质量是非常消极的。因为没有越来越多被输出到社区中的开源框架，也就没有出现更好的框架的社区环境。我们看到的这些名牌框架是明星程序员写的，他们碰巧在计算机科学和相应的社区比较发达的国家，这不是偶然。我们国家的社区正在向这个方向发展，我们看到有越来越多有自己『品味』的程序员输出自己的框架是非常积极的趋势。说不定下一个Jeremy Ashkenas就出现在我们这里呢。
闭门造车是缺乏交流的结果，所以我们不紧要看输出的框架有多少，还要看这些社区的经营。那么我觉得对于这个问题比较靠谱的一个答案就是：我国的开源社区运营，程序员对于开源社区的参与程度还严重的落后，这是很多团队自己造了很多方形的轮子的原因。
【yoyo的回答(9票)】:
也不能一遍概全吧，人人网有一些项目在使用jquery比如小站，朋友网底层则完全是jquery
之所以不使用jquery也是有原因的，举一个例子，比如jquery版本升级带来的问题，你很难保证这个库的升级一定是向下兼容，升级之后很可能带来一些意想不到的问题，但是不升级整个库，带来的问题就是无法使用新的特性，无法提高代码的效率等。
同时jquery没有做模块拆分，对于性能要求比较高的网站，一次加载整个库是没有必要的,无论是出于公司利益还是用户体验。所以很多公司会研发一些支持模块化拆分的js库。
【flamingtop的回答(7票)】:
提问者应该是专指js前端框架，所以基于nodejs的后端框架不在讨论之列，基于nodejs的后端框架和前端js框架没有可比性。
觉得大公司选择自下而上实现自己js框架的，原因是非技术大于技术，团队的主观需要超过了客观评估；强调自上而下是排除基于第三方基础库开发的所谓“自己开发”然后冠上自己公司名称的的框架，不在讨论之列。
实现一个js框架的难度比用后端语言（比如PHP）实现一个web框架要大得多，因为前端js框架必须处理跨平台的问题，自下而上实现一个js框架至少要处理好的问题是
隐藏（abstract away）多浏览器JS和DOM引擎的实现细节，为应用层代码统一调用接口
jQuery主要解决的就是这个问题，看过jQuery源代码的人都理解这不是件简单的事，难度主要还不是在于javascript语言本身，而是你需要对各类各版本浏览器的实现差异了如指掌，DOM实现，事件模型，甚至渲染方式。在这个方面，个人认为，重新发明轮子是非常不值得的，在企业开发的条件下，甚至是不可行的；
一些公司的js框架本质是实现了某组特定js或者DOM API的封装，从技术角度说更像是一个wrapper或者library，覆盖的广度离成熟的framework还是有距离的，不过那样确实可能是可行的。
另一些公司选择自己实现js框架（自下而上），更多是因为错误的评估，或者低估实现难度和复杂度，或者高估了团队的js和浏览器平台的底层知识的储备，觉得“可以做”；最终选择自己开发，有主观判断大于客观评估的因素。
现在的浏览器前端开发，如此多的优秀js框架和库，确实有绝对的必要自己闭门造车吗？我表示怀疑。
【郑海波的回答(5票)】:
我觉得. 产能过剩。 普遍国内的新库并无创新点(美其名曰微创新？)，对于类库构建者的经验提升当然是大有裨益的。为何不把有限的精力投入到成熟开源框架的贡献上？
【张辰的回答(1票)】:
无法满足公司业务需求公司拥有足够劳动力
【李陈的回答(5票)】:
首先个人觉得你的‘很多’用词有事偏颇，我倒觉得国内很多公司在用jQuery。至于你说的公司自己开发JS库，我也觉得这要看公司的规模，业余需求。一般有自身的JS库的在国内也仅有一些大公司才有。在这些公司里养着一帮前端，而这些前端很大部分水平都是经过层层筛选的，一来他们有能力，二来有时间，三来也能为公司吸引人才。种种原因，他们便有了自己的库。如果还要说，那就是程序员有反骨，不喜欢做一些没有技术含量的事。哈哈，个人愚见而已，一笑置之。
【Cat Chen的回答(0票)】:
NIH - Not Invented Here
【蒋又新的回答(3票)】:
这不算什么。还有自行开发的Key-Value数据库、分布式存储系统、HTTP服务器……稍大一点的公司都会有这些玩意的。
为什么它们会出现，大概有以下几点：
(1) 架构级的工程师需要证明自己的能力和价值（晋升需要，或者手痒）
(2) 自制轮子确实有些地方胜过标准轮子
(3) 公司足够大，能够支付自主开发的成本
以上三条中，头一条是原始推动力，后两条使事实能够成立。具体到jQuery这个例子。前端与业务逻辑的联系非常紧密，所以很容易找到一个“这更符合我们的需要”作为理由去重写一个前端的库（见(2)）。
【刘杨的回答(1票)】:
公司的框架，在没有达到JQuery的高度时，还是用JQuery吧，自己写的用起来爽，继任着就不爽了。
【mytharcher的回答(3票)】:
根据我写elf+js的经验，简单的说原因就这么几点：
别人的库用起来不爽（没有我需要的功能，或者API始终不符合理解习惯）；想把jQuery拆开用；自己的代码有了积累，不想放弃自己的劳动成果，作为给自己写代码这么些年的一个交代；写代码写自己的库是学习的一个必经过程。
【薛端阳的回答(8票)】:
说jQuery简单的人，根本没看过jQuery的代码，
同理，说xx简单的人也一样
无论在任何一家公司，首先要混口饭吃吧，你要混饭吃，就得好好干活，但是程序员都想偷懒啊，有现成的用，干嘛不用现成的？所以从打工者的角度来说，用jQuery之类现成的东西给老板自然是最好的，但是这里还涉及到一个美工的协调问题，很多直接拿来的控件，离美工MM设计出来的页面还是一定量的区别的，这里面就涉及到HTML结构的问题了，有些好改，有些不好改，
其次基于Web引用内容浏览的网页，其开发量主要在javascript的UI widget上，从打工者的角度来说，不干活或者少干活就拿钱当然是他们愿意的，但是从老板的角度来说，我花了钱请你们来打工，你小子天天不干活，就晓得抄，那不如找个高中毕业的好了，钱还要的少，活做的和你一样，这样矛盾就产生了。
还有一个很重要的是，无论在什么大公司啊，你总的要加薪把？要升职把，如何升职呢？你总得提高自己的技术水平吧，天天抄别人的东西，不用心学习如何内在实现如何体现自己的水平呢？ok，你才对了，腾讯就是最好的例子，无论出什么东西，我都拿来抄一遍，大家都是程序员，更别说有源代码的js，更好抄了，凭良心说，直接用jQuery和，抄一个jQuery，完全是两种不同的提高，就像小时候抄作业一样，用别人的原理，配合自己用自己的方式实现一个，毕竟还是要经过大脑的，不可能不提高自己水平吧，而且自己做的东西，名字就不一样，谁知道你里面有多少创新，多少抄袭，于是乎，领导看了之后就觉得小x，现在牛逼了吗，自己做了一个jQ吗，好，加薪吧，后面你就懂的。
这个是中国式的悲哀，追着别人的屁股，不是个傻瓜的人都会，问题是如何站在巨人的肩膀上，再迈一步呢？
为了加薪，没有创新！
【鄢敏华的回答(1票)】:
1. 业务的组件驱动，例如：Yahoo、阿里、百度
例如：阿里派的KISSY和百度的七巧板估计也是和自己的产品线（百度知道、百度百科）有关系；
2. 为了增加在开发者队伍中的影响力，这种公司一般推出都是重量级些的方案，例如：微软、Adobe、Google
Javascript的影响力越来越大，大公司自然不肯错过
3. 其它一些不入流的开源框架，大多为证明自己的技术价值，做技术牛人，这种一般是以借鉴、模仿和重新封装为主
4. Jquery也不是万金油，比如下面的要求最很难做到：
类似OO的写法（C#、Java的开发人员一般会这么要求）Editor这类规模和要求比较高的控件，YUI2 Editor那么久浏览器兼容性都有问题代码的可读性、可维护性（很多开发人员把Jquery的选择器和连接器用得太猛了），很难规范Jquery的插件选择比较多，且质量良莠不齐，选择和测试成本也是很高的
【Yinkan Li的回答(1票)】:
一开始JQ够用了，JQ UI 也不错。但是直到有一天，需求太过蛋疼，当有一天把业务逻辑和控件绑定之后，你会发现，JQ只能被用来操作DOM，这时候JQ就显得鸡肋了。这时候，差不多是应该要自己搞一套控件库了，就自己用，高度复用，一些业务逻辑也需要做到控件里去。
【知乎用户的回答(1票)】:
第一时间想到了这张图：
【刘大朋的回答(0票)】:
一：用第三方的有个迭代更新的问题，像微软那样，三天两头出点新东西新框架的。。。我们就得一直在后面追，自己去实现就不一样了，很大一部分是业务驱动的，所以可控度会更好。
二：公司自己开发的，其实。。。都不怎么通用。。。至少大部分是，同样是基于他们的业务模型的
【ChinarenWei的回答(0票)】:
对于没有什么根本性创新的自己“创作的” lib，称作抄袭不为过，不过公司内部用不开源也没啥问题。
【王允的回答(0票)】:
开发自己公司的库，主要是用起来方便得心应手，另一方面是适应自身发展的需求，不必要过多的引入一些不必要的累赘影响性能！我觉得另外还有习惯问题！
【郑辉辉的回答(0票)】:
显得自己牛逼
【孙博的回答(0票)】:
因为淘宝腾讯出来的时候，还没有jquery，等jquery流行起来，已经搞了一大滩，换也不好换了。
jQuery在2006年1月由美国人在纽约的barcamp发布，吸引了来自世界各地的众多高手加入，现在由Dave Methvin率领团队进行开发。
【丁雷的回答(0票)】:
看看一个流行的框架的发展历程：
1. 足够轻巧；
2. 足够灵活；
3. 足够丰富；
如果能够基本解决这些问题，它就能火起来...
【dong yan的回答(0票)】:
框架其实不是只是一个jQuery就可以的，他是一个生态系统，这样才应该叫框架。
现在的大家说的框架基本都是jQuery、YUI等，其实他们只是基础而ext、sencha这样的才叫框架。
每个公司都要开发自己的框架一般是从自身的需求出发，而不是为了创新。
【李寒的回答(0票)】:
造轮子的快感
【张旎耋的回答(0票)】:
个人感觉JQuery不是很好.不便于维护
基础不好的用它写的代码可读性更差!~
【张散集的回答(0票)】:
个人觉得JQuery挺好。如果楼主需要的话，我投一票JQuery。但抛开文化、环境、历史等等问题，就纯技术层面，我提倡“面向对象的设计，函数式的编程”，用什么库和框架真的重要的吗？
【郁辰磊的回答(6票)】:
用jQuery老板给前端的工资就少，觉得糊弄糊弄就能弄出来，就这么简单，中国特色
【季楠的回答(3票)】:
因为jQ太过简单...一个没有程序基础的人看两天视频也可以写出像样的东西，虽然可拓展性和效率比较低下，但是老板不觉得这是这个人写的问题，老板会认为jQ就是一个“简单+效率低下”的框架，进而给用jQ的工程师较少的工资...
馆藏&61179
TA的推荐TA的最新馆藏找到你梦想
关闭背景特效
最新插件 Latest jQuery plugin
&Advertisement
日期和时间
丰富的输入
日期和时间
最新代码 Latest code
常用代码 Common code解决jquery版本冲突的有效方法
投稿：shichen2014
字体：[ ] 类型：转载 时间：
这篇文章主要介绍了解决jquery版本冲突的有效方法,对于web设计的兼容性调试很有借鉴价值,需要的朋友可以参考下
用过jQuery的朋友都知道jQuery不同版本会引发冲突，本文就此问题提出有效的解决方案如下：
案例：解决jQuery1.3.2和1.4.2的冲突。（本例已测试通过！）
第一步：在1.4.2的源代码的最后加上一句 ：
var $j4 = jQuery.noConflict(true);
之所以在源码这里加，而不是像大多数文章提的在要用到的时候加，这是因为很多基于1.4.2的插件都要加，在这里加可以避免过多插件加这句代码导致重复。这一句是将1.4.2的jQuery和$的引用权限全部放弃。也就是基于1.4.2的插件不能再用jQuery和$了。同时给予$j4的新的命名空间，注意它是window的属性。看1.4.2的源代码会发现它其实也就执行了这两句：
window.$=_$;
window.jQuery=_jQ
道理同window.$=_temp$（返还命名空间）只是命名不同而已。
第二步：在基于1.4.2的框架的所有插件的头部加上以下代码：
var _temp$ = window.$,_tempjQuery = window.jQ
将jQuery1.3.2的$和jQuery放到临时的变量空间上：
window.$ = $j4;
这句和下面的那句都是为了给中间的代码能够正确使用jQuery和$用的。后面的$j4是赋予他们正确的引用。
window.jQuery = $j4;
之所以要先放临时变量存储，有三点必须这样做的理由：
①.我们不希望改动大量的jQuery插件源代码，最好是不动，即使改的话，尽量改的少。而在头部尾部加改动代码，中间的原始代码不动也是不错的一种方式。
②.因为1.4.2的已经放弃了jQuery和$的控制权，但是已有的插件代码又用了他们来做引用，因为插件不可能预知冲突，即使有冲突他人开发的插件也一定要用$或者jQuery引用，除非它不是jQuery下的插件。
③.为了防止插件里面直接用window.$和window.jQuery进行引用从而导致引用到1.3.2的jQuery和$，虽然这种情况比较少，但是以防万一。
中间的原始代码不动，尾部加以下代码：
window.$ = _temp$;//将$的引用权限返还给jQuery1.3.
window.jQuery = _tempjQ//将jQuery的引用权限返还给jQuery1.3.
第三步：以后要用基于jQuery1.4.2的选取函数就只能用$j4(element)了。
总结：到目前为止可行方案：jQuery1.4.2完全放弃$和jQuery的控制权限。1.3.2放弃$的控制权限但不放弃jQuery的权限，其实jQuery也可放弃，只不过要给个别名$j3。prototype最好放在jQuery1.3.2后面，它获得$的控制权限。只是以后要用jQuery1.4.2就必须用$j4来引用了。但这样即使有再多的jQuery框架版本冲突问题，也全部解决掉了。假如来了个1.2的jQuery怎么办，参照（2）的执行步骤，只不过第一步改为：
var $j2 = jQuery.noConflict(true);
第三步用$j2(element)罢了。道理都是相同的。
相信本文所述对大家的jQuery程序设计有一定的借鉴价值。
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具jQuery&如何写插件&-&第一步
最近在看HTML5 CSS3，上面不少提到solve
fallbacks，所以写JS的地方不少。嗯，常用jQuery但是还没有动手写过插件，这次学习尝试下。
这篇文章引自iteye，是老帖子了~~ 国外优秀的文也有，今天就看这位仁兄的吧，写的很到位啊,通俗易懂。
jQuery插件的开发包括两种：
一种是类级别的插件开发，即给jQuery添加新的全局函数，相当于给jQuery类本身添加方法。jQuery的全局函数就是属于jQuery命名空间的函数，另一种是对象级别的插件开发，即给jQuery对象添加方法。下面就两种函数的开发做详细的说明。
1、类级别的插件开发
类级别的插件开发最直接的理解就是给jQuery类添加类方法，可以理解为添加静态方法。典型的例子就是$.AJAX()这个函数，将函数定义于jQuery的命名空间中。关于类级别的插件开发可以采用如下几种形式进行扩展：
1.1 添加一个新的全局函数
添加一个全局函数，我们只需如下定义：
jQuery.foo = function()
alert('This is a test. This is only a
1.2 增加多个全局函数
添加多个全局函数，可采用如下定义：
Java代码& 收藏代码
jQuery.foo = function()
alert('This is a test. This is only a
jQuery.bar = function(param)
alert('This function takes a parameter, which is "' + param +
调用时和一个函数的一样的:jQuery.foo();jQuery.bar();或者$.foo();$.bar('bar');
1.3 使用jQuery.extend(object);　
jQuery.extend({&&&&&
function()
alert('This is a test. This is only a
test.');&&&&&
function(param)
alert('This function takes a parameter, which is "' + param
+'".');&&&&&
1.4 使用命名空间
虽然在jQuery命名空间中，我们禁止使用了大量的javaScript函数名和变量名。但是仍然不可避免某些函数或变量名将于其他jQuery插件冲突，因此我们习惯将一些方法封装到另一个自定义的命名空间。
jQuery.myPlugin =
{&&&&&&&&&
&foo:function()
{&&&&&&&&&
alert('This is a test. This is only a
test.');&&&&&&&&&
},&&&&&&&&&
bar:function(param)
{&&&&&&&&&
alert('This function takes a parameter, which is "' + param +
采用命名空间的函数仍然是全局函数，调用时采用的方法：&
$.myPlugin.foo();&&&&&&&&
$.myPlugin.bar('baz');
通过这个技巧（使用独立的插件名），我们可以避免命名空间内函数的冲突。
2、对象级别的插件开发
对象级别的插件开发需要如下的两种形式：、
(function($){&&&&
$.fn.extend({&&&&
pluginName:function(opt,callback){&&&&
&&&&&&&&&&&&&
// Our plugin implementation code goes
here.&&&&&&
})(jQuery);&&&
(function($)
$.fn.pluginName = function()
// Our plugin implementation code goes
})(jQuery);&&&&&
上面定义了一个jQuery函数,形参是$，函数定义完成之后,把jQuery这个实参传递进去.立即调用执行。这样的好处是,我们在写jQuery插件时,也可以使用$这个别名,而不会与prototype引起冲突.
2.1 在JQuery名称空间下申明一个名字
这是一个单一插件的脚本。如果你的脚本中包含多个插件，或者互逆的插件（例如： $.fn.doSomething() 和
$.fn.undoSomething()），那么你需要声明多个函数名字。但是，通常当我们编写一个插件时，力求仅使用一个名字来包含它的所有内容。我们的示例插件命名为“highlight“&&&
$.fn.hilight = function()
&& // Our plugin implementation
我们的插件通过这样被调用：&
$('#myDiv').hilight();&&&&
但是如果我们需要分解我们的实现代码为多个函数该怎么办？有很多原因：设计上的需要；这样做更容易或更易读的实现；而且这样更符合面向对象。
这真是一个麻烦事，把功能实现分解成多个函数而不增加多余的命名空间。出于认识到和利用函数是javascript中最基本的类对象，我们可以这样做。就像其他对象一样，函数可以被指定为属性。因此我们已经声明“hilight”为jQuery的属性对象，任何其他的属性或者函数我们需要暴露出来的，都可以在"hilight"
函数中被声明属性。稍后继续。
2.2 接受options参数以控制插件的行为
让我们为我们的插件添加功能指定前景色和背景色的功能。我们也许会让选项像一个options对象传递给插件函数。例如：&&
definition&
$.fn.hilight =
function(options) {&
defaults = {&
foreground: 'red',&
background: 'yellow'&
& // Extend
our default options with those
provided.&
& var opts
= $.extend(defaults, options);&
plugin implementation code goes
我们的插件可以这样被调用：
$('#myDiv').hilight({&
& foreground: 'blue'&
2.3 暴露插件的默认设置
我们应该对上面代码的一种改进是暴露插件的默认设置。这对于让插件的使用者更容易用较少的代码覆盖和修改插件。接下来我们开始利用函数对象。&&&&
// plugin definition&
$.fn.hilight =
function(options) {&
& // Extend
our default options with those
provided.&
that the first arg to extend is an empty object
is to keep from overriding our "defaults"
& var opts
= $.extend({}, $.fn.hilight.defaults,
options);&
plugin implementation code goes
// plugin defaults - added
as a property on our plugin
$.fn.hilight.defaults =
foreground: 'red',&
background: 'yellow'&
现在使用者可以包含像这样的一行在他们的脚本里：
//这个只需要调用一次，且不一定要在ready块中调用
$.fn.hilight.defaults.foreground = 'blue';&
接下来我们可以像这样使用插件的方法，结果它设置蓝色的前景色：
$('#myDiv').hilight();&
如你所见，我们允许使用者写一行代码在插件的默认前景色。而且使用者仍然在需要的时候可以有选择的覆盖这些新的默认值：
// 覆盖插件缺省的背景颜色
$.fn.hilight.defaults.foreground = 'blue';
// 使用一个新的缺省设置调用插件
$('.hilightDiv').hilight();
// 通过传递配置参数给插件方法来覆盖缺省设置
$('#green').hilight({
& foreground: 'green'
PS:威廉王子结婚~，咱这小人物忙个不停，写的东西就暂停了~~ 呵呵，今天继续
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。