掘金本周最热

前端重生之 - 前端视角下的 Python

老王以为 — Mon, 20 Apr 2026 09:21:53 GMT

以前我认为 JavaScript 就是编程世界的全部。从 jQuery 时代的 DOM 操作，到 React/Vue 的组件化革命，再到 TypeScript 的类型安全，见证了前端技术的每一次跃迁。然而，AI 时代来临，人人都在喊转 “全栈“，所以我也开始真正深入 Python 的生态系统，才发现这不仅是两门语言的对话，更是两种编程哲学、两种技术文化的碰撞与融合。这篇文章，是我从前端视角重新审视 Python 的记录，也是我对技术本质的一次探索，接下来我还将从前端视角看 Java、Go、C# 等不同的后端的语言，可能会有错误的地方，欢迎指正，也欢迎关注我，后期还将有分析其他语言的文章，奥利给！

从 JS 的异步到 Python 的同步

1.1 事件循环的底层机制

前端对事件循环（Event Loop）的理解，往往始于浏览器中的 setTimeout 和 Promise。JavaScript 的单线程异步模型，是为了应对浏览器环境中用户交互、网络请求等 I/O 密集型场景而设计的。我们习惯了回调地狱的煎熬，也享受过 async/await 带来的语法糖甜蜜。但很少有人深入思考：为什么 JavaScript 必须是单线程的？这个设计选择背后的权衡是什么？

JavaScript 诞生于浏览器环境，而浏览器的核心职责是渲染页面和响应用户交互。如果 JavaScript 是多线程的，一个线程正在修改 DOM，另一个线程同时也在修改同一个 DOM 节点，就会产生竞争条件（Race Condition），导致不可预测的行为。为了避免这种复杂性，JavaScript 的设计者选择了单线程模型，并通过事件循环来实现异步非阻塞 I/O。

浏览器的事件循环可以简化为以下伪代码：

while (true) {
    // 1. 执行宏任务队列中的一个任务
    const macroTask = macroTaskQueue.shift();
    if (macroTask) execute(macroTask);
    
    // 2. 执行所有微任务
    while (microTaskQueue.length > 0) {
        const microTask = microTaskQueue.shift();
        execute(microTask);
    }
    
    // 3. 渲染（如果需要）
    if (shouldRender) render();
}

这个模型保证了 JavaScript 的执行顺序是可预测的：宏任务 → 微任务 → 渲染。Promise 的回调之所以比 setTimeout 先执行，就是因为它们被放入了微任务队列。

然而，当我第一次接触 Python 的 asyncio 时，一种奇妙的熟悉感与陌生感同时涌现。Python 的协程机制与 JavaScript 的 Promise 有着惊人的相似性，但底层哲学却截然不同。

1.2 Python asyncio 的设计哲学

Python 的 asyncio 是在 Python 3.4 中引入的，在 3.5 中通过 async/await 语法得到大幅改进。与 JavaScript 不同，Python 并不是天生单线程的——它有多线程（threading 模块）和多进程（multiprocessing 模块）的完整支持。asyncio 是 Python 对协程（Coroutine）这一并发模型的选择，而不是被迫的设计。

让我们深入对比两者的实现：

# Python asyncio 示例
import asyncio

async def fetch_data(url):
    print(f"开始请求: {url}")
    await asyncio.sleep(1)  # 模拟网络请求
    print(f"请求完成: {url}")
    return f"数据来自 {url}"

async def main():
    # 并发执行多个任务
    tasks = [
        fetch_data("https://api.example.com/1"),
        fetch_data("https://api.example.com/2"),
        fetch_data("https://api.example.com/3")
    ]
    results = await asyncio.gather(*tasks)
    print(results)

asyncio.run(main())

// JavaScript 对比实现
async function fetchData(url) {
    console.log(`开始请求: ${url}`);
    await new Promise(resolve => setTimeout(resolve, 1000));
    console.log(`请求完成: ${url}`);
    return `数据来自 ${url}`;
}

async function main() {
    const tasks = [
        fetchData("https://api.example.com/1"),
        fetchData("https://api.example.com/2"),
        fetchData("https://api.example.com/3")
    ];
    const results = await Promise.all(tasks);
    console.log(results);
}

main();

表面看两者几乎相同，但底层实现有本质区别：

特性	JavaScript	Python
事件循环	浏览器/Node 内置，不可替换	asyncio 库实现，可自定义
协程实现	基于 Promise 和微任务队列	基于生成器（Generator）和事件循环
线程模型	单线程 + 事件循环	多线程/多进程 + 可选的协程
GIL 影响	无（天生单线程）	有（多线程受 GIL 限制）
并发性能	适合 I/O 密集型	适合 I/O 密集型，CPU 密集型需用多进程

1.3 GIL：Python 的"阿喀琉斯之踵"

谈到 Python 的并发，就不能不提 GIL（Global Interpreter Lock，全局解释器锁）。GIL 是 CPython 实现中的一个机制，它确保任何时候只有一个线程在执行 Python 字节码。这意味着，即使在多核 CPU 上，Python 的多线程也无法实现真正的并行计算。

import threading
import time

def cpu_bound_task(n):
    """CPU 密集型任务"""
    count = 0
    for i in range(n):
        count += i * i
    return count

# 多线程版本（受 GIL 限制）
def multi_threaded():
    threads = []
    for _ in range(4):
        t = threading.Thread(target=cpu_bound_task, args=(10_000_000,))
        threads.append(t)
        t.start()
    for t in threads:
        t.join()

# 多进程版本（绕过 GIL）
from multiprocessing import Process

def multi_process():
    processes = []
    for _ in range(4):
        p = Process(target=cpu_bound_task, args=(10_000_000,))
        processes.append(p)
        p.start()
    for p in processes:
        p.join()

# 性能对比
start = time.time()
multi_threaded()
print(f"多线程耗时: {time.time() - start:.2f}秒")

start = time.time()
multi_process()
print(f"多进程耗时: {time.time() - start:.2f}秒")

在我的测试环境中（4 核 CPU），多线程版本耗时约 12 秒，而多进程版本仅需 3 秒。这就是 GIL 的影响——多线程在 CPU 密集型任务上无法发挥多核优势。

JavaScript 没有 GIL 的问题，因为它天生就是单线程的。但这也意味着 JavaScript 无法利用多核 CPU 进行并行计算——除非使用 Worker Threads（Node.js）或 Web Workers（浏览器），但这些机制与主线程是隔离的，通信成本较高。

1.4 编程范式的思维转换

JavaScript 是一门多范式语言，但前端开发中函数式编程的影子无处不在：map、filter、reduce 成为日常，Immutable.js 和 Ramda 这样的库广受欢迎。我们追求纯函数、避免副作用、崇尚不可变性。这种趋势在 React 的函数组件和 Hooks 中达到顶峰。

// React 函数组件 + Hooks（函数式风格）
import React, { useState, useEffect } from 'react';

function UserList({ users }) {
    const [filteredUsers, setFilteredUsers] = useState([]);
    
    useEffect(() => {
        const activeUsers = users
            .filter(u => u.isActive)
            .map(u => ({ ...u, name: u.name.toUpperCase() }));
        setFilteredUsers(activeUsers);
    }, [users]);
    
    return (
        <ul>
            {filteredUsers.map(u => <li key={u.id}>{u.name}</li>)}
        </ul>
    );
}

Python 则是一门 "batteries included" 的语言，它拥抱多种范式却从不偏执。在 Python 中，你可以写出优雅的函数式代码：

# Python 函数式风格
users = [
    {"id": 1, "name": "Alice", "is_active": True},
    {"id": 2, "name": "Bob", "is_active": False},
    {"id": 3, "name": "Charlie", "is_active": True}
]

# 函数式写法
filtered_users = list(
    map(
        lambda u: {**u, "name": u["name"].upper()},
        filter(lambda u: u["is_active"], users)
    )
)

# 但更 Pythonic 的方式是列表推导式
filtered_users = [
    {**u, "name": u["name"].upper()} 
    for u in users 
    if u["is_active"]
]

这种"列表推导式"的语法，是 Python 对函数式编程的本土化改造。它既保留了函数式的表达能力，又符合 Python 简洁优雅的设计哲学。

Python 还支持面向对象和命令式编程：

# Python 面向对象风格
class User:
    def __init__(self, id, name, is_active):
        self.id = id
        self.name = name
        self.is_active = is_active
    
    def activate(self):
        self.is_active = True
    
    def __repr__(self):
        return f"User({self.name})"

# 使用类
users = [User(1, "Alice", True), User(2, "Bob", False)]
for user in users:
    if not user.is_active:
        user.activate()

这让我反思：前端开发中是否过度追求函数式的"纯粹"，而忽略了实用主义的平衡？React 的类组件被函数组件取代，但类组件在某些场景下（如复杂的生命周期管理）仍然有其优势。Python 的多范式支持提醒我们：没有最好的范式，只有最适合场景的范式。

类型系统——从动态到静态的考虑

2.1 TypeScript 的革命

2012 年，TypeScript 的诞生改变了前端开发的格局。作为 JavaScript 的超集，TypeScript 为动态语言带来了静态类型的严谨。今天，几乎所有大型前端项目都采用 TypeScript，类型安全已成为行业标准。

TypeScript 的成功不是偶然的。它解决了 JavaScript 开发中的几个核心痛点：

运行时错误前置：在编译阶段发现类型错误，而不是在生产环境崩溃
IDE 支持：智能提示、自动补全、重构支持
文档即代码：类型定义就是最好的 API 文档
团队协作：类型约束作为团队间的契约

// TypeScript 示例
interface User {
    id: number;
    name: string;
    email?: string;  // 可选属性
}

function greet(user: User): string {
    return `Hello, ${user.name}`;
}

// 编译错误：类型不匹配
const result = greet({ id: "1", name: "Alice" });  // Error: id 应该是 number

2.2 Python 类型注解的演进

有趣的是，Python 的类型注解（Type Hints）几乎是与 TypeScript 同期发展的。PEP 484 在 2014 年引入类型注解，PEP 526 在 2016 年完善变量注解。两条平行线，却走向了相似的终点。

from typing import Optional, List, Dict

class User:
    def __init__(self, id: int, name: str, email: Optional[str] = None):
        self.id = id
        self.name = name
        self.email = email

def greet(user: User) -> str:
    return f"Hello, {user.name}"

# 类型检查工具（如 mypy）会在静态分析时报告错误
user = User(id="1", name="Alice")  # mypy: Argument "id" has incompatible type "str"; expected "int"

然而，TypeScript 和 Python 类型系统的底层哲学存在本质差异：

2.2.1 编译时 vs 运行时

TypeScript 的类型在编译时完全擦除，编译后的 JavaScript 不包含任何类型信息：

// TypeScript 源码
function add(a: number, b: number): number {
    return a + b;
}

// 编译后的 JavaScript
function add(a, b) {
    return a + b;
}

Python 的类型注解在运行时保留，但解释器不做强制检查：

# Python 源码
def add(a: int, b: int) -> int:
    return a + b

# 运行时可以通过 __annotations__ 访问类型信息
print(add.__annotations__)  # {'a': <class 'int'>, 'b': <class 'int'>, 'return': <class 'int'>}

# 但解释器不会检查类型
result = add("hello", "world")  # 正常运行，返回 "helloworld"

2.2.2 结构类型 vs 名义类型

TypeScript 采用结构类型系统（Structural Typing），也称为"鸭子类型"（Duck Typing）：

interface Point {
    x: number;
    y: number;
}

function printPoint(p: Point) {
    console.log(`${p.x}, ${p.y}`);
}

// 只要结构匹配，就可以传递
printPoint({ x: 1, y: 2 });  // OK
printPoint({ x: 1, y: 2, z: 3 });  // OK（多余属性允许）

Python 的类型检查器（如 mypy）同样支持结构类型，通过 Protocol（PEP 544）：

from typing import Protocol

class Point(Protocol):
    x: int
    y: int

def print_point(p: Point) -> None:
    print(f"{p.x}, {p.y}")

class MyPoint:
    def __init__(self, x: int, y: int):
        self.x = x
        self.y = y

# MyPoint 没有显式继承 Point，但结构匹配即可
print_point(MyPoint(1, 2))  # OK

2.2.3 类型推断

TypeScript 的类型推断更为激进：

// TypeScript 能推断出 arr 是 number[]
const arr = [1, 2, 3];

// 能推断出 result 是 number
const result = arr.map(x => x * 2).filter(x => x > 2);

Python 的类型推断相对保守，需要显式注解：

from typing import List

# Python 需要显式类型注解
arr: List[int] = [1, 2, 3]

# 或者让 mypy 推断（有限支持）
result = [x * 2 for x in arr if x > 2]  # mypy 能推断为 List[int]

2.3 渐进式类型的价值

这种对比从侧面来说：类型系统的价值不在于"正确性"本身，而在于它如何帮助团队协作和代码演进。Python 的渐进式类型（Gradual Typing）策略——允许在需要时添加类型，在灵活时保持动态——或许比 TypeScript 的"全有或全无"更加务实。

# Python 渐进式类型示例
from typing import TYPE_CHECKING

if TYPE_CHECKING:
    from models import User  # 仅在类型检查时导入

def process_user(user):  # 动态类型，灵活
    return user.name.upper()

def process_user_typed(user: "User") -> str:  # 静态类型，安全
    return user.name.upper()

在实际的开发中，我通常采用以下策略：

公共 API 和核心模块使用完整的类型注解
脚本和原型代码保持动态类型，快速迭代
使用 mypy 在 CI 中检查关键模块的类型安全

生态系统

3.1 npm 与 PyPI：包管理的两种哲学

前端对于 npm 生态的复杂情感，可以用一句话概括："node_modules 是世界上最重的东西"。JavaScript 的微包文化（left-pad 事件）和依赖，是每个前端的心头痛。

让我们看看一个典型的 React 项目的依赖树：

$ npm list | wc -l
# 输出可能超过 1000 行

$ du -sh node_modules
# 输出可能超过 500MB

这种依赖膨胀的原因是多方面的：

微包文化：JavaScript 生态倾向于将功能拆分为极小的包，一个左填充函数（left-pad）也能成为一个包
重复依赖：不同版本的同一个库可能同时存在
开发依赖混杂：构建工具、测试框架、类型定义都混在一起

2016 年的微包事件是一个标志性案例。一个只有 11 行代码的包被作者从 npm 下架，导致全球数千个项目无法构建。这暴露了微包文化的脆弱性。

Python 的包管理生态则呈现出不同的面貌。pip、conda、poetry、pipenv …… 工具超级多，但核心理念一致：显式优于隐式。

# Python 的 requirements.txt
requests==2.28.1
numpy>=1.21.0
pandas~=1.5.0

这个文件明确告诉我们：

requests 必须严格等于 2.28.1 版本
numpy 可以是 1.21.0 或更高版本
pandas 可以是 1.5.x 系列（补丁版本可以变）

这种显式依赖管理的文化，让 Python 项目的可重现性远超 JavaScript。当你克隆一个 Python 项目，你知道需要安装什么；而当你克隆一个 Node.js 项目，node_modules 的深渊往往让人望而却步。

3.2 虚拟环境：Python 的隔离艺术

Python 的虚拟环境（virtualenv/venv）是包管理的另一大特色。每个项目可以有独立的 Python 环境和依赖，互不干扰。

# 创建虚拟环境
python -m venv myproject-env

# 激活虚拟环境
source myproject-env/bin/activate  # Linux/Mac
myproject-env\Scripts\activate  # Windows

# 安装依赖
pip install -r requirements.txt

# 退出虚拟环境
deactivate

这与 Node.js 的 node_modules 本地安装有相似之处，但更加彻底——虚拟环境甚至隔离了 Python 解释器本身。

现在 Python 项目更倾向于使用 pyproject.toml（PEP 518）来管理依赖：

