跳到正文

Hexo

Happy DOM 为什么会误判复杂的 not 选择器

一条 CSS 想排除评论区域里的节点，可以写成 .item:not(.comments *)。它在浏览器里只选中区域外的 .item，但放进 Happy DOM 测试，区域里的节点也被选中了。 这次差异不依赖点击、异步渲染或框架。只创建三个元素，第一次调用 matches() 就能复现。顺着源码看，:not() 参数里的完整后代关系在解析结构转换时被截短了，后面的匹配器检查了一个与原规则不同的条件

Stylus 嵌套选择器的逗号为什么会编译错

把两组选择器合到 :is() 里，再往下写一层嵌套，本来是很自然的整理方式。但在 Stylus 0.64.0 中，这次整理可能改变最终 CSS 的含义：一个分支的直接子元素不再命中，另一个分支仍然正常，构建过程却没有报错。 这个问题容易被误判成 CSS 权重、动态 class 或 DOM 结构变化。它的特殊之处在于，产物甚至可以是合法 CSS；浏览器忠实执行了产物，只是产物已经不再表达源码原来的意

我所理解的 UnoCSS 最佳实践

我想用原子 CSS 提高写样式的效率，但又希望打开 Vue 的 template 时，看到的是组件结构和元素职责。这两个要求可以同时满足：模板保留语义化的 BEM class，SCSS 负责组织选择器，UnoCSS 通过 @apply 展开具体样式。 最近做一个 Vue / Nuxt 项目时，我围绕这套写法调整了预处理器、变量、响应式、主题和组件边界。过程中也遇到了几个值得留下的坑：工具类名字看起

第三方页面适配：CSS 先处理外观，JS 再修正行为

打开一段异步加载的评论，某个词先以蓝色链接出现，随后又变成普通文字。最终结果没有错，但这一下颜色变化很显眼。深色弹窗先露出白底、搜索框先出现推荐词、内部滚动条先显示原生样式，也可能属于同一类问题：目标样式要等脚本发现节点、判断类型、写入标记之后才能生效。 做浏览器扩展和用户脚本时，我们通常不能修改原站组件，却可以提前声明样式。只要节点原本就带着足够的识别信息，外观便可以直接交给 CSS；需要解析地

浏览器能打开，Python 却报证书错误：一次 HTTPS 证书链排障

整理博客资料时，Matrix67 在浏览器里能打开，Python 却报证书校验失败。排查发现服务器只发送了站点证书，客户端需要另找中间证书才能构建可信路径。记录 OpenSSL 取证、系统证书库与原生链构建的区别，以及使用 truststore 后默认 Python 也恢复成功的复测变化，说明服务端补链、客户端兼容和关闭验证之间的边界。

Chrome executeScript 为什么拿不到外层变量：注入函数的序列化边界

扩展的 Popup 或 service worker 里定义了一个常量，再把用到它的函数交给 chrome.scripting.executeScript()，编辑器没有报错，普通函数调用也正常。真正注入页面时，却出现 ReferenceError。 问题出在执行边界：Chrome 传过去的是函数的序列化结果，原来模块的词法环境不会一起进入目标页面。 看起来是回调，实际已经离开模块const st

模块入口与 import 后缀：公开 API 和运行环境要分别判断

import 路径同时表达两件事：调用方从哪个公开入口拿能力，以及运行环境怎样找到文件。把这两件事混在一起，容易把「所有地方都不写后缀」或「每个目录都建 barrel」当成统一规范。 我主导的项目里，会用目录入口管理稳定模块公开面；前端 bundler 源码通常省略本地源码后缀。维护其他项目时，先沿用它已有的明确规范和稳定写法。Node ESM 的解析要求则需要单独满足。 用 index.ts 声

单行省略为什么会裁掉字：line-height、字形和 overflow 的边界

