最新文章

采集自各技术站点的近期文章。

IT 前端/ 2017-01-16 00:15:45 / 累计浏览 3,630

从零开始React服务器渲染

这篇文章讲的是如何用Node+React实现服务器渲染，重点对比了两个关键函数。作者从服务器渲染带来的SEO和首屏速度优势说起，核心聚焦在 `react-dom/server` 包中的 `renderToString` 与 `renderToStaticMarkup` 这两个API。它们的主要区别在于生成的HTML：`renderToString` 会在DOM上附加 `data-react-id` 和 `data-react-checksum` 等属性，这为客户端提供了“水合”的依据，使得React能高效地接管页面并避免重复渲染；而 `renderToStaticMarkup` 则生成更干净的HTML，没有额外属性，适用于完全静态的页面，但客户端会重新渲染整个组件。文章不仅阐述了原理，还给出了清晰的代码示例，演示了如何使用 `renderToStaticMarkup` 渲染一个静态页面，并进一步通过一个计数器例子，完整展示了从服务端渲染到客户端初始化的全流程。最终指出，选择哪个函数，决定了应用是能拥有流畅的交互，还是仅作为一个静态文档。对于想在实际项目中应用React SSR的开发者来说，理解这个核心区别是搭建稳定、高效渲染流程的第一步。

本机暂存

IT 后端/ 2017-01-16 00:13:57 / 累计浏览 3,123

订单号的生成规则

订单号生成是电商、O2O等系统的经典难题：既要保证全局唯一，又不能暴露每日流水等商业机密，同时还得满足语义性、快速路由分库分表以及控制长度等实际需求。这篇文章从这一核心矛盾出发，拆解了业内几种主流的生成策略。文章具体分析了大众点评、美团团购和淘宝的实践。例如大众点评采用“时间戳+用户标识码+随机数”来兼顾唯一与信息隐藏；美团团购和淘宝则巧妙地结合了“单表自增ID/发号器ID”与“买家ID的后几位”，这种设计不仅保证了唯一性，更关键的是能通过订单号直接计算出数据路由，快速定位到对应的库与表。除此之外，文章还介绍了分布式ID发号器的整体架构（如美团的Leaf），解释了如何通过独立服务来生成全局有序或趋势递增的ID号段，以支撑高并发和分库分表的场景。对于正在设计订单系统或对分布式ID生成感兴趣的开发者来说，这些来自大厂的实战总结提供了清晰的思路和可靠的参考方案。

本机暂存

IT 后端/ 2016-12-22 23:35:13 / 累计浏览 1,966

HTTPS 常见部署问题及解决方案

这篇文章整理了作者在 HTTPS 和 HTTP/2 部署实践中收集的典型故障与解决方案，堪称一份实用的排错手册。遇到问题时，作者推荐首先使用 Qualys SSL Labs 的在线测试工具进行诊断。针对 Let's Encrypt 证书申请验证失败的情况，文章建议改用 acme.sh 的 DNS 验证模式，通常能绕过服务器访问限制。对于 Chrome 53 浏览器报告的 ERR_CERTIFICATE_TRANSPARENCY_REQUIRED 错误，根因是 Chrome 的一个 Bug，解决方案是升级浏览器版本。当浏览器提示证书错误时，文章指出需检查证书链的完整性，特别是不要遗漏中间证书。如果问题仅出现在老旧浏览器（如 IE8），则很可能是未启用 SNI（服务器名称指示）导致，可通过将站点部署在不同服务器、使用 SAN 证书或直接忽略这些旧浏览器来解决。启用 HTTP/2 后访问异常（如 ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY），通常是因为 CipherSuite 配置不当，可参考 Mozilla 或 CloudFlare 的权威配置进行调整。若浏览器在 Nginx 启用 HTTP/2 后仍降级为 HTTP/1.1，则可能是 OpenSSL 版本过低（低于 1.0.2）不支持 ALPN 协议协商所致。最后，升级 HTTPS 后网站部分资源无法加载，原因往往是混用了 HTTP 资源，解决方案是确保所有外链资源均使用 HTTPS 协议。文章内容会持续更新，为开发者提供了具体的排查思路和改进方案。