[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

[tool.poetry]
name = "my-project"
version = "0.1.0"
description = "A sample project"

[tool.poetry.dependencies]
python = "^3.10"
requests = "^2.28"
pydantic = "^1.10"

[tool.poetry.dev-dependencies]
pytest = "^7.0"
black = "^22.0"
mypy = "^0.991"

Poetry 不仅管理依赖，还管理虚拟环境、打包、发布，是一个完整的项目管理工具。这与 JavaScript 生态中 npm/yarn/pnpm 的竞争格局形成鲜明对比。

3.3 标准库的力量

Python 的 "batteries included" 哲学，在标准库中体现得淋漓尽致。从文件处理到网络编程，从正则表达式到 JSON 解析，从单元测试到并发编程——Python 标准库几乎覆盖了一个开发者 80% 的日常需求。

# Python 标准库示例
import json
import re
import urllib.request
from datetime import datetime, timedelta
from pathlib import Path
from unittest import TestCase, main

# JSON 处理
data = {"name": "Alice", "age": 30}
json_str = json.dumps(data, indent=2)

# 正则表达式
pattern = r"\b\w+@\w+\.\w+\b"
emails = re.findall(pattern, "Contact: alice@example.com, bob@test.org")

# 文件路径操作
config_path = Path.home() / ".config" / "myapp" / "settings.json"

# 日期时间
now = datetime.now()
future = now + timedelta(days=7)

# HTTP 请求
with urllib.request.urlopen("https://api.example.com/data") as response:
    data = json.loads(response.read())

相比之下，JavaScript 的标准库堪称贫瘠。直到 ES6 引入 Promise、fetch、模块化，JavaScript 才勉强跟上时代。但即便如此，lodash、axios、moment 依然是大多数项目的标配。

这种差异的根源在于语言的设计目标：

JavaScript 诞生于浏览器，被设计为轻量级脚本语言，依赖浏览器提供的 DOM API
Python 诞生于通用编程，被设计为"可执行的伪代码"，需要在各种环境中独立运行

标准库的丰富程度，反映的是语言设计者对"开箱即用"的不同理解。

3.4 生态系统的成熟度对比

维度	JavaScript/npm	Python/PyPI
包数量	200万+	40万+
包平均大小	小（微包文化）	大（功能完整）
依赖管理	嵌套依赖（node_modules）	扁平依赖 + 虚拟环境
标准库	贫瘠	丰富（"batteries included"）
类型定义	@types/* 包	内置类型注解
安全审计	npm audit	safety, pip-audit
私有仓库	Verdaccio, Nexus	PyPI Enterprise, Devpi

数据科学的疆域的追赶

4.1 Python 的数据霸权

如果说前端是 JavaScript 的天下，那么数据科学就是 Python 的帝国。NumPy、Pandas、Matplotlib、Scikit-learn、TensorFlow、PyTorch——这些库构成了数据科学的完整工具链，而 Python 是它们的通用语言。

这种霸权不是偶然的。Python 的简洁语法、丰富的科学计算库、与 C/C++/Fortran 的良好互操作性，使其成为数据科学家的首选语言。

4.1.1 NumPy：向量化计算的威力

NumPy 是 Python 科学计算的基础。它提供了高效的多维数组对象和数学函数库，底层使用 C 实现，性能远超纯 Python。

import numpy as np

# 创建数组
arr = np.array([1, 2, 3, 4, 5])

# 向量化运算——比 Python 循环快 100 倍
result = arr * 2 + 1  # [3, 5, 7, 9, 11]

# 多维数组
matrix = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]])

# 矩阵运算
transposed = matrix.T
dot_product = matrix @ matrix.T

# 统计函数
mean = np.mean(arr)
std = np.std(arr)
max_val = np.max(matrix, axis=0)  # 每列的最大值

让我们做一个性能对比：

import time

# Python 原生列表
python_list = list(range(1_000_000))

start = time.time()
result = [x * 2 for x in python_list]
print(f"Python 列表推导式: {time.time() - start:.4f}秒")

# NumPy 数组
numpy_array = np.array(python_list)

start = time.time()
result = numpy_array * 2
print(f"NumPy 向量化运算: {time.time() - start:.4f}秒")

在我的电脑上，Python 列表推导式耗时约 0.08 秒，而 NumPy 仅需 0.001 秒——80 倍的性能差距！这是因为 NumPy 的运算是在 C 层面执行的，避免了 Python 的解释器开销。

4.1.2 Pandas：数据处理的艺术

如果说 NumPy 是数组计算的利器，Pandas 就是数据处理的瑞士军刀。它提供了 DataFrame 和 Series 两种数据结构，让数据清洗、转换、分析变得异常简单。

import pandas as pd

# 读取数据
df = pd.read_csv('sales_data.csv')

# 数据清洗
df = df.dropna()  # 删除缺失值
df = df[df['price'] > 0]  # 过滤异常值
df['date'] = pd.to_datetime(df['date'])  # 类型转换

# 数据转换
df['revenue'] = df['price'] * df['quantity']
df['month'] = df['date'].dt.month

# 分组聚合
monthly_sales = df.groupby('month').agg({
    'revenue': 'sum',
    'quantity': 'mean'
}).reset_index()

# 透视表
pivot = df.pivot_table(
    values='revenue',
    index='category',
    columns='month',
    aggfunc='sum'
)

# 合并数据
merged = pd.merge(df, customer_df, on='customer_id', how='left')

这段代码如果用 JavaScript 实现，需要多少行？lodash 可以处理数组，但没有原生的 DataFrame 概念。D3.js 可以做数据转换，但学习曲线陡峭。Pandas 的链式操作让复杂的数据处理变得可读、可维护。

4.1.3 数据可视化

Matplotlib 和 Seaborn 是 Python 数据可视化的主力军：

import matplotlib.pyplot as plt
import seaborn as sns

# 设置样式
sns.set_style("whitegrid")

# 创建图表
fig, axes = plt.subplots(2, 2, figsize=(12, 10))

# 折线图
df.groupby('date')['revenue'].sum().plot(ax=axes[0, 0], title='Daily Revenue')

# 柱状图
df['category'].value_counts().plot(kind='bar', ax=axes[0, 1], title='Category Distribution')

# 散点图
axes[1, 0].scatter(df['price'], df['quantity'], alpha=0.5)
axes[1, 0].set_title('Price vs Quantity')

# 热力图
corr = df[['price', 'quantity', 'revenue']].corr()
sns.heatmap(corr, annot=True, ax=axes[1, 1], title='Correlation Matrix')

plt.tight_layout()
plt.savefig('analysis.png', dpi=300)

前端可能会说："这些用 D3.js 也能做，而且交互性更强。"没错，D3.js 的交互能力是 Matplotlib 无法比拟的。但 Matplotlib 的优势在于快速探索和静态报告——数据分析不需要为每个图表写 200 行 D3 代码。

4.2 前端的数据觉醒

幸运的是，前端世界正在觉醒。TensorFlow.js、ONNX.js、Apache Arrow JS——这些项目正在把数据科学的能力带入浏览器。

4.2.1 TensorFlow.js

TensorFlow.js 让机器学习模型可以在浏览器中运行：

import * as tf from '@tensorflow/tfjs';

// 创建一个简单的神经网络
const model = tf.sequential({
    layers: [
        tf.layers.dense({ inputShape: [784], units: 32, activation: 'relu' }),
        tf.layers.dense({ units: 10, activation: 'softmax' })
    ]
});

model.compile({
    optimizer: 'adam',
    loss: 'categoricalCrossentropy',
    metrics: ['accuracy']
});

// 训练模型（在浏览器中）
await model.fit(xs, ys, {
    epochs: 10,
    batchSize: 32,
    callbacks: {
        onEpochEnd: (epoch, logs) => {
            console.log(`Epoch ${epoch}: loss = ${logs.loss}`);
        }
    }
});

// 预测
const prediction = model.predict(newImage);

这意味着前端可以在用户设备上运行机器学习模型，无需服务器参与。隐私保护、低延迟、离线可用——这些是服务端推理无法比拟的优势。

4.2.2 Apache Arrow JS

Apache Arrow 是一种跨语言的列式内存格式，Arrow JS 让 JavaScript 可以高效地处理大规模数据：

import { Table, FloatVector } from 'apache-arrow';

// 创建 Arrow 表
const table = Table.new(
    [
        FloatVector.from([1, 2, 3, 4, 5]),
        FloatVector.from([10, 20, 30, 40, 50])
    ],
    ['x', 'y']
);

// 高效查询
const sum = table.getColumn('y').toArray().reduce((a, b) => a + b, 0);

Arrow 的列式存储格式让数据在 Python、JavaScript、R、Julia 之间零拷贝传输成为可能。这对于前后端数据交互是一个革命性的改进。

4.3 前端的数据科学学习路径

但更深层的思考是：前端是否应该掌握数据科学的能力？

我的答案是肯定的。现代前端不再是简单的页面展示，而是数据驱动的交互应用。理解数据处理、理解机器学习的基本原理，将成为高级前端的必备技能。

Web 开发的殊途同归

5.1 Django vs Express：两种架构哲学

Django 是 Python Web 开发的旗舰框架，它的哲学是"约定优于配置"。ORM、表单处理、认证系统、管理后台——Django 提供了一站式解决方案。这种"全功能框架"的思路，让开发者可以快速搭建复杂的 Web 应用。

# Django 模型定义
from django.db import models
from django.contrib.auth.models import User

class Article(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    author = models.ForeignKey(User, on_delete=models.CASCADE)
    created_at = models.DateTimeField(auto_now_add=True)
    
    class Meta:
        ordering = ['-created_at']

# Django 视图
from django.shortcuts import render, get_object_or_404
from rest_framework import viewsets
from rest_framework.decorators import action

class ArticleViewSet(viewsets.ModelViewSet):
    queryset = Article.objects.all()
    serializer_class = ArticleSerializer
    
    @action(detail=True, methods=['post'])
    def publish(self, request, pk=None):
        article = self.get_object()
        article.publish()
        return Response({'status': 'published'})

Django 的优势在于：

快速开发：内置的 admin 界面让 CRUD 操作无需额外代码
安全性：内置 CSRF 保护、SQL 注入防护、XSS 过滤
可扩展性：丰富的第三方应用生态

但 Django 也有其局限性：

灵活性不足：Django 的"全功能"意味着你必须按照它的方式做事
学习曲线陡峭：需要理解 ORM、视图、模板、中间件等多个概念
性能开销：大而全的框架必然带来性能损耗

Express.js 则是 Node.js 世界的微框架代表：

const express = require('express');
const mongoose = require('mongoose');

const app = express();
app.use(express.json());

// 模型定义（使用 Mongoose）
const articleSchema = new mongoose.Schema({
    title: String,
    content: String,
    author: { type: mongoose.Schema.Types.ObjectId, ref: 'User' },
    createdAt: { type: Date, default: Date.now }
});

const Article = mongoose.model('Article', articleSchema);

// 路由
app.get('/api/articles', async (req, res) => {
    const articles = await Article.find().sort({ createdAt: -1 });
    res.json(articles);
});

app.post('/api/articles', async (req, res) => {
    const article = new Article(req.body);
    await article.save();
    res.status(201).json(article);
});

app.listen(3000);

Express 的优势在于：

灵活性：只提供基础功能，其他由你选择
学习曲线平缓：理解中间件概念后即可上手
性能：轻量级框架，开销小

但 Express 的灵活性也带来了问题：

选择困难症：ORM 用 Sequelize、TypeORM 还是 Prisma？验证用 Joi、Yup 还是 class-validator？
项目结构不一致：每个 Express 项目的结构都可能不同
重复造轮子：很多功能需要自己实现或选择第三方库

维度	Django	Express.js
架构风格	全功能框架（" batteries included "）	微框架
ORM	内置 Django ORM	需额外选择（Sequelize/TypeORM/Prisma）
认证授权	内置	需额外实现（Passport.js 等）
管理后台	内置 admin	无
学习曲线	陡峭	平缓
灵活性	较低	高
适用场景	大型项目、快速原型	中小型项目、API 服务
性能	中等	高

5.2 FastAPI：Python 的现代答案

如果说 Django 是 Python 的 Spring，那么 FastAPI 就是 Python 的 NestJS。FastAPI 采用声明式编程、依赖注入、类型注解，它的设计哲学与 TypeScript 生态高度契合。

from fastapi import FastAPI, HTTPException, Depends
from pydantic import BaseModel
from typing import List, Optional
from sqlalchemy import create_engine, Column, Integer, String
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker, Session

# 数据库设置
SQLALCHEMY_DATABASE_URL = "sqlite:///./test.db"
engine = create_engine(SQLALCHEMY_DATABASE_URL)
SessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine)
Base = declarative_base()

# 数据库模型
class UserDB(Base):
    __tablename__ = "users"
    id = Column(Integer, primary_key=True, index=True)
    name = Column(String, index=True)
    email = Column(String, unique=True, index=True)

# Pydantic 模型（用于 API 验证）
class UserBase(BaseModel):
    name: str
    email: str

class UserCreate(UserBase):
    pass

class User(UserBase):
    id: int
    
    class Config:
        orm_mode = True

# FastAPI 应用
app = FastAPI(title="User API", version="1.0.0")

# 依赖注入：数据库会话
def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

# 路由
@app.post("/users/", response_model=User)
def create_user(user: UserCreate, db: Session = Depends(get_db)):
    db_user = UserDB(**user.dict())
    db.add(db_user)
    db.commit()
    db.refresh(db_user)
    return db_user

@app.get("/users/", response_model=List[User])
def read_users(skip: int = 0, limit: int = 100, db: Session = Depends(get_db)):
    users = db.query(UserDB).offset(skip).limit(limit).all()
    return users

@app.get("/users/{user_id}", response_model=User)
def read_user(user_id: int, db: Session = Depends(get_db)):
    user = db.query(UserDB).filter(UserDB.id == user_id).first()
    if user is None:
        raise HTTPException(status_code=404, detail="User not found")
    return user

这段代码的优雅让我惊叹：

类型安全：Pydantic 模型自动验证请求和响应
自动文档：访问 /docs 即可获得 Swagger UI 文档
异步支持：原生支持 async/await
依赖注入：Depends 让代码解耦、可测试

对比 TypeScript 的 NestJS：

// NestJS 对比
import { Controller, Get, Post, Body, Param } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';

class CreateUserDto {
    name: string;
    email: string;
}

@Controller('users')
export class UserController {
    constructor(
        @InjectRepository(User)
        private userRepository: Repository<User>
    ) {}
    
    @Post()
    async create(@Body() createUserDto: CreateUserDto) {
        const user = this.userRepository.create(createUserDto);
        return this.userRepository.save(user);
    }
    
    @Get()
    async findAll() {
        return this.userRepository.find();
    }
}

FastAPI 和 NestJS 的设计如此相似——装饰器路由、依赖注入、DTO 验证、ORM 集成。这或许预示着 Web 开发的未来：语言的边界正在模糊，好的设计理念会被跨语言借鉴。

5.3 性能对比：Node.js vs Python

让我们做一个简单的性能测试，对比 Node.js 和 Python 处理 HTTP 请求的能力：

Node.js (Express)

const express = require('express');
const app = express();

app.get('/api/data', (req, res) => {
    // 模拟数据库查询
    const data = Array.from({ length: 1000 }, (_, i) => ({
        id: i,
        value: Math.random()
    }));
    res.json(data);
});

app.listen(3000);

Python (FastAPI)

from fastapi import FastAPI
import random

app = FastAPI()

@app.get("/api/data")
async def get_data():
    data = [
        {"id": i, "value": random.random()}
        for i in range(1000)
    ]
    return data

# 使用 uvicorn 运行：uvicorn main:app --workers 4

使用 wrk 进行压力测试：

# Node.js
wrk -t12 -c400 -d30s http://localhost:3000/api/data
# Requests/sec:  15000

# Python (单 worker)
wrk -t12 -c400 -d30s http://localhost:8000/api/data
# Requests/sec:   8000

# Python (4 workers)
wrk -t12 -c400 -d30s http://localhost:8000/api/data
# Requests/sec:  25000

结果挺让人惊讶的：在单 worker 模式下，Node.js 的性能是 Python 的 2 倍。但当 Python 使用多 worker（利用多核 CPU）时，性能反超 Node.js。这说明：

单线程性能：Node.js 的 V8 引擎优于 Python 的解释器
多核利用：Python 的多进程模型可以充分利用多核 CPU
场景选择：I/O 密集型任务两者差距不大，CPU 密集型任务需要多进程

融会贯通

6.1 语言只是工具，思维才是核心

深入 Python 之后，我越来越确信一个观点：编程语言的差异，远不如编程思维的差异重要。无论是 JavaScript 还是 Python，优秀的代码都遵循相同的原则：

6.1.1 SOLID 原则

单一职责原则（Single Responsibility Principle）

# 不好的设计：一个类做太多事
class UserManager:
    def create_user(self, data): ...
    def send_email(self, user): ...
    def generate_report(self): ...

# 好的设计：职责分离
class UserService:
    def create_user(self, data): ...

class EmailService:
    def send_email(self, user): ...

class ReportService:
    def generate_report(self): ...

开闭原则（Open/Closed Principle）

from abc import ABC, abstractmethod

# 抽象基类
class PaymentProcessor(ABC):
    @abstractmethod
    def process(self, amount: float) -> bool:
        pass

# 具体实现
class AlipayProcessor(PaymentProcessor):
    def process(self, amount: float) -> bool:
        # 支付宝支付逻辑
        return True

class WechatProcessor(PaymentProcessor):
    def process(self, amount: float) -> bool:
        # 微信支付逻辑
        return True

# 使用
class PaymentService:
    def __init__(self, processor: PaymentProcessor):
        self.processor = processor
    
    def pay(self, amount: float) -> bool:
        return self.processor.process(amount)

# 新增支付方式无需修改现有代码
class StripeProcessor(PaymentProcessor):
    def process(self, amount: float) -> bool:
        return True

6.1.2 设计模式

设计模式是跨语言的。无论是 JavaScript 还是 Python，观察者模式、工厂模式、策略模式等都有相似的实现：

# Python 观察者模式
from typing import List, Callable

class EventEmitter:
    def __init__(self):
        self._listeners: dict[str, List[Callable]] = {}
    
    def on(self, event: str, callback: Callable):
        if event not in self._listeners:
            self._listeners[event] = []
        self._listeners[event].append(callback)
    
    def emit(self, event: str, *args, **kwargs):
        for callback in self._listeners.get(event, []):
            callback(*args, **kwargs)

# 使用
emitter = EventEmitter()
emitter.on('user_created', lambda user: print(f"User created: {user}"))
emitter.emit('user_created', {'name': 'Alice'})

// JavaScript 观察者模式（几乎相同）
class EventEmitter {
    constructor() {
        this.listeners = {};
    }
    
    on(event, callback) {
        if (!this.listeners[event]) {
            this.listeners[event] = [];
        }
        this.listeners[event].push(callback);
    }
    
    emit(event, ...args) {
        (this.listeners[event] || []).forEach(cb => cb(...args));
    }
}

6.1.3 编程思维的培养

掌握多门语言的价值，不在于"技多不压身"，而在于从不同视角理解这些原则，形成更全面的技术判断力。

JavaScript 教会我：异步编程、函数式思维、事件驱动
Python 教会我：简洁优雅、实用主义、科学计算
TypeScript 教会我：类型安全、接口设计、静态分析

6.2 未来的融合趋势

技术发展的趋势是融合而非对立。我们看到 Python 和 JavaScript 都在做的事情：

6.2.1 WebAssembly 的崛起

WebAssembly（Wasm）让 Python 可以在浏览器中运行：

# 使用 Pyodide 在浏览器中运行 Python
import micropip
await micropip.install('numpy')

import numpy as np
arr = np.array([1, 2, 3, 4, 5])
result = arr * 2

这意味着前端可以在浏览器中使用 Python 的数据处理能力，而无需服务器参与。

6.2.2 PyScript 的革命

PyScript 让 Python 可以直接嵌入 HTML：

<!DOCTYPE html>
<html>
<head>
    <link rel="stylesheet" href="https://pyscript.net/latest/pyscript.css" />
    <script defer src="https://pyscript.net/latest/pyscript.js"></script>
</head>
<body>
    <div id="output"></div>
    
    <py-script>
        from js import document
        import numpy as np
        
        arr = np.array([1, 2, 3, 4, 5])
        result = arr * 2
        
        output = document.getElementById('output')
        output.innerHTML = f"Result: {result.tolist()}"
    </py-script>
</body>
</html>

6.2.3 跨语言借鉴

Node.js 的 worker_threads 借鉴了 Python 的多进程模型
TypeScript 的类型系统影响了 Python 的类型注解设计
Rust 的所有权系统正在影响 JavaScript 和 Python 的内存管理思路

6.2.4 全栈工程师的新定义

未来的工程师，可能不再被"前端"或"后端"的标签所限制。他们会根据场景选择最合适的工具：

用 Python 处理数据、训练模型、编写自动化脚本
用 JavaScript/TypeScript 构建用户界面、实现交互逻辑
用 Rust 编写高性能模块、系统级工具
用 Go 构建微服务、高并发后端

这不是"全栈"的泛化，而是技术能力的深化。真正的技术专家，不是掌握最多语言的人，而是知道何时使用哪门语言的人。

结语

写完这篇文章，我想起了一个古老的比喻：

"如果你手里只有一把锤子，那么所有问题看起来都像钉子。"

JavaScript 是我手中的第一把锤子，它帮助我构建了无数精彩的 Web 应用。从简单的页面交互到复杂的单页应用，从 jQuery 到 React，从回调地狱到 async/await——JavaScript 陪伴我走过了前端技术的每一个阶段。

但 Python 让我看到了另一片天空：

数据科学的深邃：NumPy、Pandas、Scikit-learn 让数据处理变得优雅而高效
自动化的便捷：几行 Python 脚本可以替代 hours of manual work
科学计算的严谨：从物理模拟到金融建模，Python 是科学家的首选语言
Web 开发的简洁：FastAPI 的设计哲学让我重新审视"好的代码"的定义

这两门语言不是竞争对手，而是互补的伙伴。

技术的深度，来自于对一门语言的精通；技术的广度，来自于对多门语言的理解。而技术的智慧，来自于知道何时使用哪一门语言，加油，奥利给！

为什么我不建议普通前端盲目卷全栈？

ErpanOmer — Mon, 20 Apr 2026 04:00:18 GMT

周末，一个半年前从我们组离职去当 独立开发者 的小伙子，突然约我出来喝了顿大酒。

半年前他提离职的时候，眼里是有光的。当时他手里拿着一个用 Next.js + Node + MongoDB 拼凑出来的 AI 翻译 SaaS 雏形，满脸兴奋地跟我说，现在有了 AI 辅助，前端搞全栈简直易如反掌，他马上就要去赚美金、做数字游民了😊。

半年后的饭桌上，他头发肉眼可见地稀疏了，整个人透着一股被掏空的疲惫😢。

我问他产品跑得怎么样? 他倒了一堆苦水：上线第二周，因为忘了配置 MongoDB 的白名单，数据库被黑产端了，留了个比特币勒索地址；换了云数据库后，上个月被海外羊毛党用并发脚本刷爆了注册接口，由于 Node.js 端没做事务锁和限流，AI 服务的 Token 余额一夜之间被刷欠费了两千多刀。

他长叹一口气：老大，写后端真他妈不是人干的活😖😖😖。

这两年，前端圈有一股极其狂热的风气，大厂在逼着前端转全栈，各类博主在教你怎么用 Cursor 一键生成后端 API，似乎只要会写几句 JS，连上个数据库，你就能凭一己之力抗下整个商业闭环。

但作为一个写了 9 年代码、搞过出海独立站、也无数次给新人擦过屁股的老兵，我今天必须把这层窗户纸捅破： 绝大多数普通前端理解的全栈，根本就是个一戳就破的纸老虎。我不建议你盲目去卷全栈🤷‍♂️。

你以为的全栈，只是在写玩具后端

很多前端对后端的认知，还停留在用 Express 或者 NestJS 写一个 router.get('/api/user')，然后调用一下 ORM 查查数据库。代码能跑通，能返回 JSON，就觉得自己是全栈了。

这是巨大的错觉。

真实的后端工程，最难的从来不是业务逻辑（CRUD），而是高并发下的数据一致性、资源隔离与灾备防御。

举个最经典的例子。很多刚转全栈的前端，在处理 用户消耗积分调用 AI 这个逻辑时，代码往往是这么写的：

// 前端思维写出来的后端代码
app.post('/api/generate', async (req, res) => {
  const user = await User.findById(req.userId);
  
  // 判断余额
  if (user.points < 1) {
    return res.status(403).send('积分不足');
  }
  
  // 扣减积分并保存
  user.points -= 1;
  await user.save();
  
  // 调用 AI 接口...
});

本地单步调试，毫无问题。但只要把它扔到线上，稍微遇到点网络延迟，或者有黑客同时发来 10 个并发请求。这 10 个请求会同时读到 user.points === 1，然后各自往下执行，最终用户的 1 个积分被成功扣减了 1 次，但你的 AI 接口被免费调用了 10 次。

在真正的后端视野里，这叫竞态条件（Race Condition）。解法是利用数据库层面的原子更新（比如 MongoDB 的 $inc），或者是加分布式锁。

但很多前端根本不懂什么是事务隔离级别，什么是乐观锁悲观锁，什么是慢查询引发的连接池打满。他们拿着一套写 UI 的心智模型去搞后端，最后搭出来的系统，防得住正人君子，防不住任何一次稍微猛烈的流量冲击。

2026 年独立开发者真实生存状况

现在的年轻人动不动就想搞独立 SaaS，觉得有个好点子就能变现。我带你看一眼 2026 年前端做独立开发者的真实时间线：

第一周： 激情澎湃，花 5 天时间用 Tailwind CSS 把落地页的动效调得丝滑无比，深色模式完美适配，觉得自己真是个产品天才。

第二周： 开始搭后端环境。在 Docker、Nginx 配置、SSL 证书续签里痛苦挣扎。为了省几十块钱服务器钱，买了个廉价 VPS，每天提心吊胆怕宕机。

第四周： 产品终于上线了。发到 Product Hunt 和 V2EX 上，迎来了 500 个独立访客。

第五周： 被俄罗斯或者印度的 Bot 盯上了。恶意脚本疯狂轰炸你的登录接口，你那单节点的 Node.js 进程直接 CPU 飙到 100% OOM 死机。你大半夜爬起来看日志，临时去搜 Node.js 怎么做 IP 频控。

第二个月： 热情耗尽，服务器吃灰，域名到期不续费🤷‍♂️。。。

这才是赤裸裸的真相。很多前端做独立开发，90% 的精力消耗在了配环境、查后端 Bug、修服务器配置上，真正花在打磨核心产品功能和做营销推广上的时间，连 10% 都不到。

你以为你是产品 CEO，其实你只是个免费的初级兼职运维。

普通前端该怎么破局？学会借力，而不是造轮子

说了这么多，难道前端就只能老老实实切图，彻底告别独立开发和全栈了吗？

错❌❌❌。

我的核心观点是：放弃传统后端的玩法，拥抱 Serverless 和 BaaS（后端即服务）。

2026 年了，前端的护城河绝对不是去学怎么配置 K8s 集群，也不是去死磕如何调优 MySQL 索引。你的核心价值是 极速交付业务逻辑。

要做全栈，就把脏活累活全甩给成熟的云基础设施。比如这两年我在搞出海项目时，几乎抛弃了所有传统的自建 Node 服务器部署 (比如 Render, fly.io)，全盘转向了 Cloudflare Workers + D1（Serverless SQLite） 或者 Supabase。

不用管服务器运维，不用管 Nginx 负载均衡，自带企业级防 DDOS，把代码推到边缘节点（Edge），全球毫秒级生效。

给你看一眼在 Cloudflare Workers 里，如何用极简的代码实现极其硬核的 IP 频控（Rate Limit），这在传统后端里要搭一套 Redis 才能搞定：

// 基于 Cloudflare 的现代前端全栈玩法
export default {
  async fetch(request, env) {
    const ip = request.headers.get('cf-connecting-ip');
    
    // 调用平台自带的限流服务，一行代码解决防刷问题
    const { success } = await env.RATE_LIMITER.limit({ key: ip });
    if (!success) {
      return new Response('请求过于频繁，请稍后再试', { status: 429 });
    }

    // 处理核心业务逻辑...
    return new Response('业务处理成功');
  }
};

发现了吗？这种工程维度的跨越，才是前端走向全栈的正确姿势。你不需要去理解底层的流量网关是怎么实现的，你只需要站在巨人的肩膀上，把 API 串起来，把精力留在如何优化用户的产品体验上。

别被技术焦虑绑架

很多技术社区都在制造焦虑，好像你不懂点微服务、不懂点高并发，你就不配做一个现代的前端。

但真实的世界是：没有任何一个商业项目，是因为用了多牛逼的后端架构才成功的；绝大部分死掉的项目，都是因为产品根本没人用，或者在早期就被无意义的基础设施消耗拖垮了团队🤔。

如果你是一个前端，有极强的业务嗅觉，想自己做点东西。那就用熟你手里的 Vue 或 React，用好 Tailwind 快速构建 UI，把后端托管给 Supabase 或者 Firebase，把边缘逻辑交给 Cloudflare。用两周时间把 MVP（最小可行性产品）跑通，直接推向市场验证🫡。

不要去盲目卷传统后端。把时间留给产品，留给用户，留给真正的商业闭环。这才是 2026 年，一个有独立思考能力的前端老兵，最该具备的技术品味。

你们说是不是？😊

如何写一个自己的skill

sakana — Sat, 18 Apr 2026 05:03:18 GMT

1. 前言

为什么同样用 Claude，你的效率差这么多，本文将会带大家了解 Skill，不管你是什么语言，没写过的情况下，你都可以学会他

2. 背景

如果你用过 Claude Code ,大概率遇到过这样的场景: 每次让 Claude Code 写代码，让部分代码风格保持一致, 你会告诉他项目的编码风格，或者是一段样本代码，或者是指定某个文件；

也就是，重复描述具体的某一流程，为了解决这个问题，那么就要引出今天我们要说的 Skill 。

核心速览: Skill 的本质就是一个文件夹里面放了一个 SKILL.md 文件，通过编写重复的指令，Claude 就会识别这个文件，执行特定的功能

3. 初始 Skill

在开始讨论 Skill 之前，我们要区分一个事情，它和CLAUDE.md 的区别是什么，CLAUDE.md 里的内容每次对话都会加载，而 Skill 只在需要时才加载，不用的时候几乎不占上下文。

Skill 遵循的规范 (Specification - Agent Skills)。

3.1 Skill 的位置存放

位置	路径	适用范围
个人	`~/.claude/skills/<name>/SKILL.md`	你所有的项目
项目	`.claude/skills/<name>/SKILL.md`	仅当前项目
插件	`<plugin>/skills/<name>/SKILL.md`	启用了该插件的地方

3.2 一个最小的 Skill

接下来我们就按项目级别的 Skill 来给大家说一下，如何实现，这也是你能看完本文快速能落地的方案，聪明的你，就知道如何去提取 Skill 然后省下自己的token，并且在简历猛吹，自研xxxSkill 这是我的路径： .claude\skills\my-skill\SKILL.md

my-skill/
└── SKILL.md

SKILL.md 由两部分组成——YAML 头部（frontmatter）和 Markdown 正文：

---
name: hello-world
description: 一个示例 skill，用于演示基本结构
---

当用户打招呼时，用中文回复，并附上一个冷笑话。

创建之后，你可以通过 /hello-world 手动调用，也可以让 Claude 在匹配到 description 时自动调用。

你执行的时候在对话框输入 / ，就可以得到下图：

注意： 如果没有，记得创建好上面的步骤，重启你的 Claude

最终执行，我们将得到：

常用 frontmatter 字段速查：

字段	作用
`name`	名称，也是 `/hello-world` 的名字
`description`	最重要的字段，Claude 根据它决定是否加载
`disable-model-invocation`	设为 `true` 则只能手动调用，Claude 不会自动触发
`allowed-tools`	该 skill 激活时允许 Claude 免确认使用的工具
`context`	设为 `fork` 可在子代理中隔离运行

具体的东西，可以在上面的规范中去查询，值得注意是 description 你尽量要写的通俗易懂，上图的内容，你可以再去看看，就知道指的是哪里

4. 如何高效写出一个 Skill

掌握基本结构之后，关键在于写得 "好用"。以下是从官方文档和实践中总结的核心要点：

第一，description 是触发器，不是摘要。

Claude 决定是否加载一个 Skill，完全依赖 name + description。不要写 "这是一个帮助生成代码的工具"，而要写 "生成 Vue 3 组件。当用户要求创建组件、页面或 Vue 文件时使用"。把触发词和使用场景写进去，Claude 才能准确匹配。说白了，把 Claude 当成你的合伙人，他要阅读这个说明书，才能懂你意思。

第二，指令用命令语气，按步骤编号。

写 "提取颜色主题"，不要写 "你应该提取颜色主题"。

第三，SKILL.md 控制在 500 行以内。

当你的项目特别庞大的时候，此时你的内容也会越来越多，我们可以把详细的参考资料、模板、示例拆到同目录下的独立文件里，在 SKILL.md 中引用它们：

my-skill/
├── SKILL.md           # 主指令（必须）
├── template.vue       # 组件模板
├── examples/
│   └── sample.vue     # 示例输出
└── scripts/
    └── validate.sh    # 辅助脚本

在 SKILL.md 中这样引用：

## 参考资料
- 组件模板见 [template.vue](template.vue)
- 输出示例见 [examples/sample.vue](examples/sample.vue)

第四，善用动态注入。

!`command` 语法可以在 skill 加载前执行 shell 命令，把输出注入到提示词中：

---
name: pr-review
description: 审查当前 PR 的代码变更
---

## 当前变更
!`git diff --stat`

## 变更详情
!`git diff`

请审查以上代码变更，关注潜在的 bug 和规范问题。

Claude 看到的不是命令本身，而是命令的输出结果。

第五，用 $ARGUMENTS 接收参数。

---
name: fix-issue
description: 修复 GitHub issue
disable-model-invocation: true
---

修复 GitHub issue #$ARGUMENTS：
1. 阅读 issue 描述
2. 实现修复
3. 编写测试
4. 创建 commit

调用 /fix-issue 42 时，$ARGUMENTS 会被替换为 42。也支持 $0、$1 按位置取参数。

编号可以让 Claude 按顺序执行，减少遗漏。

第六，区分"谁来调用"。

有副作用的操作（部署、发消息）加 disable-model-invocation: true，防止 Claude 自作主张。

5. 总结

建议从你日常最重复的流程开始操作，把它封装成第一个 Skill。写好之后提交到项目的 .claude/skills/ 里，这样团队成员都能受益。（前提不是古法编程）

注意：description 写成触发条件而非摘要；指令用命令语气并编号；大文件拆分引用；善用动态注入和参数传递。

Android CLI ，谷歌为 Android 开发者专研的 AI Agent，提速三倍

恋猫de小郭 — Fri, 17 Apr 2026 03:28:46 GMT

Android CLI ，虽然是 CLI ，但是不要误解，它不是一个全新的 AI CLI ，因为 Android CLI 不带模型，它更多是一个通用的 CLI 工具，负责被 Agent 调用的 agentic workflow，另外 Android CLI 天然就包含之前我们聊的 android skills ，而目的是让你在 AI 时代脱离 Android Studio 也可以进行一些 AI 工作，并且更精准节能。

简单来说，Android CLI 只负责被 Agent 调用，它会通过 android skills 和 android docs 来 “ grounding” Agent，让 Agent 严格按照 Google 最新最佳实践执行。

最简单的就是，新的 Android CLI 支持提供环境设置、项目创建和设备管理的命令，create 命令可以在几秒钟内创建一个 Android 应用项目 ，并且最重要的是：

使用 Android CLI 场景 Token 使用量减少 70% 以上，因为它改进了项目和环境设置，连带着任务完成速度也比只使用标准工具集来处理的 Agnet 快 3 倍。

在 Android CLI 场景，可以使用的主要功能包括：

SDK 管理：使用 android sdk install 只下载项目需要的特定组件，确保精简的开发环境
快速创建项目： android create 命令从官方模板生成新项目，确保从第一行代码开始就是官方推荐的架构和最佳实践
快速创建和部署：使用 android emulator 创建和管理虚拟设备，使用 android run 部署应用
更新：运行 android update ，确保拥有最新的功能支持

Android CLI 可以完成整个流程，它不仅能增强 Agent 开发流程，还能简化 CI、维护以及脚本自动化流程。

另外，配合 android skills 可以更快速和精准完成，比如通过 android skills 实现：

Navigation 3 设置和迁移
edge-to-edge 适配迁移
AGP 9 和 XML 到 Compose 的迁移
R8 配置分析
····

android skills add 默认只会安装 android-cli skill，如果不加 --all 或 --skill，并不是所有 skills 都自动带上。

另外一个就是 android docs ，目前和这个知识库包含在最新版本的 Android Studio ，提供最新版本的 Android API ，通过更新的知识库，而 Android CLI 也可以暴露这个文档能力，Agent 可以根据 Android 开发者文档、Firebase、Google Developers 和 Kotlin 文档中的最新信息来提供响应，让你的 AI 不使用过期代码：

那其实说了那么多，Android CLI 有啥场合？其实目前来看的话，这就是给 Agent 一个“不会乱用的 adb/gradle 封装” ，让 Agent 永远遵循官方最新 Knowledge Base，不会给你过时的或错误的命令，提供 Android 开发“操作系统级”接口，让任何大模型都能 3 倍速、更进准地开发 Android App 。

例如在 Gemini CLI 或者 Claude Code 里：Gemini CLI 负责思考，Android CLI 负责高效执行 Android 具体操作。

最后，想体验的话，可以通过下方安装测试：

Linux

curl -fsSL https://dl.google.com/android/cli/latest/linux_x86_64/install.sh | bash

Mac OS

curl -fsSL https://dl.google.com/android/cli/latest/darwin_arm64/install.sh | bash

Windows

curl.exe -fsSL https://dl.google.com/android/cli/latest/windows_x86_64/install.cmd -o "%TEMP%\i.cmd" && "%TEMP%\i.cmd"

或者直接下载地址：

参考链接

android-developers.googleblog.com/2026/04/bui…

同事偷偷给我介绍私活，说1万报酬全给我，结果甲方私下告诉我说，同事在当中白拿了2万，我觉得被耍了，媳妇却让我要知足，说我一点不亏

CodeSheep — Fri, 17 Apr 2026 01:08:41 GMT

最近例行逛职场社区的时候，看到一个很有意思的讨论帖。

意思大概是这样的：

同事私下偷偷给帖主介绍了单私活，说报酬有一万全部给他，结果后来不知什么原因或者机缘巧合，甲方私下告诉帖主，同事从中间吃了两万。

他感觉自己像个傻子，被耍得团团转，但他媳妇听后却不这么认为，反倒劝他要知足，如果没有这位同事的介绍，连这一万也挣不到。

关于这个帖子，我相信有不少同学也刷到过，我第一眼刷到的感觉是：

啥？接私活？这题我熟啊，这里面的坑我可就更熟了（手动 doge）。

帖子讨论的声音有很多。有人义愤填膺，骂同事不地道，也有人同意帖主媳妇的观点，认为职场本就如此，当然还有一些人在感慨，这就是技术人情怀与现实的碰撞。

作为一个在代码世界和职场江湖里摸爬滚打过的人，今天这篇文章我也想就这个话题，和大家聊聊我的一些思考。

首先，在程序员的预设里，往往会默认觉得同事的主动示好是一种善意，是一种基于同事情谊的帮助。

他接受这个项目，是出于对同事的信任。

然而，真相却是，这份善意背后有时会隐藏着一定的利益获取。

所以，这就是一个典型的职场信息差案例，将程序员置于了一个信息孤岛之中。

因此站在帖主的角度，有这种被耍感再正常不过了。

这种情绪的根源，并不仅仅是因为那 2 万块钱的差价，更深层的原因，还是源于信任的崩塌和信息的不对称。

而对于程序员媳妇的知足论，乍一听，这话似乎有些冷血，甚至有点阿 Q 精神，但是在剥离了情感色彩后，我们也不得不承认，她的话也揭示了商业世界里一条冷酷却真实的法则，那就是价值决定收益。

这几年我自己也和朋友运营着一个项目小团队，接活做活，这种感受愈发明显。

要知道，在商业合作中，分配规则往往不是按谁更辛苦来划分，而是按谁掌握稀缺资源来决定，这个道理相信大家谁都清楚。

程序员提供的，是技术能力，算是一种相对标准化的生产要素吧，在市场上有大致的价格锚点。

而那位同事提供的，则是客户资源、项目机会以及信任背书。

在这位程序员尚未建立起自己的客户网络时，这些资源对他而言，是稀缺且难以获取的。

同事表面看起来没做什么事情，就介绍了一下，但是他作为中间商，解决了流通和信息不对称的问题，其实也是创造了价值，人家从中间赚多少钱那是人家自己的本事。

没有他，程序员确实连这 1 万也赚不到。

所以结合上面这两点的分析，可以提炼出这几点对我们有益的启示。

对于帖子中的程序员来说，事情既然已成定局，我觉得过多的纠结与内耗是最没有用的。

这个问题的终极解法，我个人觉得还是在于程序员自身的觉醒和成长。

我们不能因为一次所谓的被坑，就对人性彻底失望，从此变得愤世嫉俗，当然也不能因为赚到了钱，就可以自我麻痹，而放弃准则和追求。

这个事情应该让我们看清的是职场的复杂性，同时更要明白信息和资源的重要性。

所以与其把精力消耗在对同事的道德批判上，不如把这次经历转化为自我提升的动力。

成长不都是这么走出来的么。

首先，程序员应该要建立自己的防火墙。

在接私活或进行任何形式的合作时，还是要坚持事前约定，透明沟通的原则。

要我说这事有时候挺简单，挣自己认知以内的钱，给的这些报酬你自己权衡，觉得合适就接，不合适就拒，别人能从中赚多少钱那是别人的本事。

没必要内耗，更不要因为是熟人介绍就不好意思谈钱（好多程序员在刚开始接私活的时候往往会这样）。

报酬谈好之后，接下来在实施过程中会面临的：需求、边界、责任、风险，一个都不能少，关键要素有一个算一个，全部要在事前就要明确定下来，不能糊里糊涂就答应下来。

要知道，清晰的界限才是健康关系的基础。

其次，要主动构建自己的护城河。

记住，永远不要仅仅满足于做一个机械的技术执行者，要尝试去了解业务，去拓展人脉，去积累自己的客户资源。

当你拥有了直接对接甲方的能力，当你成为了那个能提供资源的人，你就不会再轻易陷入被中间商盘剥的境地。

最后，也是最重要的，还是要保持内心的定力。

职场中金钱的得失是暂时的，但个人能力的成长和认知的升级却是永久的。

这 2 万块钱的差价，可以把它看作是为这次认知升级所支付的学费。

这笔学费的确不便宜，但是如果自己能从中学会如何更成熟、更智慧地处理复杂的人际关系和商业合作，那么它就是值得的，大家觉得呢？

那关于这个问题，你的看法是什么呢，如果有不同的见解，也欢迎一起来分享交流~

注：本文在GitHub开源仓库「编程之路」 github.com/rd2coding/R… 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。

JetBrains Amper 0.10 ，期待它未来替代 Gradle

恋猫de小郭 — Fri, 17 Apr 2026 01:00:03 GMT

最近 JetBrains 发布了 Amper 0.10 ，做为一个面向 Kotlin / Java 的实验性构建和配置工具，他的目标是通过更简单的 YAML 配置去支撑 Kotlin Multiplatform、Android、iOS、JVM 等项目管理，然后再通过 Amper CLI 完成构建、运行和工具集成。

这一次 Amper 0.10 更新之所以要聊聊，是因为它经过几年发展，它已经相对变得完善了不少，这次 0.10 主要包括了：

JDK provisioning，可以自动下载和安装匹配的 JDK，默认是 JDK 21，支持在 module.yaml 里声明需要的版本
Maven to Amper 转换，可以读取现有 pom.xml，生成 project.yaml / module.yaml
支持第三方 Kotlin compiler plugins
默认工具链版本包含 Android minSdk 23、Kotlin 2.3.20、Compose 1.10.3、KSP 2.3.6

那 Amper 有什么用？简答来说，通过 Amper 可以替代现在烦人的 Gradle ，AGP 如今的体验可以说是又臭又长，特别是现在 KMP 时代，build.gradle.kts 往往越来越厚，而 Amper 的目的是通过 YAML 来让 IDE 更容易理解项目结构、做自动补全、特别是针对 KMP 用 YAML 来声明模块、平台、依赖和平台特定配置。

看 2024–2026 的更新，Amper 不断补充的是 project file tooling、Compose resources、KSP2、Android release builds、run/test UX 这些能力，可以看出来在一步一步地侵蚀 Gradle 原本的场景。

特别是，现在对于 Amper 来说，standalone version （脱离 Gradle）已经变成主要发展方向，Gradle 版本逐步弱化，而对 Android 来说，Amper 可以让项目配置更省心：

JDK 自动准备好，可以灵活配置
模块定义更直观
KMP/Compose/Android 放在同一套声明模型下

虽然一开始 Amper 是建立在 Gradle 上的配置层，但是后来它自己也逐步发展出 standalone CLI、独立命令体系和自己的项目文件，也就是它既可以在 Gradle 生态逐步发展，也可以独立出自己的运行模式，只是目前越来越脱离 Gradle，大概类似于：

Amper = JetBrains 在 Kotlin/KMP/Android 构建体验上的新抽象层和新入口。

因为 Gradle 本质是一个可编程 DSL，所以它既可以写逻辑，又可以写条件，还可以 hook 生命周期，所以老项目的结果往往就是，配置文件逐渐变成“代码工程本身的一部分”。

而这个问题在 KMP 上变得更明显，因为多平台以来之后，环境，脚本和 CI 也变得更加复杂，但是 Amper 不一样，Amper 的官方定义是：

一个面向 Kotlin 和 Java 的构建工具，使用 YAML 进行声明式配置，并提供 CLI 和 IDE 集成。

例如在之前 Gradle 常见写法是：

kotlin {
    android()
    ios()

    sourceSets {
        val commonMain by getting {
            dependencies {
                implementation("xxx")
            }
        }
    }
}

而在 Amper 里，写法就是：

product:
  type: app

platforms:
  - android
  - ios

dependencies:
  - xxx

那为什么说它会变得更好，因为它的集成度和全自动化，例如 Amper 可以自动下载 JDK 和自动匹配版本，用官方的话说就是：

开发者可以在不手动安装任何东西的情况下就能运行项目。

也就是，用 Amper 的目的是它自己就可以负责“环境一致性”，特别是前面我们说过， 2024–2026 的各种更新内容有：

project model（项目结构）
Compose resources（资源处理）
KSP2（代码生成）
Android release builds（发布构建）
run / test UX（运行与测试）
compiler plugins（编译扩展）
JDK provisioning（环境管理）

从这些更新，可以看到一个非常清晰的覆盖路径，路径几乎就是 Gradle 在 Android 项目里的核心职责。

另外 Amper 的角度，构建工具不只是单纯的“工具”，而是带 toolchain、默认版本、项目模型的一体化生态产品，并且 Declarative 的 YAML/TOML 也在逐步替代 Gradle DSL ，因为 AI 时代：

DSL 太强，IDE 太难理解，特别是多平台下，必须要一个更简单的模型。

还有个适配小技巧，复制 gradle 然后粘贴到 module.yaml 时，它会自动转换为 Amper 适配的模式：

所以，目前虽然 Amper 0.10 还不是正式的 Gradle 的替代者，但它已经在系统性接管 Gradle 的职责，至少在 Kotlin/KMP/Android 的 JetBrains 生态里，Amper 已经不只是一个实验配置层，而是在被持续推进成为新的构建入口。

所以可以预期，未来 Amper 完全替代 Gradle 的哪一天，就可以不再面对这个又臭又大的 AGP 了。

面试官问我：“AI 写代码比你快 100 倍，你的价值在哪？”

雨夜寻晴天 — Thu, 16 Apr 2026 23:57:04 GMT

面试官是一个看着很资深的技术总监。他喝了口水，突然抛出了一个非常尖锐的问题：

“你平时用 AI 写代码吗？现在 AI 敲代码的速度比你快 100 倍，错误率还比你低。在这种背景下，你觉得程序员的核心价值到底在哪？未来的出路又在哪？”

这个问题其实我私下里思考过无数次。当 ChatGPT 刚出来能手写红黑树的时候，我也曾后背发凉，甚至怀疑过自己是不是马上要失业了。

面对面试官犀利的眼神，我深吸了一口气，给出了我的回答。

认清现实：编码的边际价值正在归零

我回答面试官的第一句话是：“AI 确实让‘写代码’这门手艺变得前所未有的廉价，但这绝对不等于‘做软件’变简单了。”

以前，咱们程序员的护城河是熟练掌握一门语言的语法、精通某个框架的边角料特性。

但今天，这些“执行层”的技能正在被大模型瞬间填平。

当“编码”本身的边际价值无限趋近于零时，我们需要重新审视自己的价值。

我跟面试官总结了三点在 AI 时代反而变得更值钱的能力：

结合现实商业语境的需求洞察与博弈：现在 AI 确实能通过多轮对话帮你把一句话需求细化成几十页的 PRD，但它不懂“老板真正的意图”，不懂跨部门的利益拉扯，更不懂业务妥协。能结合公司现状，把模糊需求转化为各方都能接受、且技术可落地的系统边界，这是人的本事。
基于有限资源的架构权衡（Trade-off）：AI 当然能给你一套完美的千万级并发高可用架构图，但它不知道你们公司服务器预算只有 5000 块，不知道你们运维团队根本 hold 不住 K8s，也不知道那个祖传的屎山数据库坚决不能动。基于团队现实的妥协与决策，AI 永远给不了“正确”答案。
最终的系统兜底与“担责”（Accountability）：这是最致命的一点。现在 AI 的 Code Review 能力确实很强，能查出大部分内存泄漏和死锁。但是，代码一旦合并，线上业务崩了、用户数据泄露了，谁来背锅？AI 没法被开除，没法去坐牢。人类作为最终节点的确认者和兜底者，提供的是无可替代的“信任背书”。

“所以，”我看着面试官说，“咱们的生路非常清晰：把‘体力活’通通外包给 AI，逼着自己去做那些更靠脑力、更需要承担责任的系统决策。”

打造护城河：未来 5 年的 5 大杀手锏

面试官听完点了点头，追问道：“思路不错，那落实到具体的个人成长上，你觉得未来几年程序员该死磕哪些能力？”

我抛出了我总结的 5 大护城河：

1. 从“调包侠”进化为“架构师”

AI 最擅长的是“局部执行”，最烂的是“全局决策”。别再只盯着业务代码怎么调用 API，必须强迫自己从 0 到 1 思考系统设计。去学领域驱动设计（DDD），去懂网络底层，去学会在高可用、低延迟和开发成本之间做权衡。

2. 把 AI 当“黑奴”，而不是“拐杖”

很多人用 AI 是浅尝辄止，拿到跑不通的代码就抱怨 AI 不行。真正的高手会给 AI 喂极度精准的背景上下文（Context），设定严格的代码规范，通过多轮追问（Prompt Engineering）让 AI 迭代，甚至让 AI 先输出设计思路再写代码。建立自己的 Prompt 军火库，能让单兵作战能力飙升 10 倍。

3. 练就火眼金睛的 Code Review 能力

以后，谁能给 AI 写的代码“擦屁股”，谁就能拿高薪。 AI 生成的代码往往隐藏着致命逻辑漏洞或极差的可维护性（精致的屎山）。你需要整理一套属于自己的 Code Review 清单：边界值、并发安全、数据库索引命中率等，把质量把控做成绝对壁垒。

4. 懂点业务，长点“产品脑”

纯技术宅的生存空间会越来越窄。技术实现成本变低后，懂业务的工程师将极度稀缺。 我们得变成技术与业务的桥梁，理解商业模式，提出直击灵魂的澄清问题，甚至用 AI 快速糊出原型去验证业务方向。

5. 用 AI 搞定实际问题，别光谈理论

真正的创新不是去手搓一个大模型，而是**“用现成的 AI 能力，解决公司陈年老垢的业务痛点”**。比如，用 LLM 改造难用的内部知识库搜索，或者用 Agent 自动化排查繁琐的运维报警。把 AI 落地变成真金白银。

破局之路：不同阶段的突围策略

面试官笑了笑：“你说的这些都挺对，但对不同工作经验的人来说，挑战是不一样的。”

我顺势接话：“没错，所以对不同阶段的程序员，我的建议是不同的。”

刚入行（0-3 年）：最怕掉进“语法陷阱”。过度依赖 AI 补全，连基本排错能力都不学了。应该利用 AI 快速跨过“死记硬背语法”的痛苦期，把时间砸在学习设计模式、数据结构和深入理解业务上。学 AI 解决问题的“思路”，而不是盲目接受“结果”。
中坚力量（3-7 年）：这是最危险的分水岭。熟练掌握的增删改查和组件使用，恰恰是 AI 最易替代的。必须向上突破，主导复杂系统设计，带新人，深耕一个垂直领域（如电商交易链路、音视频底层等），让“行业踩坑经验”不可替代。
技术老鸟（7 年以上）：别吃老本了，“最佳实践”正在被固化到 AI 工具里。要升维到“技术战略”层面。思考怎么引入 AI 工具提升部门研发效能？引入大模型算力的 ROI 划算吗？或者去做专门解决极端疑难杂症的“定海神针”。
懂业务的跨界老炮：这是你们的黄金时代！“深度的行业认知 + 用 AI 快速实现想法的能力” = 降维打击。去当业务合伙人、做独立开发者，或者搞垂直领域的 AI 创新产品。

结语：思维的跃迁才是真正的出路

面试官听完，沉默了一会儿，然后对我微微一笑。

“说得很好，”他说，“很多人还沉浸在被 AI 替代的恐慌中，你已经想清楚怎么利用它了。”

兄弟们，在 AI 时代，最值钱的程序员，永远不是敲代码最快的那个人。

最值钱的，是能一眼看透问题本质的人；是能设计出优雅且抗造系统的人；是能把 AI 当成最强副手，并有能力为最终结果兜底的人。

千万别把 AI 当成来抢饭碗的阶级敌人，它不过是你职业生涯里遇到过的、最听话、最不知疲倦的实习生罢了。

去指挥它，去审核它，然后狠狠地踩在它的肩膀上，去解决那些真正能赚大钱、有高价值的难题。

咱们的出路，就在思维的跃迁里。干就完了！大家一起加油！💪

踩坑分享：Vite Plus 最佳实践

耗子君QAQ — Thu, 16 Apr 2026 16:17:40 GMT

写在前面

掘金的同学们大家好呀，作者是 Varlet UI 的作者。掘金文章已经一年没更新了，去年跳槽到了一家创业公司负责前端架构工作，写文章这件事就一直搁置了。最近稍微缓过来了一点点（其实还是压力很大...），但不妨碍今天来给大家分享一下我们最新的开源项目 rattail。

先聊聊 Vite Plus

上个月 VoidZero 正式以 MIT 协议开源了 Vite+，它把 Vite、Vitest、Oxlint、Oxfmt、Rolldown、tsdown 统一收拢到了一个 vp 命令下面，一套工具链覆盖 dev、build、test、lint、fmt、pack 等所有工程化环节。作者第一时间就把 varlet 周边的项目迁移到了 Vite+ 上面试试水，迁移下来发现效果特别好。以前那些散落在各处的 eslint 配置、prettier 配置、lint-staged 配置、commitlint 配置可以统一收拢到一个 vite.config.ts 里面，项目根目录一下子干净了不少（以前打开根目录看到十几个 .xxxrc 文件的日子终于结束了）。而且因为工具链统一了，AI Agent 在理解项目配置的时候幻觉也少了很多。

公司项目迁移

既然体验这么好，作者就决定把公司内部的前端项目也都迁移到 Vite+ 上。迁移的过程中也让作者重新审视了一下 rattail，我们在 varlet 生态里积累了大量的工具函数、请求库、校验规则工厂、CLI 工具链，之前一直是分散在各个包里的，正好借这次机会做一次大整合，于是就有了 rattail 2.0——一个面向 Vite+、对 AI Agent 非常友好的前端工具链。140+ 工具函数、渐进式请求库、链式校验规则工厂、CLI 工具链、类型安全枚举，pnpm add rattail 一条命令全部拉齐。

目前作者也在公司项目中全面使用了 Vite+ + rattail 这套技术栈，体验下来非常舒服。另外值得一提的是，这次 rattail 2.0 的迁移和开发过程中，作者大量使用了 AI 辅助编程，包括工具函数的编写、单元测试的补全、文档的生成等等，效率提升非常明显。配合 rattail 提供的 Agent Skills，AI Agent 能够很好的理解项目上下文并正确使用 rattail 的 API，整个工作流跑下来还是相当丝滑的。后续在业务开发中也明显感觉到，因为 rattail 把工具函数、请求库、校验规则这些东西 all in one 了，AI 在生成代码的时候幻觉变得特别少，而且很会按照规范做事。

特性一览

⚙️ 面向 Vite+ 的开箱即用配置预设
🔧 CLI 工具链，支持发布、日志、Git Hooks、Commit Lint、API 生成
🧰 140+ 工具函数，覆盖通用、字符串、数字、数组、对象、数学等场景
🚀 基于 axios 的渐进式请求工具，支持 Vue 组合式 API
📏 链式校验规则工厂，适配任意 UI 框架
🏷️ 类型安全的枚举工具
🤖 提供 Agent Skills，帮助 AI 编程助手理解和使用 Rattail
🌲 可 Tree-shake，轻量，TypeScript 完整类型支持
💪 90%+ 单元测试覆盖率

下面作者挑几个有意思的能力展开聊聊。

Vite+ 配置预设

做过前端工程化的同学应该都有体会，每次新项目光配 eslint 和 prettier 这些东西就够喝一壶的了，配好了还得处理各种冲突。rattail 内置了面向 Vite+ 的开箱即用预设，一个 vite.config.ts 搞定 lint、format、staged、git hooks 等所有工程化配置。

import { lint, fmt, staged, clean, hook, defineConfig } from 'rattail/vite-plus'

export default defineConfig({
  lint: lint(),

  fmt: fmt(),

  staged: staged(),

  rattail: {
    clean: clean(),

    hook: hook(),
    
    api: {},

    release: {},

    changelog: {}
  },
})

之前作者为了配这些东西写了好几个配置文件，现在一个文件就够了（少写代码是第一生产力）。

CLI 工具链

安装 rattail 后会注册一个 rt 命令，覆盖了作者日常开发中最常用的几个场景。

# 清理产物
rt clean

# 安装 git hooks
rt hook

# 发布
rt release

# 生成 changelog
rt changelog

# 从 OpenAPI 生成 API 模块
rt api

这些命令都支持通过 vite.config.ts 中的 rattail 字段进行配置，也就是说项目根目录不需要再多出一堆 .xxxrc 文件了。这一点作者是比较在意的，毕竟谁也不想打开项目根目录看到十几个配置文件吧（有些项目根目录比 node_modules 还热闹）。

140+ 工具函数

lodash 大家都耳熟能详了，rattail 里的工具函数覆盖的场景和 lodash 类似，包括类型判断、数组、对象、字符串、数学、函数、集合、文件等分类，用法就不逐个列举了。和 lodash 不同的是，这些函数从第一天就是用 TypeScript 写的，类型推导是第一优先级，全部可 Tree-shake。除了 lodash 风格的工具函数以外，rattail 还内置了一些前端项目中常用的实用工具，比如 sumHash 计算哈希、uuid 生成唯一 ID、mitt 事件总线、duration 时间格式化、storage / cookieStorage 存储封装、copyText 复制文本、download 文件下载等等，省得同学们每次都要单独装一堆小包。更多的可以去文档里查看完整的 API 列表。

类型安全的枚举工具

这个是作者个人比较喜欢的一个工具。前端项目里到处都是枚举值，比如订单状态、用户角色之类的。一般我们用 enum 或者常量对象来管理它们，但是 label、description 这些配套信息就只能另外维护了。enumOf 把值和它的元信息放在一起管理，并且类型推导是完备的。

import { enumOf } from 'rattail'

const Status = enumOf({
  Pending: { value: 0, label: '待处理' },
  Active: { value: 1, label: '进行中' },
  Done: { value: 2, label: '已完成' },
})

Status.Pending        // 0
Status.Active         // 1
Status.values()       // [0, 1, 2]
Status.labels()       // ['待处理', '进行中', '已完成']
Status.label(Status.Pending) // '待处理'
Status.options()      // [{ value: 0, label: '待处理' }, ...]

// 直接丢给 select 组件的 options，再也不用手动维护了

前端项目里到处都需要枚举值和它对应的文案，以前每次都要写个 map 或者 switch，现在一个 enumOf 就够了。另外 enumOf 的 label 和 description 支持传入一个 getter 函数，配合 vue-i18n 之类的国际化方案可以很方便的实现多语言：

const Status = enumOf({
  Pending: { value: 0, label: () => t('status.pending') },
  Active: { value: 1, label: () => t('status.active') },
  Done: { value: 2, label: () => t('status.done') },
})

基于 axios 的渐进式请求工具

这个能力来自于作者之前开源的 @varlet/axle，现在通过 rattail/axle 直接引入。熟悉作者的同学可能看过之前介绍 axle 的文章，它在兼容 axios 的同时，天然支持 Vue3 Composition API。

import { createAxle } from 'rattail/axle'
import { createUseAxle } from 'rattail/axle/use'

const axle = createAxle({ baseURL: '/api' })
const useAxle = createUseAxle({ axle })

const [users, getUsers, { loading, error }] = useAxle({
  method: 'get',
  url: '/user',
  params: { current: 1, pageSize: 10 },
})

作者一直觉得前端请求库和 Vue 的响应式系统应该有更好的结合方式，axle 就是在这个方向上的一个尝试。如果你不喜欢 axle 也完全没问题，rattail 的其他能力和请求库是解耦的，换成你喜欢的方案就好。

OpenAPI 生成 API 模块

rt api 可以直接解析后端提供的 OpenAPI / Swagger schema 文件，自动生成类型安全的 API 调用代码，这个在实际项目里把工作流做通之后体验可太好了。

在 vite.config.ts 里配置好 schema 路径和输出目录：

import { defineConfig } from 'rattail/vite-plus'

export default defineConfig({
  rattail: {
    api: {
      input: './openapi.json'
    },
  },
})

执行 rt api 后会自动生成这样的代码：

import { api } from '@/request'
import { type paths } from './_types'

export type ApiGetUsers = paths['/users']['get']
export type ApiCreateUser = paths['/users']['post']
export type ApiGetUser = paths['/users/{uuid}']['get']
export type ApiUpdateUser = paths['/users/{uuid}']['put']
export type ApiDeleteUser = paths['/users/{uuid}']['delete']

export type ApiGetUsersQuery = ApiGetUsers['parameters']['query']
export type ApiGetUsersRequestBody = undefined
export type ApiGetUsersResponseBody = ApiGetUsers['responses']['200']['content']['application/json']
// ... 其他类型同理

export const apiGetUsers = api<
  ApiGetUsersResponseBody, ApiGetUsersQuery, ApiGetUsersRequestBody>('/users', 'get')
export const apiCreateUser = api<
  ApiCreateUserResponseBody, ApiCreateUserQuery, ApiCreateUserRequestBody>('/users', 'post')
export const apiGetUser = api<
  ApiGetUserResponseBody, ApiGetUserQuery, ApiGetUserRequestBody>('/users/:uuid', 'get')
export const apiUpdateUser = api<
  ApiUpdateUserResponseBody, ApiUpdateUserQuery, ApiUpdateUserRequestBody>('/users/:uuid', 'put')
export const apiDeleteUser = api<
  ApiDeleteUserResponseBody, ApiDeleteUserQuery, ApiDeleteUserRequestBody>('/users/:uuid', 'delete')

请求类型、响应类型全部从 schema 里提取，不需要手写。后端接口变了，重新跑一遍 rt api 就行，前后端的类型始终保持同步。这个工作流对 AI Agent 也特别友好，AI 可以直接基于生成的类型去写业务代码，不会出现参数类型对不上的问题。甚至 AI Agent 可以通过 api 定义的变化，推测出你接下来要写什么业务。默认使用 axle，也支持 axios 的预设，同时支持 自定义输出。

链式校验规则工厂

做表单的同学应该都写过类似 required、min、max 这些校验规则。不同的 UI 框架校验规则的格式还不一样，每个项目都要适配一遍。rattail 提供了一个链式校验规则工厂，写起来很流畅，并且可以适配任意 UI 框架。这种内联的声明式写法和 TailwindCSS 的思路类似，可读性和可迁移性都非常好，对 AI 也特别友好，AI 可以直接从模板里读懂校验意图，生成和修改规则的准确度很高。

以 Naive UI 和 Element Plus 为例：

<!-- Naive UI -->
<script setup lang="ts">
import type { FormItemRule } from 'naive-ui'
import { rulerFactory } from 'rattail/ruler'

const r = rulerFactory<FormItemRule>((validator, params = {}) => ({
  trigger: ['blur', 'change', 'input'],
  validator: (_, value) => validator(value),
  ...params,
}))
</script>

<template>
  <n-form :model>
    <n-form-item 
      path="name" 
      label="姓名"
      :rule="r().required('必填').min(2, '长度不正确').done()"
    >
      <n-input v-model:value="model.name" />
    </n-form-item>
  </n-form>
</template>

<!-- Element Plus -->
<script setup lang="ts">
import type { FormItemRule } from 'element-plus'
import { rulerFactory } from 'rattail/ruler'

const r = rulerFactory<FormItemRule>((validator, params) => ({
  validator(_, value, callback) {
    const e = validator(value)
    e ? callback(e) : callback()
  },
  trigger: ['blur', 'change', 'input'],
  ...params,
}))
</script>

<template>
  <el-form :model>
    <el-form-item 
      prop="email" 
      label="邮箱"
      :rules="r().email('必须是邮箱格式').done()"
    >
      <el-input v-model="model.email" />
    </el-form-item>
  </el-form>
</template>

AI Agent Skills

rattail 提供了一套 Agent Skills，说白了就是给 AI 写了一份"说明书"，让 AI Agent 知道 rattail 有哪些能力、怎么用，不用你每次都手动告诉 AI。作者觉得未来的开源库都应该考虑对 AI Agent 的友好度。

写在最后

rattail 的工具函数和能力大多来自前端社区的通用实践。感谢同学们能看到这里，但是希望 rattail 能够帮助到大家。项目基于 MIT 协议。如果在使用的过程中遇到任何问题，欢迎在 issue 里反馈给我们，同时也十分欢迎对项目有兴趣的同学给我们发 pull request。

支持我们的话留下一个 star 就好～

官方文档: rattail.varletjs.org
仓库地址: github.com/varletjs/ra…

深入理解 JavaScript 的 AbortController：从底层原理到跨语言设计哲学

老王以为 — Thu, 16 Apr 2026 09:04:53 GMT

引言

在目前的现代异步编程中，取消操作是一个看似简单却极其复杂的问题。JavaScript 的 AbortController API 作为 Web 标准和 Node.js 环境中的统一解决方案，不只是解决了异步操作的可取消性难题，更体现了一种深刻的设计哲学：协作式取消（Cooperative Cancellation）。

今天我们从底层原理出发，深入剖析 AbortController 的工作机制，对比浏览器与 Node.js 的实现差异，并横向对比其他编程语言的中断机制设计，最终揭示这一 API 背后的语言特性与设计思想。那我们开始吧！

第一部分：AbortController 的底层原理

1.1 核心架构：信号-控制器分离模式

AbortController 的设计遵循信号-控制器分离模式（Signal-Controller Separation Pattern）。这种设计将"控制"与"监听"两个职责进行分离：

// 核心架构示意
class AbortController {
  constructor() {
    // 控制器持有信号对象的引用
    this.signal = new AbortSignal();
  }

  abort(reason) {
    // 控制器触发信号的中止状态
    this.signal._abort(reason);
  }
}

class AbortSignal extends EventTarget {
  constructor() {
    super();
    this.aborted = false;
    this.reason = undefined;
  }

  _abort(reason) {
    if (this.aborted) return; // 幂等性保证

    this.aborted = true;
    this.reason = reason ?? new DOMException("Aborted", "AbortError");

    // 触发中止事件，通知所有监听器
    this.dispatchEvent(new Event("abort"));
  }
}

为什么这样设计？

单一职责原则：控制器负责"触发"，信号负责"传播"。这种分离使得一个控制器可以控制多个信号，或者多个消费者可以共享同一个信号。
不可变性保证：signal 对象一旦创建，其引用关系就固定下来。消费者只能监听信号，无法重新赋值或篡改控制器的状态。
传播语义清晰：信号作为 EventTarget 的子类，天然支持事件订阅机制，符合 JavaScript 的异步编程范式。

1.2 事件驱动机制：从信号到执行中断

AbortSignal 继承自 EventTarget，这意味着它使用事件驱动模型来传播取消信号。当调用 controller.abort() 时，内部执行以下步骤：

关键设计点：

幂等性：多次调用 abort() 不会产生副作用，确保信号状态的一致性。
同步触发：abort() 的调用是同步的，事件处理也是同步执行的，这保证了取消信号的即时性。
不可撤销：一旦信号被中止，就无法"恢复"，这符合"取消"的语义——取消是一个不可逆的操作。

1.3 底层资源释放：从信号到系统调用

AbortController 的真正威力在于它能够触发底层资源的释放。以 fetch 请求为例：

const controller = new AbortController();
fetch("/api/data", { signal: controller.signal });

// 触发取消
controller.abort();

当 abort() 被调用时，浏览器会执行以下操作：

TCP 连接中断：浏览器向服务器发送 RST（Reset）包，强制关闭 TCP 连接。这不是"忽略响应"，而是真正意义上的连接终止。
资源回收：释放与该请求相关的内存缓冲区、文件描述符、事件监听器等资源。
Promise 拒绝：fetch 返回的 Promise 被 reject，抛出 AbortError。

这种分层取消机制确保了从应用层到系统层的完整资源释放，避免了内存泄漏和资源耗尽问题。

1.4 AbortSignal.any()：信号组合的设计智慧

AbortSignal.any() 是 AbortController API 的一个重要扩展，它允许将多个信号组合成一个 "或" 关系的新信号：

const timeoutSignal = AbortSignal.timeout(5000);
const userCancelSignal = new AbortController().signal;

// 任一信号触发，组合信号就触发
const combinedSignal = AbortSignal.any([timeoutSignal, userCancelSignal]);

fetch("/api/data", { signal: combinedSignal });

实现原理：

// 简化版实现示意
class AbortSignal {
  static any(signals) {
    const controller = new AbortController();

    for (const signal of signals) {
      if (signal.aborted) {
        // 如果任一信号已中止，立即触发
        controller.abort(signal.reason);
        return controller.signal;
      }

      // 监听每个信号的 abort 事件
      signal.addEventListener(
        "abort",
        () => {
          controller.abort(signal.reason);
        },
        { once: true },
      );
    }

    return controller.signal;
  }
}

设计要点：

竞态处理：如果传入的信号中已经有一个是 aborted 状态，立即触发新信号的中止。
原因传递：触发时传递原始信号的 reason，保持错误信息的完整性。
内存管理：使用 { once: true } 确保事件监听器在触发后自动清理，避免内存泄漏。
WeakRef 优化：实际实现中使用 WeakRef 和 FinalizationRegistry 来管理信号之间的依赖关系，防止循环引用。

第二部分：Node.js 与 Web 实现的异同

2.1 实现层面的差异

虽然 Node.js 的 AbortController 遵循与浏览器相同的 WHATWG DOM 标准，但在底层实现上存在显著差异：

特性	浏览器（Blink/V8）	Node.js (libuv/V8)
事件循环	基于渲染事件循环	基于 libuv 事件循环
网络层	Chromium Network Stack	libuv + 系统调用
信号传播	通过 Blink 的绑定层	通过 Node.js 的 C++ 绑定
文件系统	受限的 File System Access API	完整的 fs 模块支持
子进程	不支持	支持 `child_process` 模块
Worker 线程	Web Workers	Worker Threads

2.2 Node.js 特有的扩展

Node.js 对 AbortController 进行了多项扩展，使其更适用于服务端场景：

2.2.1 定时器支持

import { setTimeout } from "node:timers/promises";

const controller = new AbortController();

setTimeout(1000, "value", { signal: controller.signal })
  .then((value) => console.log(value))
  .catch((err) => {
    if (err.name === "AbortError") {
      console.log("Timer aborted");
    }
  });

// 5秒后取消
setTimeout(() => controller.abort(), 500);

底层实现：Node.js 的定时器模块内部维护了一个 AbortSignal 到定时器句柄的映射。当信号触发时，调用 clearTimeout() 清除定时器。

2.2.2 文件系统操作

import { readFile } from "node:fs";

const controller = new AbortController();

readFile("/path/to/file", { signal: controller.signal }, (err, data) => {
  if (err?.name === "AbortError") {
    console.log("Read aborted");
  }
});

// 取消读取
controller.abort();

重要限制：根据 Node.js 文档，文件系统的取消不会中止底层的操作系统请求，而只是中止 Node.js 内部的缓冲操作。这意味着：

这与浏览器中 fetch 的取消（可以终止 TCP 连接）有本质区别，反映了服务端 I/O 与客户端网络请求的不同特性。

2.2.3 子进程控制

import { spawn } from "node:child_process";

const controller = new AbortController();

const child = spawn("node", ["script.js"], {
  signal: controller.signal,
});

child.on("error", (err) => {
  if (err.name === "AbortError") {
    console.log("Child process aborted");
  }
});

// 终止子进程
controller.abort();

实现机制：Node.js 在子进程模块中监听 AbortSignal 的 abort 事件，触发时向子进程发送 SIGTERM 信号。如果子进程未在超时内退出，则发送 SIGKILL 强制终止。

2.3 行为一致性与边界情况

2.3.1 事件触发时序

浏览器和 Node.js 在事件触发时序上保持一致：

const controller = new AbortController();
const signal = controller.signal;

// 注册多个监听器
signal.addEventListener("abort", () => console.log("Listener 1"));
signal.addEventListener("abort", () => console.log("Listener 2"));

controller.abort();
console.log("After abort");

// 输出顺序：
// Listener 1
// Listener 2
// After abort

事件监听器是同步执行的，这保证了取消操作的即时性。

2.3.2 已完成的操作

如果操作已经完成，取消信号会被忽略：

const controller = new AbortController();

fetch("/api/data", { signal: controller.signal }).then((response) => {
  console.log("Request completed");
});

// 延迟触发取消（假设请求已经完成）
setTimeout(() => {
  controller.abort(); // 不会产生任何效果
}, 1000);

这种行为是协作式取消的核心体现：消费者决定如何响应取消信号，包括选择忽略它。

第三部分：跨语言对比——中断机制的设计哲学

3.1 协作式取消 vs 抢占式取消

不同编程语言对"取消操作"的设计哲学可以分为两大类：

3.2 Go：Context 模式

Go 语言的 context 包提供了与 JavaScript AbortController 类似的协作式取消机制：

// Go 的 Context 模式
ctx, cancel := context.WithCancel(context.Background())
defer cancel()

// 启动 goroutine
go func(ctx context.Context) {
    select {
    case <-ctx.Done():
        // 收到取消信号
        fmt.Println("Cancelled:", ctx.Err())
        return
    case <-time.After(5 * time.Second):
        fmt.Println("Work completed")
    }
}(ctx)

// 触发取消
cancel()

与 JavaScript 的对比：

特性	Go Context	JavaScript AbortController
信号类型	Channel（`<-ctx.Done()`）	Event（`addEventListener`）
传播方式	显式传递 `ctx` 参数	通过 `signal` 属性传递
超时支持	`context.WithTimeout()`	`AbortSignal.timeout()`
值传递	支持 `ctx.Value()`	不支持（专用设计）
组合能力	可以嵌套传递	`AbortSignal.any()` 组合

设计差异分析：

Go 的 context 不仅是取消信号，还承担了请求作用域数据传递的职责（通过 ctx.Value()）。这种设计在微服务架构中非常有用，可以传递请求 ID、用户信息等。JavaScript 的 AbortController 则专注于单一职责：取消信号传递。

3.3 C#：CancellationToken 模式

.NET 的 CancellationToken 是一个成熟的协作式取消机制：

// C# 的 CancellationToken 模式
using var cts = new CancellationTokenSource();
CancellationToken token = cts.Token;

try {
    await Task.Run(async () => {
        while (!token.IsCancellationRequested) {
            // 执行任务
            await Task.Delay(100);
        }
    }, token);
} catch (OperationCanceledException) {
    Console.WriteLine("Operation cancelled");
}

// 触发取消
cts.Cancel();

关键特性：

轮询与回调双模式：既可以通过 IsCancellationRequested 属性轮询，也可以通过 Register() 方法注册回调。
链接令牌：CreateLinkedTokenSource() 可以将多个令牌链接成一个，任一令牌取消都会触发整体取消。
异常类型：取消时抛出 OperationCanceledException，与 JavaScript 的 AbortError 对应。

与 JavaScript 的对比：

⚖️ 核心差异对照表

对比维度	C# `CancellationToken`	JS `AbortSignal`
类型系统	`struct`（值类型）	`class`（引用类型）
传递语义	按值复制（快照式）	按引用共享（同一实例）
取消检测	轮询 `.IsCancellationRequested`	监听 `'abort'` 事件
异常类型	`OperationCanceledException`	`DOMException("AbortError")`
资源释放	需手动 `.Dispose()` CTS	GC 自动回收
超时内置	`cts.CancelAfter()`	`AbortSignal.timeout()` (ES2024)
多信号合并	`CreateLinkedTokenSource()`	`AbortSignal.any()` (ES2024)
与 fetch 集成	❌ 不适用	✅ 原生支持
与 async/await	✅ 原生支持	✅ 原生支持

3.4 Java：Future.cancel() 与线程中断

Java 提供了两种取消机制：

3.4.1 Future.cancel()（协作式）

ExecutorService executor = Executors.newSingleThreadExecutor();
Future<?> future = executor.submit(() -> {
    while (!Thread.currentThread().isInterrupted()) {
        // 执行任务
    }
});

// 尝试取消
future.cancel(true); // true = 允许中断运行中的线程

3.4.2 线程中断（抢占式）

Thread workerThread = new Thread(() -> {
    try {
        Thread.sleep(10000);
    } catch (InterruptedException e) {
        // 收到中断信号
        Thread.currentThread().interrupt(); // 重新设置中断标志
    }
});

workerThread.start();
workerThread.interrupt(); // 发送中断信号

关键区别：

Java 的 Thread.interrupt() 并不会强制停止线程，而是设置一个中断标志。线程需要主动检查这个标志（通过 isInterrupted()）或在可中断的阻塞操作（如 sleep(), wait()）中捕获 InterruptedException。

这与 JavaScript 的 AbortController 非常相似，都是协作式的。但 Java 还保留了 Thread.stop()（已废弃）这样的抢占式方法，反映了早期 Java 设计中对抢占式取消的探索。

3.5 Kotlin：协程的取消机制

Kotlin 协程的取消是结构化并发（Structured Concurrency）的核心特性：

import kotlinx.coroutines.*

fun main() = runBlocking {
    val job = launch {
        try {
            repeat(1000) { i ->
                println("Job: I'm working $i ...")
                delay(500L)
            }
        } finally {
            // 清理资源
            println("Job: I'm running finally")
        }
    }

    delay(1300L)
    println("main: I'm tired of waiting!")
    job.cancelAndJoin() // 取消并等待完成
    println("main: Now I can quit.")
}

关键特性：

挂起点的取消检查：Kotlin 协程只在挂起点（suspension points）检查取消状态。如果协程处于 CPU 密集型计算中，不会立即响应取消。
异常传播：取消时抛出 CancellationException，这是一种特殊的异常，不会被视为错误。
父子关系：子协程的取消会传播给所有子协程，形成树状的取消传播。

与 JavaScript 的对比：

3.6 Python：asyncio.Task 的取消

Python 的 asyncio 提供了任务取消机制：

import asyncio

async def worker():
    try:
        while True:
            print("Working...")
            await asyncio.sleep(1)
    except asyncio.CancelledError:
        print("Cancelled!")
        raise  # 必须重新抛出

async def main():
    task = asyncio.create_task(worker())
    await asyncio.sleep(2)
    task.cancel()

    try:
        await task
    except asyncio.CancelledError:
        print("Task cancelled")

asyncio.run(main())

设计特点：

异常驱动：取消通过抛出 CancelledError 实现，任务需要捕获并重新抛出。
异步清理：finally 块中可以执行异步清理操作（使用 async 语法）。
取消传播：父任务取消时，子任务会自动收到取消信号。

与 JavaScript 的对比：

Python 的 asyncio.CancelledError 与 JavaScript 的 AbortError 类似，都是异常驱动的取消机制。但 Python 的取消更依赖异常传播，而 JavaScript 更依赖事件监听。

3.7 Rust：异步取消与 Drop 语义

Rust 的异步取消机制与众不同，它利用了所有权和 Drop trait：

use tokio::time::{sleep, Duration};

#[tokio::main]
async fn main() {
    let handle = tokio::spawn(async {
        sleep(Duration::from_secs(5)).await;
        println("Task completed");
    });

    // 取消任务
    handle.abort();

    match handle.await {
        Ok(_) => println!("Task finished normally"),
        Err(e) if e.is_cancelled() => println!("Task was cancelled"),
        Err(e) => println!("Task panicked: {:?}", e),
    }
}

核心概念：

Future 的 Drop：在 Rust 中，当一个 Future（异步任务）被 drop（丢弃）时，任务就被取消了。这是通过所有权系统实现的。
取消安全性（Cancel Safety）：Rust 强调"取消安全性"，即任务在被取消时不会留下不一致的状态。这通常要求使用特定的模式（如 select! 宏）。
Async Drop：Rust 正在讨论引入 AsyncDrop trait，允许在 drop 时执行异步清理操作。

与 JavaScript 的对比：

第四部分：设计哲学与最佳实践

4.1 为什么协作式取消是主流？

从上述跨语言对比可以看出，协作式取消已成为现代异步编程的主流设计。原因如下：

资源安全：协作式取消允许任务在退出前执行清理操作（关闭文件、释放锁、回滚事务等），避免资源泄漏。
状态一致性：任务可以在安全点（挂起点或检查点）响应取消，确保数据结构处于一致状态。
可预测性：取消的时机和行为是确定的，不会出现抢占式取消的"任意点中断"问题。
组合性：多个取消信号可以组合（如 AbortSignal.any()），形成复杂的取消策略。

4.2 AbortController 的设计原则总结

根据 WHATWG DOM 规范和各实现的设计文档，AbortController 遵循以下核心原则：

分离原则（Separation）
- 控制器（Controller）负责触发
- 信号（Signal）负责传播
- 消费者（Consumer）决定如何响应
幂等性原则（Idempotency）
- 多次调用 abort() 无副作用
- 信号一旦中止，状态不可变
即时性原则（Immediacy）
- abort() 调用是同步的
- 事件处理是同步的
- 保证取消信号的即时传播
不可撤销原则（Irreversibility）
- 取消是不可逆的操作
- 信号不能"恢复"或"重置"
组合性原则（Composability）
- 支持多个信号的组合（any, race）
- 支持信号链的传播（dependent signals）
资源安全原则（Resource Safety）
- 提供清理算法的注册机制
- 支持自动解订阅（unsubscription）

4.3 实际应用中的最佳实践

4.3.1 始终传递 Signal

// ✅ 好的实践：函数接受 signal 参数
async function fetchData(url, options = {}) {
  const { signal } = options;

  // 立即检查
  signal?.throwIfAborted();

  const response = await fetch(url, { signal });

  // 中间检查
  signal?.throwIfAborted();

  return response.json();
}

// ❌ 不好的实践：忽略 signal
async function fetchDataBad(url) {
  return fetch(url).then((r) => r.json()); // 无法取消
}

4.3.2 正确清理事件监听器

async function someOperation(signal) {
  const cleanup = new AbortController();

  // 使用嵌套 signal 确保清理
  signal?.addEventListener(
    "abort",
    () => {
      cleanup.abort();
    },
    { once: true },
  );

  try {
    await doWork({ signal: cleanup.signal });
  } finally {
    // 确保清理
    cleanup.abort();
  }
}

4.3.3 区分取消错误与其他错误

async function robustFetch(url, signal) {
  try {
    return await fetch(url, { signal });
  } catch (error) {
    if (error.name === "AbortError") {
      // 取消是预期的行为，不需要上报
      console.log("Request cancelled");
      return null;
    }
    // 其他错误需要处理
    throw error;
  }
}

4.3.4 使用 AbortSignal.timeout() 设置超时

// ✅ 推荐：使用内置的超时信号
const signal = AbortSignal.timeout(5000);

// ❌ 不推荐：手动实现
const controller = new AbortController();
setTimeout(() => controller.abort(), 5000);

4.3.5 组合多个取消条件

// 组合用户取消和超时
const userController = new AbortController();
const timeoutSignal = AbortSignal.timeout(10000);

const combinedSignal = AbortSignal.any([userController.signal, timeoutSignal]);

fetch("/api/data", { signal: combinedSignal }).catch((err) => {
  if (err.name === "AbortError") {
    // 判断是哪种取消
    if (timeoutSignal.aborted) {
      console.log("Timeout");
    } else {
      console.log("User cancelled");
    }
  }
});

第五部分：深入思考——语言特性对设计的影响

5.1 JavaScript 的事件驱动本质

AbortController 的设计深深植根于 JavaScript 的事件驱动（Event-Driven）本质。JavaScript 作为单线程语言，无法使用抢占式中断（如线程信号），必须通过事件循环机制来传播信号。

这种设计使得 AbortController 与 JavaScript 的异步模型（Promise、async/await、EventTarget）无缝集成。

5.2 单线程模型的限制与优势

JavaScript 的单线程模型限制了取消机制的设计空间：

无法强制中断：无法像操作系统信号那样强制中断执行中的代码。
必须协作：任务必须主动检查信号并响应。

但这种限制也带来了优势：

避免竞态条件：没有抢占式中断的"任意点中断"问题，状态一致性更容易保证。
简化并发模型：单线程 + 事件循环使得取消信号的传播路径清晰可预测。

5.3 对比其他语言的设计选择

不同语言的中断机制设计反映了它们的运行时特性：

语言	运行时模型	取消机制	设计选择
JavaScript	单线程 + 事件循环	`AbortController`	事件驱动，协作式
Go	M:N 协程调度	`context.Context`	Channel 驱动，协作式
C#	线程池 + Task	`CancellationToken`	轮询 + 回调，协作式
Java	OS 线程	`Future.cancel()` + 中断	混合式（协作为主）
Kotlin	协程（挂起/恢复）	`Job.cancel()`	挂起点检查，协作式
Rust	异步 Future + 轮询	`Drop` 语义	所有权驱动，协作式
Python	事件循环 + 协程	`Task.cancel()`	异常驱动，协作式

核心点：

所有现代语言都选择了协作式取消，这不是偶然，而是对资源安全和状态一致性的共同追求。不同语言的实现方式反映了它们的核心抽象模型：

JavaScript 的 EventTarget → 事件驱动
Go 的 Channel → 通信顺序进程（CSP）
Rust 的 Ownership → 编译时安全
Kotlin 的 Structured Concurrency → 父子作用域

结论

AbortController 不仅是一个 API，更是 JavaScript 异步编程哲学的集中体现。它的设计遵循了以下核心思想：

协作优于强制：通过信号机制让任务自主决定如何响应取消，保证资源安全和状态一致性。
分离优于耦合：控制器与信号的分离使得取消逻辑可以灵活组合和传播。
事件驱动优于轮询：利用 JavaScript 的事件循环机制，实现即时、可靠的信号传播。
组合优于继承：AbortSignal.any() 等组合操作使得复杂的取消策略可以用简单的原语构建。

跨语言对比揭示了一个行业共识：协作式取消是现代异步编程的最佳实践。无论是 Go 的 Context、C# 的 CancellationToken、Kotlin 的协程取消，还是 Rust 的 Drop 语义，都在用各自语言的核心抽象表达同一个理念——让取消成为一等公民，但绝不以牺牲安全为代价。

理解 AbortController 的底层原理，不仅能帮助我们写出更健壮的异步代码，更能让我们洞察语言设计背后的深层思考：好的设计不是增加复杂性，而是在约束条件下找到最优雅的解决方案。

现在面试 AI 相关问题，不把底层原理扒得明明白白，真的分分钟被问麻😭 | 沸点周刊 4.16

掘金一周 — Thu, 16 Apr 2026 07:09:50 GMT

本周话题推荐

五一计划抢先晒

四月即将过半，五一假期越来越近啦，你是早早做好攻略的出行卷王，还是在疯狂抄作业的佛系选手，亦或是打算安心宅家躺平？快来分享你的假期安排，出游路线、宅家日常、避坑心得都欢迎～

万物皆可Skill

同事.Skill刚火，程序员们开始疯狂整活：老板.Skill催命，前任.Skill扎心，甲方.Skill改稿，反蒸馏.Skill保命……还有什么不能炼成Skill？晒出你见过的Skill，或者聊聊你对蒸馏的看法吧

一周“金”选

内容评审们会在过去的一周内对社区沸点进行挖掘和筛选，优质的技术、生活内容有机会出现在下方榜单中，排名不分先后。

AI & 大模型专区

上榜规则： 发布在AGI交流圈、AICoding交流、Vibe 变成交流圈、AI聊天室、大模型生态圈内，与 AI & 大模型相关的热点资讯、技术分享、使用体验等深度技术内容。

技术交流专区

上榜规则： 发布在服务端与架构、技术交流圈、前端开发圈、优秀开源项目内，掘友真实的技术体验分享、相关问题咨询、开源项目分享等深度技术内容。

优质创作者 TOP5

上榜规则： 内容积极向上，且带有明确圈子、图片的完整沸点，根据沸点热度和内容质量进行评选。

最近一次面试被问麻了吗 - 优质奖

AI 整活大赛，正式开擂！ - 优质奖

沸点活动日历

活动日历

沸点话题	有奖时间
五一计划抢先晒	2026年04月13日-2026年04月17日
万物皆可Skill	2026年04月13日-2026年04月17日

📖 投稿专区

大家可以在评论区推荐认为不错的技术类沸点，并附上链接和推荐理由，有机会呈现在下一期。沸点创建日期必须在下期沸点周刊发布前一周以内，可以推荐自己/他人的沸点。

彻底疯狂，Claude居然要上传身份证！

爱吃的小肥羊 — Wed, 15 Apr 2026 09:04:45 GMT

事情是这样的。

最近不少 Claude 用户在使用某些功能时，被弹出了一个新的页面。

要求上传政府签发的身份证件（身份证、护照、驾照），还要来一张自拍做活体识别。

不是注册的时候要上传，而是是用着用着突然要求你上传身份信息进行验证。

随后大家发现Anthropic 在帮助中心悄悄上了一篇新文档，标题叫《Identity verification on Claude》（Claude 上的身份验证）。

原文翻译过来，核心就三句话：

身份认证已经正式上线
不是所有人都触发，是"某些场景"会触发
触发了你就得传，不传就用不了

至于"某些场景"具体是哪些场景？官方一个字没说。

技术细节上，Anthropic 称不回存大家的身份证照片，而是接了一家叫 Persona 的第三方身份验证公司。

你的身份证和自拍直接给 Persona，Anthropic 想看的时候去 Persona 平台调。

官方还附赠了三连承诺：数据加密、不用于训练、不卖给第三方。

而且这事还不是孤立事件。

就在几天前，其实就已经有人发现 Claude 不太对劲了。

而在几天前，其实已经有人说Claude要进行验证还有另外一件事。

国外社交平台上，陆陆续续有用户晒出 Anthropic 发来的邮件，大意是：

"我们的团队发现信号显示，你的账户疑似由未成年人使用。"

然后给一个 30 天有效的申诉链接。

要解锁账号，得通过另一家叫 Yoti 的服务做年龄验证，选项包括上传身份证、面部扫描、生物识别。

30 天内不验证，账号直接禁用。

Anthropic 官方支持页面给的解释又是另一套说法，说年龄检测主要靠 Apple App Store 和 Google Play 的数据，部分美国州有新法规要求平台依赖应用商店年龄数据。

但用户实际收到的邮件是"我们团队发现信号"，听起来像是有人工审查 + 算法标记。

这两套说法对不上，引发了不少用户疯狂吐槽。

那现在还能怎么办？那必须只能使用Codex了。

如果你账号还没被弹验证窗口，那就继续用，能用一天是一天。

如果已经被要求传身份证、传自拍——大概率，这个号就到头了。

毕竟你不可能真的把身份证传给一个连服务都没对你开放的境外公司，对吧？

那剩下的选择就很清晰了，转到Codex上。

目前来看，Codex 是市面上唯一一个能在编程能力上和 Claude Code 掰手腕的工具。

其他的 Cursor、Cline、Aider 各有各的好，但说到"开箱即用、一个命令搞定一个项目"的体验，能打的就只剩 Codex 一个了。

而且 OpenAI 最近还很懂事地推出了 100 美金/月的 ChatGPT Pro 档位，Codex 用量直接给到 Plus 的 5 倍，发布期还有 10 倍优惠。

明摆着是来接盘的。

如果你还不会订阅ChatGPT，目前WildAI已经支持订阅了，三个档次的都有。

传送门：wildAI一键订阅GPT

可以预见的是，国内想要正常订阅和使用 Claude 这条路，会越走越窄。

但话说回来，这件事最让人想不通的，其实不是身份认证本身。

而是它发生的时间点。

根据 The Information 的消息，Anthropic 正在推进 IPO 计划，最快今年第四季度上市。

要上市了，故事得讲漂亮，估值得撑得住，用户数据要好看。

就在这个节骨眼上，亲手把一大批活跃用户挡在门外——

Claude Code 一年干出 25 亿美金的盘子，里面有多少是国内开发者贡献的，Anthropic 应该比谁都清楚。

身份认证上线那一刻，这部分收入基本就要拱手让给OpenAI。

在 IPO 前夕，主动把一个稳定收入盘砍掉，这操作怎么看都不像是一家急着冲业绩的公司该干的事。

最后只想说一句：

compose_skill 和 android skills，对 Android 项目提升巨大的专家 AI Skills

恋猫de小郭 — Wed, 15 Apr 2026 05:02:18 GMT

最近发现了一个非常不错的 Compose AI Skills 项目 compose_skill ，这个 Skills 可以针对你的 compose 项目生成一份评分的报告，例如下面就是我的 Compose 项目在这个 Skills 下得到的评分：

性能：4/10
状态管理：5/10
副作用：6/10
Composable API 质量：5/10

技能检查后的整体评价是：项目已经是比较完整的 Compose 多模块应用，结构合理，但是列表性能、状态收集方式、可复用组件的 API 设计，还有 ViewModel/模型穿透 UI 的方式，都存在系统性的问题，最关键的是这些问题不是零星个别点，而是在多个 feature 里重复出现了，所以只有 46/100 。

compose_skill 整体可信度还是可以的，它不是只是通过提示词和 rules 做评审，而是会通过内置的 Gradle 初始化脚本，直接生成并解析 Compose 编译器的报告（Reports）和指标（Metrics），主要评判维度有：

性能 (35%)：检查 Compose 里的耗时操作、Lazy 列表的 Key、稳定性（Stability）、强跳过模式（Strong Skipping）
状态管理：审计状态提升（Hoisting）、单一事实来源、生命周期感知的状态收集
Side Effects：检查 Effect API 的正确使用、Key 的选择、回调捕获
API 质量：审查 Modifier 规范、参数顺序、Slot API 设计

然后技能会生成一个名为 COMPOSE-AUDIT-REPORT.md 的报告，报告不只有分数（0-100），而是每一项扣分都会附带代码位置和官方文档引用 (References) ，例如我的检查里：

**State management: Android screens collect flows without lifecycle awareness**

- Why it matters: `collectAsState()` keeps collecting even when the screen is stopped, which wastes work and can keep screen state hot longer than intended.
- Evidence: `app/src/main/java/com/shuyu/gsygithubappcompose/MainActivity.kt:49`, `feature/search/src/main/java/com/shuyu/gsygithubappcompose/feature/search/SearchScreen.kt:34`, `feature/detail/src/main/java/com/shuyu/gsygithubappcompose/feature/detail/RepoDetailScreen.kt:106`, `feature/profile/src/main/java/com/shuyu/gsygithubappcompose/feature/profile/ProfileScreen.kt:28`
- Fix direction: add `lifecycle-runtime-compose` and switch Android UI collectors to `collectAsStateWithLifecycle()`.
- References: <https://developer.android.com/develop/ui/compose/state>

最重要是，它还能从审计结果利筛选出影响力最大的修复点，同时预测修复后对 skippable%（可跳过率）指标的提升效果。

而相比起那些只通过提示词和规格的技能，这个技能之所以能够做到深度的专家级审计，主要是因为：

Gradle ：项目自带了 scripts/compose-reports.init.gradle，在技能使用时 AI 会通过 --init-script 运行项目的 Gradle 任务，将编译器报告的配置动态注入到构建流程中，在不改动代码的情况下拿到部分数据
静态源码分析：它定义了一套详尽的 Ripgrep (rg) 搜索策略，涵盖了从 derivedStateOf 滥用、remember 缺失 Key 到 Scaffold 忽略内边距等数十种常见问题
评分机制：不是主观评价，在性能评分里如果 skippable% 低于 50%，或者不稳定类的数量超过阈值，性能得分会强制“封顶”（例如最高只能给 4 分），无论其他地方写得再好也不行
知识图谱与官方文档锚定：该项目维护了一份 canonical-sources.md，将所有的审计规则直接关联到 Android 官方文档和 AndroidX 源码中的 API 指南

所以相比起单纯的 AI 评价，它会更专业和全面，而相比起一般的 Linter，它结合了编译器的真实数据 + AI，不仅能告诉你“这个类可能不稳定”，还能通过编译器报告指出是哪个属性导致了不稳定。

当然，它对视觉能力审计会比较弱，作者也维护了另一个叫 material-3 的技能，这个技能会针对Material 3 的合规性、配色或排版进行评分。

这个技能可以看成是一个高级工程师的经验（如何看编译器报告、如何找状态提升问题、如何优化侧效应）固化成了 AI 可执行的脚本和规则，然后再通过 AI 进行量化判断，可以说是无私的奉献了：

你可以用它作为每次提交代码后的自动审查工具，或者在接手一个混乱的旧项目时，用它来快速定位性能瓶颈和架构风险。

总之，如果你正在用 Compose ，这个技能技必须不能错过。

我糟糕项目的报告可见：github.com/CarGuo/GSYG…

最后，android 官方也发布了对应的 skills ，目前主要是用于帮助 AI 升级和适配的技能，比如：

将 Android 项目升级到 Android Gradle Plugin (AGP) 9，涉及 DSL 迁移、内置 Kotlin 迁移、KSP 适配等复杂步骤
提供了将旧版 XML 视图迁移到 Jetpack Compose 的结构化工作流，定义了一套包含 10 个步骤的方法论，确保 UI 的视觉一致性和功能完整性
其他还涵盖了 Navigation 3 导航系统、R8 分析器性能优化以及 全屏显示 (Edge-to-Edge) 适配等场景

这份技能主要通过各种结构化的技术文档来告诉 AI 应该怎么处理升级和适配，需要遵循什么规则，每个技能都包含详细的前置要求、具体步骤、操作准则和验证方法，所以它不仅告诉 AI “做什么”，还明确规定了“不能做什么”，比如：

在 AGP 升级中禁止编写 Python 脚本。

技能文档中大量引用了 references/ 目录下的技术参考资料，例如在 XML 迁移技能中，它会引用专门的“分析项目布局”和“设置 Compose 依赖”的子文档。

所以这里最重要的就是，官方已经在强烈暗示你:「migrate-xml-views-to-jetpack-compose」，毕竟 AI 场景下，XML 确实也是更不上了。

总的来说，android skills 是偏通用性质的升级和适配场景，内容也都是文档和资料，而 compose_skill 则是专家级别的经验检测，能快速帮你找到需要优化的问题和建议。

我已经开始好奇了，你的项目能得几分 ~~~~~

链接

github.com/hamen/compo…

github.com/android/ski…

节省Token的8种方案

苏三说技术 — Wed, 15 Apr 2026 02:30:02 GMT

前言

最近有球友问：“三哥，我们团队在做AI客服，对话一长token消耗扛不住。有没有一种方案，既能保留完整上下文记忆，又能省token？”

这位朋友的问题，恰恰戳中了当下AI应用开发最头疼的痛点。

既要马儿跑得快，又要马儿不吃草。

这听起来像是矛盾，但经过这两年的摸索，我发现在某些条件下，确实存在“相对两全”的解法。

今天这篇文章就专门跟大家一起聊聊这个话题，希望对你会有所帮助。

更多项目实战在Java突击队网：susan.net.cn

一、为什么记忆必然消耗token？

很多小伙伴可能觉得，大模型就像一个人，你说过的话它应该天然记得住。

错！

大模型本质上是一个无状态的函数。

每次调用都是独立的，它没有任何“记忆细胞”。

为了让AI记住之前聊过什么，唯一的办法就是：把历史对话拼接到下一次请求里。

这就是所谓的“上下文注入”。

看到没？

第N次请求携带的历史，是前N-1轮的总和。

token消耗随着对话轮数线性增长——更准确地说，是O(n)级别的增长。

但事情没这么简单。

Transformer模型的核心是自注意力机制，它的计算复杂度是O(n²)。

也就是说，输入长度翻一倍，计算量翻四倍。

更可怕的是，当输入过长时，模型会患上“中间迷失症”——位于长文本中间的信息被严重忽略。

所以，我们的真实困境是：

保留全部历史 → token爆炸 + 注意力稀释 → 又贵又笨

丢弃历史 → 信息丢失 → AI变“金鱼脑”

有没有一条中间道路？

有。

下面我会介绍8种方案，从简单到复杂，从廉价到智能，你可以根据自己的场景按需选择。

二、方案一：全量记忆

简单粗暴，但不推荐。

这是最直觉的实现：把所有对话都存下来，每次请求全部带上。

public class FullMemorySession {
    // 使用LinkedList存储全部对话轮次
    private List<Message> fullHistory = new ArrayList<>();
    
    public void addTurn(String userMsg, String assistantMsg) {
        fullHistory.add(new Message("user", userMsg));
        fullHistory.add(new Message("assistant", assistantMsg));
    }
    
    public String buildContext() {
        StringBuilder sb = new StringBuilder();
        for (Message msg : fullHistory) {
            sb.append(msg.getRole()).append(": ").append(msg.getContent()).append("\n");
        }
        return sb.toString();
    }
    
    // 消息实体
    static class Message {
        String role;
        String content;
        // 构造器、getter省略
    }
}

代码解析：逻辑非常直接——fullHistory列表保存所有消息，buildContext()把它们全部拼接成字符串。没有任何优化。

优点：

信息零损失，完美保留每句话
实现极简单，5分钟写完

缺点：

token消耗随轮数线性增长，100轮可能几万token
达到模型上下文上限后（比如8K/128K），旧消息会被截断
响应时间越来越慢，账单越来越高

适用场景：只适合Demo演示、调试测试，或者保证对话不超过10轮的极短场景。

生产环境慎用。

三、方案二：滑动窗口

省token，但记性差。

滑动窗口只保留最近N轮对话，超出窗口的直接丢弃。

public class SlidingWindowMemory {
    private final int windowSize;          // 窗口大小，比如5轮
    private final Queue<Message> window;   // 用队列自动淘汰旧数据
    
    public SlidingWindowMemory(int windowSize) {
        this.windowSize = windowSize;
        this.window = new ArrayDeque<>();
    }
    
    public void addTurn(String userMsg, String assistantMsg) {
        // 加入新消息
        window.offer(new Message("user", userMsg));
        window.offer(new Message("assistant", assistantMsg));
        // 如果超过窗口大小（注意：一轮=2条消息），就移除头部
        while (window.size() > windowSize * 2) {
            window.poll();
        }
    }
    
    public String buildContext() {
        return window.stream()
            .map(m -> m.getRole() + ": " + m.getContent())
            .collect(Collectors.joining("\n"));
    }
}

代码解析：ArrayDeque作为队列，offer()在尾部添加，当大小超出windowSize * 2（因为一轮包含用户和助手两条消息）时，poll()移除最旧的。

这样窗口始终保持固定大小。

优点：

token消耗严格可控，不会无限增长
实现简单，性能高
响应速度快

缺点：

早期信息永久丢失。用户第一句说“我是VIP会员”，第20轮问“我的会员权益”，AI已经忘了
无法处理需要长期记忆的任务

适用场景：客服快速问答、闲聊机器人、临时对话——那些不需要记住早期信息的场景。

四、方案三：摘要压缩

让AI自己总结记忆。

这个方案的想法很巧妙：不保留原始对话，而是定期让大模型把旧对话“压缩”成一段摘要，只保留关键信息。

public class SummaryMemory {
    private String summary = "";                    // 历史摘要
    private List<Message> recentMessages = new ArrayList<>();  // 未压缩的新消息
    private final int compressThreshold;             // 触发压缩的token阈值
    private final LLMClient llm;                     // 大模型客户端
    
    public SummaryMemory(LLMClient llm, int compressThreshold) {
        this.llm = llm;
        this.compressThreshold = compressThreshold;
    }
    
    public void addTurn(String userMsg, String assistantMsg) {
        recentMessages.add(new Message("user", userMsg));
        recentMessages.add(new Message("assistant", assistantMsg));
        
        // 估算当前token数，超过阈值则触发压缩
        if (estimateTokenCount() > compressThreshold) {
            compress();
        }
    }
    
    private void compress() {
        // 构建待压缩的内容：旧摘要 + 新消息
        String toCompress = summary + "\n" + formatMessages(recentMessages);
        String prompt = """
            请将以下对话历史压缩成一段简洁的摘要，保留：
            1. 用户的关键信息（姓名、偏好、身份、已做出的决定）
            2. 重要的任务状态和上下文
            3. 任何后续对话可能需要的事实
            原始对话：
            %s
            摘要：
            """.formatted(toCompress);
        
        // 调用大模型生成摘要
        String newSummary = llm.chat(prompt);
        this.summary = newSummary;
        // 压缩后清空近期消息，但可以保留最后一轮作为锚点（防止断层）
        this.recentMessages.clear();
    }
    
    public String buildContext() {
        // 上下文 = 摘要 + 最近未压缩的消息
        if (summary.isEmpty()) {
            return formatMessages(recentMessages);
        }
        return "【历史摘要】\n" + summary + "\n\n【最近对话】\n" + formatMessages(recentMessages);
    }
    
    private int estimateTokenCount() {
        // 简单估算：中文1字≈2token，英文1词≈1.3token，这里粗略用字符数/2
        int totalChars = summary.length() + formatMessages(recentMessages).length();
        return totalChars / 2;
    }
    
    private String formatMessages(List<Message> msgs) {
        return msgs.stream()
            .map(m -> m.getRole() + ": " + m.getContent())
            .collect(Collectors.joining("\n"));
    }
}

代码详解：

summary字段存储压缩后的历史摘要，初始为空。
recentMessages存储尚未被压缩的新消息。
每次添加消息后，估算总token数（摘要+新消息），如果超过阈值，调用compress()。
压缩时，将旧摘要和新消息一起发给大模型，让它生成一个新的、更精炼的摘要。
压缩完成后清空recentMessages，但也可以选择保留最后1-2轮，防止摘要丢失近期细节。
buildContext()返回摘要+最近消息的拼接，作为下次请求的上下文。

优点：

压缩比极高：100轮对话可能压缩成200字摘要，token节省90%以上
关键信息被提炼出来，比滑动窗口聪明得多
成本可控，摘要生成的调用次数不多（每隔N轮一次）

缺点：

摘要可能失真：模型可能漏掉重要细节或产生幻觉
每次压缩需要额外调用LLM，增加几十毫秒延迟
摘要的“信息密度”随着压缩次数增加而下降（反复压缩会丢失细节）

适用场景：长周期对话（几十到几百轮），对信息完整性要求不是100%严谨的场景，比如教育辅导、角色扮演。

五、方案四：向量记忆（RAG）

检索相关而不是保留全部。

这是目前工业界最主流的方案。

思路是：不保存全部历史，而是把历史消息向量化后存入数据库，每次只检索最相关的几条历史。

public class VectorMemory {
    private final EmbeddingClient embeddingClient;  // 向量化模型，如OpenAI embedding
    private final VectorDatabase vectorDb;           // 向量数据库，如Milvus、Chroma
    private final int topK = 5;                      // 每次检索几条最相关的历史
    
    public VectorMemory(EmbeddingClient embeddingClient, VectorDatabase vectorDb) {
        this.embeddingClient = embeddingClient;
        this.vectorDb = vectorDb;
    }
    
    // 存储一条历史消息（每个消息单独存储，带上元数据）
    public void saveMessage(String role, String content, Map<String, Object> metadata) {
        // 1. 调用embedding接口，将文本转为向量
        float[] vector = embeddingClient.embed(content);
        // 2. 存入向量数据库
        VectorRecord record = new VectorRecord(vector, content, metadata);
        vectorDb.insert(record);
    }
    
    // 检索与当前问题最相关的历史记忆
    public List<Message> retrieveRelevantHistory(String currentQuestion) {
        // 将当前问题向量化
        float[] queryVector = embeddingClient.embed(currentQuestion);
        // 在数据库中做相似度搜索，返回topK条最相似的历史消息
        List<VectorRecord> results = vectorDb.search(queryVector, topK);
        // 转换成Message对象
        return results.stream()
            .map(r -> new Message((String)r.getMetadata().get("role"), r.getContent()))
            .collect(Collectors.toList());
    }
    
    // 构建上下文：检索结果 + 最近几轮（可选）
    public String buildContext(String userQuestion) {
        List<Message> relevantHistory = retrieveRelevantHistory(userQuestion);
        StringBuilder context = new StringBuilder("相关历史记忆：\n");
        for (Message msg : relevantHistory) {
            context.append(msg.getRole()).append(": ").append(msg.getContent()).append("\n");
        }
        return context.toString();
    }
}

代码详解：

每条消息单独存储，调用embeddingClient.embed()将其转为高维向量（比如1536维）。
向量数据库存储向量+原始文本+元数据（角色、时间戳等）。
当用户发来新问题时，同样将问题向量化，然后到数据库中做余弦相似度搜索，找到最相似的topK条历史消息。
这些检索出的历史消息就是“与当前问题最相关的记忆”，拼接进上下文。

优点：

token消耗极低：每次只带5-10条最相关的历史，而不是几百条
可以访问非常久远的记忆：只要存储了，就能检索到，不受窗口限制
灵活性高：可以混入知识库、FAQ等外部知识

缺点：

检索可能不准确：如果embedding模型质量差，或者问题与历史的相关性未被捕捉到，就会漏掉关键信息
需要额外组件：向量数据库、embedding服务，增加系统复杂度
有延迟：embedding调用+向量检索，大约增加50-200ms

适用场景：绝大多数生产环境——智能客服、AI助手、个性化推荐等。

这是目前最推荐的方案。

六、方案五：分层混合记忆

它是工业级最强方案。

没有单一方案是完美的。真正的工业级系统，往往会组合多种策略，形成分层记忆。

下面这张图展示了一个典型的混合记忆架构：

Java实现的核心骨架：

public class HierarchicalMemory {
    private SlidingWindowMemory shortTerm;     // L1 短期
    private SummaryMemory midTerm;              // L2 中期摘要
    private VectorMemory longTerm;              // L3 长期向量
    
    private final int SUMMARY_INTERVAL = 10;    // 每10轮触发一次摘要压缩
    private int turnCount = 0;
    
    public HierarchicalMemory(LLMClient llm, EmbeddingClient embed, VectorDatabase db) {
        this.shortTerm = new SlidingWindowMemory(5);   // 保留最近5轮
        this.midTerm = new SummaryMemory(llm, 2000);    // token超2000压缩
        this.longTerm = new VectorMemory(embed, db);
    }
    
    public void addTurn(String userMsg, String assistantMsg) {
        turnCount++;
        
        // 存入三层记忆
        shortTerm.addTurn(userMsg, assistantMsg);
        midTerm.addTurn(userMsg, assistantMsg);
        longTerm.saveMessage("user", userMsg, Map.of("turn", turnCount));
        longTerm.saveMessage("assistant", assistantMsg, Map.of("turn", turnCount));
        
        // 每10轮额外触发一次摘要同步（可选）
        if (turnCount % SUMMARY_INTERVAL == 0) {
            midTerm.compress();  // 强制压缩
        }
    }
    
    public String buildContext(String currentQuestion) {
        // 1. 短期记忆（最近对话）—— 最重要，直接拼接
        String shortContext = shortTerm.buildContext();
        
        // 2. 检索长期记忆（基于当前问题）
        List<Message> longMemory = longTerm.retrieveRelevantHistory(currentQuestion);
        String longContext = formatMessages(longMemory);
        
        // 3. 中期摘要（如果摘要非空）
        String midContext = midTerm.getCurrentSummary();
        
        // 4. 按重要性组装：短期 > 检索结果 > 摘要
        StringBuilder finalContext = new StringBuilder();
        finalContext.append("【最近对话】\n").append(shortContext).append("\n");
        if (!longContext.isEmpty()) {
            finalContext.append("【相关历史】\n").append(longContext).append("\n");
        }
        if (midContext != null && !midContext.isEmpty()) {
            finalContext.append("【历史摘要】\n").append(midContext).append("\n");
        }
        return finalContext.toString();
    }
}

代码解析：

L1 短期：滑动窗口保留最近5轮，保证对话连贯性，延迟最低。
L2 中期：摘要压缩，当消息积累到一定程度（比如token超2000或每10轮）就压缩一次，保留全局脉络。
L3 长期：向量数据库存储每条消息，支持按语义检索，解决“长尾记忆”问题。
构建上下文时：优先保证短期（最可靠），然后加上向量检索出的相关历史（弥补窗口丢弃的），最后补充摘要（作为兜底）。

优点：

兼具短时连贯、长时检索、全局摘要，覆盖几乎所有场景
token消耗可控（短期固定+检索topK+摘要）
即使检索失败，摘要和短期窗口也能兜底

缺点：

实现复杂，需要维护多个组件
需要精细调参（窗口大小、摘要频率、检索数量）

适用场景：大型生产系统、企业级AI应用，对体验和成本都有高要求的场景。

七、方案六：状态变量提取

该方案需要极致的结构化压缩。

有些场景下，真正需要记忆的不是整个对话，而是几个关键状态变量。

比如订票机器人只需要知道：{目的地: "北京", 日期: "2026-05-01", 人数: 2}。

public class StateVariableMemory {
    private Map<String, Object> state = new HashMap<>();  // 核心状态
    
    // 通过LLM从对话中提取结构化状态
    public void updateState(String userMsg, String assistantMsg, LLMClient llm) {
        String extractPrompt = """
            从以下对话中提取关键状态变量，以JSON格式输出。
            当前已有状态：%s
            用户最新消息：%s
            AI回复：%s
            请更新状态，只输出JSON，不要其他内容。
            """.formatted(toJson(state), userMsg, assistantMsg);
        
        String jsonResponse = llm.chat(extractPrompt);
        Map<String, Object> newState = parseJson(jsonResponse);
        state.putAll(newState);  // 合并更新
    }
    
    public String buildContext() {
        // 上下文只需要展示当前状态，而不是历史对话
        return "当前会话状态：" + toJson(state);
    }
}

优点：

极致省token：几KB的状态就能代替几十KB的对话
结构化，模型更容易理解

缺点：

只适合高度结构化的任务（订票、填表、参数收集）
提取状态本身需要调用LLM，有额外成本

适用场景：任务型对话、表单填写、配置向导。

八、方案七：工具/函数调用

把记忆“外包”给外部系统。

大模型不是万能的，记忆完全可以交给外部数据库。

模型只需要学会调用“保存记忆”和“查询记忆”的工具。

public class ToolBasedMemory {
    // 定义两个工具函数
    @Tool(name = "save_memory", description = "保存一条重要信息到长期记忆")
    public void saveMemory(String key, String value) {
        externalDB.put(key, value);
    }
    
    @Tool(name = "recall_memory", description = "根据关键词回忆之前保存的信息")
    public String recallMemory(String key) {
        return externalDB.get(key);
    }
    
    // 在对话循环中，让模型自主决定何时调用这些工具
}

这种方案让模型自主管理记忆——它觉得重要就存，需要就用。这是目前AI Agent的主流做法。

优点：极其灵活，模型可以按需存取；token消耗几乎为零（只传工具调用结果）。
缺点：依赖模型自身的函数调用能力，容易出错或漏存。

适用场景：Agent系统、自主决策类应用。

九、终极对比

方案	token节省效果	信息保留能力	实现复杂度	推荐指数
全量记忆	0%（无节省）	100%	⭐	❌ 不推荐
滑动窗口	极高（固定）	差（只留近期）	⭐	⭐⭐ 短对话可用
摘要压缩	高（70-90%）	中（可能失真）	⭐⭐⭐	⭐⭐⭐⭐ 长对话
向量检索(RAG)	高（每次topK）	高（语义检索）	⭐⭐⭐⭐	⭐⭐⭐⭐⭐ 首选
分层混合	高	极高	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐ 工业级
状态变量	极高（近乎0）	中（仅结构化）	⭐⭐	⭐⭐⭐ 任务型
工具调用	极高	中（靠模型）	⭐⭐⭐⭐	⭐⭐⭐⭐ Agent场景

更多项目实战在Java突击队网：susan.net.cn

总结

回到最初的问题：有没有方案既能保留上下文记忆，又能省token？

我的答案是：有，但不存在“免费午餐”。

每一分token的节省，都换来了系统复杂度的增加或记忆精度的下降。

根据我的实战经验，给你几条直接的建议：

如果你刚开始做MVP：直接用滑动窗口（最近10轮），上线跑起来再说。先验证产品价值，再优化成本。
如果你做的是通用客服/AI助手：首选向量检索（RAG）。这是当前最成熟、性价比最高的方案。配合一个小的滑动窗口（3-5轮）保证对话连贯性，效果已经很好了。
如果你的对话轮次非常长（100+）且信息密度高：上分层混合记忆。短期窗口+中期摘要+长期向量，三者配合才能既省token又不丢信息。
如果你做的是表单/订票/参数收集：状态变量提取是王道。几十个字段就能代表整个会话，token几乎不增长。
永远不要在生产环境用全量记忆——除非你预算无限且用户只聊5句话。

posted @ 苏三说技术阅读(0) 评论(0) MD 编辑收藏举报

别再用 JSON.parse 深拷贝了，聊聊 StructuredClone

ErpanOmer — Wed, 15 Apr 2026 01:58:12 GMT

临近下班，我们业务线出了一个极度无语的线上 Bug。

产品侧反馈，在一个非常核心的财务表单里，用户明明选择了 2026-04-14 作为结算日期，但点击提交后，整个页面直接白屏崩溃。

我打开错误监控看了一眼日志，立刻就把组里那个刚入职不久的小伙子叫了过来。原因极其经典：他在把表单的原始状态同步给历史快照时，为了图省事，顺手写了一段几乎所有前端都写过的代码：

// 模拟用户表单数据
const formData = {
  amount: 1000,
  date: new Date("2026-04-14"), // 用户选的结算日期（Date对象）
};

// 深拷贝
const snapshot = JSON.parse(JSON.stringify(formData));

console.log("原始:", formData.date, typeof formData.date); 
// Date object

console.log("快照:", snapshot.date, typeof snapshot.date); 
// "2026-04-14T00:00:00.000Z" string

// 后续业务代码
function calcSettlementTime(data) {
  // 这里默认 date 是 Date 对象
  return data.date.getTime();
}

// 页面直接崩溃😢
try {
  const time = calcSettlementTime(snapshot);
  console.log("时间戳:", time);
} catch (err) {
  console.error("页面崩溃:", err);
}

他满脸委屈：老大，大家平时深拷贝不都是这么写的吗？🤷‍♂️

我让他自己把这段代码在控制台跑一遍。当他看到表单里原本好好的 Date 对象，经过这一进一出，硬生生变成了一串 ISO 格式的字符串，导致后面调用 snapshot.date.getTime() 直接抛出 TypeError 时，他自己也沉默了。

作为前端老油条，这种因为 JSON.parse(JSON.stringify()) 引发的血案，我见过太多了。它不仅会把 Date 变成字符串，还会把 Map 和 Set 变成空对象 {}，会把 undefined、Symbol 以及函数直接活生生抹除，更别提遇到循环引用时，它会当场抛出异常让你的主线程直接崩溃。

以前，我们为了解决这个破事，不得不在每个项目里老老实实 npm install lodash，然后引入那个笨重的 cloneDeep。

但现在是 2026 年了。浏览器早就原生内置了完美的终极解药——structuredClone。

今天咱们不聊虚的架构，就花三分钟，把这个原生 API 的底层逻辑讲清楚。

它是怎么解决历史遗留问题的？

structuredClone 不是什么语法糖，它是浏览器底层暴露出来的 结构化克隆算法（Structured Clone Algorithm）。这就意味着，它在 C++ 引擎层面的处理逻辑，远比 JS 业务层面的递归拷贝要深得多。

看一下原生 API 的用法：

const original = {
  date: new Date(),
  set: new Set([1, 2, 3]),
  map: new Map([['key', 'value']]),
  regex: /hello/i,
  buffer: new Uint8Array([1, 2, 3]).buffer,
};

// 制造一个循环引用
original.self = original;

// 一行代码，原生搞定
const cloned = structuredClone(original);

console.log(cloned.date instanceof Date); // true
console.log(cloned.set instanceof Set);   // true
console.log(cloned.self === cloned);      // true 完美处理循环引用！

发现没有？它不仅完美保留了所有的内置对象类型，连 JSON.parse 绝对搞不定的循环引用，它都处理得游刃有余。由于是在引擎底层运行，不需要像 Lodash 那样在 JS 运行时里疯狂压栈递归，它的执行效率在大部分复杂场景下都具有压倒性优势👍👍👍。

零拷贝转移（Transferable Objects）

如果你以为 structuredClone 只是为了少引入一个 Lodash，那你就太小看浏览器的底层野心了。

它藏着一个 90% 的前端都不知道的极其硬核的功能：内存转移（Transfer）。

在前端处理音视频、WebGL、或者读取几十 MB 的大文件时，我们经常会生成巨大的 ArrayBuffer。如果你用传统的深拷贝，内存瞬间翻倍，几十兆的内存分配极容易引起页面的掉帧卡顿。

structuredClone 提供了一个极其变态的第二个参数配置：{ transfer }。

// 假设这是一个极大的 50MB 数据内存块
const u8Array = new Uint8Array(1024 * 1024 * 50);
const hugeBuffer = u8Array.buffer;

// 传统的深拷贝：内存翻倍，耗时极长
// const badCopy = lodash.cloneDeep(hugeBuffer); 

// 直接内存转移
const fastClone = structuredClone(hugeBuffer, { transfer: [hugeBuffer] });

console.log(fastClone.byteLength); // 52428800 (50MB 完美转移)
console.log(hugeBuffer.byteLength); // 0 (原对象的内存地址被转移)

这段代码的核心在于：它压根没有复制数据。 它直接在内存层面，把这块 50MB 数据的所有权，从 hugeBuffer 强行转移给了 fastClone。原对象被彻底掏空（变成了 detached 状态）。

这种零拷贝机制，在结合 Web Worker 处理复杂后台计算时，是打破性能瓶颈的绝对神器。这是任何第三方 JS 库都做不到的底层API。

一些坑要讲清楚🤔

既然这么牛，是不是以后项目里所有的拷贝闭着眼睛用它就行了？作为一个踩过无数坑的老兵，我必须点出它的几个致命死角。如果你在真实的业务架构里滥用，下场比用 JSON.parse 还要惨。

对于函数和 DOM 节点的处理

JSON.parse 遇到函数，它会默默地忽略掉，至少不报错。但 structuredClone 很直接。只要你的对象树里藏着一个方法，或者藏着一个 DOM 节点的引用，它会直接给你抛出 DataCloneError。

const objWithFunc = {
  data: 123,
  onClick: () => console.log('click')
};

// 只要带有函数，直接抛同步错误
// DOMException: () => console.log('click') could not be cloned.
const copy = structuredClone(objWithFunc);

这就意味着，如果你要拷贝的是一个 Vue/React 的响应式组件实例，或者是带有业务方法的数据模型，绝对不能用它👋。

原型链的断裂

不管你原本是一个通过 class 实例化的多么高级的业务对象，经过 structuredClone 的洗礼后，它都会变成一个普通的纯对象（Plain Object）。

class User {
  constructor(name) { this.name = name; }
  sayHi() { console.log('hi'); }
}

const user = new User('前端');
const cloneUser = structuredClone(user);

console.log(cloneUser instanceof User); // false 
cloneUser.sayHi(); // TypeError: cloneUser.sayHi is not a function

原型链上的所有方法全部丢失。它只关心纯粹的数据，不关心你的面向对象架构。‘

需要时收藏起来⭐⭐⭐

这几年，前端的工具链卷得飞起，大家的 package.json 越来越臃肿。遇到数组去重找库，遇到时间格式化找库，遇到深拷贝也要找库。

如果你只是单纯地处理一些后端传过来的嵌套数据，或者表单的复杂配置结构，完全可以直接把 structuredClone 敲在你的代码里。不用担心兼容性，目前主流浏览器（包括 Node.js）的支持率早就达到了工业级使用的标准了。

下次 Code Review 时，别再让我看到满屏的 JSON.parse 了（玩笑😁😁😁）。

分享完毕，谢谢大家🙌

GetX 之死 | 8 年从未用过，以后将不会再用

张风捷特烈 — Tue, 14 Apr 2026 23:55:31 GMT

1.一个时代的句号

2026 年的某一天，当你打开 https://github.com/jonataslaw/getx，迎接你的不是那个熟悉的 10000+ star 的仓库，而是一个冰冷的 404 页面。

不只是仓库。作者 jonataslaw（Jonny Borges）的整个 GitHub 主页也 404 了。get_cli、get_server、get_storage——整个 GetX 生态的所有仓库，一夜之间全部消失。

没有告别信，没有迁移公告，没有"项目已归档"的标注。一个曾经是 Flutter 社区最具争议、也最广泛使用的第三方包，就这样无声无息地消失了。

pub.dev 上的 get 包还在——因为 pub.dev 是独立托管的，不会因为 GitHub 删库而下架。你的项目今天还能 flutter pub get，还能编译，还能运行。但源码没了，issue 没了，786 个未关闭的 issue 没了，78 个待合并的 PR 没了，文档没了。

一个没有源码仓库的包，和一具没有灵魂的躯壳有什么区别？

2.回顾：GetX 曾经有多火

在说"为什么不用"之前，先承认一个事实：GetX 确实火过。并且号称宇宙第一：

GitHub 10500+ stars，1600+ forks
pub.dev 上曾经是 likes 数最高的 Flutter 包之一
README 被翻译成十几种语言（日语、韩语、阿拉伯语、葡萄牙语……）
大量教程、视频、课程围绕 GetX 构建
在中文 Flutter 社区尤其流行，几乎每个技术群都有人推荐

它火是有原因的。看这段代码：

// 传统方式：定义 StatefulWidget，写 setState，管理生命周期
class CounterPage extends StatefulWidget {
  @override
  _CounterPageState createState() => _CounterPageState();
}

class _CounterPageState extends State<CounterPage> {
  int count = 0;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(child: Text('$count')),
      floatingActionButton: FloatingActionButton(
        onPressed: () => setState(() => count++),
        child: Icon(Icons.add),
      ),
    );
  }
}

// GetX 方式：三行搞定
final count = 0.obs;

Obx(() => Text('$count'));

onPressed: () => count++;

对于刚入门 Flutter 的开发者来说，这种简洁性是致命的吸引力。"为什么要写那么多样板代码？GetX 三行就搞定了。"

但简洁和简单不是一回事。简洁是表面上代码少，简单是底层复杂度低。GetX 的代码少，但底层复杂度一点都不低——它只是把复杂度藏起来了。

3.我为什么 8 年从未用过 GetX

从 2018 年开始写 Flutter，到现在 8 年了。期间无数次被推荐 GetX，无数次在技术群里看到"用 GetX 三行代码搞定"的安利。但我一次都没用过。甚至我的群聊公告里都写着:

本群禁止讨论 GetX,有任何问题可以向 GetX 官方提issue。

不是因为我有先见之明，而是因为它违反了我认为正确的几个原则。

原则一：不要把所有鸡蛋放在一个篮子里

GetX 管了你的状态、路由、依赖注入、国际化、主题、HTTP 请求、本地存储、表单验证……一个包解决所有问题，听起来很美。

但软件工程的基本常识是：耦合越紧，风险越大。 来看一个真实的对比：

# 方案 A：每层独立
dependencies:
  provider: ^6.0.0        # 状态管理
  go_router: ^14.0.0      # 路由
  dio: ^5.0.0             # 网络请求
  shared_preferences: ^2.0.0  # 本地存储
  intl: ^0.19.0           # 国际化

# 方案 B：全家桶
dependencies:
  get: ^4.7.3             # 状态 + 路由 + DI + 网络 + 存储 + 国际化 + ...

方案 A 看起来依赖多，但每个依赖都是独立的。dio 不维护了？换成 http 包，其他四个完全不受影响。路由库想升级？只改路由层，状态管理一行不用动。

方案 B 看起来清爽，只有一个依赖。但这个依赖出问题 = 所有东西出问题。

今天，这个"所有东西出问题"的场景真的发生了。

原则二：隐式依赖是技术债的温床

GetX 最大的卖点之一是"不需要 context"。Get.find() 可以在代码的任何角落调用，不需要 Widget 树，不需要构造函数参数。

// GetX 的方式：在任何地方都能拿到任何东西
class OrderController extends GetxController {
  void submitOrder() {
    // 这三个依赖从哪来的？谁注册的？什么时候注册的？生命周期是什么？
    final cart = Get.find<CartController>();
    final auth = Get.find<AuthController>();
    final api = Get.find<ApiService>();
    // ...
  }
}

// 官方推荐的方式：依赖通过构造函数显式传入
class OrderViewModel extends ChangeNotifier {
  final CartRepository _cartRepository;
  final AuthRepository _authRepository;

  // 一眼就知道依赖了什么，测试时直接传 Fake
  OrderViewModel({
    required CartRepository cartRepository,
    required AuthRepository authRepository,
  }) : _cartRepository = cartRepository,
       _authRepository = authRepository;
}

写起来确实多了几行。但代价是什么？

维度	`Get.find()`	构造函数注入
知道一个类依赖了什么	全局搜索才知道	看构造函数就知道
测试时 Mock 依赖	配置 GetX 全局容器	直接传 Fake 对象
删了一个注册	编译通过，运行时崩	编译直接报错
重构时追踪依赖	全局搜索 `Get.find<T>()`	IDE 的"Find Usages"
循环依赖检测	运行时才发现	编译时就报错

这不是"风格偏好"，这是编译时安全 vs 运行时崩溃的根本差异。一个项目有 50 个 Controller，每个都用 Get.find() 拿依赖，你敢重构吗？

原则三：不要依赖个人英雄主义

GetX 本质上是一个人的项目。jonataslaw 一个人写了状态管理、路由、依赖注入、HTTP 客户端、国际化、主题……一个人维护这么大的范围，质量和持续性都无法保证。

早在删库之前，信号就已经很明显了：

2023 年 6 月：社区开始问"5.0 什么时候发布？"（Issue #2797），至今没有正式版
2023-2024 年：超过 13 个月没有版本更新，停留在 4.6.5
2025 年 1 月：有人开了 Issue #3295 直接问"GetX 还活着吗？"
786 个未关闭的 issue，78 个待合并的 PR——一个人根本处理不过来

对比一下官方推荐的方案：

包	维护者	会因为一个人的决定消失吗？
`provider`	Flutter 官方团队	不会
`go_router`	Flutter 官方团队	不会
`ChangeNotifier`	Flutter 框架内置	不会
`Navigator`	Flutter 框架内置	不会
`flutter_bloc`	社区团队（多人维护）	极低概率
`riverpod`	Remi Rousselet（provider 作者）	低概率，且有社区 fork 能力
GetX	jonataslaw（一个人）	已经发生了

原则四："不需要 context"不是优点，是危险信号

GetX 的宣传语之一是"不需要 context 就能导航、弹对话框、显示 SnackBar"。

// GetX：不需要 context
Get.to(HomePage());
Get.snackbar('标题', '内容');
Get.dialog(AlertDialog(...));

听起来很方便。但 context 在 Flutter 中不是累赘——它是 Widget 树的定位器，告诉框架"我在哪里"。绕过 context 意味着绕过 Flutter 的 Widget 生命周期管理，这会导致：

SnackBar 在页面已经销毁后还在显示
对话框在错误的路由上弹出
内存泄漏——Controller 没有跟随 Widget 生命周期释放

GetX 用全局状态和静态方法绕过了 Flutter 的设计，短期内写起来爽，长期维护时各种幽灵 Bug 让你怀疑人生。

4.给正在用 GetX 的项目的建议

如果你的项目正在用 GetX，不要恐慌，但也不要心存侥幸。

短期内你是安全的：

pub.dev 上的包不会因为 GitHub 删库而消失
你的 pubspec.lock 锁定了版本，flutter pub get 还能正常工作
已编译的应用不受任何影响

但定时炸弹已经埋下了：

Flutter 下一个大版本更新（比如 Dart 4.0）可能导致 GetX 不兼容，没有人会修
发现 Bug 没有人修，发现安全漏洞没有人补
新入职的同事看到一个 404 的仓库链接，会对项目的技术选型产生严重怀疑

迁移路径

不要一次性重写。逐层替换，每次只动一个模块，每次都跑测试：

第一步：路由（影响范围最小，最先动手）
  Get.toNamed('/home')  →  GoRouter 的声明式路由
  Get.back()            →  context.pop()
  GetPage              →  GoRoute

第二步：依赖注入（把隐式改成显式）
  Get.put(MyController())     →  ChangeNotifierProvider(create: (_) => MyViewModel())
  Get.find<MyController>()    →  context.read<MyViewModel>()
  Get.lazyPut(...)            →  Provider 的 lazy 默认行为

第三步：状态管理（工作量最大，收益也最大）
  GetxController + .obs + Obx  →  ChangeNotifier + Consumer / context.watch
  update()                     →  notifyListeners()
  GetBuilder                   →  Consumer

第四步：其他零散功能
  GetConnect        →  dio / http
  GetX 国际化       →  flutter_localizations + ARB 文件
  GetX 主题切换     →  ThemeData + ThemeMode
  Get.snackbar()    →  ScaffoldMessenger.of(context).showSnackBar()
  Get.dialog()      →  showDialog(context: context, ...)

每完成一步，跑一遍测试，确认没有回归。如果你的项目没有测试——这是另一个需要补的债，而且优先级比迁移 GetX 更高。

迁移的工作量评估

项目规模	GetX 使用深度	预估迁移时间
小项目（10-20 个页面）	只用了状态管理	1-2 周
中项目（30-50 个页面）	状态 + 路由 + DI	2-4 周
大项目（100+ 个页面）	全家桶深度使用	1-3 个月

如果是大项目，建议新功能用新方案写，老功能逐步迁移，不要停下业务开发来专门做迁移。

5.更深层的教训

GetX 之死不是个案。它揭示了开源生态中一个结构性的风险：社区的繁荣可以掩盖项目的脆弱性。

10000+ star、几十种语言的 README 翻译、数百个教程视频——这些都是社区繁荣的表现。但项目的健康度不取决于 star 数，而取决于：

核心维护者有几个人？（GetX：1 个）
有没有组织/公司背书？（GetX：没有）
issue 响应速度如何？（GetX：786 个未关闭）
版本发布频率如何？（GetX：5.0 难产三年）

下次选择一个第三方包时，不要只看 star 数和 likes。打开 GitHub 仓库，看看：

Contributors 页面——核心贡献者超过 3 个人吗？
最近的 commit——最后一次提交是什么时候？
Issue 列表——维护者有在回复吗？
Release 历史——版本发布有规律吗？

如果一个包只有一个核心维护者、半年没有 commit、几百个未关闭的 issue——不管它有多少 star，都要三思。

5. 2026 年，Flutter 状态管理该怎么选

GetX 退场后，Flutter 状态管理的格局更清晰了：

方案	定位	适合谁	维护状况
`provider` + `ChangeNotifier`	Flutter 官方推荐的入门方案	大多数项目	官方维护
`Riverpod`	provider 的进化版，编译时安全	追求类型安全和可测试性的项目	社区活跃，多人维护
`flutter_bloc` / `Cubit`	企业级方案，严格的单向数据流	大型项目、需要审计追踪的场景	社区活跃，多人维护
`setState`	最简单的方式	临时状态、原型开发	框架内置，永远不会消失

没有 GetX。以后也不会有 GetX。

6. 写在最后

8 年前我选择不用 GetX，不是因为预见了今天。是因为几个朴素的判断：

一个人维护的全家桶，风险太高
隐式依赖写起来爽，维护起来痛
绕过框架设计的"便利"，迟早要还债

今天这些判断被验证了。但我并不觉得高兴——毕竟有大量的项目和开发者受到了影响。那些用 GetX 写了几万行代码的团队，现在面对的是一个没有源码、没有维护者、没有未来的核心依赖。

如果你正在选择 Flutter 的技术栈，记住一条原则：

每一层都应该可以独立替换。

状态管理、路由、依赖注入、网络请求——每一层用独立的方案，每一层都有替代品。这样无论哪一层出问题，你都只需要换那一层，而不是重写整个应用。

这不是过度设计，这是基本的风险管理。

GetX 教会了我们：在开源世界里，便利是借来的，风险是自己的。

笔者目前正在公众号 编程之王 编写并发布《Flutter Agent Skills 全解析》系列，覆盖 Flutter 官方推荐的 22 个开发技能。如果你对 Flutter 官方推荐的架构、状态管理、测试等最佳实践感兴趣，欢迎关注。

我装了 30 多个 Claude Code Skill，每天真开的就 6 个

小墨同学boy — Tue, 14 Apr 2026 12:19:40 GMT

用过Claude code 的都知道，在Claude code 里没打开marketplace的时候里面琳琅满目的Skill根本看不完。我前后装了 30 多个skill,跑了两个月，最后留下的只有这六个。

剩下哪些skill，基本上都是新鲜感装完了就好了。因为最主要的问题不是它们不好——而是装太多本身就是坑，根据情况触发正确的准确率会直接掉到 50% 以下。Claude 得扫所有 skill 的描述决定用哪个，描述一多它就开始乱猜。官方建议创作者合理持有量 20 到 30 个，而且得是贴你自己工作流的那种。

这篇讲我筛剩下的 6 个。3 个通用，3 个创作。不讲原理，只讲每个放工作流哪一段、我为什么选他们的原因，替你节省判断和挑选的时间。

Skill 到底是啥，顺便把"必装清单"这个坑点掉

Skill 就是一个 SKILL.md 加几个参考资料，按需加载。关键词是按需——不用的时候不占上下文，用的时候才拉全文。这个机制叫渐进式披露，你要是一上来把所以相关的内容全塞主文件里，那这样上下文全是你的skill，根本就没办法判断到底该使用什么skill。

找 skill 的入口有几个:

Claude Code 里跑 /plugin marketplace
聚合站 skillsmpp.com,号称收录了 96,000+ 个
skillhub.club,精选路线
GitHub 上的 awesome-claude-skills

但清单里的"必装 Top 30"基本都不能抄。别人的工作流不等于你的。我筛的时候只问一个问题:

它能不能替我每天省掉一步手动动作?

答不上来就不装。比任何评分都管用。

通用 3 个:不管你写博客还是跑项目，都用得上

1. Skill Creator(官方)

元技能，主动问你流程怎么跑的，然后帮你写出 SKILL.md,连测试用例都生成好。

我排它第一的理由很直接:你装的其他 skill,最后都要能自己造。在素材库里 10 多个独立来源都把它放在起点，几乎所有教程开篇都是它。

典型指令就一句——"把我昨天手动跑的选题流程打包成 skill"。

2. Planning with Files(社区)

写长文你肯定有过这种经历,Claude 一开始答应得好好的,结果写到三千字左右就开始自己发挥了,原来说好的结构慢慢就跑偏了,连你一开头交代过的品牌调性它也会忘。

这玩意就是来修这个坑的。它会强制 Claude 动手之前先写一份 task_plan.md,然后每做两步就回头更新一下 findings.md 和 progress.md。说白了就是给它外挂了一块硬盘记事,这样对话再长,它也不会忘自己在干什么。

顺便说一下,它在 GitHub 上拿了 13,410 Stars,是目前 skill 生态里 Star 数最高的社区 skill。开发圈对它的评价比创作者圈高很多,但我觉得其实写长文一样会踩"写到后面忘开头"这个坑,你别被"开发向"三个字劝退。

3. Document & Presentation Skills(官方)

PDF、Word、Excel、PowerPoint 全家桶,Anthropic 官方做的。说实话写代码的人用它可能没啥感觉,但每天都在写东西的人,这玩意能省的活真的有点多。

我自己用得最多的就是把 PDF 转幻灯片。收到一份 23 页的行业报告 PDF,我让它把里面的关键数据抽出来做一份 10 页的 slide,顺便套我自己的品牌色。这种事以前我得开 3 个软件来回切来切去折腾大半天,现在一句话就完事。

创作 3 个:每天写东西绕不开

下面这 3 个我挑的时候标准其实就一个——哪个一次调用能替我干最多的活,我就留哪个。辅助能力越强,每天我开的次数就越多。

4. SEO Blog Writer & Lead Magnet(社区)

这个一次能跑通 3 件事:先做一轮 Ahrefs 关键词研究,然后写一篇结构完整的 SEO 长文,最后再把长文里的干货抽出来排成一份 11 页 PDF 引流手册。

写过博客的人都知道这条链有多费劲。一篇长文本身已经够累,你写完还要开 Canva 或者 Figma 手搓一份 PDF 诱饵,光排版又是两三个小时。现在三步合成一步,你只管定选题就行。

说实话我留这个 skill 不是图它省时间那层。真正让我觉得它值得留下来的,是它把邮件诱饵这件事从"下次再做"变成了"顺手就做"。博客最亏的一环就是读者看完之后走了,你连个邮箱都收不到。但你如果有 PDF 可以送,起码还能留一个联系方式回来。以前我懒得专门为每篇文章做一份诱饵,现在这一步直接折进主流程,我也没什么借口不做了。

5. Newsletter Automation(社区)

这个更狠一点,一条指令就能跑完整条 Newsletter 运营链。

具体是这么个流程:它会先让 Perplexity 去查今天的行业动态,摘 5 到 8 条要点出来,然后按你提前喂过的模板套 HTML 排版,Mailchimp 和 Substack 的样式都能直接用。配图部分你可以接 Nano Banana Pro 让它自己画,也可以直接抓你自己图床里现成的图。最后一步是存到 Gmail 草稿箱,你打开邮箱就能看到一封已经排好版的草稿躺在那,扫一眼没问题点发送就完事了。

这玩意已经不算辅助写作了,是直接替你不用写。

注意:这个 skill 跑起来要接 Perplexity API 和 Gmail MCP,前置比前面几个重一点,但你配置一次之后就是一劳永逸。

独立做 Newsletter 以前是真纠结——每天一两个小时收集信息、写稿、排版,成本高得吓人,你做一个月可能就想放弃了。我自己之前也被这个门槛拦过好几次。装完之后门槛直接砍到每天 10 分钟审一遍稿就行,我第一次看真实演示的时候心里真的有点"运营岗要凉了"的感觉。

6. Content Repurposer(社区)

解决的是多平台分发的问题。读一篇博客长文或者视频逐字稿,它可以并行生成 Twitter 线程、LinkedIn 动态、Newsletter 开头段。素材里 4 到 5 个来源都点名推荐了它,是非编程类 skill 里被提得最多的一个。

你可能会觉得,这种事直接让 Claude 改写一下不就完了?我以前也是这么想的。但你真跑过一次就知道差别在哪——三个平台的语气、节奏、钩子完全是不同的逻辑。Twitter 第一条必须是强钩子,LinkedIn 开头要像同事在说话,Newsletter 头段又得像老朋友给你写信。你手动"改写"的时候其实是在重写三遍。

它跟直接让 Claude 改写最大的区别,是它会先去读你过去发过的帖子,把你自己的语气特征先抓出来,然后再往各平台的语感上套。

一个人运营多平台最容易在分发这一步放弃,就是因为越做越像流水线工人。装完之后整条分发链从半小时直接压到一分钟。

延伸阅读:别让 AI 写得像 AI:用自己的 83 篇博客训练专属写作助手,顺手做成了一个 Skill ——创作向 skill 光装不够,还得拿自己写过的东西训一轮才真贴你的语气。

我的一些建议

其实别把 skill 想得太复杂,先装一个跑一次,比看十篇推荐文都管用。

前面讲的 6 个已经够具体,你直接照着装就行。唯一要提醒的就一条:别一上来装 50 个。素材里有个说法叫 "Setup Porn",意思就是花好几个小时配一堆 skill,结果什么内容都没产出,本质就是拿配置当拖延借口。手动跑同一个任务 3 次以上,再让 Skill Creator 帮你打包,不要反过来。

按场景选会更省事:

你每天在 Claude 里反复跑同一串动作,先装 Skill Creator。你写长内容经常写到后半段就忘了开头设定,装 Planning with Files。你写博客、公众号想一份长稿出多平台,装 Content Repurposer。你才刚点进 Claude Code,连 Skills 开关都没开过,先去 Settings → Capabilities → Skills 打开,顺手把 skill-creator 也开上。

前面装得少,Claude 的触发准确率才稳得住,又回到开头那个 50% 的数据。别跟这条反着来。

周下载60w，但是作者删库！我从本地 pub 缓存里把它救出来，顺手备份到了自己的 GitHub

小林的编程开发日记 — Tue, 14 Apr 2026 07:23:16 GMT

经过

今天在社区闲逛时，顺手看了一眼群里，说 get作者删库跑路了！我最初保持怀疑的态度，打开pub地址还能打开，

我看到时心里想:(这库的周下载逼近60w，收获了15.5k的star，而且getx是flutter四大状态管理仓库之一，时至今日，还有很多很多用户，我自己做项目，也在拿getx以及provier、riverpod、bloc做技术选型，横向对比...)

跑路了相当于vue生态中的vuex、pinia跑路，太BT了...

当我再打开github，迎接我的就是

我心中大喊不妙，这种时候最怕的不是“今天能不能跑”，而是过一阵子你换电脑、CI 重装、同事新拉项目的时候，大家突然开始补依赖、找源码、翻缓存，最后一圈人全卡住。

我这边的处理方式很简单：既然本地还能跑，那就先把本机已经缓存下来的完整包捞出来，备份到自己的 GitHub，至少后面有个稳定来源。

我已经把这份 get 4.7.3 传到了这里：

https://github.com/xinqingaa/get-4.7.3

如果你们团队里有人懒得自己再走一遍“翻缓存、复制目录、初始化 Git、上传仓库”这套流程，其实可以直接用我这个远程地址，先把项目跑起来再说。

先说结论

这里有个点得先说清楚：

GitHub 仓库 404，不等于 pub.dev 上的 hosted 包马上就拉不下来了。

只要 pub.dev 上这个版本还在，你项目里原来写的：

get: ^4.6.6

很多时候依然是可以正常 flutter pub get 的。

所以我这次做这件事，不是因为“今天已经彻底装不上了”，而是因为源码仓库、历史 issue、后续修补、团队兜底这些事情，一下子都变得不确定了。

说白了，我不是在抢救一个已经完全消失的包，我是在给未来留后路。

这次我主要确认了几件事：

项目里虽然写的是 get: ^4.6.6，但我本机实际锁定到的是 4.7.3。
本地 pub 缓存里确实还有完整源码，路径在 ~/.pub-cache/hosted/pub.dev/get-4.7.3。
flutter clean 不会把全局的 pub 缓存删掉。
真正决定后面依赖从哪里拉的，不是 flutter clean，而是 pubspec.yaml 里到底写的是 hosted 依赖还是 git 依赖。
真正能证明“依赖来源切换成功”的，不是口头说改了配置，而是 pubspec.lock 里的 source 会从 hosted 变成 git。

这个区别其实挺关键的。

因为很多人看到项目出问题，第一反应就是先 flutter clean，但它干的事情和“依赖从哪里下载”其实不是一回事。

pub 缓存到底是个什么东西

Flutter 项目里只要你执行过 flutter pub get，依赖一般都会被下载到本机的 pub 缓存目录里。

macOS 下常见路径就是：

~/.pub-cache

像这种从 pub.dev 拉下来的包，通常会放在：

~/.pub-cache/hosted/pub.dev/

比如我这次找到的就是：

/Users/lrq/.pub-cache/hosted/pub.dev/get-4.7.3

这个目录里不是一个“壳子”，而是完整包内容，里面能看到：

lib
test
example
documentation
pubspec.yaml
LICENSE
README.md

也就是说，只要你本机缓存还在，很多时候就还有机会把包完整救出来。

我这次为什么还能把 get 捞出来

因为我的项目之前已经跑过，这个包已经被下载到本地了。

哪怕现在原作者仓库不稳定，或者你就是单纯不想继续依赖外部不确定因素，只要本机缓存里还留着这份代码，就还能复制出来自己维护。

我这边最后确认到的版本不是 4.6.6，而是 4.7.3。

这个也很正常。

因为 pubspec.yaml 里写的：

get: ^4.6.6

这表示允许拿 4.x 范围内兼容的更新版本。只要锁文件已经解析到了 4.7.3，项目实际跑起来用的就是 4.7.3。

所以这次我没有死磕 4.6.6，而是直接把本机正在用的 4.7.3 备份走了。

我是怎么备份到 GitHub 的

做法其实不复杂。

第一步，不要直接在 ~/.pub-cache 里改东西。这个目录本质上还是缓存目录，不适合拿来当你自己的长期仓库。

我先把它复制到一个自己维护的位置，比如：

mkdir -p /Users/lrq/work/vendor
cp -R /Users/lrq/.pub-cache/hosted/pub.dev/get-4.7.3 /Users/lrq/work/vendor/get-4.7.3

第二步，在复制出来的新目录里初始化 Git：

cd /Users/lrq/work/vendor/get-4.7.3
git init
git checkout -b main
git add .
git commit -m "chore: import get 4.7.3 from local pub cache"

第三步，推到自己的 GitHub：

git remote add origin https://github.com/xinqingaa/get-4.7.3.git
git push -u origin main

这样做完之后，这个包就不只是“还躺在我电脑缓存里”，而是已经有了一个我自己能控制的远程仓库。

如果大家都懒得操作，直接用我的远程地址也行

这个是最省事的办法。

如果你们现在只是想先把项目跑起来，不想每个人都再自己去翻 pub cache、复制源码、传一份仓库，那可以直接把依赖切到我这个地址：

https://github.com/xinqingaa/get-4.7.3

pubspec.yaml 可以这么写：

dependencies:
  get:
    git:
      url: https://github.com/xinqingaa/get-4.7.3.git
      ref: main

如果你们希望再稳一点，不想后面有人往 main 推了东西影响现有项目，那就别写 main，直接写具体提交号：

dependencies:
  get:
    git:
      url: https://github.com/xinqingaa/get-4.7.3.git
      ref: 具体commit_sha

这个方式更适合线上项目或者多人协作。

因为一旦写死 commit，后面就算仓库继续更新，你当前项目也不会跟着乱动。

这里顺便说清楚：`flutter clean` 到底是干嘛的

很多人会把 flutter clean 理解成“把依赖也一起清掉”，其实不是。

flutter clean 的主要作用，是清理当前项目目录下面的构建产物和临时文件。

它更像是在对当前工程说一句：
“你之前编译留下来的东西先都别要了，等会儿我重新来一遍。”

一般它会影响这些东西：

build/
.dart_tool/
一些 Flutter 构建过程中生成的中间文件
平台侧部分临时产物

但有一点一定要注意：

flutter clean 默认不会删除全局的 ~/.pub-cache。

也就是说，你执行完 flutter clean 之后：

项目本地的构建状态会被清掉
但你之前下载过的依赖缓存，通常还在

所以它不会直接把我刚才说的 get-4.7.3 这个缓存目录删掉。

那现在执行 `flutter clean`，具体会发生什么

如果你当前项目还是正常状态，这时候执行：

flutter clean

你大概率会看到下面这种结果：

当前项目下的 build 目录被清掉。
.dart_tool 下面很多重新生成用的文件被清掉。
下一次你再跑项目，Flutter 会重新做一轮初始化和构建。

但是：

~/.pub-cache/hosted/pub.dev/get-4.7.3

这个目录通常还在。

所以从“救包”这个角度说，flutter clean 不是最危险的操作。

真正危险的是你把本地缓存手动删了，或者换了新机器，而你又没有自己的备份来源。

那现在执行 `flutter pub get`，又会发生什么

这个要分情况看。

情况一：你还没改依赖，项目里还是这样写

get: ^4.6.6

那 flutter pub get 做的事情大概是：

读取 pubspec.yaml
结合 pubspec.lock 解析当前应该使用哪些版本
检查本机缓存里有没有现成依赖
如果缓存里有，就直接复用
如果本机没有，再去对应源拉取
重新生成 .dart_tool/package_config.json 之类的文件

如果你的 pubspec.lock 里已经锁的是 get 4.7.3，而且本地缓存也还在，那这一步通常不会有什么大动静，很多时候就是直接复用本地缓存。

换句话说，flutter clean 之后再 flutter pub get，项目大概率还是能恢复起来。

情况二：你已经把依赖改成 GitHub 仓库

比如你改成了：

dependencies:
  get:
    git:
      url: https://github.com/xinqingaa/get-4.7.3.git
      ref: main

那这时候再执行：

flutter pub get

事情就变成另外一种逻辑了：

pub 会识别到这是一个 git 依赖
它会去拉取这个 GitHub 仓库
然后把对应版本缓存到本机
更新锁文件和项目依赖映射
后面项目再编译时，就会基于这份新的依赖来源来跑

也就是说，从这一刻开始，项目依赖的就不再是“原来那个 hosted 包来源”，而是你指定的这个 Git 仓库。

这也是为什么我说，真正决定依赖来源的是 pubspec.yaml，不是 flutter clean。

所以 `flutter clean` + `flutter pub get` 连着执行时，应该怎么理解

这两个命令经常一起出现，但它们负责的事情完全不是一层。

你可以把它理解成：

flutter clean：把项目现场打扫干净
flutter pub get：按当前依赖配置重新把材料搬进来

如果你没改依赖来源，它就继续按原来的来源取。

如果你把 get 改成了你自己的 GitHub 仓库，它就会按新的地址重新拉。

所以这套动作本身不可怕，关键是你在执行之前，pubspec.yaml 到底写成了什么样。

我个人建议的处理方式

如果你只是想先保命，让项目先稳住，我建议直接做两件事：

先把能找到的完整包备份到自己的 GitHub。
再把项目依赖切到你自己能控制的地址。

这样做最大的好处是：

新同事拉项目时不用到处找缓存
换电脑时不用赌本机有没有旧依赖
CI 重建时也不会因为某个外部仓库状态异常而临时翻车

说白了，就是把“我电脑里刚好还有缓存”这件事，变成“团队里任何人都有稳定地址可用”。

如果你也想直接用我这份地址，可以抄这段

这个是最省心的版本：

dependencies:
  get:
    git:
      url: https://github.com/xinqingaa/get-4.7.3.git
      ref: main

改完之后执行：

flutter clean
flutter pub get

一般会发生这些事：

当前项目构建缓存被清理。
pub 按新的 Git 地址重新获取 get。
锁文件会更新成新的依赖来源。
之后项目再跑，走的就是你指定的仓库了。

如果项目比较重要，建议把 ref: main 换成具体 commit。

GitHub 上的备注怎么补

这块我建议至少补两个地方，一个是仓库描述，一个是 README.md。

1. 仓库描述

GitHub 仓库首页右侧 About 那里，点编辑，简单写一句就够了，比如：

Backup mirror of get 4.7.3 recovered from local pub cache.

这个主要是让别人点进来时一眼知道这仓库是干嘛的。

2. README

这个更重要，因为后面真正给别人复制依赖地址的时候，大家通常会先看 README。

可以直接写清楚三件事：

这个仓库是什么
它是从哪里恢复出来的
在 Flutter 项目里怎么引用

下面这段 README 你可以直接拿去用。

README 示例

# get-4.7.3

这是从本地 `pub cache` 中恢复出来的 `get 4.7.3` 备份仓库，用来做内部依赖兜底。

原始恢复来源：

- `~/.pub-cache/hosted/pub.dev/get-4.7.3`

如果你想在 Flutter 项目里直接使用这个仓库，可以这样写：

```yaml
dependencies:
  get:
    git:
      url: https://github.com/xinqingaa/get-4.7.3.git
      ref: main

如果用于正式项目，建议把 ref 改成具体 commit SHA，避免后续分支内容变化影响构建结果。


---

如果你已经在本地把 README 改好了，上传方式和平时推代码一样：

```bash
git add README.md
git commit -m "docs: add repository usage notes"
git push origin main

这就算把“备注”一起传上去了。

最后

这次事情也算给我提了个醒。

平时大家都觉得依赖装上了就完事了，但只要项目还在维护，关键依赖最好还是留一手。

尤其是那种项目里已经深度使用、短时间又很难替换掉的包，真碰到上游不稳定，最省时间的办法不是现场慌，而是趁本机缓存还在，赶紧先救一份出来。

如果你们团队现在也懒得自己再折腾一遍，那就直接先用我这份：

https://github.com/xinqingaa/get-4.7.3

先把项目稳住，比什么都重要。

往期文章回顾

Flutter 图片编辑器

Flutter 全链路监控 SDK

Flutter 全场景弹框

Flutter日历组件

日期选择器

做中后台业务，为什么我不建议你用 Tailwind CSS？

ErpanOmer — Tue, 14 Apr 2026 02:33:29 GMT

大家好，我又来了😁

最近我接手了一个隔壁组转过来的中后台重构项目。

交接的时候，对方的技术负责人特意跟我强调，说这个项目采用了最新的技术栈，全面拥抱了 Tailwind CSS，开发体验极其丝滑。

我当时心里还挺期待，毕竟这两年 Tailwind 的风刮得太大了，各种国内外大佬都在疯狂带货。结果周末我抽空把代码拉下来，打开 VSCode 准备梳理一下业务主流程。盯了屏幕不到十分钟，我感觉自己的眼睛快瞎了。

光说理论没意思，我直接给你们截取一段真实的、承载了各种表单校验和状态联动的业务侧边栏组件。你们自己品鉴一下所谓的极致开发体验👇：

const OrderCard = ({ order, isAdmin, isExpanded }) => {
  return (
    <div 
      className={`flex flex-col w-full p-5 mb-4 border rounded-lg shadow-sm transition-all duration-300 ${
        isAdmin ? 'bg-red-50 border-red-200' : 'bg-white border-gray-200'
      } ${
        isExpanded ? 'max-h-[800px]' : 'max-h-24 overflow-hidden'
      } hover:shadow-md cursor-pointer`}
    >
      <div className='flex items-center justify-between pb-3 mb-3 border-b border-gray-100'>
        <span className='text-sm font-semibold text-gray-800 truncate w-[60%]'>
          {order.id}
        </span>
        <span 
          className={`px-2 py-1 text-xs rounded-full ${
            order.status === 'PAID' 
              ? 'bg-green-100 text-green-700' 
              : 'bg-orange-100 text-orange-700'
          }`}
        >
          {order.statusText}
        </span>
      </div>
      {/* 内部极其复杂的业务字段渲染... */}
    </div>
  );
}

