bilipan's Weblog

编写 ESLint 插件（上）

2025-11-03T00:00:00Z

背景

最近在团队内落地统一规范时，需要保证“每个 SFC 模板至少包含一个 data-xxx 或 v-data-xxx”这类规范。研究了下，可选方案有三种：

文档宣导，依赖自觉
Code Review 阶段全局扫描
在提交前通过自动化工具拦截

第三种方案接入成本低、反馈路径短，是目前工程化实践中的首选。实现手段通常有两种：编写构建插件（vite/webpack）或编写 ESLint 插件。后者配置统一、生态成熟，更利于长期维护，语义上也更符合 ESLint 场景。

实现思路

（ESLint 插件的完整规范可参考官方文档，本文仅聚焦关键步骤。）

ESLint 的核心流程可简化为三步：

解析器把源码生成 AST
插件基于 AST 做规则校验
若命中规则，则上报错误或警告

因此，开发插件的关键在于理解 AST 结构，并针对目标节点编写访问逻辑。

Vue 文件解析

在 Vue 工程里，构建侧常用 @vue/compiler-sfc。编写规则时，应改用 vue-eslint-parser，它专门处理 .vue 单文件，仅解析 <template> 区块并提供 template visitor，可直接在插件中使用。

规则实现示例

需求：模板中至少有一个 DOM 元素或自定义组件带 data-xxx 属性或 v-data-xxx 指令。

module.exports = {
  meta: {
    type: 'problem',
    docs: {
      description: 'Enforce at least one data-xxx or v-data-xxx attribute in template',
      category: 'Best Practices',
      recommended: true
    },
    fixable: null,
    schema: []
  },
  create(context) {
    return {
      /*
       * 只能匹配“指令”属性（v-data-xxx），若要同时检测普通 DOM 属性（如 data-xxx），需再写一条非指令属性选择器：
       * 'VAttribute[directive=false][key.name^="data-"]'(node) { ... }
       * 'VAttribute[directive=true][key.name.name^="data-"]'(node) {...}
       * 改用 VElement 统一检查所有属性，无需区分指令与普通 DOM 属性
      */
      VElement(node) {
        const hasDataAttr = node.startTag.attributes.some(attr => {
          const name = attr.directive ? attr.key.name.name : attr.key.name
          return name.startsWith('data-')
        })
        if (!hasDataAttr) {
          context.report({
            node,
            message: 'Template must contain at least one data-xxx or v-data-xxx attribute'
          })
        }
      }
    }
  }
}

用例测试

ESLint 提供 RuleTester 工具，可在本地模拟完整校验流程：

const { RuleTester } = require('eslint')
const rule = require('./require-data-xxx-attributes')

const tester = new RuleTester({
  parser: require.resolve('vue-eslint-parser')
})

tester.run('require-data-xxx-attributes', rule, {
  valid: [
    { code: '<div data-xxx></div>' },
    { code: '<div v-data-xxx></div>' },
    { code: '<custom data-xxx></custom>' }
  ],
  invalid: [
    { code: '<div></div>', errors: [{ message: 'Template must contain at least one data-xxx or v-data-xxx attribute' }] },
    { code: '<custom></custom>', errors: [{ message: 'Template must contain at least one data-xxx or v-data-xxx attribute' }] }
  ]
})

发布与集成

插件开发完成后，发到 npm 即可。另外，最好将 eslint 声明为 peerDependencies，毕竟eslint并不是插件的直接依赖。

后续

理解 ESLint 工作原理后，插件本身的编码并不复杂。但在真实业务落地时，仍需解决「仅对 .vue 生效」「组合多条规则」「提供统一配置入口」等细节。这些主题将在下篇展开。

超简单的主题切换技巧

2025-11-05T00:00:00Z

原先这个网站的代码高亮主题是默认暗色的，但是考虑到网站本身已经支持了跟随系统主题自动切换，所以为了保持统一，准备将代码高亮主题跟系统主题自动同步。

一开始我想的还是传统的方式，比如通过添加类，或是在css中添加media查询来实现。后来让AI去实现这个功能时，发现了一个更简单的方式，直接在<link />标签中添加media属性，利用prefers-color-scheme媒体查询在不同的系统主题下加载不同的样式。

<link rel="stylesheet" href="https://unpkg.com/prismjs@1.29.0/themes/prism.css" media="(prefers-color-scheme: light)">
<link rel="stylesheet" href="https://unpkg.com/prismjs@1.29.0/themes/prism-okaidia.css" media="(prefers-color-scheme: dark)">

分析了下这个方案，发现了一些有趣的细节。

当页面为亮色主题时，会同时下载prism.css和prism-okaidia.css，但是没有命中的media（暗色主题）不会参与渲染（也就不会阻塞渲染）。
虽然两个主题文件都会下载，但是它们的优先级不一样，比如当页面为亮色主题时，prism.css比prism-okaidia.css的优先级高。
如果此时切换为系统或浏览器的主题为暗色，则prism-okaidia.css会命中media，就直接渲染了。
如果是刷新页面（比如当前系统主题为暗色），两个主题文件会重新下载，但是由于浏览器的缓存机制，所以一般情况下不会重新请求。此时，prism-okaidia.css的优先级就比prism.css高了。

我的 AI 当着面骂了我一顿

2025-11-13T00:00:00Z

那天早上，我照例送完孩子，在公园里溜达。