昵称和表格单元格常用单行省略。有时省略号正常出现，字母底部或重音却少了一截。开发者容易先改宽度，甚至换成 JavaScript 截字符串；真正需要看的往往是行高和裁切区域。 省略号只处理行内溢出常见的 truncate 对应 overflow: hidden、text-overflow: ellipsis 和 white-space: nowrap。它解决的是横向空间不足，没有承诺字形在垂直方向一

环境变量怎么管理：共用配置、个人覆盖与框架差异

两个人开发同一个项目，API 地址和功能开关大体相同，代理端口、调试服务和测试账号却各有各的设置。如果这些值都放在一份受 Git 追踪的 .env 里，改一次本机代理就会出现一个不该提交的 diff；顺手提交后，另一位开发者拉取代码，还要把自己的配置改回来。 把所有 .env 文件都忽略，又会遇到另一种麻烦：项目新增一个共用配置，代码已经同步，配置却还要另行通知。.env.example 如果只在

前端请求方案选型：fetch、Axios 与服务端状态管理

用户列表页需要加载数据，搜索框需要在输入变化后重新请求，编辑资料后还要更新详情和列表。第一次实现时，每个功能都可以从一个 fetch() 开始；等这些功能放到同一个应用里，问题就逐渐变成了：两个组件会不会重复请求，页面回来时能不能先显示旧数据，保存成功后哪些地方需要更新。 这些问题经常被一起归进「请求封装」。于是，原生 fetch、Axios、React Query、SWR、各种 useReque

从搜索动效原型到 Nuxt 应用：滚动、正文渲染和工程边界

做这个搜索工具时，我先找了一份喜欢的动效参考：The Collaboratory — Refine Search。输入框从首页移到结果页，资料旁边有相关、不相关和收藏操作，选中的资料再进入细化面板。这套交互比单纯堆一个搜索框和列表更有意思，适合做一个可以逐步整理线索的小工具。 演示数据很容易把效果撑起来。真正接上搜索接口，问题才陆续出现：一篇长摘要让整个弹窗开始滚动，标题和关闭按钮一起消失；上游文

固定输入框里一打字，页面就往上跳：scroll-padding 与焦点滚动

搜索结果页往下滚了一段，顶部搜索框仍然可见。点进去补几个字，下面的结果却跟着往上跳；继续输入，页面会一步步退回顶部。 这个问题出现在一个 Nuxt 搜索页面里。起初值得怀疑的地方不少：输入会更新字符计数，筛选条件显示成标签，Header 使用 sticky，页面还接了 OverlayScrollbars。测量以后发现，搜索框的位置和尺寸一直没变，变的是文档的 scrollY。 最终修复只有一行：删

桌面快捷方式为什么找不到脚本：一次 MSIX 文件系统虚拟化排查

给 Windows 上的 WSL 装好 KDE 桌面后，我希望像打开普通软件一样，双击桌面的「Ubuntu KDE Plasma」就能进入 Linux 桌面。启动器负责唤起后台服务，再用 Edge 的独立窗口打开 noVNC。 桌面本身已经能用了，快捷方式却反复出问题：最早提示「无法找到脚本文件」，换成 CMD 启动器后，又表现为双击没有反应，或者命令窗口一闪而过。奇怪的是，让 Codex 执行同

在 WSL 中用 noVNC 操作 KDE Wayland：一次嵌套桌面的实践

在 Windows 上装好 WSL 和 KDE，再把桌面放进浏览器，看起来已经很接近一台普通的 Linux 电脑：有任务栏，可以打开应用，也可以最小化、最大化窗口。 但在 4K 屏幕上用起来，问题接连出现。画面铺满了，字却不一定清楚；分辨率提高了，按钮又变得很小；在 KDE 设置里修改缩放，关闭 noVNC 再打开，界面还是老样子。 我因此想把原来的 KDE X11 会话换成 Wayland，继续

Happy DOM 和 jsdom：差异、选型与测试迁移

