Welcome to labtab — my new personal blog built with Jekyll and deployed on GitHub Pages.

This blog features a custom dark theme with neumorphism and glassmorphism design elements, inspired by the Orion UI Kit aesthetic.

What You’ll Find Here

I’ll be writing about:

• Web development techniques and best practices
• Software engineering insights
• Design systems and UI/UX explorations
• Open source contributions and discoveries

How This Blog Works

This blog is powered by Jekyll, a static site generator that transforms Markdown files into a beautiful website.

Adding a New Post

To create a new post, simply add a Markdown file to the _posts directory with the following naming convention:

YYYY-MM-DD-your-post-title.md

Each post starts with front matter like this:

---
layout: post
title: "Your Post Title"
date: 2026-05-17 10:00:00 +0800
categories: [Category]
tags: [tag1, tag2]
toc: true
comments: true
---

Code Highlighting

The blog supports syntax highlighting for various languages:

function greet(name) {
  console.log(`Hello, ${name}!`);
  return { message: 'Welcome to labtab' };
}

def fibonacci(n):
    """Generate fibonacci sequence."""
    a, b = 0, 1
    for _ in range(n):
        yield a
        a, b = b, a + b

Features

Here’s what’s included in this blog:

1. Search — Press Ctrl+K to search through all posts
2. Categories & Tags — Organized content navigation
3. Comments — Powered by Giscus (GitHub Discussions)
4. Responsive — Looks great on all devices
5. Dark Theme — Easy on the eyes with purple-blue accents

“The best way to learn is to build and share.” — A wise developer

What’s Next

Stay tuned for upcoming posts. I’m excited to share my journey and learnings with you.

Thanks for reading! Feel free to leave a comment below.

A well-configured development environment can significantly boost your productivity. In this post, I’ll share my current setup and the tools I find essential.

Essential Tools

Terminal

A good terminal is the foundation of any dev setup. Here are my recommendations:

• Windows Terminal — Great for Windows users, supports tabs and panes
• iTerm2 — The gold standard for macOS
• Alacritty — Cross-platform, GPU-accelerated

Code Editor

Visual Studio Code remains my editor of choice for its extensibility and performance:

{
  "editor.fontSize": 14,
  "editor.fontFamily": "JetBrains Mono",
  "editor.fontLigatures": true,
  "editor.minimap.enabled": false,
  "workbench.colorTheme": "One Dark Pro"
}

Version Control

Git is non-negotiable. Here are some useful aliases:

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.st status
git config --global alias.lg "log --oneline --graph --all"

Package Managers

Different ecosystems require different package managers:

Conclusion

The key is finding tools that work for you and investing time in configuring them properly. The upfront cost pays dividends in daily productivity.

“First, solve the problem. Then, write the code.” — John Johnson

JavaScript 是单线程语言，但 Web 开发中存在大量耗时操作——网络请求、文件读写、定时器……如果这些操作同步执行，页面会直接”卡死”。

异步编程正是为了解决这个问题：让耗时操作在后台运行，主线程继续响应用户交互。

第一代：回调函数

最早的异步方案，简单直接，但嵌套多层后形成”回调地狱”：

getUserData(userId, function(user) {
  getOrders(user.id, function(orders) {
    getOrderDetail(orders[0].id, function(detail) {
      // 嵌套三层，已经开始混乱...
      renderPage(detail, function(result) {
        // 嵌套四层，维护噩梦 😱
        console.log('done');
      });
    });
  });
});

问题：

• 代码横向增长，难以阅读
• 错误处理复杂，每层都要 if (err) return cb(err)
• 无法使用 try/catch

第二代：Promise

ES6 引入 Promise，将异步操作包装成对象，支持链式调用：

getUserData(userId)
  .then(user => getOrders(user.id))
  .then(orders => getOrderDetail(orders[0].id))
  .then(detail => renderPage(detail))
  .then(result => console.log('done'))
  .catch(err => console.error('出错了:', err));

核心状态机：

pending → fulfilled (成功，触发 .then)
pending → rejected  (失败，触发 .catch)

手写一个简单的 Promise：

