最新 5 篇文章

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

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

---

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

从小到大，我们被告知：

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

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

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

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

---

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

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

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

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

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

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

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

---

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

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

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

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

---

但别做傻事

断食不是挨饿竞赛。

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

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

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

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

然后我看到了它。

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

---

原来我一直在骗自己

报告里说：

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

7年。

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

AI 毫不客气地戳穿：

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

我盯着这句话看了很久。

它说的对。

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

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

然后，项目就进了坟墓。

---

完美主义是个体面的借口

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

但 AI 说得更狠：

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

操。

这话说得太准了。

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

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

一开始我想的还是传统的方式，比如通过添加类，或是在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高了。

背景

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

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

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

实现思路

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

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

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

因此，开发插件的关键在于理解 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 工具，可在本地模拟完整校验流程： … 查看更多

hello~