★ FEATURED ARTICLE 写这份总结的念头是某天下午临时起的。我翻了一遍自己收藏夹里那些“再看一遍”的链接、历史项目里的老代码、还有评论区里读者问过的问题发现JavaScript这个技术点确实庞杂判断数据类型有四种以上写法函数this能在三个环节被改掉事件从冒泡到捕获能绕晕人run时报错在浏览器里显示得比编译器难看多了。更重要的是我发现很多问题不是“不会写”而是“没想清楚为什么”。所以这份JavaScript总结我不想写成一本语法手册而是想把那些高频接触、容易踩坑、能直接用起来的知识点按照一个前端老兵的实际工作经验重新过一遍。这篇内容适合两类人一类是刚把JS基础语法啃完、正卡在“能看懂但不会用”阶段的开发者另一类是写过不少页面、但遇到类型判断、浮点精度、跨端调用、性能优化这类专项问题时习惯性去搜索引擎翻答案的同行。我会尽量把每一步用什么、为什么这么用、踩过什么坑都讲明白读完可以直接拿去用。1. 整体设计思路不要说“总结”就说“重建”1.1 为什么需要一份会被反复推翻的总结JavaScript有个特点它和Java、C#这类语言不一样语言规范的更新节奏快运行环境又分裂导致“标准做法”经常变。三年前你写var、用parseInt截掉小数尾数那时候没毛病今天团队来了一位较真的新人打开你的代码看到一个 null可能就要拉你讨论半小时。所以做JavaScript总结这件事核心不是把API背一遍而是建立一套能随时更新的知识框架。我给自己的方法论是每一个知识点都要回答三个问题——它解决什么问题在不同环境浏览器版本、Node版本、WebView版本下行为有没有差别有没有更现代的替代方案。这三点想清楚了写出来的代码才有生命力。这套总结方法同样适用于团队内部带新人。我发现如果把知识点按“语言核心、浏览器能力、跨端协作、性能与排错”四层拆开新人的上手速度会明显加快因为每一层的排错逻辑是独立的语言核心层错了说明基础不牢浏览器能力层错了大概率是兼容性跨端协作层错了要去看桥接协议性能与排错层错了绝大多数是执行时机或者事件循环被阻塞。1.2 知识地图怎么搭这份总结的地图长这样先解决语言本身的高频细节——数据类型判断、函数、事件然后解决业务场景里的对应实现——保留小数、Canvas画图、日历组件再往外一层是跨端与兼容问题——OC和JS互调、框架库的跨浏览器兼容方案最后是运行时错误与高负载脚本的处理。这样由内到外正好对应开发者在真实项目里遇到问题的顺序。比如你写FullCalendar时发现日期显示错位不会去翻JS语言规范而是先看时区、再看数据类型传参。如果你在脑子里先把“语言核心”和“业务组件”分层排查路径就会非常清晰。2. 核心语言细节类型判断、函数与事件的实际取舍2.1 判断数据类型的几种方法别再说typeof就完事了提到JavaScript判断数据类型很多人的第一反应是typeof。typeof确实简单方便但它的BDD断言之于动态语言的脆弱性在二进制的边界上暴露得很彻底typeof null返回objecttypeof []返回objecttypeof new Date()还是object。这不是bug是语言历史遗留但如果你把它当成唯一的判断工具代码迟早会在某个隐藏的null值上炸掉。我现在判断类型的优先级是这样的基本类型优先用typeof但要加上 undefined来区分未声明变量对象类型数组、日期、正则等优先用Object.prototype.toString.call——它返回的是[object Array]这样的精确标签虽然写法长了一点但准确性和跨环境一致性都很好。function getType(value) { if (value null) return null; if (typeof value ! object) return typeof value; const tag Object.prototype.toString.call(value); const map { [object Array]: array, [object Date]: date, [object RegExp]: regexp, [object Object]: object }; return map[tag] || unknown; }Array.isArray()也是一个好工具但要注意它是ES5引入的在非常老旧的浏览器里没有现代环境可以放心用。还有一个很多人忽略的场景跨iframe判断数组类型。如果你在一个iframe里创建一个数组在父页面里用instanceof Array判断会得到false因为两边的Array构造函数不是同一个这种情况只能用Object.prototype.toString.call兜底。2.2 函数与this谁调用它它就指向谁但箭头函数除外函数是JavaScript里最容易被误解的部分。普通函数的this由调用方式决定这句话初学者都会背但真正写代码时setTimeout回调、事件监听器、对象方法取值这三种场景能把人整到怀疑人生。以setTimeout为例里面的回调函数执行时this指向全局对象浏览器里就是window。如果你在对象方法里写了一个setTimeout想去访问对象属性直接写this.xxx一定报错或者返回undefined。解决办法无外乎三种箭头函数捕获外层this、bind(this)、或者在外层先存一个that this。前两种我都在用that写法我基本已经淘汰了因为可读性确实差一些。const user { name: echo, greet: function () { setTimeout(() { console.log(hi, ${this.name}); }, 1000); } }; user.greet();事件监听器是另一个坑。el.addEventListener(click, handler)里如果handler是普通函数this指向触发事件的元素如果你在handler里调用了别的对象方法要小心this是否已经被改绑。实际开发里我倾向于在事件回调里不用this而是用event.currentTarget这样语义更清晰也便于在回调里抽出公共逻辑。箭头函数没有自己的arguments、没有原型、不能当构造函数。这些“限制”在某些场景反而是优点比如写回调、写柯里化、写函数式处理数组时箭头函数的简洁和词法this都让代码更可靠。真正需要用function关键词的地方是构造函数、需要动态this的方法、以及需要借用arguments对象的情况。2.3 事件机制目标、冒泡与捕获以及事件委托的价值事件这块我总结过一句话**事件从window出发一路向下到目标再一路向上回window。向下走是捕获阶段向上走是冒泡阶段。**真正触达目标元素的那一下不区分捕获和冒泡。很多业务代码根本不关心捕获阶段因为默认监听都在冒泡阶段注册。但有一个典型场景必须用捕获你想在事件到达目标之前拦截比如禁止页面上某个容器里的所有click被下游处理或者监听scroll时不想频繁触发子元素处理器。事件委托是我推荐每人都会的优化手段。给父容器绑定一次事件通过event.target判断实际触发元素可以少绑定很多监听器动态插入的节点也自动获得事件处理能力。比如一个列表要支持点击每项进入详情用委托只需要写一次listEl.addEventListener(click, function (e) { const item e.target.closest(.list-item); if (item) { openDetail(item.dataset.id); } });这里有个容易被忽略的小技巧e.target可能是列表项内部的子元素所以要用closest向上找最近的.list-item。老代码里有人会写e.target.parentNode一层一层判断维护起来非常痛苦。closest基本支持所有现代浏览器放心用。事件对象的preventDefault()和stopPropagation()也有细微区别前者阻止默认动作但不影响传播后者阻止传播但不影响默认动作。表单的submit事件里经常两个都调但先说清楚——如果你是为了“先校验再提交”只需要preventDefault如果你既不想提交、又不想让祖先元素的监听器收到消息才需要stopPropagation。滥用stopPropagation会带来隐蔽的交互bug比如其他组件监听document上的点击去关闭弹窗结果你在中间层把冒泡掐断了弹窗就关不掉了。这类问题我排查过不止一次最后都是去掉多余的stopPropagation解决。3. 高频业务场景保留两位小数、Canvas与日历组件3.1 保留两位小数toFixed不是银弹先聊浮点精度toFixed(2)是最直观的保留两位小数方案但要说清楚两件事第一它返回的是字符串不是数字第二它的舍入规则在部分浏览器里会出现“非标准”的错觉。比如(1.005).toFixed(2)很多环境下得到1.00而不是1.01原因是浮点数存储时1.005实际是1.004999999...四舍五入自然向下走了。如果业务要求“严格四舍五入保留两位”我建议先放大再缩小function roundToFixed(value, digits 2) { const factor Math.pow(10, digits); return Math.round((value Number.EPSILON) * factor) / factor; }在此基础上再决定是否toFixed(digits)转字符串。为什么加Number.EPSILON因为Math.round对x.5这类边界情况的浮点误差也不稳定加一个极小量可以抵消部分误差但不能保证所有场景所以如果你在做金融类计算建议直接引入decimal.js这样的大数库别在原生Number上死磕。顺带提一句数值展示和数值存储的分离表格里显示19.90但实际传给接口的是19.9这是一个需要的转换。显示交给toFixed存储尽量用原始数字否则字符串拼起来、比较大小都会出事。3.2 Canvas画云彩素材从静态图形到动态动画Canvas的热度一直不低但很多人的canvas代码还停留在“画个长方形”的水平。这里我拿“云彩素材”举个例子因为云彩本身是渐变、透明、弧线、随机性的综合体练一遍能把Canvas常用API覆盖大半。画一朵简单的云可以拆成几个圆叠加再统一填充白色带透明度的渐变function drawCloud(ctx, x, y, scale) { ctx.save(); ctx.translate(x, y); ctx.scale(scale, scale); ctx.beginPath(); ctx.arc(0, 0, 30, 0, Math.PI * 2); ctx.arc(30, 10, 20, 0, Math.PI * 2); ctx.arc(-30, 8, 22, 0, Math.PI * 2); ctx.fillStyle rgba(255, 255, 255, 0.85); ctx.fill(); ctx.restore(); }注意ctx.save()和ctx.restore()的配对这是Canvas里最容易被忽略的规范。一个独立绘制的单元负责保存和恢复状态否则旋转、缩放、透明度会互相污染画出来的图形一团乱。动画部分要用requestAnimationFrame而不是setInterval。requestAnimationFrame会跟随屏幕刷新率通常60fps标签页切到后台时自动暂停不浪费CPU。移动云彩的做法是每一帧清空画布、更新云的位置、重新绘制。清空用ctx.clearRect(0, 0, canvas.width, canvas.height)如果背景不透明也可以直接重绘背景。高分辨率屏上Canvas会糊这是必踩的坑。解决方案是让Canvas的width和height等于CSS显示尺寸乘以devicePixelRatio再通过ctx.scale(devicePixelRatio, devicePixelRatio)把坐标系拉回来。这个细节不处理好iPhone上画的云边缘直接锯齿。3.3 FullCalendar集成把日程组件的默认行为摸透FullCalendar在JavaScript论坛里搜索量不小因为它是老牌日程组件功能全但配置也多。我集成过几次给它的定位是“能快速出页面、但不建议过度自定义”的库。核心集成步骤可以浓缩成三条引入样式与脚本、初始化Calendar实例、配置数据源。这里讲两个实际问题。第一个是数据格式。FullCalendar无论用events数组还是eventSources接口标准的日期字段都推荐ISO字符串。如果后端返回的是时间戳数字不要在初始化时直接在配置里减、加、格式化而是单独写一个mapEvents函数做转换。好处是数据源切换、时区调整时改动被收敛在一个函数里排错容易。第二个是日期点击与事件点击的交互。要给dateClick里打开新建日程弹窗、给eventClick打开编辑弹窗的话注意两个回调的参数结构不一样dateClick拿到的是info.dateStreventClick拿到的是info.event.extendedProps。属性层级最容易写错我见过同事在dateClick里读info.event结果一直是undefined找了半天。FullCalendar的周视图和月视图切换时viewDidMount会被反复触发不要在里面对DOM做一次性绑定否则切换几次视图会出现重复监听。要监听就交给FullCalendar自身的回调不要再叠一层DOM事件了。4. 跨端与兼容OC和JavaScript互调、框架库的本质4.1 OC与JavaScript互相调用的桥接思路移动端混合开发里OC和JavaScript互相调用是老话题。在iOS的WKWebView体系下JS调用OC有标准路径通过WKScriptMessageHandler注册原生方法JS侧用window.webkit.messageHandlers.方法名.postMessage(参数)触发。OC调用JS则简单一些直接evaluateJavaScript执行一段JS代码。// JavaScript侧调用原生 window.webkit.messageHandlers.showToast.postMessage({ text: hello native });原生注册的名字是showToast参数可以传一个JSON序列化后的对象。实践中我建议参数永远传JSON字符串或对象不要分拆成多个参数因为原生和JS的边界会对参数类型做序列化结构化的数据最稳。OC侧调用JS的常见场景是把一段JSON数据回传给页面比如登录态更新后const result document.getElementById(userInfo); result.textContent data updated;注意执行JS的时机。页面还没加载完时evaluateJavaScript可能报错或者找不到DOM元素所以OC调用JS前最好确认WebView的加载状态。我的做法是在页面里暴露一个初始化标记原生侧通过判断标记决定是直接调用还是等webView:didFinishNavigation:再执行。JS回调OC时如果同时传了中文、长字符串、特殊符号需要核对桥接层有没有做URL编码。很多老旧的UIWebView桥接方案里中文参数变成乱码的问题非常常见WKWebView的postMessage走的是内部消息机制基本不踩编码坑这也是我优先推荐新项目一律用WKWeBView的原因。4.2 框架与库跨浏览器兼容的真相热搜词里那句“JavaScript框架或库是一组能轻松生成跨浏览器兼容的JavaScript代码的工具和函数”话是对的但容易让人误解成“用了框架就有免死金牌”。框架确实封了很多兼容性差异。比如jQuery时代的$.ajax替我们处理了XMLHttpRequest的分支判断现代前端框架的虚拟DOM、事件系统也抹平了一部分差异。但跨浏览器兼容的最后一公里往往需要自己补比如对Promise的finally方法做polyfill对CSSaspect-ratio做降级对Intl.DateTimeFormat在低版本WebView里的缺失做兜底。我的建议是三层处理第一用构建工具做语法转译配置好browserslist让Babel按目标浏览器版本编译第二针对标准API做运行级判断不支持的路径写替代逻辑第三把必须用新API的场景收拢到一个工具函数里方便统一替换。不要一上来就上重型polyfill全家桶先看看实际访问用户里的浏览器占比。为了一个占比0.1%的旧浏览器引入几百KB的polyfill得不偿失。以Array.from为例它在IE里不存在如果你的项目真的要求兼容IE就写一个Array.prototype.slice.call(arrayLike)的替代如果不要求别浪费精力。4.3 库与原生JS的选择标准这里多说一句库的选型。FullCalendar、Canvas库比如Konva、框架Vue/React都是工具选型前先列三个问题这个库的核心场景和我的需求匹配吗它的更新频率和维护状态如何体积和许可协议对我有没有限制。我在集成FullCalendar时的经历可以说明问题它功能强但我只需要一个简单的日程展示那我自己写一个Canvas格子列表也就三百行反而更轻。选型不是越重越好而是越贴合越好。5. 运行时错误与高负载JavaScript排查实录5.1 常见的运行时错误以及我常用的排查路径JavaScript运行时错误是社区提问的常客。我看了一下最近被问得多的报错基本集中在几类错误类型典型的报错信息常见场景语法错误Unexpected token手写括号不匹配、模板字符串漏了闭合类型错误Cannot read properties of undefined (reading xxx)DOM节点没找到、接口数据为空范围错误Maximum call stack size exceeded递归没有退出条件、死循环异步错误Uncaught (in promise) ...Promise里的reject没有catch排查工具比记忆力有用得多。浏览器DevTools的Sources面板里报错信息会有调用栈我会先看栈顶是不是自己的业务代码栈底如果是zone.js或者框架内部的代码说明问题可能出在生命周期钩子或者异步边界上。有一次排查一个连续点击按钮导致的崩溃就是靠调用栈定位到是requestAnimationFrame循环里重复启动了一个新循环。5.2 屏蔽高负载JavaScript从源头优化长任务“屏蔽高负载JavaScript”听起来像某个浏览器插件的功能实际上指的是页面里有一段脚本长时间占用主线程导致滚动卡顿、按钮点击无响应。处理高负载JS优化思路有三层减少计算量、拆分执行时机、可延迟的坚决延迟。减少计算量的典型手段是缓存和预处理。比如第一次解析完一份很大的JSON数组后把解析结果存在变量里不要每次都JSON.parse。拆分执行时机的手段是分片和分批。比如要渲染一万条列表可以直接一次性append也可以用requestIdleCallback或者setTimeout分批插入让主线程有喘息空间。我收到过一段让人哭笑不得的脚本大概意思是“代码javascript:((){try{let xdocument.getElementsByClassName(progress...’)...”后面被截断了从风格上判断是一段直接在控制台执行的自动脚本用来读取页面上的进度信息。这种脚本本身不复杂但问题在于如果它在一个循环里高频查询DOM而该页面的布局很复杂就会反复触发重排整个页面变得极其卡顿。我的建议是查询到的DOM节点缓存复用不要每次循环都重新getElementsByClassName在循环里改成const progressEls document.querySelectorAll(.progress); for (let i 0; i progressEls.length; i) { // 处理每个节点不要在循环里再查DOM }这只是优化思路的一个缩影高负载JavaScript的敌人不是“执行了多久”而是“是否阻塞了用户关键路径”。首屏必须执行的代码越短越好其他可以往后放。defer和async脚本加载属性、IntersectionObserver代替scroll监听、content-visibility: auto跳过屏幕外渲染都是配套手段。5.3 常见问题速查表问题排查思路推荐做法toFixed结果不对浮点存储误差先放大整数四舍五入再缩小typeof null是object语言历史遗留需要区分空值时用全等判断事件委托拿不到目标元素目标可能是子元素用closest向上匹配切换View后事件重复绑定容器被缓存/重建改用组件生命周期或事件代理WKWebView回调中文乱码桥接层编码问题统一用postMessageJSON长列表渲染卡顿主线程被反复占用分批渲染节点缓存setTimeout回调内this丢失this绑定规则箭头函数或bindCanvas在高清屏模糊DPR没处理画布尺寸乘以devicePixelRatio这张表是我在实际项目里踩过、又帮别人排查过的集合每条背后都有完整的故事。排查问题的时候别一上来就怀疑内存泄漏先看控制台报错、再查网络请求、最后追代码逻辑顺序对了问题少一半。6. 几点额外的心得这份JavaScript总结写到这里我再分享一个我个人的习惯代码注释不写“做了什么”而是写“为什么这么做”。比如判断数据类型时加一行“这里不用instanceof因为跨iframe时Array构造函数不一致”半年后再回来看你会感谢当时的自己。另一个习惯是遇到报错先复现再谈修复。不要看着报错信息凭感觉找地方改先写一个最小复现页面通常几行代码就能把问题收敛。我见过最离谱的一次同事觉得是WebView版本问题升级了一堆依赖最后发现只是接口返回的字段名大小写不一致一个JSON.parse后就undefined了。最后再提一个小技巧写JavaScript时多利用控制台的“条件断点”。在DevTools里给一个会在循环里执行很多次的行设置条件比如i 500这样就能在特定数据状态下停下来检查比手动写一堆console.log干净得多。这个习惯我在团队里推了很多次反馈都很好。JavaScript这个语言最大的特点是包容但包容不等于没有规则。把这些规则整理清楚写成属于自己的总结之后写代码会少很多犹豫。
阅读完成 · 觉得有帮助？