代码跑得通吗？当然跑得通。UI 还原度高吗？也挺高。但是作为接下来要维护这个项目的组长，我只觉得一阵头皮发麻。

很多前端新人，甚至是做惯了 C 端 独立开发的兄弟，对 Tailwind 简直是顶礼膜拜。因为它不用取名字，不用在 JS 和 CSS 文件之间来回切换，写起来确实有快感。

但作为趟过无数中后台项目的深水区，我今天必须给这股跟风热潮泼一盆冷水： 在绝大多数重型中后台业务场景里，Tailwind CSS 并不是什么神兵利器，而是给后期维护带来不方便。

来，咱们拿真实代码说话，看看它到底是怎么摧毁中后台工程的👇。

彻底掩盖你的业务主线？

做中后台系统，最难的从来不是画 UI，而是处理极度复杂的数据状态流转。

上面那段代码最大的问题在于信噪比极低。作为一个接手代码的前端，我点开这个文件，首先想看的是：这个组件在不同权限、不同展开状态下，业务逻辑是怎么走的？

但在 Tailwind 的体系下，我的视线全被 flex、p-5、mb-4、max-h-[800px] 这种毫无业务价值的视觉原子类给强暴了。如果退回到老古董的 CSS Modules 方案，这段代码在 JS 侧应该长什么样？咱们对比一下：