把 DOM 测试从 jsdom 切到 Happy DOM，通常只需要改一个配置项。但测试跑起来之后，原来预期的 "0px" 变成了 "0"，弹窗 mock 找不到目标方法，还有一个 HTML 解析用例读不到正文里的耗时了。 这几种失败看起来都是「换库以后坏了」，原因却不同。有的是断言绑定了字符串格式，有的是外部依赖没有显式控制，还有的是模拟器对标准行为的实现有偏差。仅仅把 expected 改成新

Regex Tuesday 题解

Regex Tuesday 是 Callum Macrae 做的一组在线正则练习。每道题都有一组输入和预期结果，可以直接在页面里填写正则，看哪些用例通过、哪些没有通过。题型分为匹配和查找替换两类，内容从重复单词、日期、URL，到元素符号、音乐和国际象棋记号，适合用来练习把文字规则变成正则。 偶然发现这个网站以后，我把里面的 20 道题逐一做完，也记录了解题时用到的规则和踩过的坑。最新一题发布于 2

浏览器如何识别网页、图片和下载：MIME、Content-Type 与内容嗅探

浏览器收到响应后，怎样决定渲染网页、展示图片，还是下载文件？MIME 类型提供声明，内容嗅探处理部分缺失或错误信息，加载场景与安全规则继续限制使用方式。结合 Chrome 实验，可以看清扩展名、类型响应头、下载指令和文档属性各自的作用，解释脚本类型报错、图片解码失败与上传校验中的常见误区。

如何获取 URL 参数：原生 API、工具库与路由的选型

打开详情页，要知道展示哪条记录；进入活动页，要知道用户从哪个入口过来；登录完成，还要回到之前的页面。把这些信息放进 URL，链接就能携带上下文，复制给别人、刷新页面或在新标签中打开时，目标页面仍然知道该做什么。从 URL 里读取参数，是前端开发里再普通不过的一件事。 读取这些参数，可以用浏览器原生的 URLSearchParams，也可以用 qs、query-string 或 ufo 这样的工具库

正则为什么会卡死：ReDoS、非回溯引擎与 ESLint 护栏

一个校验函数只有一行正则，输入正常时几乎感觉不到耗时；把输入末尾换成一个不符合规则的字符，它却可能长时间占满 CPU。表达式没有死循环，字符串也未必有多长，问题出在匹配失败之前，引擎尝试了太多条路径。 这种问题叫 ReDoS（Regular expression Denial of Service，正则表达式拒绝服务）。攻击者让程序花费大量时间匹配特定输入，正常请求因此无法及时得到处理。业务代码固

给 Markdown 文档接入 textlint：加粗、术语和异常字符检查

一篇 Markdown 文章能正常生成网页，并不意味着里面的格式和用词都符合预期。双星号可能作为普通文字留在页面上，产品名称可能有几种拼法，从网页复制来的文字还可能夹着看不见的字符。 此前整理中文加粗为什么会露出星号时，我关注的是解析器为什么不接受某种写法。写文章时还需要另一层反馈：保存或提交之前，工具能不能直接指出那一行有问题？ textlint 提供了这样的检查框架。它的工作方式与 ESLin

设计组件库时需要考虑什么：从通用 UI 到业务组件

面试里问「如果让你设计一个组件库，需要考虑什么」，很容易从 TypeScript、打包工具、按需加载一路讲到单元测试。这些都需要考虑，但在选工具之前，还有一个决定后续设计的问题：准备把什么东西复用起来？ 按钮、下拉框复用的是视觉和交互；查询表格复用的是查询、分页、排序等页面模式；店铺选择器复用的则可能是店铺身份、可选范围、历史值回显和业务限制。它们都叫组件，承担的责任却不一样。 知乎这道关于组件库

React、Vue 2 与 Vue 3 的 DOM Diff：从节点身份到最长递增子序列

