企业官网建设流程全解析

做前端这些年，jQuery 的“杂项方法”一直是我觉得最被低估的一块。大家一提到 jQuery，第一反应是$(document).ready、动画、AJAX、选择器，好像这套库的全部价值就这些。但实际写业务代码、维护老项目、甚至在新项目里借鉴它的一些思路时，杂项方法反而成了我敲得最频繁的东西——$.each、$.extend、$.inArray、$.trim、$.param，每一个单拎出来都很不起眼，组合起来却几乎撑起了日常脚本的半边天。这篇文章我不打算面面俱到地把每个方法都抄一遍官方文档，而是把我这些年实际用下来、觉得值得讲透的部分拆开聊：哪些方法容易用错、哪些场景有替代方案、哪些坑是文档不会告诉你的。适合刚接触 jQuery 但已经能写简单交互的同学，也适合那些明明用了好几年却始终没留意这些工具函数的老手。

1. 杂项方法到底是什么，为什么值得单独拎出来讲

1.1 先给“杂项”正个名

jQuery 官方文档里有个分类叫 “Utilities”，中文常被翻译成“工具方法”或者“杂项方法”。这批方法有一个共同特征：它们不依赖 DOM 操作，也不直接绑定到某个元素集合上，大部分挂在jQuery这个全局对象上，形如$.xxx()。换句话说，它们是纯 JS 层面的通用工具，跟你选中了几个元素、要不要操作页面结构基本没关系。

这一点恰恰是它们容易被忽略的原因。刚接触 jQuery 的人，脑子里全是“选元素、改样式、绑事件”这个套路，很少会停下来想：如果我想把一个数组里的每个值都翻个倍、把一段字符串两头的空格去掉、把用户填的表单拼成查询串，jQuery 能帮上什么忙？实际上这些场景用的正是杂项方法。它们看起来不酷，但写业务逻辑时几乎每天都要用。

1.2 哪些方法被归进了杂项

为了方便后面展开，我先按用途把常见杂项方法分个组，后文会挑重点逐个展开：

• 数组与对象遍历类：$.each、$.map、$.grep、$.inArray、$.makeArray、$.merge、$.uniqueSort
• 类型判断类：$.type、$.isArray、$.isFunction、$.isNumeric、$.isEmptyObject、$.isPlainObject
• 对象与数据处理类：$.extend、$.param、$.trim、$.parseJSON（老版本）、$.now
• DOM 关系判断类：$.contains
• 函数辅助类：$.proxy、$.noop

这些方法里有一部分在原生 ES5/ES6 里已经有了对应实现，比如Array.prototype.forEach、Array.prototype.map、Object.keys、String.prototype.trim。但这不代表杂项方法就失去意义——在跨浏览器兼容需求仍然存在的老项目里，在需要统一处理类数组对象和 NodeList 的场景里，$.each和$.map的健壮性依然是很多原生写法比不上的。

2. 数组与对象处理：each、map、grep 的适用边界

2.1$.each()与$().each()的本质区别

这是我在实际开发中被问过最多的问题：$.each和$().each到底有什么区别？一个最直观的区分方式是看调用形式：$.each(array, fn)是静态工具，传什么就遍历什么，传数组遍历数组，传对象遍历对象；$("li").each(fn)是实例方法，它内部拿到的是当前 jQuery 对象里那一串 DOM 元素，本质上是针对元素集合的便捷封装。

真正值得留心的是$.each对对象和数组的“一视同仁”。普通数组用 for 循环遍历没问题，但如果你拿到的是一个类数组对象，比如arguments、getElementsByTagName返回的 HTMLCollection，直接用Array.prototype.forEach往往要先做一次转换，而$.each直接就能处理：

$.each(arguments, function(index, value) { console.log(index, value); }); $.each({ name: "张三", age: 30 }, function(key, value) { console.log(key, value); });

它内部会根据obj.length是否存在来决定走数组式循环还是键值对循环，这个自动判断帮我省去了大量“先判断是不是数组”的样板代码。

有一点必须提醒：$.each里的回调如果返回false，会立即终止遍历。这个行为在新手代码里经常被误用——有人想在回调里“跳过当前项”就写return false，结果整个循环全停了。跳过一项应该写return true（或者什么都不返回，只要不是 false），终止整个循环才用return false。我第一次接手别人的代码时，就见过因为这种误用导致列表只渲染了一半的 bug，排查的时候很绕。

2.2$.map()与$.grep()：转换与过滤的分工