import classNames from 'classnames';
import styles from './OrderCard.module.less';

const OrderCard = ({ order, isAdmin, isExpanded }) => {
  return (
    <div 
      className={classNames(styles.orderCard, {[styles.adminMode]: isAdmin,
        [styles.expanded]: isExpanded
      })}
    >
      <div className={styles.cardHeader}>
        <span className={styles.orderId}>{order.id}</span>
        <span 
          className={classNames(styles.statusBadge, {
            [styles.statusPaid]: order.status === 'PAID',
            [styles.statusPending]: order.status === 'PENDING'
          })}
        >
          {order.statusText}
        </span>
      </div>
      {/* 业务字段一目了然 */}
    </div>
  );
}

发现区别了吗？重构后的 JSX 变得极其纯粹。我只通过 adminMode、expanded 这种类名，就极其清晰地传达了业务语义。至于那个订单编号到底占百分之几十的宽度，那是 UI 层 该关心的事情，它安静地待在 .less 文件里，绝不会来污染我的业务主逻辑。

跟现成的组件库水土不服

中后台业务是不可能脱离 Ant Design、Element Plus 这类重型组件库的。而组件库的本质，是封装好了一整套内部的 DOM 结构和 ClassName 规范。

这就带来了一个极其致命的冲突：当你用 Tailwind 去覆盖 Ant Design 的内部样式时，你会写出极其恶心的 Hack 代码😖。

