TailwindCSS v4 全新颜色系统与主题切换
TailwindCSS v4 对颜色系统进行了重大重构，核心解决了此前通过 CSS 变量自定义颜色时遇到的痛点。旧方法在变量中存储分离的 RGB 分量字符串，不仅导致编辑器无法识别颜色预览，更严重的问题是当颜色自身带有透明度时，`/
个人网站的再次重建
作者此前使用Notion作为博客后端，在实践中遇到CSS定制困难、RSS生成消耗大量Vercel云函数配额以及页面意外无法访问等问题，促使他决定重建个人网站。新方案旨在将所有对外内容归集于 zgq.me 域名下，实现内容源的单一真实来源（Single Source of Truth），并解除对第三方的依赖。 技术实现上，网站继续基于Next.js静态站点生成，内容从Markdown文件读取，替代了Notion作为CMS。文章从Notion导出后，按slug整理并包含Front Matter元数据，目录以年份组织。Markdown解析采用@mdx-js/mdx，样式方案选用Tailwind CSS以保持简洁。 重建过程重点解决了几个技术细节：处理Next.js无法直接引用public目录外资源的问题，通过复制文件至static目录并修改URL访问路径；针对Vercel部署后图片缓存策略（max-age为0）的问题，在CDN层面进行配置优化，并预加载图片尺寸以避免布局偏移。此外，作者计划重新构建极简的评论系统，采用SQLite作为数据库，基于Koa和React开发前后端，以降低维护负担。 整个重建过程体现了作者对技术栈自主性、内容所有权及系统简洁性的追求，参考了多位同行的实践经验。
浅谈 GUI 应用开发
本文基于作者从Web前端切入GUI开发的实践经验，提出了一套关注技术核心的思维框架。在状态管理上，强调抓住引起UI变化的核心状态，并利用枚举等手段管理状态流转，对于复杂应用则需借助组件化拆分或状态管理库来分而治之。生命周期视角下，将应用视为流程集合，关注流程的触发、运转与异常终止，强调流程设计的清晰性及通过测试保障其健壮性。交互模式方面，对比了Web App的单画布模型与Mobile App的堆栈模型，需针对性处理History/API导航及多屏通信等差异。屏幕适配主张避免简单缩放，提倡使用px单位配合弹性布局与媒体查询实现稳健设计。研发流程则倡导基于“流程”或“用户故事流”进行协作开发，明确了从技术评估、MVP开发到产品化打磨的路线图，并强调测试建设、同理心与抓大放小的执行原则。全文为从Web转向更广泛GUI应用开发提供了架构与工程层面的实践参考。
CSS 中的标点悬挂及其现状
标点悬挂是一种排版微调技术，通过让标点悬出段落对齐边界来保持正文文字边缘整齐，从而提升阅读体验。在中文排版中，它源自西文排版，但中文传统强调版框概念——内容需完全放入版心，因此标点悬挂通常仅在行尾进行，以避免零碎空隙，维持网格式密排模式，增强可读性。简单套用西文规则可能导致版面怪异。CSS 定义了 hanging-punctuation 属性来实现这一效果，语法如 hanging-punctuation
如何使用CSS判断鼠标从哪个方向进入元素？
这篇讲的是前端开发中一个很实用的细节：如何用纯CSS或结合少量JS，来精准判断鼠标是从哪个方向进入一个元素的。作者从常见的菜单悬停效果切入，直接对比了两种主流思路。一种是利用JavaScript监听事件来计算方向，另一种则是通过巧妙的CSS变量与伪元素配合，仅用`mouseenter`触发就能实现方向感知。文章不仅展示了最终效果，还拆解了每种方案的核心实现逻辑，比如CSS方案中如何通过过渡属性控制伪元素的“展开”动画，从而自然呈现进出方向。作者对比了两种方案的代码量、性能开销以及适用的场景，指出纯CSS方案在轻量级交互中更显优雅，而JS方案在复杂逻辑中则更灵活。读完后，你不仅能直接套用代码，更能理解这些技术选择的权衡点。
浅谈阿里前端的多样化
这篇讲的是阿里前端团队如何跳出传统 Web 开发的范畴，在互动体验、业务搭建乃至 Serverless 等多个领域发挥关键作用。作者从有趣的 Atwood 定律（所有应用最终都会用 JavaScript 编写）出发，结合阿里内部的实践，展示了前端技术的边界如何被不断拓宽。 文章以“双十一”等大型活动为例，详细介绍了前端如何驱动从“网页特效”到大型游戏化互动产品的演变，并构建了一套集框架、素材中心和研发平台于一体的互动技术体系。同样，在低代码搭建领域，前端工作也从单纯页面交付，演变为贯穿选品、算法、跨端渲染等完整业务链条的产品工程。 更深入的变革来自 Serverless。它让前端工程师得以摆脱运维和底层架构的束缚，有机会转型为离业务更近的“产品工程师”，从而重新定义前后端的协作边界。作者认为，这种角色演变正是前端多样化发展的必然方向。文章最后借 Reg Braithwaite 的箴言提醒我们：技术的强大在于无所不能，而挑战在于如何明智地选择与运用。
一图看懂HTTP缓存控制/浏览器缓存控制
这篇从一张广为流传但部分有误的HTTP缓存控制流程图说起，系统梳理了浏览器缓存的两大核心机制：强缓存与协商缓存。 作者清晰对比了两者的关键差异。强缓存（状态码200）在资源有效期内直接从本地读取，不发起网络请求，主要依赖`Cache-Control`（相对时间）和`Expires`（绝对时间）头部控制，前者优先级更高。而协商缓存（状态码304）则需服务器验证资源是否更新，核心涉及`ETag/If-None-Match`与`Last-Modified/If-Modify-Since`两组字段的配合，服务器会优先校验ETag。 文章还深入解答了常见实践问题：例如，为何需要ETag（解决Last-Modified在秒级修改和内容不变时更新时间等情况下的局限性），以及在未设置任何缓存策略时，浏览器采用的启发式算法。最终，作者提供了一张更正后的流程图，将复杂的缓存判断逻辑可视化，帮助开发者理清`Cache-Control`、`ETag`、`Last-Modified`等字段在决策树中的具体位置与作用，避免在实际开发中配置出错。
浏览器中丢失referrer和HTTPS=>HTTP丢失referer的解决：基于会话的站内来源地址URL还原
这篇讲的是浏览器中Referer丢失导致来源分析失效的常见痛点，以及一个巧妙的后端解决方案。作者从实际项目出发，梳理了Referer丢失的五种主要场景：代码因素如JavaScript构造链接、HTTPS降级到HTTP时的协议限制、多核浏览器切换内核或隐私模式、鼠标手势等高级功能的干扰，以及来自微信或微博等移动App的点击。这些问题逐一修补开发量巨大，且浏览器兼容性复杂。 核心方案是采用基于会话的站内来源地址URL还原。具体做法是在服务端设置会话Cookie，例如通过OpenResty的encrypted-session模块生成加密会话，然后在日志分析系统中跟踪同一Cookie的访问路径。这样就能模拟还原用户完整的站内导航轨迹，无需依赖前端Referer头。 作者指出，这种方法绕开了传统修复中代码层面的繁琐调整，尤其应对多核浏览器和隐私模式这类难以控制的因素。通过后台日志的会话跟踪，网站能可靠地进行来源分析，提升了数据追踪的完整性和可维护性。
Rax 系列教程（native 扫盲）
这篇文章面向前端开发者，讲清楚了 Rax 在 native 端到底是什么，以及它和 React Native、Weex 这两个常见框架的核心区别。作者从“Rax = RN 语法 + Weex 能力”这个公式切入，指出 Rax 吸收了 React Native “一次学习”的开发体验，同时依托 Weex 实现了“一次编写，多端运行”的跨端目标。 文章重点拆解了 Weex 这个“幕后工作者”的运作机制。它详细解释了 Weex 从 DSL 代码到原生渲染的流程，包括 JS Framework 如何作为 JS 与 Native 通信的桥梁，以及 Weex 的 virtual-DOM 如何在简化传统 DOM 后高效控制原生视图。这些讲解剥离了复杂的客户端概念，专为前端同学理解而设计。 对于想上手的开发者，文章特别点明了 Weex 与 Web 的“天生不同”：布局上只有 Flexbox，样式不支持继承和许多 CSS 特效，单位处理也存在差异。这些细节直接关系到日常编码的取舍，比如为什么不能随意用 float 或 absolute 定位。 总之，这篇文章帮前端同学快速扫清了 Rax 背后的 native 知识盲区，理解框架的设计权衡，能更顺畅地处理跨端开发中遇到的差异问题。
Javascript创建对象方式总结
这篇文章梳理了在JavaScript中创建对象的多种常见方式，从基础到进阶，覆盖了不同场景下的选择。作者从最简单的对象字面值讲起，逐步介绍了使用new关键字（包括内建和自定义构造函数）、原型方法、Object.create()、Object.assign()以及ES6的class等不同途径。 核心对比在于各方法的实现原理与适用性：对象字面值最为直接快捷；使用new和构造函数（或ES6类）能更结构化地创建多个相似实例，并涉及原型链绑定；Object.create()允许基于现有对象创建新对象，便于实现原型继承；Object.assign()则擅长合并多个源对象的属性，生成新对象。文章也提及了单例模式这种特殊用法。 对于初学者，掌握字面值和构造函数是关键；理解原型与Object.create()有助于深入对象模型；而在需要组合或扩展已有对象时，Object.assign()提供了便利。ES6的class语法糖则让基于类的写法更贴近传统面向对象语言的习惯。整体而言，文章系统梳理了这些方式的异同，为根据项目需求选择合适的对象创建模式提供了清晰参考。
Atag - Web Components 最佳实践
这篇讲的是作者基于在淘宝小程序基础组件 Atag 中的实践，总结了 Web Components 的开发经验与避坑指南。文章从 Web Components 的核心优势切入——它由 W3C 标准驱动，具备可重用、封装性好且无框架“传染性”的特点，因此非常适合用于开发底层基础组件。 作者详细分享了几个关键的实战要点。在基础设施方面，强调了 polyfill 库 `webcomponentsjs` 和 Polymer 3 的选型与使用建议。在构建配置上，他点出了一个经典陷阱：Babel 将 ES6 class 转译为 ES5 时会导致自定义元素注册失败，并提供了解决方案。兼容性分析显示，在移动端通过 polyfill 可覆盖绝大多数用户。 文章还提供了直接的性能对比数据。在渲染 1 万个组件的场景下，原生 Web Components 的表现显著优于 React，而 Polymer 在注册阶段虽略有开销，但其开发便利性带来的整体收益依然很高。这些基于具体数据和踩坑经验的总结，对于考虑使用 Web Components 构建可复用组件的开发者来说，有很强的参考价值。
Rax 系列教程（长列表）
这篇讲的是Rax框架下长列表组件的选型与实战指南。面对scrollview、recyclerview、listview、waterfall等多个列表组件，新手往往不知如何选择。作者结合Rax 0.5版本，对这些组件的特性、适用场景与性能差异进行了清晰梳理：例如水平滚动推荐scrollview，但要注意内容过多时的性能瓶颈；追求高性能的垂直长列表则应首选recyclerview。 文章不止于理论对比，更深入讲解了关键组件的实用技巧。比如，针对recyclerview中因列表数据更新导致onEndReached失效的问题，提供了使用`resetScroll`方法重置状态的解决方案。同时，它也剖析了下拉刷新（RefreshControl的放置位置）、appear事件（在滚动容器内绑定并注意性能影响）以及onScroll动画（推荐使用BindingX降低通信成本）等基础能力的实现要点。 最后，文章展示了多种典型的页面组织模式——从简单的全屏滚动、部分固定区域布局，到复杂的模块吸顶和横滑切换多页面，均给出了具体的代码结构参考。对于需要在Web与Native端实现一致滚动体验的开发者而言，这篇教程提供了从组件选择到场景落地的系统性思路。
多个动画间存在部分相同动画的优化方案:gka
当多个Web动画包含部分相同内容时，直接加载所有帧图片会导致资源冗余。作者从一个“抓娃娃”的交互动画切入，发现“成功”与“失败”两个结果动画中，抓杆的初始滑动和晃动部分其实是完全相同的。问题在于，肉眼无法高效识别这些重复帧。 为此，文章推荐使用开源工具gka来解决。这款工具能一键处理多个帧动画，其核心亮点在于支持图片去重（-u参数）。对于上述例子，只需简单运行命令`gka ./workspace/img/ -u`，工具便会自动分析并合并相同帧，让不同动画共享这部分图片资源，从而大幅减小总体积。 通过这个具体的优化实践，文章不仅展示了一个实用的性能优化思路，也介绍了gka这款高效的帧动画生成与处理工具。
React一线问题十问十答
这篇精选自开源中国问答活动的技术盘点，直面开发者在React实践中踩过的“坑”与真实的困惑。文章通过十个典型问答，覆盖了从入门学习到框架对比、从组件设计到技术选型的多个维度。 作者没有空谈理论，而是结合具体场景给出建议：比如在谈React与Vue时，指出二者会长期并存，关键在于面向问题编程而非局限于框架；在讨论组件设计时，提出应根据库代码与业务代码区分粒度，业务组件保持合理大小。文章也探讨了React的生命周期、SSR的适用场景（如需要SEO的内容类网站）、表单处理的优化思路以及技术选型时对业务形态的考量。 整篇文章的价值在于，它呈现了一线开发者的真实问题图谱与务实的解决思路，对正在使用或考虑引入React的团队有直接的参考意义。
Chrome runtime 不稳定（GC）导致插件绑定事件失败
作者在重构Chrome插件时遇到了一个令人头疼的间歇性问题：插件完成加载后，在初始化绑定`chrome.webRequest`等事件时会概率性失败，控制台抛出`Cannot read property ‘onBeforeSendHeaders’ of undefined`的错误，导致后续逻辑完全中断。尤其是在调试页面时，错误源还会在`extensions::guestViewEvents`和`extensions::runtime`等内部脚本之间反复切换，让人难以定位。 经过排查，问题的根源在于Chrome扩展运行时的不稳定，这很可能与V8引擎的垃圾回收（GC）机制有关。在GC发生时，某些在初始化期间依赖的底层对象或接口可能被意外回收或未就绪，从而导致访问失败。 针对这个棘手的环境问题，作者尝试了包括简化代码、调整生命周期钩子（如onload、DOMContentLoaded）执行顺序等常见方法，但均未奏效。最终，他采用了一个务实但有效的容错方案：在初始化代码外包裹`try-catch`，一旦捕获到异常，就立即触发`location.reload()`进行页面自动重载。由于故障本身是概率性的，通过这种快速的自动恢复机制，可以很大程度上规避初始化失败导致的功能完全不可用。虽然这并非从根源上解决了运行时不稳定的问题，但在这种特定场景下，却是一个能够保障插件可用性的巧妙“妥协”。
了解JS中的全局对象window.self和全局作用域self
这篇文章从初学者常有的疑问切入：JS全局对象window、window.self和直接使用self这几个写法到底有什么区别？文章首先澄清，在普通的Web页面上下文里，它们确实是等价的，仅凭这点self似乎可有可无。 真正的价值区分出现在HTML5时代。随着Service Workers和Web Workers的兴起，JavaScript需要在独立于浏览器主窗口的后台线程中运行，而Worker环境没有“窗口”的概念，因此不存在window对象。此时，self就成为了指代全局作用域的唯一关键。文章通过一个Service Worker注册的实例，清晰地展示了在Worker脚本中，如何通过`self.addEventListener`来监听事件，这正是self的核心应用场景。 简而言之，这篇文章厘清了self从“冗余别名”到“Worker环境基石”的角色转变，帮助开发者理解在不同的运行上下文中应该选择哪个全局引用。对于涉及前端性能优化、离线应用或后台数据处理的开发者来说，这是理解现代Web API一个不可或缺的细节。
Web开发中的响应式图片处理
这篇讲的是移动时代网页图片如何“看人下菜碟”的难题。随着设备屏幕尺寸和像素密度千差万别，传统的三种方案——要么全加载高清图耗流量，要么依赖JS异步加载损SEO，要么靠服务端cookie处理欠灵活——都显得捉襟见肘。 作者详细拆解了HTML5带来的原生解决方案：为img标签添加srcset和sizes属性。核心在于理解“设备CSS像素”、“设备物理像素”和“设备像素比”这三个概念。通过“w”（物理像素宽度）和“x”（像素比）两种描述符，浏览器能自动选择最匹配设备屏幕的图片。文章通过对比实例指出，“w”描述符比“x”更灵活，能精确控制图片在不同屏幕宽度下的显示比例。 最后，文章推荐了一个名为“Responsive Image”的开源工具。它解决了手动准备多套图片的麻烦，通过简单的URL规则（如/crop和/reduce），就能在服务器端动态生成并缓存适配各种设备的图片，实现了灵活性与性能的平衡。
脚本错误量极致优化-监控上报与Script error
这篇讲的是前端监控中一个常见痛点：脚本错误上报后却只拿到一堆无用的“Script error.”信息，无法定位问题。作者以手Q家校群的优化实践为案例，系统梳理了从监控到上报的完整流程。 文章首先厘清了两种核心监控方式：try-catch用于捕获特定代码块的已知错误，而window.onerror则像一张大网，能捕获全局未预料的语法和运行时错误。两者结合，才能高效地构建监控体系。在信息上报环节，介绍了通过动态创建Image标签这类轻量可靠的常见做法。 但文章的重点和亮点在于深入剖析了“Script error”的成因。它揭示了当页面加载并执行跨域脚本（例如CDN上的脚本）时，出于安全策略，浏览器会阻断详细的错误信息传递，只返回一个笼统的“Script error.”。针对这一经典难题，文章指出了根本解法：需要同时在服务器端为跨域JS文件设置正确的CORS响应头，并在客户端为script标签添加crossOrigin属性，这样才能让onerror事件获得完整的错误详情。 对于前端开发者而言，这篇文章的价值在于它不仅讲清了“怎么做”，更讲透了“为什么”，提供了一套可落地的脚本错误监控最佳实践，直接助力提升线上项目的稳定性和问题排查效率。
从工程化角度讨论如何快速构建可靠React组件
这篇讲的是作者从接手一个凌乱的、几乎没有组件复用的业务开始，如何通过工程化手段，系统性地快速构建出可靠React组件的实战经验。文章并非泛泛而谈组件设计，而是聚焦于用规范和自动化来保障效率和质量。 核心方法分为两块：一是建立清晰的目录与命令规范，比如约定好src、dist、example等目录的用途，以及统一start、test、lint等命令；二是搭建自动化工具链，让规范落地。作者详细介绍了如何配置webpack和开发服务器来搭建流畅的组件调试环境，以及如何使用babel或webpack打包library来区分开发依赖与组件依赖，并处理样式文件，最终通过npm publish完成发布。 整篇文章提供了一套可直接复用的组件工程化方案，从目录结构、命令模板到构建配置都有具体示例，对希望提升前端团队组件开发效率与质量的读者有很强的参考价值。
Omi应用md2site发布-markdown转网站利器
这篇讲的是腾讯AlloyTeam基于其Omi框架发布的一款名为`md2site`的开源工具。如果你正需要将一堆Markdown文档（比如技术文档、博客文章）快速整理并生成一个结构清晰的网站，它提供了一个轻量而强大的解决方案。 `md2site`的核心优势在于“轻巧”与“开箱即用”。生成的网站除Omi外不依赖任何第三方库，体积非常小。它完整支持Markdown语法，并天生具备响应式布局和多语言能力，只需在配置文件中稍作修改即可切换。代码高亮也做得很细，甚至能支持代码块内特定行的高亮，让技术内容的呈现更加清晰。 使用上非常简单，通过`npm install`安装后，用`md2site init`命令即可初始化项目。在指定的`docs`目录下编写Markdown文档，并在`config.js`中配置好目录树，通过`npm run dev`就能实时预览，`npm run dist`一键打包生成网站。文章最后还展示了其扩展的Markdown语法特性，让生成的文档效果更出彩。 对于想快速搭建技术文档站或个人博客的开发者来说，`md2site`或许是个值得一试的轻量级选择。
