动态创建iframe在IE下的两个问题
这篇技术文章聚焦于动态创建iframe在早期IE浏览器（IE6/7/8）中遇到的两个具体兼容性坑点。作者首先指出，使用`createElement`动态创建iframe后，将其设置为表单提交目标（target）的方式在IE6/7下会失效，导致无法实现无刷新提交。其根因在于IE浏览器对这种方式创建的iframe元素识别存在缺陷，解决方案是改用`innerHTML`的方式将iframe插入DOM。 第二个问题同样常见：通过`onload`属性为动态创建的iframe绑定加载完成回调，在IE6/7/8中均会失效。作者解释，这是因为IE的旧版本不支持该属性的事件绑定，需要改用其特有的`attachEvent`接口来实现。文章为两个问题都提供了简洁有效的代码示例，方便读者直接参考修改。 对于仍在维护老旧系统或需要处理兼容性的前端开发者而言，这篇文章清晰地剖析了问题现象、根源并提供了即用型的解决方案，是一份实用的排错指南。
从千分位格式化谈JS性能优化
这篇文章从日常开发中常见的千分位格式化（如“10,000”）需求切入，以此为案例，深入探讨了JavaScript代码的性能优化之道。作者没有满足于一个能用的函数，而是依次展示了六种不同的实现思路，包括基于数组循环、字符串拼接、正则循环匹配、字符串截取以及正则替换等方法。 文章的核心价值在于对这些方法进行了清晰的对比。关键差异主要体现在两个方面：一是操作对象（是将数字打散为数组操作还是始终处理字符串），二是算法与工具的选择（是循环遍历还是利用正则表达式）。作者通过“执行5000次消耗的时间”这一直观的性能测试数据，给出了明确的结论：避免使用数组的`unshift`方法和复杂的正则循环，通常能获得更好的性能。例如，纯字符串操作的“方法二”和“方法四”在多数情况下表现优异，而一行代码的“懒人法”（方法六）虽然简洁，但性能并非最优。 这篇文章生动地说明，一个看似微小的功能点，其背后也蕴含着值得优化的算法选择。它提醒开发者，在编写代码时，除了功能正确，也应关注实现方式对性能的潜在影响，尤其是在处理频繁调用的工具函数时。
前端开发中Cookie那些事儿
这篇讲的是前端开发中cookie的那些事儿。作者从实际项目经验出发，详细解释了cookie的各种属性及其用法，特别是那些容易踩坑的地方。例如，cookie的生存期由expires和max-age属性控制，但max-age用秒表示，已成为现代标准；max-age为正时cookie会持久化存储，为负时仅在当前会话有效，为0时则删除cookie。在ie6浏览器中，session cookie在不同打开方式下行为不一，作者曾为此吃过大亏，调试过程颇为曲折。 文章还深入解析了domain、path、secure和httpOnly等属性。domain属性允许跨子域共享cookie，但需谨慎设置域以确保安全；path属性定义cookie的关联路径；secure确保cookie仅通过HTTPS传输；httpOnly则防止JS脚本访问，增强安全性。作者分享了一个实战教训：因忽略httpOnly属性，尝试用JS读取cookie失败，耗时近两小时才定位问题。 在性能优化方面，文章强调cookie会随HTTP请求发送，增加网络开销，因此不建议将其作为客户端存储方案，并推荐了localStorage等本地存储作为替代。此外，还解释了cookie值的编码解码必要性，以及同名cookie在不同域或路径下的区别规则。 通过结合理论解释和踩坑经历，这篇文章为前端开发者提供了实用的cookie操作指南，帮助大家避开常见陷阱，在复杂应用中更高效地管理状态和提升性能。
Beforeunload打点丢失原因分析及解决方案
这篇技术文章由1688的朱铁根和胡大军撰写，他们从淘宝团队早年发现的“页面跳转前发送的打点请求丢失”现象切入，深入剖析了这一前端数据采集中的经典痛点。 作者指出，问题核心在于浏览器页面卸载机制与网络请求时序的冲突：当页面跳转指令发出后，浏览器会迅速销毁当前页面的所有对象，包括用于发送打点请求的Image对象。如果此时打点服务器尚未完成响应，该HTTP请求就会被强制终止，导致数据丢失。 为解决这一矛盾，文章并未建议以牺牲用户体验（如延迟页面响应）为代价，而是巧妙地利用了`window.name`属性的特性。在页面卸载前，将打点数据临时附加到`window.name`中；页面刷新加载后，新页面立即读取并发出这个积攒的打点请求。该方案有效规避了`window.name`在页面刷新后依然保留的特性，同时解决了`cookie`或`localStorage`存在的跨域限制问题。 实测数据显示，该方案效果显著，在Chrome浏览器中打点回收率平均提升了约13%，在各版本IE浏览器上也取得了稳定的提升，为解决此类前端数据采集问题提供了一种可靠且兼容性良好的工程思路。
人人网首页拖拽上传详解(HTML5 Drag&Drop、FileReader API、formdata)
这篇讲的是一个人人网早在2011年就上线的前端功能——首页拖拽上传，作者从这个实际案例出发，详细拆解了背后的实现技术。当时这个功能不仅是为了提升用户体验，也承载着向用户推广标准浏览器、逐步淘汰IE的期望。 文章核心围绕着三个HTML5关键API展开：首先是Drag&Drop事件机制，用于监听用户将文件拖入、拖离页面的行为；其次是File API中的FileList和FileReader，它们负责获取被拖拽文件的列表并读取其内容；最后是基于XMLHttpRequest Level 2的FormData对象，它能像表单一样封装文件数据，从而实现通过AJAX直接向服务器发送二进制文件流。 作者没有停留在理论介绍，而是直接给出了关键部分的代码示例，比如如何监听`dragenter`、`dragover`、`drop`等事件，并特别强调了清除`dragover`默认行为的重要性，否则后续的`drop`事件将无法触发。这些细节清晰地展示了一个完整拖拽上传功能的实现骨架。 虽然技术方案有一定年份，但文章清晰展示了如何组合基础API解决一个实际的交互问题，对于理解前端文件处理与异步上传的演进脉络仍有不错的参考价值。
通过WebRTC获取摄像头影像
这篇技术文章讲的是如何利用 WebRTC API 在网页中调用摄像头并实现一键截图。作者从基础的 video 标签搭建开始，引出了核心的 `navigator.getUserMedia` 接口，并特别指出了它在当时浏览器环境下的兼容性现实：Chrome 和 Firefox 需要加前缀，移动端支持不佳。 文章的核心实现思路清晰：通过 `getUserMedia` 请求摄像头权限，成功后拿到视频流，再通过 `window.URL.createObjectURL` 将流媒体转换为 URL 填入 video 标签播放。截图功能则依赖 canvas 的 `drawImage` 方法，把视频当前帧“画”上去。作者贴心地给出了处理浏览器差异的兼容代码，并分享了一个实战中遇到的“坑”：在 Firefox 中无法通过常规事件可靠获取视频尺寸，最终采用 `setTimeout` 轮询的变通方案来绑定截图按钮。 除了核心步骤，文章末尾还补充了几个有价值的细节，比如同一浏览器不同标签页可以共享摄像头，但不同浏览器不行；以及推荐将截图上传至服务器再提供下载，而非在本地强制保存。整体上，这是一份对前端开发者来说相当直接、步骤明确的实践指南。
IE6下经典的请求abort问题
作者掉进了一个坑：在IE6下给`a`标签绑定事件来切换验证码图片，但图片总是刷不出来，抓包一看请求状态是**abort**。问题出在IE6对`a`标签的执行顺序上——它先执行`onclick`里的事件处理函数，紧接着就会执行`href`属性定义的跳转。如果你没有在事件里阻止这个默认的跳转行为，浏览器会认为页面即将导航离开，从而把刚才在`onclick`中发起的请求（比如获取验证码的AJAX请求）给强制中止了。 解决办法很直接：在事件处理函数的最后加上`return false;`，或者把`href`属性改成不会跳转的锚点，比如`javascript:void(0)`或`#`。最稳妥的做法是两者结合使用。文章通过这个具体的bug，把IE6下事件流与页面跳转之间的微妙关系讲得很清楚，虽然现在IE6已罕见，但其中关于浏览器默认行为会干扰异步请求的原理，在其他场景下依然值得留意。
通过WebRTC获取摄像头影像
这篇讲的是如何利用WebRTC实现实时获取摄像头影像并在浏览器中完成截图。文章从创建`
JavaScript 中的陷阱
这篇讲的是JavaScript开发中那些因为语言特性而容易“掉坑”的典型场景。作者从JavaScript“弱语言”的灵活与宽松出发，指出了几个开发者常会忽略的陷阱细节。 比如，全局变量的隐式创建并不局限于省略`var`关键字，`var a = b = 0;`这样的连写同样会让`b`意外泄露为全局变量。文章还深入剖析了“变量提升”与“函数提升”机制——你可能以为在函数里使用`alert`会输出外部变量，但实际结果往往是`undefined`，因为该作用域内的变量声明已被提前解析。函数声明也遵循同样的提升规则，甚至允许后面的声明覆盖前面的，导致行为与直觉相悖。 这篇文章的价值在于，它没有泛泛而谈，而是用一连串精准的代码实例，揭示了JavaScript在变量作用域、解析顺序方面的核心机制。它提醒开发者，要写出健壮的代码，就必须理解这些“坑”背后的语言设计逻辑，养成逐一声明变量、手动管理提升作用域的习惯。
使用SeaJS实现模块化JavaScript开发
这篇文章通过一个Web应用“TinyApp”的具体开发场景，清晰地对比了传统JavaScript开发与使用SeaJS进行模块化开发的差异。作者指出，传统模式下随着文件增多，开发者需要手动维护繁琐的script标签列表和复杂的模块依赖顺序，极易导致代码纠缠与维护困难。 而SeaJS作为一个遵循CommonJS规范的轻量级模块加载框架，其核心在于“一切皆模块”的理念。文章展示了在SeaJS模式下，HTML页面只需引入一个sea.js，所有模块依赖都通过模块内部的`require`声明并由框架自动处理。这使得代码组织清晰，开发者可以专注于业务逻辑本身，不必再被依赖管理所累。 此外，文章还深入讲解了SeaJS的实践细节，包括如何使用`define`函数定义模块，以及工厂函数中`require`、`exports`和`module`这三个关键参数的作用。作者强调SeaJS秉持KISS原则，API简洁，能够与jQuery等主流框架无缝集成，从而提升前端工程的代码可维护性。
javascript继承机制
这篇讲的是 JavaScript 中实现继承的两种经典机制：构造函数继承与原型继承。作者从具体的代码示例出发，清晰地展示了 `Animal.apply(this, arguments)` 这种构造函数继承如何复用父类构造函数中的属性，同时点明了它无法继承原型方法的局限性。 文章的核心在于对比。它指出，如果使用 `class.prototype = new parent_class()` 的原型继承方式，则能同时继承父类构造函数和原型上的属性与方法。此外，文章还细致地区分了 `call` 与 `apply` 在传参方式上的不同，并通过反例（如在构造函数内使用 `this.prototype`）强调了原型继承的正确写法。 最后，作者给出了一个精炼的总结：根据是否需要继承原型方法来选择继承方式——若只需构造函数内的成员，用 `apply/call`；若需要原型链上的完整继承，则用原型赋值。这种对比式的讲解，帮助开发者快速理解不同继承模式的核心差异与适用场景。
JQuery,Extjs,YUI,Prototype,Dojo 等JS框架的区别和应用场景简述
这篇从Web2.0时代JavaScript的角色演变谈起，指出在敏捷开发中借助JS框架是效率与深度的双赢，并重点对比了几大主流框架的特性与适用场景。 作者将JQuery评为首推的五星级框架，理由在于其体积小巧、学习曲线平缓、强大的DOM操作与灵活的UI扩展性。Extjs和YUI则凭借出色的UI组件，更适配后台管理系统或网盘这类复杂交互的应用。Dojo功能最为全面，尤其适合需要离线存储、数据网格等企业级特性的产品，但代价是庞大的体积和陡峭的学习成本。Mootools则以其纯正的面向对象设计和低耦合的模块化见长。 文章的核心观点是：没有“最好”的框架，只有“最适合”的选择。开发者应依据项目实际需求来决策，如果感到迷茫，不妨从最灵活的JQuery入手开始实践。
加载，不只是少一点点
这篇讲的是前端性能优化中的“加载精简”策略，其核心目标是解决页面加载慢、带宽成本高的问题。文章重点剖析了离线存储（Application Cache）这一具体方案。 作者指出，加载精简能通过减少资源加载量来加速首屏，并在一定程度上提升渲染速度。具体实施上，离线存储依赖于manifest文件来划分需要缓存和在线获取的资源，在移动端（如离线APP）应用尤为广泛。文章详细说明了其配置方法、基于版本注释的更新机制，以及监听网络状态实现更智能更新的进阶思路。 然而，文章并未止步于优点。它坦诚地揭示了离线存储的“残缺美”：更新时全量下载导致效率低下，manifest文件可能因资源列表庞大而变得臃肿，以及无法很好处理同一页面的不同参数URL等问题。 因此，作者的结论非常务实：寻找适合项目自身阶段（如初期侧重SEO）和性质的方法至关重要，而非盲目采用。离线存储虽能有效“加速”，但其使用需要权衡其利弊与实际场景需求。
JavaScript 设置浏览器标题闪动
这篇文章讲的是一个简单却实用的前端交互技巧：如何让浏览器标签页的标题闪动，从而在用户不看页面时也能有效提醒他们有新消息或内容更新。 作者直接给出了一个名为 `BlinkTitle` 的 JavaScript 类来实现这一功能。核心思路非常清晰：通过 `setInterval` 定时器，让 `document.title` 在一个新标题（如“新消息！”）和原始标题之间来回切换，制造视觉上的闪烁效果。代码实现中巧妙地做了备份和恢复，用户点击“停止”后，标题能立刻恢复原样。 这种方法不依赖任何库，代码轻量，非常适合嵌入到需要实时提醒的网页应用中，比如在线客服系统、后台管理界面或者任何使用 Ajax 长轮询的页面。当用户切换到其他标签页工作时，这个闪动的标题就能成为一个不容忽视的提醒信号。
Javascript触屏手势库-jTouch
这篇讲的是作者因项目代码混乱而受刺激，在业余时间封装的一个触屏手势库——jTouch。它专注于为触屏浏览器提供一套完整的手势识别方案。 文章开篇就坦诚地分享了作者的创作动机，那种对整洁代码的追求很能引起开发者共鸣。jTouch目前主要针对iPad测试，支持tap（单击）、doubletap（双击）、longtap（长按）、hold（拖拽）、swipe（滑动）、flip（轻拂）、pinch（捏合）和rotate（旋转）这八种核心手势。 作者没有停留在功能列表，而是详细说明了每个手势回调函数中能获取到的关键数据。比如，swipe和flip会返回方向（direction）和移动距离（x, y）；pinch会返回缩放类型（in/out）和比例（scale）；rotate则会返回方向和旋转角度（rotation）。这些细节对于开发者在回调中实现具体交互逻辑至关重要。 文章还提供了链式调用的简洁语法示例，并附带了几个生动的在线演示，包括一个触摸平滑移动的轮播效果，以及一个模拟iPad图标长按抖动、双击复位的界面。这些示例直观展示了库的实用性，也为想实现类似效果的开发者提供了直接的参考思路。
用 javascript 判断 IE 版本号
这篇讲的是如何用一段巧妙的JavaScript代码来准确判断IE的版本号。作者从一个实际项目需求出发，发现jQuery 2.0已放弃版本检测转而推荐特性检测，但面对特定场景，版本号信息依然重要。 文章的核心亮点是分享了一段“以巧破力”的代码。它没有采用常规的解析User-Agent字符串的方法，而是利用了IE浏览器独有的“条件注释”特性。通过动态创建元素并循环写入特定条件注释，代码能够检测出当前IE的精确版本，且对不支持条件注释的现代浏览器能安全地返回`false`，兼容性极佳。 作者也解释了为何要绕开User-Agent检测——那些字符串（比如IE10和IE11的）早已被各厂商修改得杂乱无章，完全不可靠。相比之下，这段利用浏览器原生特性的检测方式，既简洁又稳健，避免了“猜谜”式的判断，为需要区分IE版本的场景提供了一个值得参考的解决方案。
javascript函数的throttle和debounce
这篇讲的是JavaScript开发中两个常用的性能优化技巧：函数节流（throttle）与函数去抖（debounce）。文章从一个常见的性能优化问题——频繁触发的 `window.resize` 和 `scroll` 事件——切入，形象地将这些持续触发的事件比喻为“机关枪扫射”，而节流就像控制射击频率的扳机。 作者明确指出了两者的核心差异：throttle 是控制函数在连续调用时，按固定时间间隔执行（例如每隔400ms执行一次），适合处理鼠标移动、窗口拖拽等持续触发的场景；而 debounce 则是控制函数在连续调用结束后，必须等待一段指定的空闲时间才执行，特别适用于文本输入、搜索自动补全等场景，能有效过滤掉用户的“快速连续操作”。 文章不仅解释了概念，还提供了原生的 setTimeout 实现思路作为节流示例，并附上了一个通用且实用的函数代码，通过传递参数同时实现了节流和去抖功能。文末提供的在线 Demo 和扩展阅读链接，让读者可以直观体验效果并深入学习。对于前端开发者而言，理解并正确运用这两个技巧，对提升页面交互性能至关重要。
jQuery的data()方法
这篇讲的是jQuery中data()方法如何优雅地管理HTML5的data-*自定义属性。它解决了一个实际问题：如何方便、安全地在DOM元素上绑定和读取各种类型的数据，同时避免循环引用可能导致的内存泄漏。 作者从基本用法切入，展示了四种调用方式，核心优势在于data()会智能处理数据类型——字符串值的"true"会被转为布尔值true，"43"会变成数字43，而符合JSON格式的对象或数组字符串也会被自动解析。这意味着你从HTML属性拿到的不再是笨重的原始字符串，而是可以直接使用的JavaScript值，省去了大量手动转换的代码。 更关键的是它的存储机制：data-*属性在首次读取后，数据便交由jQuery在内部缓存，后续操作都基于这个内存对象。这不仅性能更优，也保证了数据的一致性。需要注意的是，如果你想严格保持字符串形式，就该用attr()方法。 文章用一段简洁的示例演示了这种自动转换的直观效果，比如`$("div").data("options").name`直接就能获取到对象属性，非常适合需要在HTML标签上轻量级配置复杂参数的场景。
谈谈 jQuery 中的防冲突（noConflict）机制
这篇讲的是如何优雅解决多 JavaScript 框架混用时对 `$` 符号的争夺问题，核心是解读 jQuery 的 `noConflict` 机制。 当项目同时引入 jQuery 和其他库（如 KISSY、Prototype）时，大家都喜欢用 `$` 作为快捷方式，冲突在所难免。作者从这个实际痛点出发，拆解了 jQuery 的应对之策：它通过 `jQuery.noConflict` 方法，允许开发者主动释放对 `$` 甚至 `jQuery` 对象本身的控制权。 文章深入源码，揭示了其实现上的巧妙之处。jQuery 在加载时会预先将 `window.jQuery` 和 `window.$` 保存在私有变量中。调用 `noConflict` 时，正是通过对比这些备份，决定将控制权“归还”给之前的占有者。那个可选的 `deep` 参数，就决定了是只交出 `$`，还是连同 `jQuery` 本身一并交出。 这种设计不仅适用于框架混用，也为 jQuery 多版本共存提供了解决方案。文章最后还给出了一个非常实用的技巧：通过闭包包裹代码，并传入 `noConflict` 返回的 jQuery 对象，可以在局部安全地恢复 `$` 的用法，让现有插件无缝工作。整个机制体现了 jQuery 在 API 设计上对复杂运行环境的周全考量。
Js事件监听封装（支持匿名函数）
这篇讲的是JavaScript中一个常见但容易被忽视的痛点：如何优雅地取消事件监听，尤其是当使用匿名函数绑定时。作者从实际开发中“想解绑却拿不到函数引用”的困境出发，提出了一套简洁的封装方案。 核心思路是利用一个哈希表（handleHash）作为事件类型的索引，在绑定时不仅执行原始函数，还将内部包装函数的引用缓存到对应的数组中。这样，即使外部是匿名函数，内部通过 arguments.callee（在非严格模式下）依然能获取其引用并保存下来。解绑时，则遍历该数组，逐个移除监听器。 这个方案的巧妙之处在于，它通过一层轻量的“包装”和“缓存”，完全兼容了 addEventListener 与 attachEvent，同时将匿名函数的“不可见引用”问题巧妙地转化为可管理的内部引用，让开发者可以随意使用匿名函数而无需担心内存泄漏或无法解绑。实际使用时，只需像普通绑定一样调用 bind，在需要时用 unbind 按事件名一键清理即可。