消除JavaScript闭包的一般方法
这篇讲的是JavaScript闭包作为“被动解决方案”时的替代思路。作者指出，虽然闭包常被用于封装私有状态，但有时它源于语言本身的限制，导致代码结构难以扩展。 文章对比了两种处理“变量只初始化一次”这类需求的方法：一种是常见的闭包写法（立即执行函数创建私有变量），另一种则是作者推荐的“消除闭包”写法——通过构造函数和`this`引用来组织状态与方法。核心差异在于可扩展性：当需要为同一状态添加新操作时，闭包写法往往需要重写或嵌套更复杂的结构，而基于构造函数的方式只需简单添加新方法，更接近线性扩展。 作者强调，虽然闭包在特定场景下依然有用，但面对需要后续维护或扩展的需求时，考虑“消除闭包”的模式能减少不必要的重构，让代码更清晰、更易迭代。对于日常开发中那些因语言特性而“不得不”使用闭包的场景，这提供了一种更面向未来的写法选择。
JavaScript实现的抛物线运动效果
这篇讲的是如何用JavaScript实现购物车常见的抛物线飞入动画效果。作者从天猫购物车的交互体验得到启发，参考了张鑫旭的抛物线运动原理，但觉得现有代码结构可以优化，于是重新实现了一版更简洁易用的方案。 核心实现基于抛物线数学公式，通过动态计算元素在每一帧的left和top偏移来模拟运动轨迹。作者的巧妙之处在于将整个过程封装成了一个可配置的`Parabola`对象，开发者只需通过参数设置目标偏移量（`offset`）、运动时长（`duration`）和曲线弧度（`curvature`），就能快速获得想要的运动效果。文章还提供了运动前后的回调函数接口，方便在动画结束时触发后续逻辑。 文末附有完整的在线Demo和清晰的参数说明表格，方便读者直接上手测试和理解每个选项的作用。这种从实际需求出发、重构成更符合个人习惯代码的思路，对前端开发者如何学习和改进现有方案也有不错的参考价值。
JavaScript原型之路
这篇文章探讨了JavaScript中两种对象创建方式的差异与选择：传统的构造函数方法与更纯粹的原型（OLOO）方法。 作者从Frontend Masters的教程和一篇经典博文出发，对比了这两种路径。标准方法通过构造函数和原型链建立继承，是目前大多数教程和框架（如Angular）所要求的。而纯原型方法则利用`Object.create()`直接克隆对象，语法上更接近IO这类原生原型语言，显得更直接和动态。 然而，文章指出一个关键的现实考量：性能。测试显示，纯原型的实现在某些操作上可能比构造函数方式慢数十倍，这是JavaScript引擎优化导致的结果。此外，ES6引入的`class`语法本质上仍是构造函数的语法糖，并未改变原型的底层机制。 作者的结论反映了实践中的权衡：个人偏好纯原型的表现力和趣味性，但在追求性能的生产代码中，会继续采用构造函数方法，并期待未来能更广泛地使用ES6的类语法。
Node.js 打造实时多人游戏框架
这篇讲的是作者在一个极客松的36小时高压环境下，如何利用Node.js从零打造一个名为“Spaceroom”的实时多人游戏框架。框架的核心目标是解决LAN Party场景下的低延迟同步问题，让身处同一局域网的玩家能够实时互动。 作者设计了以“房间”为单位的用户管理和一个基于“bucket”的指令同步算法。简单来说，服务器会将时间切分成固定的小片段（bucket），收集并广播各客户端的指令。客户端根据收到的bucket序列来更新状态，从而在理论上保持画面一致，将网络延迟的影响控制在约定范围内。 实现过程中并非一帆风顺。文章用相当的篇幅分享了一个典型的“踩坑”经历：他们发现Node.js在Windows平台下的`setTimeout(…, 1)`实际精度只有15.625ms左右，远达不到毫秒级计时的要求。通过测试和查阅资料，他们揭示了这是Windows系统计时器的固有特性，并最终给出了基于实际系统时间差进行补偿的解决方案。 总的来说，这篇文章不仅展示了一个具体技术方案的实现过程，也坦诚地分享了探索中的陷阱与排错思路，对于想用Node.js处理实时通信或游戏同步的开发者来说，很有参考价值。
JavaScript中双叹号(!!)作用
这篇讲的是 JavaScript 中一个常见但常被误解的操作符：双叹号（!!）。作者从日常编码中“var b = !!a;”这样的片段出发，解释了它的核心作用——将任何表达式强制转换为布尔值（true 或 false）。 文章不仅解释了 !! 如何通过两次逻辑取反来实现转换（第一次转为布尔值取反，第二次再反转回来），更深入地剖析了 JavaScript 的布尔转换规则。它对比了显式转换（如 parseInt、toString）和隐式转换（利用算术运算符或连接符），并明确了哪些值会被视为 false（如 false、undefined、null、0、""），哪些为 true。 通过 undefined 和 null 的具体示例，文章展示了 !! 的实用价值：它能清晰地将“未定义”或“空”状态归为 false，而将实际有值（哪怕是对象）的变量归为 true，为后续的条件判断提供了稳定、明确的依据。这本质上是对 JavaScript 弱类型特性的一种优雅应对。理解了这一点，开发者就能更自信地使用这种简写语法，编写出更简洁可靠的布尔判断逻辑。
window resize和scroll事件的基本优化
这篇讲的是前端开发中一个常见的性能陷阱。文章从同事在项目中实际遇到的“翻车”现场切入：在低版本IE里，频繁触发的`resize`和`scroll`事件会导致页面卡死。问题的根源在于这两个事件触发频率极高，每次都同步执行复杂计算或DOM操作，会瞬间耗尽浏览器的性能资源。 作者的核心优化思路是“节流”：通过一个定时器，确保在设定的时间窗口（如400毫秒）内，无论事件被触发多少次，实际的处理函数只执行一次。代码示例清晰展示了如何用`setTimeout`和`clearTimeout`来实现这个简单的“节流阀”，这个方案对`resize`和`scroll`事件同样有效。 对于需要监听这些高频事件的场景，尤其是需要兼容老版本IE的项目，这个低成本、高收益的基础优化方法能有效避免页面假死，值得借鉴。
Javascript中的delete操作符
这篇文章深入剖析了JavaScript中`delete`操作符的行为，特别是它与变量、对象属性之间微妙而关键的互动关系。作者从一个核心矛盾出发：看似等价的全局变量和对象属性，在`delete`面前却表现迥异。 核心差异在于，通过`var`声明的变量和函数声明都带有`dontdelete`特性，因此它们无法被`delete`操作符移除。相比之下，直接在对象上创建的属性（无论是自定义的还是来自原型链的）则可以被轻松删除。文章通过一系列精准的代码示例展示了这种区别，例如`delete global`对`var global`无效，但`delete obj`却能移除一个未用`var`声明的全局变量（它本质上是`window`对象的属性）。 此外，文章还细致地探讨了`delete`操作符的几个边界情况：它无法删除原型（prototype）中定义的属性或对象自带的属性（如`length`）；在`eval`执行的代码中，通过`var`声明的变量反而失去了`dontdelete`保护，可以被删除；而`delete`的返回值（`true`/`false`）更多反映了操作是否成功，而非属性是否真的存在。理解这些细节，对于避免JavaScript中关于删除操作的常见陷阱至关重要。
浏览器特性检测工具：Modernizr
这篇文章从早期前端开发中常见的浏览器嗅探技术切入，引出了一个至今仍普遍存在的问题：面对CSS3和HTML5等新技术时，各浏览器的支持程度依然参差不齐。作者指出，依赖navigator.userAgent进行浏览器身份推断已不可靠，取而代之的是更直接的“特征检测”——即询问浏览器“你能做什么？”而非“你是谁？”。 Modernizr正是为此而生的JavaScript库，它能够快速检测数十项HTML5和CSS3特性的支持情况，其执行效率极高。文章重点阐释了Modernizr所依托的“渐进增强”开发理念，即从基础功能层开始，逐层添加增强体验。它不仅能帮助开发者清晰地了解当前环境，还能通过提供polyfill脚本，模拟缺失的HTML5功能（如地理定位），从而填补浏览器的功能漏洞。 此外，文章也贴心地介绍了Modernizr的两个版本：包含完整检测功能的development版适合学习和测试，而可按需定制的production版则能优化体积与性能。对于希望构建健壮、可适应不同环境的前端应用的开发者来说，Modernizr提供了一套可靠且高效的检测与应对工具箱。
说说最近Google:safebrowsing引发页面加载阻塞的问题
这篇讲的是一个由Google SafeBrowsing机制引发的线上故障。某业务在Firefox浏览器中突然出现JS加载阻塞，导致页面功能异常，但代码变更仅有文案修改。排查发现，问题根源在于Firefox内置的Google安全浏览功能。 正常情况下，浏览器加载资源后会与本地哈希库进行碰撞检查，若疑似风险则会向Google服务器发送检测请求。但在国内网络环境下，该请求被阻塞（GFW采用了“hold连接”而非重置），导致Firefox一直等待响应，页面因此卡住。由于哈希库无法更新，即使升级浏览器或清理缓存也无济于事，同一个请求会因在等待队列中而被完全忽略。 最终，团队通过修改静态资源文件名（如JS的路径、CSS的时间戳）绕过了哈希碰撞，作为临时方案。文章不仅详细拆解了从发现问题、分析机制到定位网络环境影响的全过程，也提醒开发者需要更主动地关注浏览器底层安全机制与本地网络环境的潜在冲突。
jQuery 设置复选框选中状态的 BUG
这篇讲的是 jQuery 开发中一个容易被忽略的“坑”。作者从一个过去一直正常工作的全选/全不选功能代码突然失效说起——使用 `attr('checked')` 设置复选框状态，代码却只在第一次点击时生效，之后无论怎么点击都无效，让人非常困惑。 经过反复测试，作者发现问题出在 jQuery 版本兼容性上。在新版本中，`attr()` 方法对 `checked` 这类布尔属性的处理与浏览器原生属性不同步，导致状态无法被正确切换和识别。文章指出，正确的做法是使用 `prop('checked')` 来显式地设置 DOM 属性，或者采用更直接的原生 JS 遍历赋值，以确保所有 jQuery 版本都能兼容。 这个案例典型地揭示了 jQuery 早期版本中 `attr()` 和 `prop()` 在语义上的一个重要区别：前者侧重于 HTML 属性（attribute），后者侧重于 DOM 对象属性（property）。对于像 `checked`、`selected`、`disabled` 这类状态属性，直接操作 DOM 属性才是稳定可靠的方式。
js 面向对象日历实现原理详解
这篇教程拆解了如何用JavaScript手写一个动态日历组件。作者从实际开发需求出发，比如表单日期选择场景，提出了一个清晰的实现思路：只需解决两个关键问题——确定目标月份第一天是星期几，以及该月总天数。 基于Date对象的方法，这两个问题都能被优雅地解决。文章提供的核心代码展示了一个自包含的calendar对象，它封装了获取日期信息、渲染日历网格以及处理月份切换的逻辑。巧妙之处在于，通过动态生成HTML和简单的CSS高亮，就能实现今日标记和月份导航等基础交互功能。 整体来看，文章将万年历这一常见组件的原理讲得透彻且可操作。这种面向对象的实现方式也让代码结构清晰，便于根据业务需求扩展样式或功能。对于想理解DOM操作与日期API结合应用的前端学习者，这篇提供完整代码和在线演示的教程，是一个不错的实践起点。
基于jQuery的简易手风琴切换插件
作者在项目需要手风琴效果时，对比了几个现有jQuery插件，觉得它们相对笨重，于是自己动手写了一个更轻量、脉络清晰的版本。这篇讲的就是这个自制插件的实现思路和具体用法。 插件的核心思路很直接：将所有切换元素绝对定位在容器内，通过计算容器宽度与单个元素宽度的差值，动态分配每个元素的初始位置。当鼠标触发事件时，根据当前激活元素的索引，重新计算并动画所有元素的 left 值，从而实现展开收起的手风琴效果。 实现上考虑得比较周全。它支持通过参数配置鼠标事件类型（如mouseover或click）、默认展开项、动画间隔以及缓动函数（需配合jQuery.easing）。作者在代码中添加了详细注释，清晰说明了每个参数的作用和整体逻辑。 调用方式遵循标准jQuery插件模式，引入后只需一行代码即可启用。作者还提供了在线样例演示，帮助直观理解效果。这个插件适合那些需要轻量级手风琴交互，并且希望对实现细节有完全掌控的项目。
javascript运算符
这篇讲的是JavaScript里运算符的“脾气”。它不只是简单列举了+、-、==、===这些符号，而是深入拆解了它们背后的规则和容易踩坑的地方。 文章把运算符按算术、比较、逻辑、赋值等用途分门别类，然后着重讲了几个关键点：比如“+”号面对字符串时，就从“加法”变成了“拼接”；而“==”和“===”的区别，直接关系到比较时会不会自动做类型转换。这些细节在日常编码里稍不注意就会埋雷。 它还特别点出了运算符的结合性顺序——比如“++”放在变量前后的不同效果，这在实际循环或表达式中非常实用。同时，对于除法可能产生浮点数、模运算对非数字的处理等边缘情况，也都给出了明确的规则说明。 整体来说，这篇文章适合想理清JavaScript基础语法、避免低级错误的开发者。它把枯燥的语法点结合实际执行行为来讲，读起来能帮你建立起对这些运算符更清晰、更可靠的心理模型。
jQuery.ajax处理302重定向
这篇文章探讨了一个前端开发者常遇到的坑：使用jQuery.ajax()时，遇到302重定向为什么会“卡住”？作者从底层原理出发，指出问题的核心在于xmlHttpRequest的跨域限制。如果跳转目标是同域，服务器本就不该用302；如果是跨域，则天然会被浏览器拦截。不过，随着现代浏览器对CORS的支持，情况有了变化。在配置得当的前提下，302是能够被处理的。文章给出了一个实用的解决思路：利用ajaxComplete事件来捕获这个“错误”，并手动跟踪重定向。作者特别提醒，如果业务需要携带Cookie，切记要在xhr对象上设置withCredentials为true，否则认证信息可能会丢失。文章最后引用了Stack Overflow等社区的讨论，提供了深入实践的参考。
如何捕获和分析 JavaScript Error
这篇文章从现代 Single Page App 的痛点切入：用户操作状态复杂，简单的“刷新页面”已无法作为错误处理的万能药，因此系统性地捕获与分析前端错误变得至关重要。 它详细对比了两种核心捕获方式：try-catch 用于已知会抛出异常的 API 调用或回调，确保代码局部容错；而 window.onerror 则是兜底方案，用于捕获未预料到的全局错误。文章进一步剖析了跨浏览器环境下的属性丢失难题——window.onerror 有限的参数会导致关键信息（如列号、堆栈）缺失，作者探讨了通过序列化 message 或利用现代浏览器提供的第五个参数（Error 对象）来解决。 针对跨域脚本抛出的 “Script error.” 这一普遍难题，文章提供了基于 CORS 的注入方案来绕过安全限制，并深入到一个非常实际的工程细节：通过插入空行的“行号反查”技巧，解决内联代码导致的行号冲突问题，使得错误定位依然准确。 整体来看，作者从基础方法讲到浏览器兼容性深水区，再到跨域场景的工程化应对，为前端开发者提供了一份清晰、可落地的错误监控实施指南，而不仅仅是罗列 API。
cookie窃取和session劫持
这篇讲的是网络安全中一个经典但常被忽视的威胁——Cookie窃取与Session劫持。文章从基础讲起，细致梳理了Cookie在HTTP请求/响应中的传递机制，并解释了会话Cookie、持久Cookie、安全属性（Secure/HttpOnly）以及第三方Cookie、超级Cookie等多种类型的核心区别与应用场景。 其核心价值在于清晰剖析了风险：当用于维持用户登录状态的Session Cookie被窃取时，攻击者便能劫持整个会话，以你的身份操作系统。文章重点指出了最常见的攻击入口是XSS漏洞，攻击者可通过注入的恶意脚本直接读取Cookie并将其外传。 此外，文章还延伸介绍了Cookie用于个性化设置和用户行为追踪的用途，并提及了如“僵尸Cookie”等更复杂的持久化追踪技术。它不仅是前端开发者理解浏览器安全模型的重要参考，也为后端开发者配置安全的Cookie策略提供了直接依据。
理解JavaScript 中的 this
这篇讲的是JavaScript里那个让人又爱又恨的`this`关键字。作者从`this`的基本工作机制切入，核心观点是：它的指向并非由函数定义决定，而是取决于函数被调用的“方式”。 文章用简洁的代码示例对比了关键差异：当函数作为对象的方法调用时，`this`指向该对象；若将方法赋给变量再调用，`this`却会“叛逃”至全局。在构造函数中，`this`指向新创建的实例，但若漏写`new`，又会指向全局——这种“脆弱性”正是许多困惑的根源。 作者进一步剖析了用`call`、`apply`和`bind`这三个工具显式绑定`this`的场景，它们适用于需要在不同上下文中复用函数，或提前锁定`this`指向的情况。最后，文章点明了一个进阶痛点：在嵌套函数（作用域链）中，`this`无法自动继承，通常需要借助`self`或`that`变量来“捕获”外层的引用。 通篇没有空泛的理论，而是紧扣开发者日常会遇到的实际陷阱和解决方案，对理清`this`的作用规则很有帮助。
javascript DOM操作中的insertAdjacentHTML方法
这篇讲的是如何用更现代的方式在DOM中插入HTML内容。作者从大家熟悉的innerHTML和innerText方法的局限性出发，引出了功能更强大的insertAdjacentHTML。 它最大的特点是支持四个精确的插入位置参数：beforeBegin、afterBegin、beforeEnd、afterEnd，可以让你在目标元素的外部前后、内部开头或结尾处插入内容，控制粒度非常细，避免了innerHTML可能覆盖原有内容的风险。 文章还贴心地分享了一个兼容老版本IE的自定义insertHTML函数实现。这个函数的思路很巧妙：对于不支持原生方法的浏览器，它通过创建Range对象并使用createContextualFragment来解析和插入HTML片段，从而模拟了四个位置的插入行为，确保了代码的跨浏览器可用性。 如果你还在频繁使用innerHTML拼接界面，或者对DOM插入位置有更灵活的需求，这篇对insertAdjacentHTML的实操讲解会提供一个清晰直接的解决方案。
浏览器的重绘(repaints)与重排(reflows)
这篇讲的是浏览器渲染页面的核心机制——重绘与重排，这是前端性能优化中必须理解的概念。文章从页面加载流程入手，清晰地区分了两个关键环节：重排是元素几何属性变化导致渲染树需要重新计算，性能开销显著；重绘则是元素外观改变触发的重新绘制，不一定引发重排。但重排必然伴随重绘，理解这种连锁反应至关重要。 作者列举了几种典型的重排触发场景，比如修改DOM几何属性、改变DOM结构，甚至只是读取 `offsetWidth` 等属性值，也会强制浏览器同步计算布局，打乱其优化节奏。这些细节揭示了性能问题的隐形来源。 文章的价值不止于概念解析，更提供了切实的优化策略：将多次样式修改合并、对动画元素使用绝对定位以隔离影响、在内存中操作节点后再插入文档，以及隐藏元素进行复杂操作等。这些实践建议直接指向如何在开发中最小化重排次数和影响范围，帮助开发者规避常见的性能陷阱。
页面重绘和回流以及优化
这篇讲的是前端性能优化中的关键概念：页面重绘与回流。作者从浏览器渲染页面的流程切入，清晰解释了DOM树、样式结构与渲染树（Render Tree）的构建关系，并指出渲染树不包含 `display:none` 等隐藏节点这一重要细节。 文章的核心是区分回流与重绘：当元素的几何属性（如尺寸、位置）改变时触发回流，浏览器需要重新构建部分渲染树；而仅改变外观属性（如背景色）则只触发重绘。作者强调“回流必将引起重绘”，并列举了六种常见触发回流的场景，如DOM增删、窗口尺寸变化等。 为说明性能影响，文章通过一段JS代码演示了连续样式修改如何导致多次不必要的回流。同时，作者揭示了浏览器内部的优化机制——通过维护操作队列来合并回流操作，并提醒开发者某些属性访问（如 `offsetWidth`）会强制刷新该队列。 最后，文章给出了具体的优化策略：批量修改样式（如使用 `className` 或 `cssText`）、采用离线操作（如 `DocumentFragment`）、缓存布局信息，以及让动画元素脱离文档流。这些方法能有效减少渲染树的重构规模，提升页面性能。