class MyPromise {
  constructor(executor) {
    this.state = 'pending';
    this.value = undefined;
    this.handlers = [];

    const resolve = (value) => {
      if (this.state !== 'pending') return;
      this.state = 'fulfilled';
      this.value = value;
      this.handlers.forEach(h => h.onFulfilled(value));
    };

    const reject = (reason) => {
      if (this.state !== 'pending') return;
      this.state = 'rejected';
      this.value = reason;
      this.handlers.forEach(h => h.onRejected(reason));
    };

    try {
      executor(resolve, reject);
    } catch (e) {
      reject(e);
    }
  }

  then(onFulfilled, onRejected) {
    return new MyPromise((resolve, reject) => {
      this.handlers.push({
        onFulfilled: (value) => {
          try { resolve(onFulfilled(value)); } catch(e) { reject(e); }
        },
        onRejected: (reason) => {
          try { resolve(onRejected ? onRejected(reason) : Promise.reject(reason)); } catch(e) { reject(e); }
        }
      });
    });
  }
}

第三代：async/await

ES2017 的语法糖，让异步代码写起来像同步代码：

async function fetchUserPage(userId) {
  try {
    const user = await getUserData(userId);
    const orders = await getOrders(user.id);
    const detail = await getOrderDetail(orders[0].id);
    const result = await renderPage(detail);
    console.log('done');
    return result;
  } catch (err) {
    console.error('出错了:', err);
    throw err;
  }
}

并行执行多个请求：

// 顺序执行（慢）
const user = await getUser(id);
const settings = await getSettings(id); // 等 user 完成后才执行

// 并行执行（快）
const [user, settings] = await Promise.all([
  getUser(id),
  getSettings(id)  // 同时发起
]);

常用 Promise 工具方法

超时控制示例：

function withTimeout(promise, ms) {
  const timeout = new Promise((_, reject) =>
    setTimeout(() => reject(new Error('请求超时')), ms)
  );
  return Promise.race([promise, timeout]);
}

const data = await withTimeout(fetchData(), 5000);

最佳实践

1. 避免在 async 函数中使用 forEach，改用 for...of 或 Promise.all
2. 总是处理 rejected 状态，否则会产生未捕获的 Promise 异常
3. 适当使用并行，await 是顺序执行，多个独立请求应该并行

// ❌ 错误：串行执行，慢
for (const id of userIds) {
  await processUser(id);
}

// ✅ 正确：并行执行，快
await Promise.all(userIds.map(id => processUser(id)));

掌握异步编程是 JavaScript 进阶的必经之路。从回调到 async/await，每一代方案都是对前一代痛点的改进。

设计系统不只是 UI 组件库，它是团队共同遵守的设计语言——包括颜色规范、字体比例、间距系统、交互规则。

一个好的设计系统能做到：

• 保证 UI 视觉一致性
• 加速开发（复用而非重复）
• 降低沟通成本（设计师与开发者说同一种语言）

第一步：Design Tokens（设计令牌）

Design Tokens 是设计系统的原子，将抽象的设计决策存储为具名变量。

颜色系统

不要直接使用颜色值，要赋予语义：