$.map(array, fn)做的事情是“映射”，把每个元素经过回调处理后收集成一个新数组返回。这里有个和原生Array.prototype.map不太一样的地方：jQuery 版的$.map如果回调返回null或undefined，对应位置会被直接删掉，而不是像原生 map 那样保留一个空洞。这个特性有时候是好消息，有时候是坏消息。

好消息是，你想“一边转换一边过滤”的时候特别顺写：

var nums = [1, 2, 3, 4, 5]; var result = $.map(nums, function(n) { if (n % 2 === 0) { return n * 10; } // 不返回，奇数项自动被剔除 }); // result: [20, 40]

坏消息是，如果你按照原生 map 的习惯，以为回调里不 return 会得到一个undefined占位，那结果长度会跟你预期不一致。这个坑我踩过一次，后来总结出的规律是：纯粹的“变换”用$.map，但要在回调理清楚“不返回就删除”这层语义；如果需要严格保长，建议先$.map再$.grep，或者直接改用原生Array.prototype.map。

$.grep(array, fn, invert)是专门做过滤的，第三个参数可以控制是否反向筛选——传true时返回“不满足条件”的元素。这个参数我用得不多，但偶尔写“排除列表”时确实方便，可以省掉临时变量。

2.3$.inArray()的使用细节

$.inArray(value, array)返回的是找到的下标，找不到返回-1。用法本身很简单，但有个经典的“新手陷阱”：

if ($.inArray("苹果", list) !== -1) { // 存在 }

问题在于，很多刚从别的语言转过来的人习惯把判断写成if ($.inArray(value, list))，这在英语语境下（比如 PHP 的in_array）是对的，但在 jQuery 里，下标为 0 时会被当成 false。我见过因为这个判断导致第一个元素永远“不存在”的案例，排查了半天才发现是布尔判断的问题。所以写判断宁可啰嗦一点，也要带上!== -1或者用>= 0。

另外，$.inArray内部用的是严格相等===，不会做类型转换，"1"和数字1是两个东西，做表单值匹配时要注意源头数据的类型。

2.4$.makeArray()与$.uniqueSort()

$.makeArray(obj)可以把类数组对象转成真正的数组。以前转arguments最常用的写法就是Array.prototype.slice.call(arguments)，在老浏览器上偶尔会有性能问题，$.makeArray的语义更直白，而且对 null、undefined 也做了容错——传进去会得到空数组，至少不会直接抛错。

$.uniqueSort()现在的名字叫的是 sort，以前叫$.unique()，专门用来给 DOM 元素数组去重并排序。注意它只对 DOM 元素有意义，对普通字符串数组、数字数组使用不会有预期的去重效果。如果你要给普通数组去重，还是用new Set()或者自己写循环更靠谱。这个适用范围的区别，文档里写得不显眼，但用错场景的人真不少。

3. 类型判断那一摊子事：type、isArray、isNumeric 背后的门道

3.1$.type()比typeof强在哪

typeof的短板大家都熟：typeof null是"object"，typeof []也是"object"，遇到正则、日期这些内置对象时更是分不清。$.type()用内部Object.prototype.toString配合正则解析，能给出更精细的结果：

$.type(null); // "null" $.type([]); // "array" $.type(new Date()); // "date" $.type(/abc/); // "regexp" $.type(function() {}); // "function" $.type(undefined); // "undefined"

说实话，这个工具在原生 ES6+ 环境下已经可以被Array.isArray、Object.prototype.toString直接替代，但在兼容老浏览器的项目里，$.type依然是写类型分支判断最省事的一招。我自己写代码的习惯是：判断是不是数组用$.isArray或原生Array.isArray，判断一个对象是“什么特殊类型”时才用$.type。

这里顺便提一个和$.type互补的方法$.isPlainObject()，它判断的是“这个对象是不是纯粹由字面量或new Object()创建出来的普通对象”。这个判断在传参校验里特别有用——很多时候我要区分“用户手动构造的对象”和“类的实例、DOM 节点、window 这类特殊对象”，$.isPlainObject可以直接帮我把后几种排除掉。

3.2$.isNumeric()的边界情况

$.isNumeric(value)这个方法名看起来很直白，判断是不是数字，但它的实际行为比字面意思宽不少。它内部做的是把传入值转成数字，再判断转换结果是不是有限数。所以：

$.isNumeric(123); // true $.isNumeric("123"); // true，字符串数字也算 $.isNumeric("0xAF"); // true，十六进制字符串也能解析 $.isNumeric(""); // false $.isNumeric(false); // false $.isNumeric(null); // false

我踩过的一个坑是：用$.isNumeric(input.val())判断输入框内容是不是数字时，发现负数、小数、带空格的情况表现都正常，但如果输入框是空的，""返回 false，这块没问题；真正容易出问题的是用户输入了科学计数法或者像"1e3"这种，$.isNumeric("1e3")是 true。做金额校验时如果没留意，会被这种输入带偏。另外一个暗坑是$.isNumeric([1])、$.isNumeric(new Number(1))结果都是 true，因为这些都能成功转成数字。文档不会把每个边界都列给你，批量处理数据前最好用几组脏数据实测一下。

3.3$.isEmptyObject()的真实场景

$.isEmptyObject({})判断对象是否没有自身可枚举属性。有人会问：这不就是Object.keys(obj).length === 0吗？大部分场景确实等价，但$.isEmptyObject额外处理了toString这类不能被 for-in 枚举的属性，并且对节点对象、window 对象的行为做了特殊修正。在老项目中写“当前对象是否为空配置”时，直接用这个方法最稳。

另外一个常用搭配是$.isFunction()。用它判断回调参数是否传了函数，比typeof fn === "function"多一层跨窗口（iframe）的容错——不同 window 之间函数原型不同，typeof不会出错但instanceof Function会，$.isFunction走的是$.type的路径，在这类场景下更稳。以前做多 iframe 的入口脚本时，这个差异是真实存在过的。

4.$.extend()：对象合并的利器与深坑

4.1 深拷贝与浅拷贝，一个参数之差

$.extend(target, source1, source2, ...)把后面的对象依次合并到第一个对象上。如果第一个参数传入true，就会变成深拷贝模式：

var a = { name: "张三", info: { age: 30, city: "北京" } }; var b = {}; $.extend(true, b, a); b.info.age = 31; console.log(a.info.age); // 30，深拷贝后互不影响

浅拷贝模式下，b.info和a.info指向同一个对象，改其中一个另一个也会变。这个区别我讲过很多次，但每次还是要提醒：业务里凡是把配置对象做备份、传给后端的逻辑，一律用深拷贝，不然改来改去改到源对象上，排查半天都不知道哪来的副作用。

$.extend也是经典的 options 默认值合并方案。写插件时最常用的套路是：

function createWidget(options) { var settings = $.extend({}, defaultOptions, options); // settings 就是合并后的最终配置 }

把空对象放第一个，既不改动 defaultOptions，也不改动用户传入的 options，避免污染默认配置让后续调用出问题。这个习惯比直接往默认对象里塞值要安全得多。

4.2 必踩的坑

第一个坑是深拷贝在遇到循环引用时会爆栈。比如a.self = a;这样的结构，$.extend(true, {}, a)会无限递归下去，最终报栈溢出。实际业务中很少构造循环引用，但解析一些 JSON 图结构数据时，对象互相指向的情况还是存在，这时候要提前判断，别让数据把页面卡死。

第二个坑是深拷贝对函数和正则的处理。$.extend(true)不会递归函数，函数是引用直接拷贝的，这是符合预期的；但正则对象的处理在不同版本里有过差异，如果你要拷贝的对象里带着 RegExp，建议单独写处理逻辑，别完全依赖 deep extend。

第三个坑是$.extend会改变第一个参数对象本身。有时候我只是想生成一份合并后的副本，结果一不留神把某个源头对象给改了。所以再次强调那个空对象占位习惯，这个习惯能挡掉大部分这类问题。

5. 工具函数里的扫地僧：param、noop、trim、contains

5.1$.param()：把对象变成查询字符串

$.param(obj)做的事是把对象序列化成key=value&key2=value2格式的字符串。以前做 AJAX GET 请求拼接参数时，手写字符串拼到崩溃，后来发现其实一行就能搞定：

var params = { name: "张三", tags: ["前端", "jQuery"], age: 30 }; $.param(params); // "name=%E5%BC%A0%E4%B8%89&tags%5B%5D=%E5%89%8D%E7%AB%AF&tags%5B%5D=jQuery&age=30"

它自动处理里 URL 编码，数组会生成带[]后缀的键。这个序列化规则和后端常见的解析方式是对得上的，所以拿它做表单多字段提交相当省心。如果用的是$.ajax，直接传 data 对象也是一样的效果，内部走的就是$.param。

不过$.param对嵌套对象的序列化比较扁平，比如{ user: { name: "张三" } }会变成user%5Bname%5D=...，也就是方括号语法。大部分后端框架能解析这种格式，但也有少数接口只认简单键值对，对接前最好先确认一下对方协议。

5.2$.noop()：空函数也讲究

$.noop()返回一个什么都不做的函数。很多人不理解一个空函数有什么好封装的，但实战里它太常用了。最典型的场景是给回调参数设置默认值：插件里写options.onComplete = options.onComplete || $.noop;之后，后续就可以放心直接调用options.onComplete()而不用每次判断是否存在了。还有做 A/B 测试开关时，把“不启用”分支的回调直接设为$.noop，代码结构能保持统一。

5.3$.trim()：老项目里的顺手工具

$.trim(str)去掉字符串首尾空白。现在原生String.prototype.trim已经全面普及，这个方法的必要性大大降低，但有两种情况我还是会用它：一是代码风格统一、不想在个别老文件里混用新旧 API；二是在低于 IE9 的兼容修复场景（现在基本碰不到）。写原生.trim()遇到null、undefined会直接报错，这一点上$.trim(null)会返回空字符串而不是抛错，容错性更好，所以批量清洗数据时反而比原生写法更省事。

5.4$.contains()：判断 DOM 的包含关系

$.contains(parent, child)返回布尔值，判断一个节点是不是另一个节点的后代。这个看起来小众，但做下拉菜单“点击外部关闭”的时候非常有用——我判断点击目标是否在菜单容器内，直接$.contains(menu, target)或者menu === target一起判断，比一层层parentNode往上跑干净得多。

还有一个容易混淆的地方：$.contains只判断 DOM 节点关系，不判断两个 jQuery 对象，使用时需要传原生节点，用$el[0]取出来再传进去。

6.$.proxy()：绑定上下文的正确姿势

6.1 它到底解决了什么问题

$.proxy(fn, context)返回一个新函数，这个函数无论被谁调用，内部的this都指向 context。说直白点，它就是把函数和对象“绑死”的胶水。

最常见的场景是事件回调。比如有个对象：

var widget = { name: "计数器", init: function() { $("#btn").on("click", function() { this.name; // 这里的 this 是按钮 DOM，不是 widget }); } };

如果我想在点击回调里访问widget.name，传统写法是var self = this;存一下，或者用箭头函数，或者用$.proxy。$.proxy的好处是语义清晰：$("#btn").on("click", $.proxy(function() { console.log(this.name); }, this));。在箭头函数普及之前，这是 jQuery 插件代码里最常见的绑定方式之一，至今在老代码里看到$.proxy也非常正常。

6.2 什么时候要用，什么时候别用

需要留意的是，$.proxy的绑定是永久的。如果你做一个可复用的回调函数，在不同元素上都绑这个函数但 context 不同，千万注意别互相覆盖。另外在解绑事件时，$.proxy出来的新函数和原函数不是同一个引用，所以绑定和解绑必须用同一个$.proxy返回的函数，否则off()解不掉。我自己习惯的做法是先把代理函数存成变量：

var handler = $.proxy(this._onClick, this); $("#btn").on("click", handler); // 后面解绑 $("#btn").off("click", handler);

现在写新代码，我更多是用箭头函数替代$.proxy，但读老项目时还是得认得出这套写法，别看到$.proxy一头雾水。

7. 常见坑排查速查表与实操心得

7.1 高频问题速查

我把这些年遇到比较典型的杂项方法问题整理成一个表，方便以后遇到类似情况直接对照：

7.2 几条实操心得

写到这里，我想把个人经验里最值的几条心得收个尾。

第一，杂项方法不是只是老古董的遗产。即使现在原生 API 已经很强大，$.extend的深拷贝、$.isPlainObject的语义、$.param的序列化规则，在今天写工具函数时仍然有参考价值。我在新项目里写自己的deepClone、isPlainObject时，参考的框架逻辑很多就是从 jQuery 里演化来的。

第二，读库源码是提升调试能力的好路径。$.type的实现只有几行，$.extend的核心循环也不复杂。某次我排查线上问题时卡了很久，最后就是翻开 jQuery 源码，顺着$.each的具体分支逻辑才找到根因。源码比文档更能回答“为什么”。

第三，用之前先确认数据形状。杂项方法大多容错性不错，但容错不等于正确。处理用户输入或接口返回的数据前，先打印一次$.type(data)，看清它是数组、字符串还是类数组对象，再决定用哪个方法。这一步能省下后面大量的console.log调试时间。

最后想说，做技术排查时别急着给 jQuery 判死刑。这套库虽然时代感强了些，但它沉淀下来的工具函数设计，放到现在依然是很好的参考教材。理解这些方法背后的边界和取舍，远比单纯背 API 列表有价值。