本机暂存

IT 前端/ 2016-12-22 23:32:37 / 累计浏览 3,760

你必须收藏的Github技巧

这篇讲的是几个能立即提升GitHub使用效率的“隐藏”小技巧。作者没有长篇大论，而是直接分享了五个具体的、可操作的方法。其中比较亮眼的有：直接将master分支设置为GitHub Pages网站源，免去了在gh-pages分支间手动同步的繁琐；通过在URL后添加#L行号，可以精准分享单行或多行高亮代码，对方打开链接就能定位到指定位置；在提交信息中使用fix、close等关键字关联issue，可自动关闭问题，保持项目管理清爽。此外，文章还介绍了如何用HTML代码在网站中嵌入GitHub的Star按钮，以及通过.gitattributes文件自定义项目被识别的语言类型。整篇文章没有空泛的理论，每个技巧都配有示例或效果说明，对于日常使用GitHub的开发者来说，这些都是能立刻用上、节省时间的实用干货。

本机暂存

IT 安全/ 2016-12-22 23:31:26 / 累计浏览 2,491

恶意邮件不完全分类及防范指南

这篇讲的是日常邮件背后潜藏的恶意攻击路径。文章没有停留在“要警惕”的泛泛建议上，而是从发件人（伪造身份与陌生人）和恶意行为（骗信息、骗链接、骗附件）两个维度，把常见的恶意邮件套路拆解得非常清晰。比如，文中提到“挂马附件”可能就是一个伪装成图片的超链接，真正的附件图标反而藏在邮件主题下方，鼠标悬停时状态栏会显示真实URL。对于“带毒附件”，文章也指出了当前流行的勒索软件新马甲：伪装成TXT的JS文件。最有价值的部分在于结尾的防范指南。作者抛弃了复杂的邮件头分析，直接从攻击者希望你做什么（要信息、点链接、开附件）这个角度切入，给出了“不动脑子”的简单原则：凡属意料之外的要求，一律采取“不管不问”，或者通过电话、短信等备用渠道核实发件人。这套逻辑清晰、易于执行，切实能帮助非技术背景的读者建立起第一道防线。

本机暂存

IT 数据库/ 2016-12-22 23:30:22 / 累计浏览 6,819

SQL里是否可以使用JOIN

这篇讲的是一个流传甚广的技术误区：很多公司出于“性能慢”的理由禁止程序员在SQL中使用JOIN。作者从这个常见的约定出发，通过一个查询最新帖子和用户信息的实例进行了直接对比。文章指出，用JOIN完成的操作，如果拆解成两次独立查询和代码层合并，其开销很可能更大，“用JOIN慢”其实是个没有严格论证的人云亦云的结论。作者进一步点明了真正值得考虑的问题所在——它并非性能，而是系统架构的灵活性。当使用JOIN时，你隐含地假设了相关的表将永远部署在同一个数据库实例上。一旦项目发展，表可能因拆分而“离婚”到不同实例，届时所有用到JOIN的地方都可能需要重构。因此，文章给出的核心建议是：如果相关表未来有独立部署的可能，就要谨慎使用JOIN；否则，完全可以用。所以，用JOIN慢往往不是问题的本质。下次如果听到别人以性能为由反对JOIN，或许可以指出，真正需要权衡的是对未来数据库架构变更的预判。

本机暂存

IT 后端/ 2016-12-22 23:28:32 / 累计浏览 3,229

PHP的性能演进(从PHP5.0到PHP7.1的性能全评测)