比如产品经理要求：在这个特定页面里，把 Ant Design 表格的表头背景色改成浅蓝色，单元格的 padding 改小一点。

正常的 Less 做法是用样式穿透，精确打击：

/* 样式文件覆盖 */
.myCustomTable {
  :deep(.ant-table-thead > tr > th) {
    background-color: #f0f8ff;
    padding: 8px 16px;
  }
}

你知道那个拥抱 Tailwind 的小伙子是怎么写的吗？为了不写 CSS 文件，他强行使用了 Tailwind v3+ 的任意变体语法：

// Tailwind 强行覆盖组件库内部样式
<Table 
  className='[&_.ant-table-thead>tr>th]:bg-blue-50[&_.ant-table-thead>tr>th]:py-2 [&_.ant-table-thead>tr>th]:px-4 [&_.ant-table-tbody>tr>td]:text-gray-600[&_.ant-table-tbody>tr>td]:py-2' 
  dataSource={data} 
  columns={columns} 
/>

这段代码合进主分支的时候，我都替后续维护的兄弟感到悲哀😢。

这玩意儿连换行都没有，密密麻麻挤在一起。未来如果要做主题切换，或者升级 Ant Design 导致内部类名变了，谁敢去动这坨连正则都极难匹配的字符串？

不仅没有提高开发效率，反而为了强行凑 Tailwind 的语法，写出了一堆极难维护的代码。