// ❌ 反例：硬编码颜色
.button { background: #6c63ff; }

// ✅ 正例：语义化命名
:root {
  /* Primitive tokens（基础颜色） */
  --color-purple-500: #6c63ff;
  --color-purple-600: #5a52e0;
  --color-blue-500:   #3b82f6;

  /* Semantic tokens（语义颜色） */
  --color-primary:     var(--color-purple-500);
  --color-primary-hover: var(--color-purple-600);
  --color-bg-base:     #0f0a1e;
  --color-text-primary: #e8e6f0;
}

.button { background: var(--color-primary); }

间距系统

使用 4px 基础单位（base-4 系统）：

:root {
  --space-1: 0.25rem;   /* 4px */
  --space-2: 0.5rem;    /* 8px */
  --space-3: 0.75rem;   /* 12px */
  --space-4: 1rem;      /* 16px */
  --space-6: 1.5rem;    /* 24px */
  --space-8: 2rem;      /* 32px */
  --space-12: 3rem;     /* 48px */
  --space-16: 4rem;     /* 64px */
}

字体比例

使用模块化比例（Modular Scale），本例采用 1.25 比例（Major Third）：

:root {
  --text-xs:   0.64rem;   /* 10.2px */
  --text-sm:   0.8rem;    /* 12.8px */
  --text-base: 1rem;      /* 16px   */
  --text-lg:   1.25rem;   /* 20px   */
  --text-xl:   1.563rem;  /* 25px   */
  --text-2xl:  1.953rem;  /* 31px   */
  --text-3xl:  2.441rem;  /* 39px   */
}

第二步：组件设计

Button 组件

一个完整的 Button 应该覆盖所有状态（default, hover, focus, active, disabled）和变体（primary, secondary, ghost）：

.btn {
  /* 基础样式 */
  display: inline-flex;
  align-items: center;
  gap: var(--space-2);
  padding: var(--space-2) var(--space-4);
  border-radius: 0.5rem;
  font-weight: 500;
  font-size: var(--text-sm);
  cursor: pointer;
  border: 1px solid transparent;
  transition: all 0.2s ease;

  /* Focus 可访问性 */
  &:focus-visible {
    outline: 2px solid var(--color-primary);
    outline-offset: 2px;
  }

  /* Disabled 状态 */
  &:disabled {
    opacity: 0.5;
    pointer-events: none;
  }

  /* Primary 变体 */
  &--primary {
    background: var(--color-primary);
    color: white;

    &:hover { background: var(--color-primary-hover); }
  }

  /* Ghost 变体 */
  &--ghost {
    background: transparent;
    border-color: var(--color-primary);
    color: var(--color-primary);

    &:hover { background: rgba(108, 99, 255, 0.1); }
  }

  /* Size 变体 */
  &--sm { padding: var(--space-1) var(--space-3); font-size: var(--text-xs); }
  &--lg { padding: var(--space-3) var(--space-6); font-size: var(--text-lg); }
}

Card 组件（复合组件）

.card {
  background: var(--color-surface);
  border-radius: 1rem;
  border: 1px solid var(--color-border);
  overflow: hidden;

  &__header {
    padding: var(--space-4) var(--space-6);
    border-bottom: 1px solid var(--color-border);
  }

  &__body {
    padding: var(--space-6);
  }

  &__footer {
    padding: var(--space-4) var(--space-6);
    border-top: 1px solid var(--color-border);
    background: rgba(255, 255, 255, 0.02);
  }
}

第三步：文档化

每个组件都需要文档，包括：

• 使用场景
• Props/变体说明
• Do & Don’t 示例
• 无障碍注意事项

没有文档的组件库，等于没有路标的城市。

深色模式支持

使用 CSS 自定义属性，深色模式切换只需重新定义根变量：

/* 浅色模式（默认） */
:root {
  --color-bg: #ffffff;
  --color-text: #1a1a1a;
  --color-border: #e5e7eb;
}

/* 深色模式（系统自动或手动切换） */
@media (prefers-color-scheme: dark) {
  :root {
    --color-bg: #0f0a1e;
    --color-text: #e8e6f0;
    --color-border: rgba(168, 139, 250, 0.15);
  }
}

/* 手动切换 */
[data-theme="dark"] {
  --color-bg: #0f0a1e;
  --color-text: #e8e6f0;
}

设计系统是长期投资，初期会增加一些工作量，但随着项目规模增长，它带来的一致性和开发效率提升是巨大的。

工具是手段，不是目的。但合适的工具能让你专注于真正重要的事。这篇文章整理了我 2026 年实际在用的工具栈，每个工具我都说明为什么选它、它解决了什么问题。

编辑器与 IDE

Cursor（主力编辑器）

基于 VSCode，深度集成 AI 辅助编程。我迁移到 Cursor 的核心理由：

• Tab 自动补全整段代码（比 Copilot 更智能）
• Ctrl+K 在文件内直接对话修改代码
• @codebase 可以引用整个项目上下文

我的关键配置：

{
  "editor.fontFamily": "JetBrains Mono",
  "editor.fontSize": 14,
  "editor.fontLigatures": true,
  "editor.formatOnSave": true,
  "editor.wordWrap": "on",
  "workbench.colorTheme": "One Dark Pro Monokai Darker"
}

JetBrains IDE（特定场景）

Java/Kotlin/Go 项目我仍然用 IntelliJ/GoLand，它们的重构支持和调试器远超 VSCode。

终端与命令行

Wezterm

用 Lua 配置的现代终端，替换了我用了三年的 Windows Terminal：

• 原生 GPU 渲染，滚动流畅
• 多路复用（类 tmux，内置）
• 跨平台（Windows/macOS/Linux 同一份配置）

Fish Shell

比 zsh 更友好的 Shell，开箱即用的自动补全：

# config.fish 关键配置
set -gx EDITOR "cursor"
set -gx PATH $HOME/.local/bin $PATH

# 常用 abbreviation（输入即展开）
abbr -a g git
abbr -a gs git status
abbr -a gc git commit -m
abbr -a gp git push

常用 CLI 工具

版本控制

Git + Lazygit

lazygit 是终端里的 Git TUI，让我不再需要 GUI 客户端：

# 安装
winget install jesseduffield.lazygit

# 启动（在任意 git 仓库目录）
lazygit

关键 Git 配置：

[core]
  editor = cursor --wait
  autocrlf = input

[alias]
  lg = log --oneline --graph --all --decorate
  undo = reset HEAD~1 --soft
  wip = commit -am "wip: work in progress"

[pull]
  rebase = true

知识管理

Obsidian

本地 Markdown + 双向链接，数据自己掌控：

• 所有笔记存在本地 .md 文件
• 通过 Git 同步（不依赖官方云服务）
• Dataview 插件：把笔记当数据库查询

我的笔记结构：

vault/
├── inbox/        # 快速捕捉，每日清理
├── projects/     # 进行中的项目
├── areas/        # 持续关注的领域
├── resources/    # 参考资料
└── archive/      # 归档

浏览器

Arc（主力）+ Chrome（测试）

Arc 的 Space 和 Folder 功能改变了我的多任务工作方式：

• 不同项目放不同 Space，切换不串标签
• Command Bar（Cmd+T）直接搜索历史

必装扩展：

• uBlock Origin — 广告拦截
• Vimium C — 键盘控制浏览器
• SteadyFocus — 专注模式，屏蔽干扰网站

其他

• Rectangle Pro（macOS）/ FancyZones（Windows）— 窗口管理
• Raycast — Alfred 的现代替代，快速启动+脚本
• Shottr — 截图标注（macOS）
• Bruno — Postman 替代，接口调试，文件存本地

总结

我的选工具原则：

1. 数据本地化：尽量避免数据锁定在某家云服务
2. 可配置：能适应自己的工作流，而不是被工具牵着走
3. 键盘友好：减少鼠标依赖，提高速度

工具会变，但这三条原则让我在工具选择上少走弯路。

《人月神话》（The Mythical Man-Month）是 Fred Brooks 根据他主导 IBM OS/360 开发的经历写成的。那是 1964 年，离 GitHub 的诞生还有 44 年。

然而这本书里的观点放在今天，仍然刺痛人心。

核心论点：人月不可互换

书名来自软件行业最根深蒂固的谬误：“这个项目延期了，加人就能追回来”。

Brooks 的反驳简洁有力：

“向一个已经落后的软件项目增加人手，只会使它更加落后。”

这就是著名的 Brooks 定律。

为什么？因为软件开发不像搬砖——新人需要培训时间，而且增加人手会增加沟通成本。

如果一个团队有 n 个人，沟通路径的数量是 n(n-1)/2：

• 3 人团队 → 3 条沟通路径
• 5 人团队 → 10 条沟通路径
• 10 人团队 → 45 条沟通路径

人数翻倍，沟通路径增加 4 倍。这些沟通本身就会消耗大量时间。

没有银弹

Brooks 后来补写的章节”没有银弹”（No Silver Bullet）同样振聋发聩：

“在未来十年，没有任何单一的软件工程进展，能够使生产率提高一个数量级。”

他区分了软件复杂度的两种来源：

• 本质复杂度（Essential Complexity）：问题本身固有的难度，无法消除
• 偶然复杂度（Accidental Complexity）：我们引入的工具、语言、流程带来的难度，可以优化

大多数技术进步——高级语言、IDE、框架——只是在减少偶然复杂度。但本质复杂度始终存在，这正是软件依然难做的根本原因。

外科手术式团队

Brooks 提出了一个反直觉的团队结构：与其用 10 个平均水平的程序员，不如用 1 个顶尖程序员加上支持他的几个辅助角色。

这和我们今天说的”10x engineer”遥相呼应。但 Brooks 强调的不只是个人能力，而是减少接口、保持概念完整性：

“概念完整性是系统设计最重要的考量因素。”

一个人脑子里的设计，比 10 个人委员会讨论出来的设计，往往更一致、更优雅。

第二个系统综合症

有趣的心理现象：程序员第一个系统往往因为经验不足，反而简洁克制。到了第二个系统，信心大增，把所有”第一次没敢加”的东西全塞进去，结果做成了大而复杂的怪物。

这不是 50 年前的问题。看看多少开源项目 v2 重写把 v1 的简洁全丢掉了？

今天还有什么意义？

读完这本书，我的体会：

1. 进度估计要诚实：软件估时的艰难不是因为程序员懒惰，而是不确定性本质上难以量化
2. 小团队更高效：Spotify、Amazon 的”two-pizza team”原则，本质上就是 Brooks 几十年前说的
3. 警惕复杂度积累：每加一个依赖、每多一个抽象层，都在增加偶然复杂度
4. 文档是系统的一部分：Brooks 花大量篇幅讲文档，因为代码只解释”怎么做”，不解释”为什么”

“乐趣在于做出东西……痛苦在于，要做出别人真正需要的东西，而不只是自己觉得有趣的东西。”

这句话值得每个工程师贴在显示器旁边。

书籍信息： 《人月神话》，Fred Brooks，1975 年初版，推荐读带”没有银弹”章节的 20 周年纪念版。

• CI（持续集成）：每次代码提交后自动运行测试，快速发现问题
• CD（持续部署）：测试通过后自动部署到生产环境

GitHub Actions 将这两者整合在一起，配置文件直接存在仓库里，版本可追踪。

基础概念

# .github/workflows/ci.yml
name: CI Pipeline

on:                         # 触发条件
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:                     # 一个 Job
    runs-on: ubuntu-latest  # 运行环境
    steps:                  # 步骤列表
      - uses: actions/checkout@v4
      - run: npm test

核心概念对应关系：

实战：Node.js 项目完整流水线

name: Full CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: $

jobs:
  # =====================
  # Job 1: 代码质量检查
  # =====================
  lint:
    name: Lint & Type Check
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run ESLint
        run: npm run lint

      - name: Run TypeScript check
        run: npm run typecheck

  # =====================
  # Job 2: 单元测试
  # =====================
  test:
    name: Unit Tests
    runs-on: ubuntu-latest
    needs: lint        # 依赖 lint Job 先完成
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - run: npm ci

      - name: Run tests with coverage
        run: npm test -- --coverage

      - name: Upload coverage report
        uses: codecov/codecov-action@v4
        with:
          token: $

  # =====================
  # Job 3: 构建 Docker 镜像
  # =====================
  build:
    name: Build & Push Image
    runs-on: ubuntu-latest
    needs: test
    if: github.ref == 'refs/heads/main'   # 只在 main 分支构建
    permissions:
      contents: read
      packages: write

    steps:
      - uses: actions/checkout@v4

      - name: Login to GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: $
          username: $
          password: $

      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: $/$
          tags: |
            type=sha,prefix=git-
            type=raw,value=latest

      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: $
          cache-from: type=gha     # GitHub Actions 缓存层
          cache-to: type=gha,mode=max

  # =====================
  # Job 4: 自动部署
  # =====================
  deploy:
    name: Deploy to Production
    runs-on: ubuntu-latest
    needs: build
    environment: production    # 需要手动审批（可选）

    steps:
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: $
          username: $
          key: $
          script: |
            docker pull ghcr.io/$:latest
            docker-compose up -d --no-deps app
            docker system prune -f

使用 Secrets 管理敏感信息

绝对不要在代码里硬编码密码、API Key！在仓库 Settings → Secrets and variables → Actions 中添加：

# 使用方式
- name: Deploy
  env:
    API_KEY: $    # 从 Secrets 读取
    DATABASE_URL: $       # 从 Variables 读取（非敏感）

优化构建速度

# 缓存依赖安装
- uses: actions/setup-node@v4
  with:
    cache: 'npm'          # 自动缓存 node_modules

# 缓存自定义目录
- uses: actions/cache@v4
  with:
    path: ~/.cache/pip
    key: $-pip-$
    restore-keys: |
      $-pip-

PR 检查保护

在 Settings → Branches → Branch protection rules 中：

• 启用 “Require status checks to pass before merging”
• 选中 lint 和 test 这两个 Job
• 这样有 bug 的 PR 就无法合并到 main

GitHub Actions 的魅力在于它完全是代码化的——流水线配置存在仓库里，和业务代码同版本管理，任何人都能看到和修改。这才是真正的 Infrastructure as Code。