这篇评测通过CPU基准测试脚本，系统比较了PHP从5.0到7.1各主要版本的性能表现。作者发现，性能提升主要发生在主版本迭代时，而非小版本更新。例如，PHP 5.1比5.0性能翻倍，PHP 5.4有一次显著跃升，而PHP 7.0则实现了重大突破，其重新设计的Zend Engine使性能得到质的飞跃。测试数据直观展示了这一历程：在bench.php脚本中，PHP 7.0比5.0快了数倍，而试验性的JIT分支（预览PHP 8）更是将差距拉大到40倍以上。文章也梳理了各版本的核心优化点，从PHP 5.1的编译变量与执行器优化，到PHP 5.4的内部字符串优化，再到PHP 7.0全面重构的数据结构与内存管理。除了回顾，文章也展望了引入JIT编译技术的PHP 8，指出这将是另一个性能飞跃点，但同时也提醒其效果因场景而异。对于PHP开发者而言，这份横跨十余年的评测，不仅验证了每次重大升级的价值，也为性能优化与版本升级决策提供了扎实的数据参考。

本机暂存

IT 前端/ 2016-12-22 23:25:54 / 累计浏览 3,518

优化JavaScript的执行效率

这篇讲的是一个在前端性能优化中常被忽视但影响重大的环节——JavaScript的执行效率。作者从页面动画和数据计算等常见场景切入，指出错误的执行时机和过长的代码执行时间是两大元凶。文章给出的核心建议非常具体：实现动画时，应果断用`requestAnimationFrame`替代`setTimeout`或`setInterval`，因为后者无法保证回调的执行时机，容易导致掉帧。对于耗时的计算任务，则应放到Web Workers中异步执行，避免阻塞主线程。同时，DOM更新应拆分成多个小任务，分批在多个帧中完成。此外，作者还强调了借助Chrome DevTools的Timeline和JavaScript Profiler进行性能分析的重要性，因为经过JIT编译器优化后的实际执行代码可能与你所写代码大相径庭。这些技巧组合使用，能有效解决页面卡顿，让动画更流畅，是前端开发中必须掌握的性能优化基础。

本机暂存

IT 安全/ 2016-12-22 23:24:35 / 累计浏览 3,487

浅谈Web安全验证码

这篇文章从大家熟悉的“春运验证码”切入，谈了谈Web安全中这个既熟悉又令人头疼的验证机制。作者首先解释了验证码（CAPTCHA）的初衷：它本质上是一道区分人类与计算机程序的图灵测试，用于抵御暴力破解、垃圾广告等滥用行为。接着，文章深入剖析了验证码的工作原理。一个典型的流程是，服务器为每个会话生成唯一验证码并关联，用户识别后提交，服务器再进行校验。然而，实现上常见的漏洞不少：比如验证码在错误后未失效，导致攻击者可能固定使用一个码反复尝试；或是不慎将验证码字符串明文写在响应包里，使其形同虚设。面对验证码，攻防双方的博弈从未停止。文章总结了当前主要的对抗方式：攻击者会通过更换IP、延迟请求来“避免触发”验证码；或者利用上述漏洞实现“验证码固定”；更直接的是通过“机器自动识别”（涉及去噪、二值化、切片、模板匹配等步骤）或借助“人工分布式打码”平台来破解。这反过来也推动了验证码技术的演进，未来验证码会更强调增强干扰与字符变形，并可能拓展字符空间至中文，以应对不断升级的识别技术。

本机暂存

IT 前端/ 2016-12-22 23:23:56 / 累计浏览 1,998

浏览器的渲染性能

这篇讲的是如何让网页“丝般顺滑”。用户都希望页面响应迅速、动画流畅，而这一切的背后，是浏览器在毫秒之间完成的复杂渲染工作。文章首先点明，要达到60fps的流畅度，浏览器每一帧的处理时间必须控制在约16毫秒，留给实际渲染的纯净时间可能仅有10毫秒，否则就会出现恼人的卡顿（jank）。要想优化，就必须理解从代码到像素的“像素渲染流水线”。作者从开发者视角出发，将这条核心路径拆解为五个关键步骤：JavaScript执行、样式计算、布局、绘制和渲染层合并。文章清晰地说明了，任何一步的耗时超标都可能导致掉帧。更重要的是，文章指出了并非所有视觉更新都需要经历全部五步。例如，修改一个元素的“几何属性”（如宽度）会触发完整的“JS→计算样式→布局→绘制→合并”路径，而仅修改颜色或阴影则可能跳过布局步骤。这种对不同操作路径的剖析，能帮助开发者精准定位性能瓶颈，编写出真正高效的前端代码。