负边距引发的问题

一行代码被写出来的成本，远远低于它在未来三年里被维护的成本。

Tailwind 本质上就是披着 ClassName 外衣的行内样式。它把所有的样式固化在了 HTML 结构上。

设想真实的维护场景，前任开发为了让一个按钮和旁边的输入框对齐，极其随意地写了一个向左偏移负间距的类名：

<Button className='-ml-2 mt-1'>提交</Button>

半年后你接手这个需求，产品要求在这俩元素中间加一个 Icon。你看着这个 -ml-2 和 mt-1 会陷入极其痛苦的挣扎：他当时为什么要写负边距？是因为外层父元素加了错的 padding 导致的？还是为了抵消 Button 内部自带的 margin？🤷‍♂️

在传统 CSS 中，我们往往会留有注释说明抵消输入框自带的右侧留白。但在 Tailwind 里，没有注释的容身之所。

为了保证不出线上 Bug，你绝对不敢删掉那个 -ml-2。你会选择在它后面再打个补丁，加个 pl-4 试图把它顶回来。第二年，另一个接手的同事遇到了错位，又在后面补了一个 mt-[-5px]🤣🤣🤣。

日积月累，HTML 标签上的类名越来越长，死代码和冲突代码全堆在 DOM 上，最终变成一座没人敢碰的屎山💩。