阳光穿过树叶，斑驳的光影打在地上。我打开 flomo，想随便记点什么。

然后我看到了它。

AI 给我生成了一份"洞察报告"——说的全是我，但比我更了解我自己。

原来我一直在骗自己

报告里说：

"从2018年那个未发布的应用开始，你就明白'能跑就发'的道理。但奇怪的是，7年过去了，你还在笔记里反复告诫自己——'快速发布'、'别追求完美'。"

7年。

同样的教训，我写了不知道多少遍。

AI 毫不客气地戳穿：

"你的认知已经到位，但执行时总被'还没准备好'的心态羁绊。"

我盯着这句话看了很久。

它说的对。

我知道该快速发布，但每次到临门一脚，我就会想：

"这个功能还没优化好..."
"界面可以再精致一点..."
"等我把这个技术栈研究透..."

然后，项目就进了坟墓。

完美主义是个体面的借口

我以前以为这是对技术的执着。

但 AI 说得更狠：

"你不断涌出的新想法和对新技术的探索，可能是一种逃避——用规划替代行动，用可能性取代交付成果。"

操。

这话说得太准了。

学新技术很爽，因为你在"进步"。写计划很爽，因为你在"准备"。但真正的发布？那意味着可能被评判、可能失败。

所以我一直"准备"，从不"交付"。

代价不只是没发布的项目

AI 还指出了我更不想面对的东西：

"这种延迟发布的习惯，已经在生活的其他领域产生连锁反应。"

我开始回想。

工作上，我越来越麻木——因为一直在为别人的项目赶 deadline，自己的却永远"明天再说"。

家庭里，我愧疚陪伴时间太少——因为下班后的时间都被"还没准备好"的个人项目吞噬了。

最可怕的是——我开始怀疑这些时间投入的价值。

如果7年前那个应用发布了，现在会怎样？如果每次"准备"的时间都用来迭代，我现在会有多少产品？

这些问题，我不敢深想。

所以，怎么破？

好消息是，AI 也看到我的出路了。

"你早已总结出应对之策：熟悉的技术栈、可复用的模板、让 AI 处理杂事。"

对，我知道怎么做。

但知道和做到之间，差着一整个太平洋。

真正的问题不是技术能力，而是我对"未完成"状态的容忍度。

我要的不是更多准备，而是更短的交付周期。

我的新实验

读完那份 AI 报告，我做了一个决定：

下一个想法，不管做成什么样，1周内必须发布。

粗糙？没关系。没人用？没关系。被嘲笑？也没关系。

发布本身，就是胜利。

因为7年了，我总算明白：

产品的成败与投入的工作量没有必然联系。真正值得交付的，不是完美代码，而是为用户解决问题的能力。

给同样拖延的你

如果你也像我一样：

笔记里写满了"道理"，生活里重复同样的错误
永远在"准备"，从不"交付"
用新想法逃避真正的行动

试试这个：

找一个你信任的工具，让它"审视"你的记录。

不是让它帮你整理，而是让它点破你的模式。

有时候，我们需要的不是更多建议，而是被当面戳穿。

现在，去发布那个"还没准备好"的东西吧。

它永远不会准备好的。

我不再吃三餐了

2025-12-04T00:00:00Z

不是因为穷，不是因为忙。

是因为我终于理解了身体这台机器的真实运作逻辑。

我们被"一日三餐"骗了太久

从小到大，我们被告知：

早餐要吃好
午餐要吃饱
晚餐要吃少

但没人告诉你：每一次进食，身体都在切换模式。

你吃完早餐，身体进入「储能模式」——忙着把碳水变成糖原，存进肝脏。你刚吃完午餐，它还没处理完早餐。晚餐又来了。

你的消化系统像个996的打工人，永远没有「大扫除」的时间。

脂肪燃烧的开关藏在哪里？

这里有个反直觉的事实：你的身体不愿意燃烧脂肪。

脂肪是你祖先留给你的「末日储备粮」，只有糖原耗尽时，身体才会不情愿地分解脂肪，产生酮体供能。

问题是——你从未给过它这个机会。

三餐+零食，让你的血糖永远在波动，糖原永远有库存。脂肪？锁得死死的。

14/10轻断食的核心就一句话：

给身体14小时不进食的时间，让它被迫动用脂肪。

自噬：身体的深度清洁模式

还有一个更少人知道的好处：自噬。

当你进食时，身体忙着消化，没空打扫卫生。断食10-14小时后，糖原耗尽，身体终于闲下来，开始「大扫除」——清理衰老细胞、修复受损组织、降低炎症。

这不仅是减肥，这是细胞层面的抗衰。

但别做傻事

断食不是挨饿竞赛。

时间太短（<10小时），糖原没耗尽，脂肪不燃烧。时间太长（>16小时），代谢可能变慢，还容易报复性暴食。

14小时断食+10小时进食窗口，是可执行性和效果的平衡点。

我的做法

晚上8点后不吃东西
早上10点后开始第一餐
断食期间只喝水、黑咖啡
进食窗口正常吃，但控制碳水和总热量

不是节食，是重新安排进食时间。

最后

现代人最大的问题不是吃得太多，而是吃得太频繁。

给你的消化系统放个假。让脂肪有机会离开你的身体。让细胞有机会自我修复。

你不是在断食，你是在夺回身体的控制权。