本机暂存

IT 前端/ 2016-12-22 23:17:28 / 累计浏览 1,867

降低样式计算的范围和复杂度

这篇讲的是如何优化前端性能中一个关键却容易被忽视的环节：样式计算。作者从DOM操作引发样式重算的现象出发，直接点明性能瓶颈。文章核心给出了两个优化方向。第一是降低CSS选择器的复杂度。它对比了简单的类选择器（如`.title`）与复杂的复合选择器（如`.box:nth-last-child(-n+1).title`），后者会让浏览器花费大量时间去确认父子关系和次序，严重拖慢渲染。作者提倡采用BEM这类基于class的方法论来简化规则。第二，也是更重要的，是减少需要执行样式计算的元素范围。文章解释了最坏情况下计算量与元素和规则数量的乘积关系，并介绍了现代浏览器通过为每个元素维护样式规则集合来优化计算范围的机制。此外，文章还介绍了如何使用Chrome DevTools的Timeline功能来实际评估样式计算的成本。通过分析帧率图表和紫色的样式计算耗时事件，开发者可以准确定位卡顿原因。整体而言，这是一篇非常实用的性能优化指南，给出了具体可操作的方法和诊断工具。

本机暂存

IT 前端/ 2016-11-06 22:37:20 / 累计浏览 2,064

CSS3 Flexbox解决方案

这篇文章直指CSS布局长期以来的痛点——缺乏一套优雅、直观的解决方案。作者通过一个名为“Flexbox解决方案”的实例合集，展示了Flexbox如何一举攻克那些曾让开发者头疼的布局难题。它没有停留在理论讲解，而是聚焦于实战：从更简单灵活的栅格系统，到历史上几乎无解的“圣杯布局”；从需要clearfix hack的媒体对象，到高度未知的“粘性页脚”和经典“垂直居中”问题，Flexbox都提供了简洁得近乎“魔法”的代码实现。这些Demo证明，许多过去需要依赖复杂浮动、定位或框架才能勉强实现的效果，如今用一两个Flexbox属性就能搞定。更关键的是，随着IE11和Safari 6.1的发布，这套规格已获所有现代浏览器支持。文章提供的源代码和在线演示，让开发者能直观看到，当Flexbox成为布局基石后，CSS代码可以变得多么干净与高效。它预示着Web布局方式正迎来一次实质性的简化。

本机暂存

IT 前端/ 2016-11-06 22:36:27 / 累计浏览 1,403

jQuery 3.0 升级指南

这篇指南是为那些正在或将要将项目升级到 jQuery 3.0 的开发者准备的实用手册。文章开宗明义，指出 3.0 版本对 API 进行了清理和更改，并明确了新的浏览器支持范围（如 IE 9+、现代浏览器的前两个版本等）。其核心亮点在于详尽介绍了官方推荐的平滑迁移方案——使用 jQuery Migrate 插件。文章不仅解释了该插件的作用，即充当升级工具来警告不兼容用法，还给出了一个清晰的八步升级流程，指导开发者如何从 1.x/2.x 逐步过渡到 3.0，并确保代码的稳健性。例如，流程中强调先在 2.x 版本下使用 Migrate 1.x 插件解决遗留问题，再切换到 3.0 与 Migrate 3.x 插件配合。此外，文章将 3.0 的重要变更进行了分类梳理（如“更改”、“功能”、“已弃用”），帮助读者快速评估潜在影响。整体上，它不仅列出了“做什么”，更通过具体的步骤和工具解释了“如何安全地做”，为这次大版本升级提供了清晰、可操作的路线图。

本机暂存

IT 开发者/ 2016-11-06 22:34:25 / 累计浏览 3,703

8大实用又重要Mac使用技巧