别瞎搞，先认清你的场景🫡

说了这么多，难道 Tailwind 真的就是垃圾吗？当然绝对不是。

如果你在做偏 C端 的炫酷落地页、做 SaaS 官网，或者你是独立开发者，没有沉重的历史包袱，不需要配合复杂的重型组件库，那 Tailwind 绝对是神作。它自带极其优秀的设计规范，能让你极速堆出好看的界面。

但咱们讨论的是中后台。中后台是干嘛的？团队十几个人来回交接，动辄几百个页面，充斥着极其复杂的表单联动和权限校验，生命周期长达五年甚至十年。

在这种重型项目中，保持业务逻辑的纯粹性，分离关注点，远比你少写几行 CSS 要重要一万倍。

好了，今天分享到这，谢谢大家😁

全面升级！看看人家的后台管理系统，确实清新优雅！

MacroZheng — Tue, 14 Apr 2026 01:23:00 GMT

关注过我的mall项目的小伙伴应该有所了解，mall项目的后台管理系统一直都是Vue2版本的，主要原因是项目从Vue2升级到Vue3基本等于要重写了。最近我花了一个月的时间，将mall项目的后台管理系统升级到了Vue3版本，今天和大家聊聊做了哪些升级！

项目介绍

mall-admin-web是mall电商项目后台管理系统的前端项目，基于Vue3+Element-Plus实现。主要包括商品管理、订单管理、会员管理、促销管理、运营管理、内容管理、统计报表、财务管理、权限管理、设置等功能。