最近一道前端面试题问到了 React、Vue 2 和 Vue 3 的 DOM Diff。这个问题既涉及列表如何重排，也涉及更基础的更新：同一个按钮改了 class 与文本，是否重建 DOM；把 div 换成 section，原来的子组件状态还在不在；同一种组件收到新 props，和换成另一种组件又有什么区别。 这些场景需要先回答「旧节点与新节点是否属于同一个身份」，再决定更新什么。列表还多了一层顺

Vue 的 VNode 生命周期事件：在模板里监听子组件挂载

Vue 有一些不太常见的写法。比如，我们可以直接在组件标签上监听它的挂载： <Child @vue:mounted="onChildMounted" /> 日常写组件时，生命周期通常出现在 mounted()、onMounted() 这些位置。模板里的 @ 除了监听点击、输入或子组件发出的业务事件，也能让父组件在使用子组件的地方，监听这个子组件对应节点的生命周期。 这个能力由 Vue 自身提供，官

无法接入虚拟滚动时，怎样减少长列表的屏外渲染

一个不断加载内容的列表，滚得越久，页面里的卡片就越多。理想的处理方式是让列表组件只挂载视口附近的节点，也就是虚拟滚动。但有时列表由第三方组件或现成页面管理，我们只能给已有 DOM 加样式和少量脚本，碰不到它的数据源、分页状态与节点复用逻辑。 这种约束下，仍然可以减少一部分浏览器工作：保留卡片及其占据的空间，让浏览器暂时跳过远离视口的内容布局和绘制。负责这件事的是 content-visibilit

中文加粗为什么会露出星号：Markdown 的标点边界与 AI 输出

最近让 Codex 把一个约 100 GB 的本地 AI 项目迁到另一块硬盘。任务结束后，它给了一段完成说明：项目已经从新位置启动，模型和视频预览正常，旧目录还需要清理。 说明里的列表、链接都能正常显示，偏偏最后一句想要加粗的提醒露出了星号。 这种问题很容易被当成偶发的界面毛病。内容是通顺的，星号也成对出现了，为什么只有这一小段格式失效？我此前在一段关于中文 Markdown 加粗的公开讨论里也追

让 Codex 调用普通 ChatGPT：一次本地代理链路验证

看到网罗灯下黑的《不加钱，把 ChatGPT 几乎无限的网页额度当 Codex 用》后，我想验证另一种接法：继续在本地 Codex 里读文件、执行命令、改代码，把模型请求转给普通 ChatGPT。 这样既不用把工作搬到网页，也能保留 Codex 的本地执行环境。CC Switch 可以帮忙改配置，不过我更想知道，能不能直接启动一个本地服务完成转发。 2026 年 10 月 5 日，Codex 通过

把 QQ 超级调色盘的配色导出来：从原生模块到可复用数据

QQ 的设计团队在「超级调色盘」里准备了多套成组的界面配色，主色、背景、聊天气泡和浅色、深色模式都有对应安排。它们可以给其他 App 的设计提供参考：既能观察现成配色如何协调，也能研究主题算法怎样把一个基础色展开成整套颜色。 Windows QQ 9.9.36-53644 的「超级调色盘」配置里，提取到了 7 个系列、37 个固定配色条目：17 套静态配色保存了浅色、深色模式的主色、背景和气泡色；

给 AI 写的 Markdown 做批注：CriticMarkup、MarkMark 和 Windows 工作流

最近用 Codex 写文档、方案和博客草稿时，有一个反馈动作越来越别扭：我明明是在改一篇 Markdown，却经常要回到聊天框里写「第 37 行那句话删掉」「第 52 行改成另一种说法」。 这套反馈方式把文章当成代码补丁来处理。文章里的问题常常落在段落、证据、标题和例子上：一段表达方向不对，一个概念需要补证据，一个标题该收紧，一个例子该换掉。只用行号描述，反馈者要费力定位，Agent 也要重新理解