这篇讲的是Mac日常使用中的效率提升指南，文章从区分苹果几种容易混淆的Store开始，为你理清App Store、iTunes Store和Apple Store的区别。不过核心干货集中在对快捷键系统的深度拆解上。文章将零散的快捷键梳理成了清晰的几类：顶行功能键的巧用、空格键堪称“万能预览键”的神奇之处、以及一整套覆盖文件管理、窗口切换、截屏和系统控制的组合键。比如，文中特别介绍了Command+Shift+4接空格可以精准截取窗口，比QQ截图更原生高效；而Command+Option+Esc用于强制退出卡死的程序，也是Mac用户的必备技能。除了介绍，文章也提到了如何自定义快捷键，并推荐了KeyCue这个辅助工具，让记忆变得更轻松。最后，作者强调了一个常被忽略的观点：熟练使用触控板的各种手势，其效率其实远超外接鼠标，建议所有用户都去系统偏好设置里完成官方教学。整体来看，这篇文章从基础认知到进阶操作都覆盖了，是一份很实用的Mac使用备忘录。

本机暂存

IT 前端/ 2016-11-06 22:32:41 / 累计浏览 1,763

用webgl打造一款简单第一人称射击游戏

这篇讲的是如何用原生WebGL从零构建一款简单但完整的3D第一人称射击游戏。作者从一个有趣的缘由切入——为了回应同事对之前3D迷宫项目“缺少一把枪”的吐槽，于是有了这个新Demo。文章的重点不在于游戏复杂度，而在于两个WebGL核心知识点的实践：**如何在没有建模工具的情况下，用代码拼凑基本几何体来生成枪械等3D模型**，以及**如何控制“摄像头”来实现第一人称视角**。作者坦诚地展示了“手搓”模型的艰辛过程：通过将现实尺寸映射到WebGL坐标系，并拆解为简单子模型来组合成型。这种方式虽然不实用，但生动地揭示了3D物体在代码层面的构成逻辑。更精彩的部分是关于摄像头的讲解，作者用一组直观的对比图，清晰地说明了物体移动与摄像机移动在视觉上等效的原理，即它们都在改变物体相对于“视锥体”的位置，这是理解3D视角控制的关键。文章附有可直接试玩的链接和开源代码，将抽象的顶点变换（uPMatrix*uVMatrix*uMMatrix）与具体的射击游戏体验结合起来，让理论立刻变得可感知。对于想理解WebGL渲染管线，特别是摄像机机制的前端开发者来说，这是一个非常生动的实践案例。

本机暂存

IT 后端/ 2016-11-06 22:22:31 / 累计浏览 2,739

Python 代码规范小结

这是一份从实践中总结的 Python 代码编写规范清单。作者从一次 code review 的小结出发，强调了两个核心原则：一切都与复杂度有关，以及代码应当易于理解。文章将规范具体化到了编码的各个环节。在基础风格上，它指出代码被阅读的次数远多于编写和修改的次数，因此可读性至关重要。接着，文章系统性地梳理了注释、命名、常量、变量、数据结构以及表达式的写法，并深入到了控制流（分支、循环、异常处理）的具体实现建议。对于函数和类的设计，文中也给出了相应的组织思路。最后，内容还延伸到了模块、抽象与整体设计层面。特别值得一提的是，文章提出了一个评估项目可行性的公式：可行性=(当前价值+未来价值)/(实现成本+维护成本)，强调了降低长期维护成本的优先级。这些从具体语法细节到宏观设计思想的总结，为写出更规范、更易于维护的 Python 代码提供了清晰的路线图。

本机暂存

IT 后端/ 2016-11-06 22:20:50 / 累计浏览 1,121

Lua 中 Cache 冷数据的落地

这篇讲的是如何在 Lua 虚拟机中，为缓存模块设计一个安全的冷数据落地机制。作者从一个实际 bug 讨论出发，详细分析了不同方案的演进。文章最初提出一个基于时间戳的朴素方案，但发现其无法保证业务正在使用数据时，数据不会被错误地异步写回。随后，作者引入 Lua 弱表和 `__gc` 元方法进行改进，利用垃圾回收机制来判断数据是否“冷”。然而，这个方案存在一个微妙的“第三状态”漏洞：当对象被 GC 回收、但其 `__gc` 方法尚未将其“复活”到待处理表时，系统会短暂地失去对该数据的追踪，导致可能从数据库加载出旧版本的数据。为解决这个并发与状态管理的核心难题，文章最终提出了基于元表代理的方案。通过让 cache 表存储代理对象，将真正的数据隔离在另一个全局表中，从而稳定了数据从缓存中移除的时机，并使冷数据落地流程可以清晰地通过集合差集来识别目标，避免了复杂的状态竞争问题。这实质上是用间接层换取了状态管理的清晰与安全。