下面是mall-admin-web项目运行的效果图，界面还是很清新优雅的！如果你想体验完整功能的话，可以访问这个在线演示地址：www.macrozheng.com/admin/

技术栈

mall-admin-web技术栈已经全面升级，基于目前主流的前端技术栈，版本也是比较新的，具体技术栈如下。

技术	说明	版本
Vue	前端框架	3.5.25
Element Plus	前端UI框架	2.12.0
Vue Router	路由框架	4.6.3
Pinia	全局状态管理框架	3.0.4
Pinia Plugin Persistedstate	Pinia持久化插件	4.7.1
Axios	前端HTTP框架	1.13.2
Vue-charts	基于Echarts的图表框架	8.0.1
TinyMCE Vue	富文本编辑器	5.1.1
Js-cookie	cookie管理工具	3.0.5

升级内容

这里和大家聊聊mall-admin-web做了哪些升级！

Vue2升级Vue3

项目的Vue版本从之前的2.7.2升级到了3.5.25，改动还是挺大的，之前使用的选项式API都已经改成了Vue3的组合式API。

我在升级项目的同时，给代码添加了更加详尽的注释，方便大家来学习。

之前经常有小伙伴问接口文档在哪里，其实把后端项目运行起来，就有接口文档了，我这里给前端调用的接口方法添加了详细的注释，大家也可以直接从代码中查看接口调用。

JavaScript升级TypeScript

TypeScript我们可以把它看作是带有类型的JavaScript，JavaScript里的支持的语法，它基本都支持。

项目中对于使用到的对象添加了类型支持，用起来有点Java中对象的感觉。

这样我们在编写代码时就可以有属性提示了，使用TypeScript我们在编译时就可以发现错误，以便及时修正。

这里有两者使用的优势对比，大家可以参考下！

Element UI升级Element Plus

由于Element UI已经停止更新，这里升级到了支持Vue3的Element Plus组件库，两者使用过程中的特性与优缺点对比如下。

Vuex升级Pinia

Pinia是Vue官方开发的状态管理库，使用它API更简洁，而且完美支持Vue3和TypeScript。

项目中的用户信息存储就使用了它，配合pinia-plugin-persistedstate插件，还可以实现数据的持久化。

两者使用过程中的特性与优缺点对比如下。

v-charts升级vue-charts

之前项目中使用的图表库v-charts已经停止维护，这里升级到了vue-charts，使用该库生成的图表功能也更加强大了！

两者使用过程中的特性与优缺点对比如下。

总结

今天给大家分享了mall后台管理系统前端的升级内容，主要是项目升级到了Vue3，一些过时的库也迁移到了新的库，升级之后项目更加适合学习了，感兴趣的小伙伴可以学习下！

项目地址

Github：github.com/macrozheng/…
Gitee：gitee.com/macrozheng/…

写给 Claude Code 初学者的使用技巧

双越AI_club — Tue, 14 Apr 2026 00:59:53 GMT

大家好，我是双越。wangEditor 作者，前百度滴滴资深前端工程师，慕课网金牌讲师，PMP，前端面试派作者。

我正致力于两个项目的开发和升级，感兴趣的可以私信我，加入项目小组。

划水AI Node 全栈 AIGC 知识库，包括 AI 写作、多人协同编辑。复杂业务，真实上线。
智语 AI Agent 智能体项目。一个智能面试官，可以优化简历、模拟面试、解答题目等。

本文总结了一些 Claude Code 使用技巧，针对初学者的，“老司机”可划走～

CLAUDE.md

用 claude 打开一个新项目，执行 /init 命令，它会自动话分析项目并创建一个 CLAUDE.md 文件。

CLAUDE.md 是项目记忆文件，每次会话都会携带，它包含了项目中最重要的一些信息，例如格式、规范、命令、开发者癖好等。

CLAUDE.md 可放在项目根目录，也可以放在 .claude 目录，或一些二级目录。二级目录的，要等 Claude 加载当前文件时，才会加载。

CLAUDE.md 尽量保持在 200 行以内，如果内容太多可能会影响 AI 输出的效果，更容易出现幻觉。如果有按需加载的内容，请使用 skill ，下文会介绍。

简单示例：

# Todo List Project

## 常用命令
- 启动: `npm run dev`
- 测试: `npm test`
- 构建: `npm run build`

## 代码规范
- 使用 ES Modules，不用 CommonJS
- 使用函数式组件 + Hooks
- 状态管理用 Zustand（见 src/stores）

## 文件结构
- src/components/ 放 UI 组件
- src/api/ 放接口调用

还有一个 AGENTS.md 但它不是 Claude Code 原生的文件，而是来自整个 AI 编程工具生态的一个开放标准。它的定位是：一个文件，兼容所有 AI 编程工具。

目前每个主流 AI 编程工具都有自己的配置文件：Claude Code 读取 CLAUDE.md，Codex CLI 读取 AGENTS.md，Gemini CLI 读取 GEMINI.md，Cursor 用 .cursorrules，GitHub Copilot 用 copilot-instructions.md

Plan Mode

使用 Claude Code 一般是：先探索，再规划，最后编码。

使用 shift+tab 可切换到 Plan mode

此时输入一些指令让它去学习和探索，例如

read /src/auth and understand how we handle sessions and login.
also look at how we manage environment variables for secrets.

然后，让它根据探索的内容做详细规划，例如

I want to add Google OAuth. What files need to change?
What's the session flow? Create a plan.

最后，切换回 Normal Mode 并让 Claude 编码，根据其计划进行验证。

implement the OAuth flow from your plan. write tests for the
callback handler, run the test suite and fix any failures.

常见命令

总结了一下 Claude Code 常见的命令。

会话管理（最常用）

命令	作用
`/clear`	清空对话历史，开始新任务时必用
`/compact`	压缩上下文，保留重要信息，释放 token
`/context`	查看当前 context 使用情况
`/help`	查看帮助
/init	初始化项目，增加 CLAUDE.md

功能类

命令	作用
`/memory`	打开并编辑 CLAUDE.md 文件
`/model`	切换模型（Opus / Sonnet 等）
`/mcp`	管理 MCP 服务器连接
`/cost`	查看本次会话的 token 消耗

代码相关

命令	作用
`/code-review`	对当前代码进行审查
`/rewind`	打开检查点菜单，可回滚代码和对话

在对话框中还有几个特殊前缀：/ 触发 slash 命令，! 直接执行 bash 命令，@ 引用文件（带自动补全）。

!npm test          # 直接执行 shell 命令
!git status
@src/index.ts      # 把文件内容加入上下文

Skill

Skill 现在已经是 agent 非常成熟且常用的模块了，在 claude code 同样如此。
可以自己创建，也可以安装第三方的，例如 vercel.com/blog/introd…

执行命令

npx skills add vercel-labs/agent-skills

会创建在 .claude/skills 目录下

如下图，下面三个是我安装的 skill ，上面几个是 claude code 内置的 skill

这样 Cluade Code 在写 React 或前端代码时，就会参考这些 skill 写的更好。

这些第三方的都是全世界开发者通用的技能，在你的实际工作中，你应该还需要积累一些自己或公司内部使用的 skill ，一般要一边应用一边积累，慢慢改善。

MCP

MCP server 是 agent 联通外部世界的方式。几个推荐安装的 MCP server

1. Context7 — 解决文档过时问题 Context7 把版本精确的库文档直接注入 Claude Code 会话。Claude 不再靠训练数据猜 API，而是拿到你项目实际使用的 React、Next.js、Prisma 那个版本的真实文档。有效解决 Claude 写出已废弃方法的问题。

claude mcp add -s project context7 npx @upstash/context7-mcp

这里的 project 是安装在项目里，也可以改为 user
安装以后会在项目根目录 .mcp.json 文件中看到

2. Playwright — 浏览器自动化测试 Playwright MCP 让 Claude Code 可以打开浏览器、点击页面、截图验证 UI，这个反馈闭环能捕获单元测试发现不了的问题。

claude mcp add -s project playwright npx @playwright/mcp@latest

3. GitHub — 无缝 PR 和 issue 管理 GitHub MCP 消除了编辑器和 GitHub 网页之间最多的上下文切换，创建分支、开 PR、搜索代码、管理 issue 和 Actions workflow 全在对话里完成。

claude mcp add -s project github npx @modelcontextprotocol/server-github
# 需要设置 GITHUB_PERSONAL_ACCESS_TOKEN

安装以后，启动 claude 时候需要选择

可以让 claude code 帮我打开网页访问 localhost:3000 来测试网页，它会自动分析网页元素，进行测试。

现在 claude code 有 tool search 功能，默认只家在 tool name ，其他内容都是按需加载，不会占用太多 token

Hooks

Hooks 是用户定义的 shell 命令，在 Claude Code 生命周期中的特定点执行。它们对 Claude Code 的行为提供确定性控制，确保某些操作始终发生，而不是依赖 LLM 选择运行它们。使用 hooks 来强制执行项目规则、自动化重复任务，并将 Claude Code 与现有工具集成。

例如，阻止受保护的文件被编辑，如 .env、package-lock.json 或 .git/ 中的任何内容。

编辑 .claude/settings.json 文件，增加

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": ""$CLAUDE_PROJECT_DIR"/.claude/hooks/protect-files.sh"
          }
        ]
      }
    ]
  }
}

其中 PreToolUse 就是在工具使用增加 Hook ，这里的 sh 文件内容如下

#!/bin/bash
# protect-files.sh

INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')

PROTECTED_PATTERNS=(".env" "package-lock.json" ".git/")

for pattern in "${PROTECTED_PATTERNS[@]}"; do
  if [[ "$FILE_PATH" == *"$pattern"* ]]; then
    echo "Blocked: $FILE_PATH matches protected pattern '$pattern'" >&2
    exit 2
  fi
done

exit 0

Hook 事件类型有很多，例如 SessionStart SessionEnd PreToolUse PostToolUse 具体看文档 code.claude.com/docs/zh-CN/…

总之，Hook 允许用户在 claude code 多种行为的开始和结束增加监测机制，保障安全稳定。

SubAgents

sub agent 单独的环境，单独的上下文，运行单独的任务，不影响主 agent 。
例如代码审查、单元测试、排查 bug 等。

使用 /agents 命令查看当前 sub agents （cc 内置了几个 agent），或者创建一个新的

创建以后会在 .claude/agents/ 目录下创建一个 md 文件，描述这个 agent ，你可以修改

运行一个 sub agent 让它帮我写单元测试

Context Window

一次聊天太长，上下文内容过多，就会消耗过多 token，且让 AI 产生幻觉。这是所有 Agent 都无法避免的事情。
所以，开发新的功能时，要及时清理聊天记录，使用 /clear 命令。
恢复上次会话 claude --continue ，选择会话 claude --resume

下图是 claude code 各个功能对于上下文的影响，可以看到

CLAUDE.md 是每次请求都携带
MCP servers 是只携带工具名称，其他按需 —— 但如果 base_url 不是官方 claude ，这里就不确定了！！！
Skills 只写代码 name desc ，内容按需加载

最后

之前和同学沟通，有人提到一句话非常好：如果 AI 写错了，不是纠正他，而是考虑自己的环境、规则和计划是否合理，这也是 harness 编程和 vibe coding 的区别。

Claude Code 的功能和使用就很契合这一点，Plan Mode + Skill + Hook 就是环境、规则和计划。

掘金本周最热

前端重生之 - 前端视角下的 Python

从 JS 的异步到 Python 的同步

1.1 事件循环的底层机制

1.2 Python asyncio 的设计哲学

1.3 GIL：Python 的"阿喀琉斯之踵"

1.4 编程范式的思维转换

类型系统——从动态到静态的考虑

2.1 TypeScript 的革命

2.2 Python 类型注解的演进

2.2.1 编译时 vs 运行时

2.2.2 结构类型 vs 名义类型

2.2.3 类型推断

2.3 渐进式类型的价值

生态系统

3.1 npm 与 PyPI：包管理的两种哲学

3.2 虚拟环境：Python 的隔离艺术

3.3 标准库的力量

3.4 生态系统的成熟度对比

数据科学的疆域的追赶

4.1 Python 的数据霸权

4.1.1 NumPy：向量化计算的威力

4.1.2 Pandas：数据处理的艺术

4.1.3 数据可视化

4.2 前端的数据觉醒

4.2.1 TensorFlow.js

4.2.2 Apache Arrow JS

4.3 前端的数据科学学习路径

Web 开发的殊途同归

5.1 Django vs Express：两种架构哲学

5.2 FastAPI：Python 的现代答案

5.3 性能对比：Node.js vs Python

融会贯通

6.1 语言只是工具，思维才是核心

6.1.1 SOLID 原则

6.1.2 设计模式

6.1.3 编程思维的培养

6.2 未来的融合趋势

6.2.1 WebAssembly 的崛起

6.2.2 PyScript 的革命

6.2.3 跨语言借鉴

6.2.4 全栈工程师的新定义

结语

为什么我不建议普通前端盲目卷全栈？

你以为的全栈，只是在写玩具后端

2026 年独立开发者真实生存状况

普通前端该怎么破局？学会借力，而不是造轮子

别被技术焦虑绑架

如何写一个自己的skill

1. 前言

2. 背景

3. 初始 Skill

3.1 Skill 的位置存放

3.2 一个最小的 Skill

4. 如何高效写出一个 Skill

5. 总结

Android CLI ，谷歌为 Android 开发者专研的 AI Agent，提速三倍

参考链接

同事偷偷给我介绍私活，说1万报酬全给我，结果甲方私下告诉我说，同事在当中白拿了2万，我觉得被耍了，媳妇却让我要知足，说我一点不亏

JetBrains Amper 0.10 ，期待它未来替代 Gradle

面试官问我：“AI 写代码比你快 100 倍，你的价值在哪？”

认清现实：编码的边际价值正在归零

打造护城河：未来 5 年的 5 大杀手锏

1. 从“调包侠”进化为“架构师”

2. 把 AI 当“黑奴”，而不是“拐杖”

3. 练就火眼金睛的 Code Review 能力

4. 懂点业务，长点“产品脑”

5. 用 AI 搞定实际问题，别光谈理论

破局之路：不同阶段的突围策略

结语：思维的跃迁才是真正的出路

踩坑分享：Vite Plus 最佳实践

写在前面

先聊聊 Vite Plus

公司项目迁移

相关链接

特性一览

Vite+ 配置预设

CLI 工具链

140+ 工具函数

类型安全的枚举工具