本机暂存

IT 设计/ 2016-11-06 22:20:09 / 累计浏览 2,948

Python创建单例模式的三种方式

这篇文章聚焦于Python中实现单例模式的常见方案，对比了三种不同的技术路径。作者从实际编码场景出发，展示了如何通过装饰器、基类继承与元类编程这三种方式来确保一个类仅存在唯一实例。具体来看，三种方法各有特点。使用装饰器时，核心是通过一个外层函数维护一个实例字典，逻辑直观，易于理解。基于基类的方法则重写了对象创建的入口`__new__`方法，通过检查并缓存实例属性来保证唯一性，这种方式更贴近面向对象的直观理解。而利用元类的方式最为“底层”，它重写了`__call__`方法，在类被调用创建对象时进行拦截和控制，其设计思想更具全局性和侵入性。文章的价值不仅在于展示代码，更在于清晰地勾勒出不同方案的实现逻辑与适用场景。选择装饰器通常更灵活轻量；使用基类则提供了标准的继承约束；而元类方式虽然强大，但也可能增加系统的复杂度。对于开发者而言，理解这些差异有助于在具体项目中权衡简洁性、可读性与架构影响，做出合适的技术选型。

本机暂存

IT 设计/ 2016-11-06 22:16:46 / 累计浏览 2,369

消费领域的挤牙膏效应：沉迷网游后的一点心得

作者以自己近期沉迷一款免费手游的经历为引子，探讨了消费领域中普遍存在的“挤牙膏效应”。文章从对比《聚爆》这类优秀买断制游戏与国内免费游戏内购模式的差异切入，核心观点在于：无论是游戏中的VIP等级设计（从首充60元到累积数万元），还是现实中的摩拜单车押金、付费阅读、轻奢消费等，都依赖于精心设计的“小额消费”来持续吸引并绑定用户。作者发现，这种模式成功的关键在于，它为那些无力承担巨额消费（如买房）的中间阶层提供了一种可负担的、能够彰显“存在感”的路径。游戏通过累充好礼和可控的战力差距保持用户粘性，社会则通过层出不穷的新潮小额消费维持人们的参与感。但文章也指出，这种模式存在风险：当小额消费带来的新鲜感消退、存在感变得麻木时，无论是游戏还是更广泛的社会消费，都可能面临“断崖式下跌”。最后，文章以幽默口吻自嘲沉迷网游，实则完成了对一种普遍消费心理与模式的冷静观察。

本机暂存

IT 前端/ 2016-11-06 22:11:30 / 累计浏览 2,130

漫谈Nuclear Web组件化入门篇

这篇文章从传统 Web 前端开发中常见的痛点切入，比如 CSS 样式冲突、事件处理污染全局作用域、组件复用困难、数据更新时 DOM 操作繁琐，以及首屏渲染性能问题。作者详细描述了过去为了规避这些“坑”所采取的各种笨拙方案，例如为 CSS 添加冗长的命名空间，或将事件函数绑定在 window 对象上，指出这些做法只是妥协而非根本解决之道。核心介绍的是腾讯 AlloyTeam 开发的 Nuclear 框架如何通过组件化来系统性地解决这些问题。Nuclear 提供了从创建组件、声明式事件绑定、模板条件判断到循环渲染的一整套方案，将 HTML、CSS 和 JavaScript 封装成独立的单元。文章通过“Hello, Nuclear!”等具体代码示例，展示了其内置的模板引擎和清晰的组件 API。使用 Nuclear 这样的组件化方案，不仅能够提升代码的可维护性和复用性，还能在需要时通过同构（服务端渲染）无缝优化首屏加载性能，避免了架构推倒重来的痛苦。

本机暂存