普通视图

发现新文章,点击刷新页面。
今天 — 2026年4月7日首页

每日一题-模拟行走机器人 II🟡

2026年4月7日 00:00

给你一个在 XY 平面上的 width x height 的网格图,左下角 的格子为 (0, 0) ,右上角 的格子为 (width - 1, height - 1) 。网格图中相邻格子为四个基本方向之一("North""East""South" 和 "West")。一个机器人 初始 在格子 (0, 0) ,方向为 "East" 。

机器人可以根据指令移动指定的 步数 。每一步,它可以执行以下操作。

  1. 沿着当前方向尝试 往前一步 。
  2. 如果机器人下一步将到达的格子 超出了边界 ,机器人会 逆时针 转 90 度,然后再尝试往前一步。

如果机器人完成了指令要求的移动步数,它将停止移动并等待下一个指令。

请你实现 Robot 类:

  • Robot(int width, int height) 初始化一个 width x height 的网格图,机器人初始在 (0, 0) ,方向朝 "East" 。
  • void step(int num) 给机器人下达前进 num 步的指令。
  • int[] getPos() 返回机器人当前所处的格子位置,用一个长度为 2 的数组 [x, y] 表示。
  • String getDir() 返回当前机器人的朝向,为 "North" ,"East" ,"South" 或者 "West" 。

 

示例 1:

example-1

输入:
["Robot", "step", "step", "getPos", "getDir", "step", "step", "step", "getPos", "getDir"]
[[6, 3], [2], [2], [], [], [2], [1], [4], [], []]
输出:
[null, null, null, [4, 0], "East", null, null, null, [1, 2], "West"]

解释:
Robot robot = new Robot(6, 3); // 初始化网格图,机器人在 (0, 0) ,朝东。
robot.step(2);  // 机器人朝东移动 2 步,到达 (2, 0) ,并朝东。
robot.step(2);  // 机器人朝东移动 2 步,到达 (4, 0) ,并朝东。
robot.getPos(); // 返回 [4, 0]
robot.getDir(); // 返回 "East"
robot.step(2);  // 朝东移动 1 步到达 (5, 0) ,并朝东。
                // 下一步继续往东移动将出界,所以逆时针转变方向朝北。
                // 然后,往北移动 1 步到达 (5, 1) ,并朝北。
robot.step(1);  // 朝北移动 1 步到达 (5, 2) ,并朝  (不是朝西)。
robot.step(4);  // 下一步继续往北移动将出界,所以逆时针转变方向朝西。
                // 然后,移动 4 步到 (1, 2) ,并朝西。
robot.getPos(); // 返回 [1, 2]
robot.getDir(); // 返回 "West"

 

提示:

  • 2 <= width, height <= 100
  • 1 <= num <= 105
  • stepgetPos 和 getDir 总共 调用次数不超过 104 次。

【宫水三叶】简单模拟题

作者 AC_OIer
2022年4月14日 11:10

模拟

根据题目给定的移动规则可知,机器人总是在外圈移动(共上下左右四条),而移动方向分为四类:

image.png

当行走步数为 $mod = 2 * (w - 1) + 2 * (h - 1)$ 的整数倍时,会回到起始位置,因此我们可以通过维护一个变量 loc 来记录行走的总步数,并且每次将 locmod 进行取模来得到有效步数。

在回答 getPosgetDir 询问时,根据当前 loc 进行分情况讨论(见注释)。

另外还有一个小细节:根据题意,如果当前处于 $(0, 0)$ 位置,并且没有移动过,方向为 East,若移动过,方向则为 South,这可以通过一个变量 moved 来进行特判处理。

代码:

###Java

class Robot {
    String[] ss = new String[]{"East", "North", "West", "South"};
    int w, h, loc; // loc: 有效(取模后)移动步数
    boolean moved; // 记录是否经过移动,用于特判 (0,0) 的方向
    public Robot(int width, int height) {
        w = width; h = height;
    }
    public void step(int num) {
        moved = true;
        loc += num;
        loc %= 2 * (w - 1) + 2 * (h - 1);
    }
    public int[] getPos() {
        int[] info = move();
        return new int[]{info[0], info[1]};
    }
    public String getDir() {
        int[] info = move();
        int x = info[0], y = info[1], dir = info[2];
        // 特殊处理当前在 (0,0) 的情况,当未移动过方向为 East,移动过方向为 South
        if (x == 0 && y == 0) return moved ? ss[3] : ss[0];
        return ss[dir];
    }
    int[] move() {
        if (loc <= w - 1) {
            // 当移动步数范围在 [0,w-1] 时,所在位置为外圈的下方,方向为 East
            return new int[]{loc, 0, 0};
        } else if (loc <= (w - 1) + (h - 1)) {
            // 当移动步数范围在 [w,(w-1)+(h-1)] 时,所在位置为外圈的右方,方向为 North
            return new int[]{w - 1, loc - (w - 1), 1};
        } else if (loc <= 2 * (w - 1) + (h - 1)) {
            // 当移动步数范围在 [(w-1)+(h-1)+1,2*(w-1)+(h-1)] 时,所在位置为外圈的上方,方向为 West
            return new int[]{(w - 1) - (loc - ((w - 1) + (h - 1))), h - 1, 2};
        } else {
            // 当移动步数范围在 [2*(w-1)+(h-1)+1,2*(w-1)+2*(h-1)] 时,所在位置为外圈的左方,方向为 South
            return new int[]{0, (h - 1) - (loc - (2 * (w - 1) + (h - 1))), 3};
        }
    }
}
  • 时间复杂度:$O(1)$
  • 空间复杂度:$O(1)$

最后

如果有帮助到你,请给题解点个赞和收藏,让更多的人看到 ~ ("▔□▔)/

也欢迎你 关注我 和 加入我们的「组队打卡」小群 ,提供写「证明」&「思路」的高质量题解。

所有题解已经加入 刷题指南,欢迎 star 哦 ~

分类讨论,O(1) 时间复杂度(Python/Java/C++/C/Go/JS/Rust)

作者 endlesscheng
2021年11月14日 08:20

本文把 $\textit{width}$ 简称为 $w$,把 $\textit{height}$ 简称为 $h$。

根据题意,机器人只能在网格图的最外圈中移动,移动一整圈需要 $2(w+h-2)$ 步。

lc2069.png

设当前移动的总步数模 $2(w+h-2)$ 的结果为 $s$。分类讨论:

  • 如果 $s < w$,机器人往右走了 $s$ 步,位于 $(s,0)$,面朝东。
  • 如果 $w\le s < w+h-1$,机器人先往右走 $w-1$ 步,再往北走 $s-(w-1)$ 步,位于 $(w-1,s-w+1)$,面朝北。
  • 如果 $w+h-1\le s < 2w+h-2$,机器人先往右走 $w-1$ 步,再往北走 $h-1$ 步,到达右上角 $(w-1,h-1)$,再往西走 $s-(w-1)-(h-1)$ 步,位于 $(w-1-(s-(w-1)-(h-1)),h-1) = (2w + h - s - 3,h-1)$,面朝西。
  • 否则,机器人先往右走 $w-1$ 步,再往北走 $h-1$ 步,再往西走 $w-1$ 步,到达左上角 $(0,h-1)$,再往南走 $s-2(w-1)-(h-1)$ 步,位于 $(0,h-1-(s-2(w-1)-(h-1))) = (0, 2(w+h)-s-4)$,面朝南。

注意:总步数为 $0$ 时,机器人面朝东,但总步数为 $2(w+h-2)$ 的正整数倍时,机器人面朝南。需要特判总步数为 $0$ 的特殊情况吗?不需要,当总步数大于 $0$ 时,我们可以把取模后的范围从 $[0, 2(w+h-2)-1]$ 调整到 $[1, 2(w+h-2)]$,从而使原先模为 $0$ 的总步数变成 $2(w+h-2)$,落入面朝南的分支中,这样就可以避免特判了。

class Robot:
    def __init__(self, width: int, height: int) -> None:
        self.w = width
        self.h = height
        self.s = 0

    def step(self, num: int) -> None:
        # 由于机器人只能走外圈,那么走 (w+h-2)*2 步后会回到起点
        # 把 s 取模调整到 [1, (w+h-2)*2],这样不需要特判 s == 0 时的方向
        self.s = (self.s + num - 1) % ((self.w + self.h - 2) * 2) + 1

    def _getState(self) -> Tuple[int, int, str]:
        w, h, s = self.w, self.h, self.s
        if s < w:
            return s, 0, "East"
        if s < w + h - 1:
            return w - 1, s - w + 1, "North"
        if s < w * 2 + h - 2:
            return w * 2 + h - s - 3, h - 1, "West"
        return 0, (w + h) * 2 - s - 4, "South"

    def getPos(self) -> List[int]:
        x, y, _ = self._getState()
        return [x, y]

    def getDir(self) -> str:
        return self._getState()[2]
class Robot {
    private int w, h, s;

    public Robot(int width, int height) {
        w = width;
        h = height;
        s = 0;
    }

    public void step(int num) {
        // 由于机器人只能走外圈,那么走 (w+h-2)*2 步后会回到起点
        // 把 s 取模调整到 [1, (w+h-2)*2],这样不需要特判 s == 0 时的方向
        s = (s + num - 1) % ((w + h - 2) * 2) + 1;
    }

    public int[] getPos() {
        Object[] t = getState();
        return new int[]{(int) t[0], (int) t[1]};
    }

    public String getDir() {
        Object[] t = getState();
        return (String) t[2];
    }

    private Object[] getState() {
        if (s < w) {
            return new Object[]{s, 0, "East"};
        } else if (s < w + h - 1) {
            return new Object[]{w - 1, s - w + 1, "North"};
        } else if (s < w * 2 + h - 2) {
            return new Object[]{w * 2 + h - s - 3, h - 1, "West"};
        } else {
            return new Object[]{0, (w + h) * 2 - s - 4, "South"};
        }
    }
}
class Robot {
    int w;
    int h;
    int s = 0;

    tuple<int, int, string> getState() {
        if (s < w) {
            return {s, 0, "East"};
        } else if (s < w + h - 1) {
            return {w - 1, s - w + 1, "North"};
        } else if (s < w * 2 + h - 2) {
            return {w * 2 + h - s - 3, h - 1, "West"};
        } else {
            return {0, (w + h) * 2 - s - 4, "South"};
        }
    }

public:
    Robot(int width, int height) : w(width), h(height) {}

    void step(int num) {
        // 由于机器人只能走外圈,那么走 (w+h-2)*2 步后会回到起点
        // 把 s 取模调整到 [1, (w+h-2)*2],这样不需要特判 s == 0 时的方向
        s = (s + num - 1) % ((w + h - 2) * 2) + 1;
    }

    vector<int> getPos() {
        auto [x, y, _] = getState();
        return {x, y};
    }

    string getDir() {
        return get<2>(getState());
    }
};
typedef struct {
    int w;
    int h;
    int s;
} Robot;

Robot* robotCreate(int width, int height) {
    Robot* r = malloc(sizeof(Robot));
    r->w = width;
    r->h = height;
    r->s = 0;
    return r;
}

void robotStep(Robot* r, int num) {
    // 由于机器人只能走外圈,那么走 (w+h-2)*2 步后会回到起点
    // 把 s 取模调整到 [1, (w+h-2)*2],这样不需要特判 s == 0 时的方向
    r->s = (r->s + num - 1) % ((r->w + r->h - 2) * 2) + 1;
}

int* robotGetPos(Robot* r, int* returnSize) {
    int w = r->w, h = r->h, s = r->s;
    int x, y;
    if (s < w) {
        x = s;
        y = 0;
    } else if (s < w + h - 1) {
        x = w - 1;
        y = s - w + 1;
    } else if (s < w * 2 + h - 2) {
        x = w * 2 + h - s - 3;
        y = h - 1;
    } else {
        x = 0;
        y = (w + h) * 2 - s - 4;
    }

    int* ans = malloc(2 * sizeof(int));
    *returnSize = 2;
    ans[0] = x;
    ans[1] = y;
    return ans;
}

char* robotGetDir(Robot* r) {
    int w = r->w, h = r->h, s = r->s;
    if (s < w) {
        return "East";
    } else if (s < w + h - 1) {
        return "North";
    } else if (s < w * 2 + h - 2) {
        return "West";
    } else {
        return "South";
    }
}

void robotFree(Robot* r) {
    free(r);
}
type Robot struct {
w, h, step int
}

func Constructor(width, height int) Robot {
return Robot{width, height, 0}
}

func (r *Robot) Step(num int) {
// 由于机器人只能走外圈,那么走 (w+h-2)*2 步后会回到起点
// 把 step 取模调整到 [1, (w+h-2)*2],这样不需要特判 step == 0 时的方向
r.step = (r.step+num-1)%((r.w+r.h-2)*2) + 1
}

func (r *Robot) getState() (x, y int, dir string) {
w, h, step := r.w, r.h, r.step
switch {
case step < w:
return step, 0, "East"
case step < w+h-1:
return w - 1, step - w + 1, "North"
case step < w*2+h-2:
return w*2 + h - step - 3, h - 1, "West"
default:
return 0, (w+h)*2 - step - 4, "South"
}
}

func (r *Robot) GetPos() []int {
x, y, _ := r.getState()
return []int{x, y}
}

func (r *Robot) GetDir() string {
_, _, d := r.getState()
return d
}
var Robot = function(width, height) {
    this.w = width;
    this.h = height;
    this.s = 0;
};

Robot.prototype.step = function(num) {
    // 由于机器人只能走外圈,那么走 (w+h-2)*2 步后会回到起点
    // 把 s 取模调整到 [1, (w+h-2)*2],这样不需要特判 s === 0 时的方向
    this.s = (this.s + num - 1) % ((this.w + this.h - 2) * 2) + 1;
};

Robot.prototype.getState = function() {
    const w = this.w, h = this.h, s = this.s;
    if (s < w) {
        return [s, 0, "East"];
    } else if (s < w + h - 1) {
        return [w - 1, s - w + 1, "North"];
    } else if (s < w * 2 + h - 2) {
        return [w * 2 + h - s - 3, h - 1, "West"];
    } else {
        return [0, (w + h) * 2 - s - 4, "South"];
    }
};

Robot.prototype.getPos = function() {
    const [x, y, _] = this.getState();
    return [x, y];
};

Robot.prototype.getDir = function() {
    return this.getState()[2];
};
struct Robot {
    w: i32,
    h: i32,
    s: i32,
}

impl Robot {
    fn new(width: i32, height: i32) -> Self {
        Self { w: width, h: height, s: 0 }
    }

    fn step(&mut self, num: i32) {
        // 由于机器人只能走外圈,那么走 (w+h-2)*2 步后会回到起点
        // 把 s 取模调整到 [1, (w+h-2)*2],这样不需要特判 s == 0 时的方向
        self.s = (self.s + num - 1) % ((self.w + self.h - 2) * 2) + 1;
    }

    fn get_state(&self) -> (i32, i32, String) {
        let w = self.w;
        let h = self.h;
        let s = self.s;
        if s < w {
            (s, 0, "East".to_string())
        } else if s < w + h - 1 {
            (w - 1, s - w + 1, "North".to_string())
        } else if s < w * 2 + h - 2 {
            (w * 2 + h - s - 3, h - 1, "West".to_string())
        } else {
            (0, (w + h) * 2 - s - 4, "South".to_string())
        }
    }

    fn get_pos(&self) -> Vec<i32> {
        let (x, y, _) = self.get_state();
        vec![x, y]
    }

    fn get_dir(&self) -> String {
        let (_, _, d) = self.get_state();
        d
    }
}

复杂度分析

  • 时间复杂度:均为 $\mathcal{O}(1)$。
  • 空间复杂度:$\mathcal{O}(1)$。

分类题单

如何科学刷题?

  1. 滑动窗口与双指针(定长/不定长/单序列/双序列/三指针/分组循环)
  2. 二分算法(二分答案/最小化最大值/最大化最小值/第K小)
  3. 单调栈(基础/矩形面积/贡献法/最小字典序)
  4. 网格图(DFS/BFS/综合应用)
  5. 位运算(基础/性质/拆位/试填/恒等式/思维)
  6. 图论算法(DFS/BFS/拓扑排序/基环树/最短路/最小生成树/网络流)
  7. 动态规划(入门/背包/划分/状态机/区间/状压/数位/数据结构优化/树形/博弈/概率期望)
  8. 常用数据结构(前缀和/差分/栈/队列/堆/字典树/并查集/树状数组/线段树)
  9. 数学算法(数论/组合/概率期望/博弈/计算几何/随机算法)
  10. 贪心与思维(基本贪心策略/反悔/区间/字典序/数学/思维/脑筋急转弯/构造)
  11. 链表、树与回溯(前后指针/快慢指针/DFS/BFS/直径/LCA)
  12. 字符串(KMP/Z函数/Manacher/字符串哈希/AC自动机/后缀数组/子序列自动机)

我的题解精选(已分类)

欢迎关注 B站@灵茶山艾府

5911. 模拟行走机器人 II【模拟详解】

作者 yaojun2026
2021年11月14日 00:27

分析

  • 题目:
  • 思路:
    • 直接按照题意模拟一遍。
    • 我们发现机器人只会绕着网格图的外圈走,因此可以先将多余的圈数去掉,直接取余。
    • 140/142测试点过不去,有两类错误
      • 第一种,没有考虑到余数为0的时候,方向可能没有转过来,还是之前的方向。比如饶了一圈回到(0,0),最开始是向右,但是此时正确答案应该向下。
      • 第二种,考虑了余数为0,但是直接对方向回退。在有的数据上,并不能直接回退方向,这个方向是固定的,可以写死。

QQ截图20211114002552.png

代码

class Robot {
public:
    int w, h;
    int x, y, d;
    string dir[4] = {"East", "North", "West", "South"};
    int dx[4]={1, 0, -1, 0};
    int dy[4]={0, 1, 0, -1};
    Robot(int width, int height) {
        w = width;
        h = height;
        x = 0, y = 0, d = 0;
    }
    
    void move(int num) {
        // 外一圈的步数,这里不等于周长,而是长宽减一后的周长,最好手动模拟走一下。
        // 也可以这样写 int cc = 2*(w-1 + h-1);
        int cc = 2*w + 2*h - 4;
        num %= cc;
        // 140/142没考虑到的测试点 num == 0
        if(!num && !x && !y) d = 3;
        while(num--) {
            int nx = dx[d] + x, ny = dy[d] + y;
            if(nx < 0 || nx >= w || ny < 0 || ny >= h) {
                // 如果越界了,就逆时针转90度,换到下一个方向继续走
                d++, d %= 4;
                nx = dx[d] + x, ny = dy[d] + y;
            }
            x = nx, y = ny;
        }
    }
    
    vector<int> getPos() {
        return  {x, y};
    }
    
    string getDir() {
        return dir[d];
    }
};

/**
 * Your Robot object will be instantiated and called as such:
 * Robot* obj = new Robot(width, height);
 * obj->move(num);
 * vector<int> param_2 = obj->getPos();
 * string param_3 = obj->getDir();
 */

用 AI 搞定用户系统:Superpowers 工程化开发教程

2026年4月6日 21:57

🧠 如果你最近在关注 AI Coding,大概率已经刷到过 Superpowers 和 ui-ux-pro-max。 前者试图把“想到哪写到哪”的 AI 编程,拉回到更像工程交付的节奏里;后者则想解决另一个老问题:AI 能把页面写出来,但不一定写得像一个成熟产品。

这篇文章不准备再用“工具很强、流程很酷、装上就起飞”那种方式来介绍它们。

我更想做的,是把几个真正重要的问题讲清楚:这两个 Skill 分别解决什么问题、官方文档里到底怎么安装和工作的,以及如果把它们放进一个真实项目里,具体应该怎样用。

为了把过程讲具体,后文用一个 RBAC 用户权限系统 作为案例来串起整条链路。本文讨论的是单租户后台管理系统里的 RBAC,不展开 ABAC、行级权限、组织继承、多租户隔离这类更复杂的话题。

这是最终完成初版的多租户 RBAC 系统项目,仓库地址为 github.com/Cookieboty/…。感兴趣的同学可以 Star 支持一下。需要注意的是,这个项目虽然是按下文流程 VB 出来的,但过程中也做了不少 bug 处理;另外,受 AI 幻觉影响,部分分支出现过偏差,因此做了一些调整,但整体流程基本可控。


一、Superpowers 与 ui-ux-pro-max 的定位

1.1 Superpowers:面向工程流程的 AI 开发工作流

很多 AI 编程体验之所以让人又爱又烦,本质上不是模型不会写代码,而是它太容易过早进入实现阶段。你刚抛出一个需求,它就开始生成文件;你话还没说完,它已经默认做了三层扩展。

Superpowers 的核心思路,正是把这种“先写再说”的节奏,改造成一套更接近工程实践的工作流。它并不是单一 Skill,而是一套围绕软件开发流程组织起来的技能系统:从 brainstorm、plan,到执行、TDD、review、收尾,尽量让代理在每个阶段做该做的事。

1.2 ui-ux-pro-max:面向前端产出的设计增强能力

很多人第一次用 AI 生成前端页面时,都会有一种熟悉的感觉:布局也有,按钮也有,表格也有,生了一堆组件;但页面往往停留在“摆上去”的层面,缺少真正的设计判断——比如配色节奏、版式层级、字号体系、交互一致性。

ui-ux-pro-max 官方 README 对它的定位,是一个为多平台 AI coding assistant 提供 design intelligence 的 Skill。它不是一个 UI 组件库,也不是设计工具,而更像一个给模型补设计经验的知识层。

1.3 两者的互补关系

  • Superpowers:解决“开发过程是否可控”
  • ui-ux-pro-max:解决“前端结果是否足够成熟”

1.4 何时使用 Superpowers,何时使用 ui-ux-pro-max

Superpowers 适合的场景:

  • 中大型功能开发,一次对话内完成不了
  • 任务同时涉及后端建模、接口、前端、测试的多模块联动
  • 需要跨 session 持续推进,上下文断了也要获山再起
  • 需要可审计、可复盘的交付结果

不容易起效的场景:

  • 修一个很小的 bug、一次性脚本、快速验证原型的任务
  • 尚在探索方向、需求本身就不收敛的创意型工作

ui-ux-pro-max 适合的场景:

  • 页面目标和组件库已经确定,你需要的是更统一、更成熟的设计产出
  • 技术栈比较主流(React、Next.js、Tailwind 等)
  • 不适合:尚在探索风格方向、仓库本身设计不统一或项目组件混乱的情况

💡 实践中最常见的用法:先用 Superpowers 把任务拆清楚、推到后端骨架就位,再用 ui-ux-pro-max 进入前端阶段。两个工具的切换点是自然的:前者管流程,后者管疯界面。


二、安装与基础验证

2.1 Superpowers 安装

官方 README 先强调:不同平台的安装方式并不一样。Claude Code 和 Cursor 这类带插件市场的环境装法比较直接;Codex、OpenCode 这类环境则需要走手动安装说明。

Claude Code:官方 Marketplace 安装

/plugin install superpowers@claude-plugins-official

Claude Code:通过 Superpowers Marketplace 安装

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

2.2 ui-ux-pro-max 安装

先决条件:Python 3.x

官方文档强调,Python 3.x 是必需的,因为它的搜索脚本依赖 Python 运行。

# 检查是否已安装
python3 --version

# macOS
brew install python3

这一步最好别省。很多“装了但是不好使”的问题,最后往往不是 Skill 本身的问题,而是本地依赖没有满足。

Claude Code:Marketplace 安装

/plugin marketplace add nextlevelbuilder/ui-ux-pro-max-skill
/plugin install ui-ux-pro-max@ui-ux-pro-max-skill


三、官方工作流概览

按照官方 README,Superpowers 的基本工作流如下:

  1. brainstorming
  2. using-git-worktrees
  3. writing-plans
  4. subagent-driven-developmentexecuting-plans
  5. test-driven-development
  6. requesting-code-review / review 相关环节
  7. finishing-a-development-branch

3.1 需求澄清

对应 brainstorming。它不是“礼貌地追问几句”,而是把模糊需求转成一个能继续往下推的设计起点。最关键的产物不是聊天记录,而是后续会被固化下来的设计判断。

3.2 方案收敛与计划拆分

对应 writing-plans。AI 应把任务拆成一组可以逐步完成、逐步验收的动作。官方文档里一直强调 plan 的粒度要小,就是为了让长任务不会因为上下文膨胀而失控。

3.3 执行阶段的约束机制

对应 executing-planssubagent-driven-developmenttest-driven-development。Superpowers 想做的是,让执行阶段继续受到测试、review 和阶段性检查的约束,而不是有了计划也照样一口气往前冲。

3.4 收尾与交付

对应 finishing-a-development-branch。很多 AI 生成代码的问题,不在生成时,而在收尾时:没确认测试结果,没做回归,也没有明确说明当前分支该如何处置。

3.5 ui-ux-pro-max 的工作方式

你提出任何 UI/UX 相关任务,Skill 在相关平台上自动激活,然后识别任务类型,检索对应的风格、配色、字体、布局建议,再把这些结果提供给模型。它更像“设计顾问”,而不是“页面生成器”。


四、RBAC 案例的选择

RBAC 系统之所以合适作为演示案例,是因为它天然有几层结构:后端要建模用户、角色、权限;接口层要做 Guard 和装饰器;前端要做登录、列表、权限分配、菜单控制;交付阶段还要处理联调、初始化数据和容器化启动。这正好能把 Superpowers 的长任务工作流和 ui-ux-pro-max 的前端辅助能力放进同一个案例里观察。

📌范围边界:本文讨论的是单租户后台管理系统里的 RBAC,不涉及 ABAC、数据行级权限、组织/部门继承、多租户隔离等更复杂的权限模型。


五、在 RBAC 项目中的使用方式

5.1 需求边界澄清

权限系统最容易出问题的,不是 CRUD 本身,而是边界不清时默认做了太多假设。所以第一步不是写代码,而是让 AI 先把问题问完整。

  • 🤖 Prompt:需求边界澄清

    /superpowers:brainstorm
    
    我要做一个后台管理系统的 RBAC 权限模块。
    后端使用 NestJS + Prisma + PostgreSQL,前端使用 Next.js 14 + Tailwind + shadcn/ui。
    
    请不要直接写代码,先帮我把边界条件问清楚,包括:
    - 权限粒度到页面、按钮还是接口
    - 是否需要 super_admin 绕过机制
    - refreshToken 是否落库
    - 是否需要审计日志
    - 是否涉及组织 / 部门 / 租户维度
    

这一步的意义非常大。你以为自己要的是“后台权限控制”,模型理解成了“完整企业权限平台”;你只想做按钮级控制,它顺手给你加上了租户维度和审计模型。超出范围的内容局部不一定错,但大概率不是你当下真正需要的东西。

5.2 Spec 设计说明

一旦问题问得差不多了,让 AI 把核心决策收敛成一份设计说明。有没有把下面几件事说死才是关键:

  • 后端模块怎么拆
  • 权限命名采用什么规范
  • 前端如何接入权限判断
  • 哪些内容这次明确不做

如果这些东西不先落下来,后面生成的 Plan 再细,也只是把一堆摇摆中的决定拆得更碎而已。

5.3 Plan 拆分原则

不要用“实现用户模块”这种粗粒度的任务名。一步里面包含的决策越多,执行时越容易发散。

  • 🤖 Prompt:生成实施计划

    /superpowers:writing-plans
    
    基于刚才对齐的 RBAC 权限系统需求,生成完整实施计划。
    
    要求:
    - 后端和前端分开规划
    - 每个步骤要有明确的交付物和验收标准
    - 数据库 Schema 设计作为独立步骤
    - 鉴权模块和业务模块分开
    - 前端页面按功能模块拆分
    

一份可执行的 Plan 应该是这样的结构:

### Phase 1:工程底座
- [ ] 1.1 初始化 monorepo(apps/api + apps/web)
- [ ] 1.2 配置 Prisma + PostgreSQL
- [ ] 1.3 设计并迁移数据库 Schema

### Phase 2:后端核心
- [ ] 2.1 实现 Auth 模块(登录/刷新 Token)
- [ ] 2.2 实现 Users 模块(CRUD + 状态管理)
- [ ] 2.3 实现 Roles 模块
- [ ] 2.4 实现 Permissions 模块
- [ ] 2.5 实现 JwtAuthGuard + PermissionsGuard
- [ ] 2.6 实现 @Permissions() 装饰器

### Phase 3:前端核心
- [ ] 3.1 初始化 Next.js + Tailwind + shadcn/ui
- [ ] 3.2 实现登录页
- [ ] 3.3 实现布局和侧边栏(权限驱动菜单)
- [ ] 3.4 实现用户、角色、权限管理页

### Phase 4:集成与收尾
- [ ] 4.1 前后端联调
- [ ] 4.2 Docker Compose 一键启动
- [ ] 4.3 初始化管理员账号与默认权限

Plan 不是项目目录,而是执行顺序。进入下一阶段前,务必确认当前阶段验收已通过、git commit 已提交。

5.4 后端实现阶段

  • 🤖 Prompt:执行后端阶段

    /superpowers:executing-plan
    
    执行 PLAN.md 中 Phase 1 和 Phase 2 的所有步骤。
    
    每个步骤执行完后,输出对应的验收 curl 命令。
    

让 AI 牛马🐮🐮🐮🐮给我冲啊!!!

后端验收清单:

# 登录获取 Token
curl -X POST http://localhost:3002/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"admin@test.com","password":"123456"}'

# 获取用户信息 Token 应返回 200
curl -X GET http://localhost:3002/api/auth/profile \
    -H "Authorization: Bearer $ACCESS_TOKEN"

# 无权限的 Token 应返回 403(不是 401)
curl -X DELETE http://localhost:3002/users/1 \
  -H "Authorization: Bearer <limitedToken>"

# super_admin 应能访问所有接口
curl http://localhost:3002/users \
  -H "Authorization: Bearer <superAdminToken>"

上述验收标准因实现而异,具体内容可以交由 AI 生成。

验收标准:

  • ✅ 登录成功,返回中包含权限列表的 Token

  • ✅ 有权限接口正常返回 200

  • ✅ 无权限接口返回 403(不是 401)
  • ✅ super_admin 跳过权限检查
  • ✅ Token 过期后 refreshToken 自动续签

5.5 前端实现阶段

等后端骨架差不多了,这时你已经知道自己要做哪些页面,需要的不再是“帮我想我要做什么”,而是“在页面目标已经明确的前提下,把它们做得更像一个成熟后台”。这就是 ui-ux-pro-max 程开始發揮其真正价值的时候。

  • 🤖 Prompt:执行前端阶段

    /superpowers:execute-plan
    
    执行 PLAN.md 中 Phase 3 的所有步骤,使用 ui-ux-pro-max 技能生成前端页面。
    
    设计要求:
    - 整体风格:SaaS 后台管理系统,Modern + Clean
    - 配色方案:参考 SaaS 行业调色盘,主色深蓝(#1E40AF),辅色浅灰
    - 字体:Inter + 系统字体栈
    - 组件库:shadcn/ui,不自造轮子
    - 侧边栏:固定宽 240px,图标 + 文字菜单,根据权限动态渲染
    - 表格:带分页、搜索、批量操作
    - 表单弹窗:Drawer 风格(从右侧滑入),不用居中 Modal
    - 权限分配:Checkbox 树形结构,按 module 分组
    
    页面清单:
    1. 登录页(/login)
    2. 用户管理(/dashboard/users)
    3. 角色管理(/dashboard/roles)
    4. 权限列表(/dashboard/permissions)
    5. 个人信息(/dashboard/profile)
    

前端权限控制实现示例:

// hooks/usePermissions.ts
export function usePermissions() {
  const { user } = useAuth();
  const can = (permission: string) =>
    user?.permissions?.includes(permission) ?? false;
  return { can };
}

// 按钮级权限控制
{ can('user:delete') && (
  <Button variant="destructive" onClick={handleDelete}>
    删除用户
  </Button>
)}

// 路由守卫
export function PermissionGuard({ permission, children }) {
  const { can } = usePermissions();
  if (!can(permission)) return <NoPermission />;
  return children;
}

前端验收清单:

  • ✅ 菜单根据权限动态显示/隐藏
  • ✅ 没权限的页面不允许进入
  • ✅ 没权限的按钮不展示
  • ✅ 权限分配界面能正常保存
  • ✅ 禁用用户无法登录

5.6 集成与交付阶段

很多教程写到前后端页面都出来了,就差不多结束了。但真实项目往往恰恰是在集成阶段开始变难。

  • 🤖 Prompt:执行集成阶段

    /superpowers:execute-plan
    
    执行 PLAN.md 中 Phase 4 的集成步骤:
    
    1. 前后端联调:
       - 配置 Next.js API 代理(/api/* -> http://localhost:3001)
       - 封装 axios 实例,自动注入 Bearer Token,处理 401 自动刷新
       - 统一错误处理(403 跳转无权限页,401 跳转登录页)
    
    2. Docker Compose:
       - postgres 服务(数据持久化)
       - api 服务(NestJS)
       - web 服务(Next.js)
       - 支持 docker compose up -d 一键启动
    
    3. 初始化脚本:
       - 自动创建 super_admin 角色和初始管理员账号
       - 自动写入所有权限枚举到数据库
    
    完成后输出完整的 README,包含本地启动步骤。
    

集成验收清单:

# 一键启动
docker compose up -d

# 初始化数据(运行一次)
docker compose exec api npx ts-node src/scripts/seed.ts

# 验证协调:前端登录后调用后端接口
curl http://localhost:3001/users \
  -H "Authorization: Bearer <tokenFromFrontend>"

最终验收标准:

  • ✅ docker compose up -d 一键启动,服务全部起来
  • ✅ 初始化脚本正常写入权限和管理员账号
  • ✅ 前端登录后 Token 注入正常,接口可访问
  • ✅ 401 / 403 按预期跳转
  • ✅ 足够翻译:无需手动修改配置文件

六、适用场景与现实限制

6.1 真正适合它的场景

  • 中大型功能开发:不是几个小修小补,而是会牵涉模型、接口、页面、测试的完整模块
  • 多模块联动任务:前后端、交互、鉴权、配置、联调需要协同推进
  • 需要跨 session 续做的任务:一次对话干不完,后面还要继续接着做
  • 需要复盘与审计的交付:你希望知道设计是怎么定的、每一步做到哪了、为什么这样做

6.2 不适合全流程的场景

  • 修一个很小的 bug
  • 一次性脚本
  • 快速验证想法的原型
  • 本来就需要边做边改方向的创意型任务

一句话说就是:小任务轻流程,大任务重流程。

6.3 现实限制

Spec / Plan 确实会带来前置成本

如果任务本来就很小,前面花十几分钟对齐、落文档、拈计划,可能真的不划算。

TDD 会让 AI 显得更慢

它的好处是结果更可验证,但代价就是执行节奏不会像“直接写一版能跑的代码”那么快。

ui-ux-pro-max 的效果依赖代码基线

如果你的仓库本身组件体系混乱、设计 token 失控、页面结构脏乱,那它的上限也会被拉低。

人工决策依旧不可替代

Skill 能加强执行,但不能替你决定:哪些复杂度该引入、哪些边界这次先不做、什么时候追求速度还是追求稳定。


七、稍微总结一下

Superpowers 和 ui-ux-pro-max 的真正价值,不在于它们能把 AI 变成“全自动高级工程师”,而在于它们分别补上了两个最常见的缺口:一个补流程,一个补设计。

前者让任务不那么容易一路失控,后者让前端结果不那么容易停留在“有组件,但没产品感”的层面。

它们不是所有项目都需要的东西,也不是装完就一定立刻见效的东西。你还是得判断任务值不值得走完整流程,还是得亲自做关键决策,还是得面对代码基线、团队习惯和项目复杂度这些很现实的问题。

最后别只停留在“看”的层面,亲自去试一试。这是一个新的世界,尽力去拥抱,别被甩开。

Superpowers 适合把大任务拉回工程轨道,ui-ux-pro-max 适合把前端结果拉回产品语境。 它们真正有用的时候,通常不是在“随便试试”的那一刻,而是在你开始认真交付一个项目的时候。

附:跑通这套流程,你还需要一个顺手的模型接入层

用 Superpowers 推进大任务、用 ui-ux-pro-max 打磨前端,本质上都是在让模型做更多事。做得越多,Token 消耗越真实,模型选型的代价也越具体。

用 Claude Code 跑完一个 RBAC 项目的完整流程,从 brainstorm 到集成交付,实际花费可能远超你的预期——尤其是在 subagent 并行、多轮 review、TDD 来回循环的场景下。

这时候你会开始真正关心几个问题:

  • 这个阶段该用旗舰模型,还是可以切小模型?
  • 缓存命中率到底有多少?前缀是否稳定?
  • 每一步的输入输出 Token 分别是多少,优化前后差多少?

要回答这些问题,你需要的不只是模型能力,还需要一个计费清晰、可以自由切换模型、方便做 A/B 对比的接入层。

我朋友超哥在做的 Amux API 正好适合这个场景:

  • 多模型统一接入:Claude、GPT、Gemini 等主流模型一个 Key 搞定,方便按阶段切换,不用维护多套账号;
  • 成本与用量可视化:输入、输出、缓存命中分开统计,跑完一个 Phase 就能看到真实账单,不是估算;
  • 贴近工程实际:用同一套业务请求验证"上下文裁剪""前缀稳定""输出约束"等策略的实际收益,数字说话。

如果你打算认真跑一遍本文的 RBAC 流程,或者手头有类似的中大型 AI 辅助开发项目,不妨把它作为模型接入层试一试。

💬 选平台时,倍率只是起点。充值口径、缓存表现、计费透明度、稳定性,这几项加在一起才决定它是否真的适合工程场景。

写在最后

🧪 这里是言萧凡的 AI 编程实验室

我会在这里持续记录和分享 AI 工具、编程实践,以及那些値得沉淀下来的高效工作方法。

不只聊概念,也尽量分享能直接上手、能够复用的经验。

希望这间小小的实验室,能陪你一起探索、实践和成长。

2026 年,一起进步。

setTimeout设为0就马上执行?JS异步背后的秘密

作者 牛奶
2026年4月6日 20:52

你有没有遇到过这种情况:代码里写了 setTimeout(fn, 0),心想这下该马上执行了吧?结果发现,还是慢了一拍。还有,为什么 PromisesetTimeout 先执行?async/await 到底在等什么?

今天,用餐厅点餐的故事,来讲讲 JavaScript 事件循环。


原文地址

墨渊书肆/setTimeout设为0就马上执行?JS异步背后的秘密


为什么需要事件循环?

单线程的困境

JavaScript 是单线程的——同一时间只能做一件事。

就像只有一个厨师的小餐厅:如果厨师做完一道菜才接下一单,客人等得头发都白了。

所以 JavaScript 采用了异步回调的方式:点完单先去干别的,菜好了再叫你。

事件循环就是"传唤员"

事件循环就像餐厅里的传唤员

  • 厨房做好了菜,传唤员看看单子,喊"33号,你的菜好了"
  • 如果你正在吃饭(执行其他代码),传唤员就等着
  • 轮到你的时候,你放下筷子(执行完当前代码),去取菜(执行回调)

调用栈 — 厨师的工作台

代码是怎么"跑起来"的?

当你调用一个函数,这个函数就被放进调用栈里执行。

就像厨师在工作台上,一边做菜一边接新单,做完一单马上处理下一单:

function cooking() {
  console.log('开始炒菜');
  fry();
  console.log('炒好了');
}

function fry() {
  console.log('放油');
  console.log('放菜');
  console.log('翻炒');
}

cooking();

执行顺序:

调用栈:
1. cooking() 入栈
2. console.log('开始炒菜') 入栈,执行,出栈
3. fry() 入栈
4. fry() 内的 console.log 依次执行
5. fry() 出栈
6. console.log('炒好了') 入栈,执行,出栈
7. cooking() 出栈

调用栈的特点

  • 后进先出:就像叠盘子,最后放上去的先被用
  • 同步执行:每个函数必须执行完,下一个才能进来
  • 栈溢出:如果递归没终止,栈会无限增长直到崩溃
// 栈溢出示例
function recursive() {
  recursive();
}
recursive();
// RangeError: Maximum call stack size exceeded

任务队列 — 取餐口

异步代码放哪儿?

当遇到 setTimeoutPromise事件回调 这些异步任务时,它们不会马上执行,而是被放到任务队列里。

就像点完单,服务员把单子放到取餐口,等叫号再去取。

事件循环的运行机制

┌─────────────────────┐
       调用栈            正在执行
   (Call Stack)       
└─────────────────────┘
          
┌─────────────────────┐
      任务队列           等待执行
   (Task Queue)       
└─────────────────────┘
          
    事件循环 (Event Loop)
    "栈空了?好,取下一个"

事件循环的规则

  1. 首先执行调用栈里的所有同步代码
  2. 调用栈清空后,去任务队列取一个任务执行
  3. 完成后回到步骤1
console.log('1');

setTimeout(() => {
  console.log('2');
}, 0);

console.log('3');

// 输出:1 → 3 → 2
// 因为 setTimeout 的回调在任务队列,要等调用栈空才能执行

微任务 vs 宏任务 — VIP和普通号

两种不同的"队"

任务队列其实分两种:

类型 例子 优先级
宏任务(Macrotask) setTimeoutsetIntervalI/OUI渲染
微任务(Microtask) Promise.then()回调、MutationObserverqueueMicrotask

就像餐厅里:

  • 宏任务 = 普通取餐号,要排队
  • 微任务 = VIP会员卡,来了直接优先处理

注意:不是 Promise 本身是微任务,而是 Promise.then() 的回调函数是微任务。

执行顺序

console.log('1');

setTimeout(() => {
  console.log('2');  // 宏任务
}, 0);

Promise.resolve().then(() => {
  console.log('3');  // 微任务
});

console.log('4');

// 输出:1 → 4 → 3 → 2
// 同步代码 → 微任务 → 宏任务

完整执行流程

setTimeout(() => console.log('setTimeout'), 0);

Promise.resolve()
  .then(() => console.log('Promise1'))
  .then(() => console.log('Promise2'));

Promise.resolve()
  .then(() => console.log('Promise3'));

console.log('同步代码');

// 输出顺序:
// 同步代码
// Promise1
// Promise3
// Promise2      ← Promise.then 链式调用在同一个微任务队列
// setTimeout     ← 所有微任务完成后,才执行宏任务

嵌套的 Promise

Promise.resolve().then(() => {
  console.log('第一个微任务');

  Promise.resolve().then(() => {
    console.log('嵌套的微任务');
  });
});

console.log('同步代码');

// 输出:
// 同步代码
// 第一个微任务
// 嵌套的微任务
// 微任务队列清空后,才会执行下一个宏任务

async/await — 语法糖的秘密

async/await 是什么?

async/await 是 Promise 的语法糖,让异步代码看起来像同步代码。

// Promise 写法
function getData() {
  return fetch('/api/user')
    .then(res => res.json())
    .then(data => console.log(data));
}

// async/await 写法
async function getData() {
  const res = await fetch('/api/user');
  const data = await res.json();
  console.log(data);
}

await 到底在等什么?

await暂停当前 async 函数的执行,等待 Promise 完成,然后继续执行后面的代码。

暂停期间,其他代码可以继续执行

async function example() {
  console.log('1');

  await fetch('/api/data');  // 这里"暂停"

  console.log('3');  // ← 这行去哪了?
}

console.log('2');
example();
console.log('4');

// 输出:2 → 1 → 4 → 3

await 后面那行代码去哪了?

await 后面的代码不会马上执行,而是被包成一个微任务。等 await 的 Promise resolve 后,这个微任务才会执行:

async function example() {
  console.log('1');

  await fetch('/api/data');  // Promise pending...
  // 下面的代码被包成微任务,要等 Promise 完成才执行

  console.log('3');  // ← 这行实际上是 await 的 resolve 后的回调
}

// 等价于:
function example() {
  console.log('1');
  return fetch('/api/data').then(() => {
    console.log('3');  // ← 这里
  });
}

async 函数返回值

async 函数总是返回一个 Promise

async function getNumber() {
  return 42;
}

getNumber().then(console.log);  // 42

// 等价于:
async function getNumber() {
  return Promise.resolve(42);
}

错误处理

// try-catch
async function fetchData() {
  try {
    const res = await fetch('/api/data');
    const data = await res.json();
  } catch (error) {
    console.log('出错了:', error);
  }
}

// Promise catch
async function fetchData() {
  const res = await fetch('/api/data').catch(err => console.log(err));
}

requestAnimationFrame — 动画的正确姿势

为什么不用 setInterval?

setInterval 不保证什么时候执行,也不保证每次间隔精确:

setInterval(() => {
  moveBall();  // 可能丢帧、卡顿
}, 16);  // 约60fps,但不一定准

requestAnimationFrame 的特点

  • 浏览器优化:在下一次重绘之前执行,不丢帧
  • 页面不可见时:自动暂停,节省性能
  • 约60fps:和屏幕刷新率同步
function animate() {
  moveBall();
  requestAnimationFrame(animate);
}

requestAnimationFrame(animate);

// 取消动画
const id = requestAnimationFrame(animate);
cancelAnimationFrame(id);

执行顺序

用户点击
   
事件触发
   
微任务(全部清空)← 先清空所有微任务
   
宏任务
   
requestAnimationFrame   所有微任务清空后,渲染之前
   
浏览器渲染

深入了解事件循环 🔬

Node.js 的事件循环

Node.js 和浏览器的事件循环不一样

┌───────────────────────────────────────────────────────┐
│                    Node.js 事件循环                    │
├───────────────────────────────────────────────────────┤
│  ① Timers          →  setTimeout, setInterval 回调    │
│  ② Pending I/O     →  I/O callbacks(延迟到下一循环)   │
│  ③ Idle/Prepare    →  内部使用                         │
│  ④ Poll            →  获取新 I/O 事件                  │
│  ⑤ Check           →  setImmediate 回调               │
│  ⑥ Close           →  close 事件回调                   │
└────────────────────────────────────────── ────────────┘

浏览器和 Node.js 的区别

// 浏览器
setTimeout(() => console.log('timeout'), 0);
Promise.resolve().then(() => console.log('microtask'));
// 输出:microtask → timeout

// Node.js(可能不同)
setTimeout(() => console.log('timeout'), 0);
Promise.resolve().then(() => console.log('microtask'));
// 可能输出:microtask → timeout
// 但 setImmediate 可能更早

queueMicrotask vs Promise.then

queueMicrotask 显式创建一个微任务:

queueMicrotask(() => {
  console.log('我也是微任务');
});

Promise.resolve().then(() => {
  console.log('Promise微任务');
});

// 两者都是微任务,执行顺序相同

浏览器渲染时机

不是每次事件循环都会渲染,浏览器会批量处理

// 可能只触发一次重排/重绘
div.style.top = '100px';
div.style.left = '100px';
div.style.width = '200px';

// 而不是三次单独的重排

任务分解 — 避免卡顿

长时间任务可以分解,让页面保持响应:

function processItems(items) {
  let i = 0;

  function step() {
    // 处理一项
    process(items[i]);

    i++;
    if (i < items.length) {
      // 用 setTimeout 让出主线程
      setTimeout(step, 0);
    }
  }

  step();
}

// 现代浏览器可以用 scheduler.yield()
async function processItems(items) {
  for (const item of items) {
    process(item);
    await scheduler.yield();  // 让出主线程
  }
}

横向对比

API 类型 优先级 使用场景
setTimeout 宏任务 延迟执行、轮询
setInterval 宏任务 定时任务(慎用)
Promise.then 微任务 异步结果处理
async/await 微任务 异步代码写法
requestAnimationFrame 宏任务 动画、游戏循环
MutationObserver 微任务 DOM 变化监听

怎么选?

场景 推荐
延迟执行 setTimeout
等待 Promise await / Promise.then
动画/游戏 requestAnimationFrame
批量 DOM 操作 MutationObserver
分解长任务 setTimeout / scheduler.yield()

总结

概念 像什么 作用
调用栈 厨师灶台 同步代码执行
任务队列 取餐口 等待执行的异步任务
宏任务 普通取餐号 setTimeout、setInterval
微任务 VIP会员卡 Promise、queueMicrotask
事件循环 传唤员 协调调用栈和任务队列

同步代码 → 微任务 → 宏任务 → 渲染 → 下一轮


写在最后

现在你应该明白了:

  • setTimeout(fn, 0) 不是马上执行,要等调用栈空、微任务清空后才轮到你
  • PromisesetTimeout 先执行,因为微任务优先级更高
  • async/await 只是 Promise 的语法糖,本质还是异步
  • requestAnimationFrame 是做动画的正确方式,别用 setInterval

下次你的代码执行顺序不对,先看看是微任务还是宏任务——可能就是它插队了。

5MB vs 4KB vs 无限大:浏览器存储谁更强?

作者 牛奶
2026年4月6日 20:44

你有没有想过这个问题:为什么在网页上勾选了"记住我",下次打开还是登录状态?你改了个主题设置,关掉浏览器再打开,主题还在?浏览器是怎么记住这些数据的?

今天,用**"收纳房间"**的故事,来讲讲浏览器存储。


原文地址

墨渊书肆/5MB vs 4KB vs 无限大:浏览器存储谁更强?


浏览器是怎么"装东西"的?

想象一下你家要装修,需要各种收纳工具:

  • 贴身口袋:装点小东西,随时能用
  • 床头柜:装常用物品,随取随用
  • 衣柜:装换季衣服,大容量
  • 仓库:存大件物品,最大但找起来麻烦

浏览器存储也是这个道理。不同的数据,要用不同的"收纳工具"。


Cookie — 贴身口袋

像个口袋,随身带

Cookie 是最"古老"的浏览器存储方案。它最大的特点是——会自动跟着请求一起发出去

就像你出门带了个口袋,里面装着身份证、银行卡。进任何一家店,都要掏出身份证证明身份。

浏览器也是:每次请求网页,Cookie 都自动带上,服务器就知道"哦,这是张三的浏览器"。

Cookie 的特点

属性 像什么
容量 ~4KB 口袋里只能装这么多
发送 自动随请求发送 出门就带
生命周期 可设置过期时间 可以设有效期
访问 JS和服务器都能读 谁都能用

Cookie 的使用场景

  • 登录状态:"记住我"功能
  • 购物车:逛淘宝加购物车
  • 追踪分析:埋点上报

Cookie 的代码

// 设置Cookie
document.cookie = "username=张三; expires=Fri, 31 Dec 2026 23:59:59 GMT; path=/";

// 读取Cookie
console.log(document.cookie);  // "username=张三; theme=dark"

Cookie 的安全问题

Cookie 虽然方便,但有几个安全属性要注意:

属性 作用 什么意思
HttpOnly JS无法访问 口袋上锁了,店员碰不到
Secure 只在HTTPS发送 只能用加密通道
SameSite 防止CSRF攻击 别人拿不到你的卡

深入了解 Cookie 🔬

Cookie 是怎么工作的?

Cookie 由 HTTP 协议定义,通过 Set-Cookie 响应头设置:

HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure; SameSite=Strict

HTTP/1.1 200 OK
Cookie: sessionId=abc123

浏览器怎么存 Cookie?

每个浏览器都有自己的存储方式:

浏览器 存储位置
Chrome/Edge SQLite 数据库 (%APPDATA%\Local\Google\Chrome\User Data\Default\Cookies)
Firefox JSON 文件 (cookies.sqlite)
Safari 二进制文件

Cookie 的发送规则?

浏览器根据 Domain + Path + SameSite 三个规则决定是否发送:

// 例如:Cookie 设置为 Domain=example.com, Path=/admin
// 会发送给:
// ✅ example.com/admin
// ✅ example.com/admin/users
// ❌ example.com/ (path不匹配)
// ❌ other.com/admin (domain不匹配)

Session Cookie vs 持久 Cookie?

# 会话Cookie(没有Expires/Max-Age)
Set-Cookie: sessionId=abc123
# 关掉浏览器就失效

# 持久Cookie
Set-Cookie: sessionId=abc123; Expires=Wed, 01 Jan 2027 00:00:00 GMT
# 有效期内都有效

LocalStorage — 床头柜

容量大,但不主动发

LocalStorage 是 HTML5 引入的存储方案。最大的特点:不会随请求发出去

就像床头柜——你把东西放里面,下次进门直接拿,不用每次出门都背着。

LocalStorage 的特点

属性 像什么
容量 ~5MB/域 床头柜大小
发送 不随请求发送 不随身带
生命周期 永久存储 除非搬家(手动删除)
API 同步操作 马上拿到

LocalStorage 的使用场景

  • 主题设置:深色/浅色模式
  • 用户偏好:字体大小、语言设置
  • 数据缓存:接口数据本地缓存

LocalStorage 的代码

// 设置
localStorage.setItem('username', '张三');
localStorage.setItem('theme', 'dark');

// 读取
const theme = localStorage.getItem('theme');  // 'dark'

// 删除
localStorage.removeItem('theme');

// 清空
localStorage.clear();

// 遍历
for (let i = 0; i < localStorage.length; i++) {
  const key = localStorage.key(i);
  console.log(`${key}: ${localStorage.getItem(key)}`);
}

LocalStorage 的缺点

  • 同步操作:大量数据会卡界面
  • 只能存字符串:对象要转成 JSON
  • 容量有限:5MB 对大数据不够

深入了解 LocalStorage 🔬

同源策略限制

LocalStorage 遵循同源策略:

✅ http://example.com 和 https://example.com 共享同一个Storage
✅ http://example.com:8080 和 http://example.com:3000 不共享(端口不同)
✅ http://www.example.com 和 http://example.com 不共享(子域名不同)

存储配额

实际容量取决于浏览器和磁盘空间,Chrome 默认是 5MB(可申请更多):

// 查询当前配额和使用量
navigator.storage.estimate().then(({ usage, quota }) => {
  console.log(`已使用: ${(usage / 1024 / 1024).toFixed(2)} MB`);
  console.log(`总配额: ${(quota / 1024 / 1024).toFixed(2)} MB`);
});

// 请求更大的存储空间(需要用户授权)
navigator.storage.persist().then((granted) => {
  console.log('永久存储权限:', granted);
});

为什么 LocalStorage 是同步的?

因为 LocalStorage 读取是直接读磁盘。如果数据量大,同步读取会阻塞主线程:

// ❌ 错误:大数据量时卡界面
localStorage.setItem('bigData', JSON.stringify(largeArray));

// ✅ 更好:拆分存储或用 IndexedDB

SessionStorage — 抽屉

只在当前标签页有效

SessionStorageLocalStorage 几乎一样,唯一的区别是——关闭标签页就没了

就像抽屉里的东西,只有在这个房间能用。换到另一个房间(另一个标签页),抽屉里的东西就不在了。

SessionStorage 的特点

属性 和LocalStorage的区别
容量 ~5MB/域 一样
作用域 仅当前标签页 ❌ 跨标签页不共享
生命周期 关闭标签页失效 ❌ 不能持久保存

SessionStorage 的使用场景

  • 表单草稿:填写到一半的表单
  • 临时状态:当前页面的操作状态

SessionStorage 的代码

// 用法和LocalStorage完全一样
sessionStorage.setItem('draft', JSON.stringify({ title: '我的文章', content: '...' }));

关键区别

// 标签页A中设置
sessionStorage.setItem('key', 'value');
localStorage.setItem('key', 'value');

// 在标签页B中读取
sessionStorage.getItem('key');  // null ❌
localStorage.getItem('key');    // 'value' ✅

深入了解 SessionStorage 🔬

iframe 共享问题

注意:同一个标签页中的 iframe 会共享 SessionStorage(因为是同一个浏览器标签页):

// 父页面
sessionStorage.setItem('shared', 'value');

// iframe 内可以读取到
console.log(sessionStorage.getItem('shared'));  // 'value'

sessionStorage 在隐私模式下

  • Chrome 无痕模式sessionStorage 仍然存在,但标签页关闭后失效
  • Firefox 隐私窗口:完全隔离,每个新窗口都是新的 sessionStorage

和 LocalStorage 的性能对比

两者都是同步 API,性能特性相同。但 SessionStorage 因为数据不持久,有时候比 LocalStorage 更适合存临时数据。


IndexedDB — 仓库

浏览器里的数据库

IndexedDB 是浏览器内置的数据库。容量巨大,能存文件、音频、视频这些大东西。

就像仓库——你家装修工具、电风扇、行李箱都放这儿。东西多,但找起来要翻半天。

IndexedDB 的特点

属性 像什么
容量 很大(取决于磁盘) 仓库,接近无限
数据类型 什么都能存 不挑东西
API 异步操作 异步,不卡界面
查询 支持索引 能分类查找

IndexedDB 的使用场景

  • 离线数据:PWA离线应用
  • 多媒体存储:图片、音频、视频缓存
  • 复杂数据:需要索引查询的数据

IndexedDB 的代码

// 打开数据库
const request = indexedDB.open('myDatabase', 1);

// 创建表(对象存储)
request.onupgradeneeded = (event) => {
  const db = event.target.result;
  const store = db.createObjectStore('users', { keyPath: 'id' });
  store.createIndex('name', 'name', { unique: false });
  store.createIndex('email', 'email', { unique: true });
};

// 添加数据
request.onsuccess = (event) => {
  const db = event.target.result;
  const tx = db.transaction(['users'], 'readwrite');
  const store = tx.objectStore('users');

  store.add({ id: 1, name: '张三', email: 'zhangsan@example.com' });
  store.add({ id: 2, name: '李四', email: 'lisi@example.com' });
};

// 查询数据
const getRequest = store.get(1);
getRequest.onsuccess = () => {
  console.log('查询结果:', getRequest.result);
};

// 使用索引查询
const index = store.index('name');
const indexRequest = index.get('张三');
indexRequest.onsuccess = () => {
  console.log('索引查询结果:', indexRequest.result);
};

IndexedDB 的缺点

  • API 复杂:需要写一堆回调
  • 学习成本高:概念多(数据库、表、事务、索引)

深入了解 IndexedDB 🔬

数据库版本和升级

const request = indexedDB.open('myDatabase', 2);  // 版本号从1升到2

request.onupgradeneeded = (event) => {
  const db = event.target.result;

  // 创建新存储
  if (!db.objectStoreNames.contains('products')) {
    db.createObjectStore('products', { keyPath: 'id' });
  }

  // 删除旧存储
  if (db.objectStoreNames.contains('oldData')) {
    db.deleteObjectStore('oldData');
  }
};

事务的原子性

const tx = db.transaction(['users', 'orders'], 'readwrite');

// 两个操作在一个事务里,要么全成功,要么全失败
tx.objectStore('users').add({ id: 1, name: '张三' });
tx.objectStore('orders').add({ id: 1, userId: 1, product: '电脑' });

tx.oncomplete = () => console.log('事务成功');
tx.onerror = () => console.log('事务失败,全部回滚');

游标遍历大量数据

const tx = db.transaction(['users'], 'readonly');
const store = tx.objectStore('users');
const cursor = store.openCursor();

cursor.onsuccess = (event) => {
  const cur = event.target.result;
  if (cur) {
    console.log('用户:', cur.value.name);
    cur.continue();  // 继续下一个
  }
};

Promise 封装(更简洁的写法)

function openDB(name, version) {
  return new Promise((resolve, reject) => {
    const request = indexedDB.open(name, version);
    request.onupgradeneeded = (e) => resolve(e.target.result);
    request.onsuccess = (e) => resolve(e.target.result);
    request.onerror = (e) => reject(e.target.error);
  });
}

// 使用
const db = await openDB('myDatabase', 1);
const tx = db.transaction('users', 'readwrite');
await tx.objectStore('users').add({ id: 1, name: '张三' });

Cache API — 集装箱

Service Worker 的专属工具

Cache API 是 Service Worker 的一部分,专门用来缓存网络请求。

就像集装箱——你坐飞机带不了大件行李,但可以用集装箱海运。东西多、个头大,但只能走特定渠道。

Cache API 的特点

属性 像什么
容量 很大 集装箱,装得多
存储内容 Request/Response 对 整套打包
生命周期 手动管理 不用就扔
API 异步操作 不卡界面

Cache API 的使用场景

  • 离线应用:把整个网站缓存下来
  • 性能优化:缓存静态资源
  • Service Worker:配合SW实现缓存策略

Cache API 的代码

// 在Service Worker中使用
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request)
      .then((cachedResponse) => {
        return cachedResponse || fetch(event.request);
      })
  );
});

// 打开缓存
caches.open('my-cache').then((cache) => {
  cache.addAll([
    '/css/style.css',
    '/js/app.js',
    '/images/logo.png'
  ]);
});

// 缓存特定请求
cache.put(request, response);

// 删除缓存
caches.delete('my-cache');

深入了解 Cache API 🔬

缓存策略

// Cache First(缓存优先)
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request)
      .then((response) => response || fetch(event.request))
  );
});

// Network First(网络优先)
self.addEventListener('fetch', (event) => {
  event.respondWith(
    fetch(event.request)
      .catch(() => caches.match(event.request))
  );
});

// Stale-While-Revalidate(先返回缓存,同时更新缓存)
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.open('my-cache').then((cache) => {
      return cache.match(event.request).then((response) => {
        const fetchPromise = fetch(event.request).then((networkResponse) => {
          cache.put(event.request, networkResponse.clone());
          return networkResponse;
        });
        return response || fetchPromise;
      });
    })
  );
});

Cache API 和 cookies

Cache API 存储的是完整的 Request/Response 对,不只是 body:

// 缓存时包含了headers、status等所有信息
cache.match(request).then((response) => {
  console.log(response.status);      // 200
  console.log(response.headers.get('content-type'));  // 'text/html'
});

缓存清理策略

// 删除指定缓存
caches.delete('old-cache');

// 清理所有版本,只保留最新的
caches.keys().then((cacheNames) => {
  Promise.all(
    cacheNames
      .filter((name) => name.startsWith('app-') && name !== 'app-v2')
      .map((name) => caches.delete(name))
  );
});

Storage Event — 跨标签页喊话

标签页之间能"喊话"

当 LocalStorage 发生变化时,其他同源的标签页会收到通知。

就像你在客厅喊了一句"饭好了",厨房的人、卧室的人都能听到。

Storage Event 的代码

// 标签页A中监听
window.addEventListener('storage', (event) => {
  console.log('key:', event.key);      // 变化的键
  console.log('oldValue:', event.oldValue);  // 旧值
  console.log('newValue:', event.newValue);  // 新值
  console.log('url:', event.url);      // 触发变化的页面URL
  console.log('storageArea:', event.storageArea);  // localStorage 或 sessionStorage
});

// 标签页B中修改
localStorage.setItem('theme', 'dark');  // 标签页A会收到通知

使用场景

  • 多标签页同步:一个标签页登录,其他标签页同步登录状态
  • 状态广播:跨标签页的状态通知

深入了解 Storage Event 🔬

Storage Event 的触发条件

// ✅ 会触发 storage 事件
localStorage.setItem('key', 'value');
localStorage.removeItem('key');
localStorage.clear();

// ❌ 不会触发 storage 事件(同一个标签页)
// Storage Event 只在「其他标签页」变化时触发

SessionStorage 也会触发?

注意:SessionStorage 本身不跨标签页共享,但 Storage Event 只监听 localStorage 的变化。

// SessionStorage 变化不会触发 storage 事件
sessionStorage.setItem('key', 'value');  // 不会触发其他标签页

// localStorage 变化会触发
localStorage.setItem('key', 'value');  // 其他标签页会收到通知

隐私模式下不触发

在无痕/隐私模式下,Storage Event 不会触发,这是浏览器的隐私保护机制。


横向对比

特性 Cookie LocalStorage SessionStorage IndexedDB Cache API
容量 ~4KB ~5MB ~5MB 很大 很大
生命周期 可设置 永久 关闭失效 永久 手动
发送 自动发 不发 不发 不发 不发
API 简单 同步简单 同步简单 异步复杂 异步
数据类型 字符串 字符串 字符串 所有可序列化 Request/Response
跨标签页 共享 共享 不共享 共享 不共享

怎么选?

场景 推荐
需要服务器读取 Cookie
存用户偏好、主题 LocalStorage
临时状态、标签页隔离 SessionStorage
大数据、离线存储 IndexedDB
Service Worker缓存 Cache API

注意事项

1. 不要存敏感信息

LocalStorage 可以被 JS 访问,XSS 攻击能偷走数据。敏感信息用 HttpOnly Cookie。

2. 存储配额

浏览器对存储有限制,可以用 API 查询:

navigator.storage.estimate().then(({ usage, quota }) => {
  console.log('已用:', (usage / 1024 / 1024).toFixed(2), 'MB');
  console.log('总配额:', (quota / 1024 / 1024).toFixed(2), 'MB');
});

3. 序列化问题

LocalStorage 和 SessionStorage 只能存字符串,对象要转 JSON:

// 存
localStorage.setItem('data', JSON.stringify({ name: '张三' }));

// 取
const data = JSON.parse(localStorage.getItem('data'));

4. 同步 API 的性能问题

LocalStorage/SessionStorage 是同步操作,大量数据会阻塞主线程:

// ❌ 不好:大量数据卡界面
for (let i = 0; i < 10000; i++) {
  localStorage.setItem(`key${i}`, `value${i}`);
}

// ✅ 更好:用 IndexedDB 存储大量数据

总结

存储方式 像什么 特点
Cookie 口袋 小、随请求发、安全属性多
LocalStorage 床头柜 5MB、不发送、永久
SessionStorage 抽屉 5MB、不发送、仅标签页
IndexedDB 仓库 巨大、异步、复杂
Cache API 集装箱 Service Worker专用

选对"收纳工具",数据管理更轻松。


写在最后

现在你应该明白了:

  • Cookie = 口袋,随身带、自动发送、容量小
  • LocalStorage = 床头柜,大容量、不发送、永久保存
  • SessionStorage = 抽屉,只在当前标签页有效
  • IndexedDB = 仓库,最大但操作复杂
  • Cache API = 集装箱,Service Worker专用

下次你在网页上勾选"记住我",或者调整了主题设置——你就知道浏览器是用哪种"收纳工具"帮你存的了。

【节点】[Posterize节点]原理解析与实际应用

作者 SmalBox
2026年4月6日 20:20

【Unity Shader Graph 使用与特效实现】专栏-直达

Posterize 节点是 Unity URP ShaderGraph 中实现色调分离效果的核心工具,其技术本质是通过离散化算法将连续数值空间转换为阶梯状色阶。该节点的数学实现基于经典量化函数:

Out = floor(In * Steps) / Steps

其中 floor 函数负责向下取整操作。在具体实现中,节点通过输入值(In)和色阶数量(Steps)两个关键参数,将颜色、UV 坐标或多通道数据分割为指定数量的等距区间,每个区间内的连续值被统一映射为离散的阶梯值,最终形成类似海报印刷的视觉效果。

端口功能深度解析

  • 输入端口 In‌:支持从标量(float)到四维向量(float4)的全类型动态输入,可灵活处理颜色 RGBA 通道、位置坐标、法线向量等多维数据。实际应用中,开发者可将任意连续数据流接入此端口,实现从色彩管理到几何变形的多样化效果。
  • Steps 参数‌:控制色阶数量的核心参数,每个分量必须 ≥1。当 Steps=4 时,原本连续的 0-1 色调范围将被精确分割为[0,0.25)、[0.25,0.5)、[0.5,0.75)、[0.75,1.0]四个等距区间,每个区间内的值都会映射到对应的离散值(0、0.25、0.5、0.75)。
  • 输出端口 Out‌:返回经过离散化处理的数据,输出维度与输入端口保持严格一致,确保数据流的完整性。

技术优势与实现细节

  • 多维度统一处理‌:支持同时处理颜色空间、纹理坐标、法线贴图等多通道数据,实现全通道的同步色调分离。在高级应用中,开发者可分别控制各通道的 Steps 参数,实现 RGB 通道独立分离等复杂效果。
  • 参数化艺术控制‌:通过 Steps 参数的动态调整,可实现从照片级真实感(Steps=256)到极致简约风格(Steps=2)的平滑过渡,完美适配 Low Poly、像素艺术、复古海报等多样化艺术风格需求。
  • GPU 并行优化‌:相比传统手写 HLSL 代码,Posterize 节点通过 ShaderGraph 的优化编译流程,充分利用 GPU 的并行计算架构,在移动端和高端设备上均能保持出色的渲染性能。

行业应用场景扩展

游戏美术风格化渲染

在独立游戏开发中,通过将 Steps 参数设置为 3-6 区间,配合 UV 坐标的 Posterize 处理,可快速生成低多边形建模的视觉特征。典型案例包括:将角色模型的 UV 坐标 X/Y 分量分别离散化处理,配合颜色通道的阶梯化调整,实现类似《纪念碑谷》的几何艺术风格。同时,通过法线贴图的 Posterize 处理,可在保持模型细节的同时强化风格化表现。

影视级后期处理效果

在虚拟制片领域,结合 Steps=4-8 的色阶分离与动态饱和度调整,可精准模拟 20 世纪海报印刷的经典网点效果。工业化应用流程包括:

  • 使用 Posterize 节点分层处理基础颜色、高光和阴影通道
  • 通过 Saturation 节点分区域增强色彩对比度
  • 添加 Dither 节点模拟印刷半色调和网点纹理
  • 结合 Camera Stacking 技术实现非破坏性后期处理

专业数据可视化系统

在科学计算可视化领域,Posterize 节点可将连续物理数据(如温度梯度、气压分布、地震波强度)转换为清晰的色阶图谱。典型实现方案:将热力图原始数据离散化为 8-16 个精确色阶,通过 Color Mapping 节点实现数据到颜色的智能映射,大幅提升科研人员的数据解读效率。在气象预报、地质勘探等专业领域具有重要应用价值。

交互艺术装置设计

在新媒体艺术领域,Posterize 节点结合实时输入数据,可创建动态变化的视觉艺术装置。通过连接音频分析器输出的频谱数据,驱动 Steps 参数的动态变化,实现音乐可视化效果。同时配合 Kinect 等体感设备,实现基于人体运动的实时色调分离交互。

实战案例深度优化

自适应马赛克效果实现

  • 创建增强型 URP Lit ShaderGraph‌:在 Project 面板右键 Create → Shader → URP → Lit ShaderGraph,并启用 Advanced 选项
  • 智能化节点连接方案‌:
    • 添加 High Definition Render Pipeline Texture 节点作为基础颜色输入
    • 使用 Dual Posterize 节点架构分别处理 UV 坐标的 U/V 分量
    • 通过 Remap 节点精确控制离散化后的数值范围
    • 将最终结果连接至 BaseColor 和 Emission 通道,增强视觉效果
  • 动态参数控制系统‌:通过材质面板的 Float 参数动态调节 Steps 值,并结合 Vertex Color 通道实现基于模型空间的位置遮罩,打造局部马赛克特效。

影视级动态色调分离

  • 创建可复用子图系统‌:将 Posterize 节点封装为功能完整的子图,支持 In、Steps、Intensity 等多个输入参数
  • 高级动态控制网络‌:
    • 添加 Sine Time 节点驱动 Steps 参数的周期性变化
    • 使用 Smoothstep 节点实现色阶数量的非线性过渡
    • 通过 Animation Curve 节点精确控制离散化效果的演变轨迹
  • 多通道协同应用‌:结合 Normal Map 节点和 Height Map 节点,实现法线贴图和视差效果的同步离散化,增强材质的体积感和细节表现力。

性能优化与多平台兼容性方案

精细化性能影响分析

Posterize 节点的性能消耗主要受三个维度影响:

  • 输入数据的复杂度:标量计算消耗最低,四维向量处理消耗最高
  • Steps 参数的数值大小:测试显示 Steps 从 8 增加到 64,性能消耗提升约 40%
  • 多通道并行使用:同时处理颜色、UV 和法线通道时,需要特别注意移动端性能表现

实际性能测试数据表明,在高端移动设备(骁龙 888)上,对 RGBA 颜色通道使用 Steps=8 的 Posterize 处理,帧率下降约 12-15%;而在低端设备(骁龙 660)上,相同操作可能导致帧率下降 25-30%。

全平台兼容性解决方案

  • URP 版本智能适配‌:确保使用 Unity 2019.4 LTS 及以上版本,并安装 URP 7.0+ 版本包
  • 跨平台差异化处理‌:针对 iOS/Android/PC 等不同平台,通过 Graphics Settings 中的 Quality Levels 自动配置最优 Steps 参数
  • 性能优先替代方案‌:对性能敏感的场景,可使用 Half Precision Posterize 节点(减少 50% 计算量)或预计算离散化贴图

常见问题与系统性解决方案

输出异常深度排查

  • 现象分析‌:Posterize 节点输出全黑或全白
  • 根本原因‌:Steps 参数设置过小(<2)导致过度离散化,或输入数据范围超出预期
  • 系统解决方案‌:
    • 使用 Clamp 节点限制 Steps 参数的有效范围(2-256)
    • 通过 Normalize 节点预处理输入数据,确保数值在 0-1 范围内
    • 添加 Debug 节点实时监控各端口数据流

材质渲染错误综合处理

  • 现象识别‌:应用 Posterize 材质后模型出现闪烁、撕裂或颜色异常
  • 多维原因分析‌:URP 渲染管线配置错误、Shader Graph 版本不兼容、材质参数越界等
  • 完整解决流程‌:
    • 通过 Edit → Project Settings → Graphics 确认 Scriptable Render Pipeline 设置
    • 检查 Package Manager 中 Shader Graph 版本与 URP 版本的匹配性
    • 使用 Frame Debugger 逐帧分析渲染状态

进阶技巧与创新应用扩展

非线性色阶分离技术

通过自定义 Steps 曲线实现艺术化离散效果:

  • 添加 Animation Curve 节点控制 Steps 参数的动态变化
  • 使用 Curve Mapping 实现 RGB 通道的独立离散化控制
  • 结合 Noise 节点创建有机变化的色阶分离效果

多节点协同创新应用

  • 与 Hue/Saturation/Luminance 节点组合‌:构建完整的色彩管理系统,实现先分离色阶再精细调整色调的工业化流程
  • 与 Blend 节点深度结合‌:创建多层混合材质,实现局部色调分离与全局效果的完美融合
  • 与 Mask 节点智能联动‌:通过顶点颜色、纹理坐标或深度信息生成动态遮罩,精确控制 Posterize 效果的应用区域和强度

移动端专项优化体系

  • 自适应 LOD 系统‌:根据设备 GPU 性能自动调整 Steps 值和计算精度
  • 预计算优化策略‌:对静态场景元素使用预计算的 Posterize 贴图阵列
  • 精度控制矩阵‌:通过 Shader 属性中的 Precision 选项分级控制计算精度,平衡效果与性能

【Unity Shader Graph 使用与特效实现】专栏-直达 (欢迎点赞留言探讨,更多人加入进来能更加完善这个探索的过程,🙏)

我用 1 天的时间 vibe coding 了一个多人德州扑克游戏

作者 lihaozecq
2026年4月6日 20:13

这是我第一次全程没有修改 AI 代码的 vibe coding 体验,整体下来除了交互和边界 case 需要反复与 AI 确认,功能层面 AI 完全可以顺利搞定,甚至出乎我的意料。

背景

业余时间会跟异地朋友视频聊天,吐槽吐槽生活,偶尔会通过视频的方式娱乐下比如德州扑克,之前用过其他软件但功能繁琐,又需要做任务获取金币。所以一直想自己做一个在线的德州扑克游戏,由于开发工作量比较大,一直搁置。(之前也尝试通过 AI 去实现,但整体效果一般就放弃了)。这周末心血来潮,想到 Harness Engineering 理念这么火,决定用 Claude Code 尝试一下。

先看成果:

游戏桌效果

在线体验:texas-holdem-production-c30c.up.railway.app | 开源仓库:GitHub

过程中用到的工具

Claude Code CLI

本项目全程使用 Claude Code CLI 完成,模型为 Opus 4.6(1M context)。使用最强模型可以提高整体的代码质量,节省很多给反馈给 AI 的沟通时间。

Superpowers Skills

Superpowers 是一套 Claude Code 的 Skills 插件。它的价值在于让 AI 在动手之前先思考。尤其是 brainstorming,当我说实现一个德州扑克的游戏时,它会进入脑暴模式多次跟我对齐最终方案,过程中会提到很多我未曾考虑到的方面。并且每次 Feature 开发都会提前调研相关技术方案,并且给出相应的 trade-off。 这种"先探索再执行"的范式,避免了 AI 闷头写出一堆需要推翻的代码。

Playwright MCP / Browser Use

传统开发流程是:写代码 → 手动打开浏览器 → 看效果 → 截图反馈给 AI。有了 Playwright MCP,Claude 可以自己操控浏览器:打开页面、 创建房间、进入房间、开始游戏、截图验证。

最典型的例子——项目整个 README 的效果截图全是 Claude 自己截图并保存的。

这种"AI 自主验收"的能力大幅减少了沟通往返。

Context7 MCP

LLM 的训练数据有截止日期。当你用 Tailwind CSS v4(和 v3 配置方式完全不同)、LiveKit 最新 SDK、Hono.js 等较新的库时,AI 很容易写出过时的 API。

Context7 MCP 解决这个问题:它能实时拉取 npm 包的最新文档,让 Claude 基于当前版本生成代码。比如 Tailwind v4 不再需要 tailwind.config.js,直接在 CSS 里用 @theme 指令。又或者是 railway 的最新版本部署方式,通过 railway CLI 就帮我完成了部署。我记着前段时间还需要我手动创建 services,配合它才可以完成。


Vibe coding 过程记录

第一阶段:核心骨架

一句话起手:

帮我创建一个移动端德州扑克项目

Claude 使用 Superpowers 完成了 spec、plan 的编写,我确认后一口气生成了:

  • 完整的 monorepo 结构 + tsconfig
  • 共享类型(Card、PlayerInfo、RoomState、GameState)
  • WebSocket 协议定义(15+ 事件类型,全类型安全)
  • 基础的房间管理 + 游戏引擎

这里有个返工的情况,一开始 Claude 提供我前端渲染方案有 dom + css,pixiJS 等方案,我考虑性能问题没有听从它的建议让它采用 pixiJS。但随后问题出现,由于渲染是 Canvas, 导致 Claude 并不能很有效的进行自我测试,我对该技术栈也不熟悉,导致实现效果一般,后又让它基于 dom + css 帮我重新实现。

反思: 在确定技术方案的时候,最好采用自己熟悉的方式,这样在后续的开发中能更有效的进行沟通,适当时也可以看懂代码细节。尤其是 MVP 版本,需要快速迭代,而不是从一开始就想着炫技。

第二阶段:游戏引擎 + UI

这是工作量最大的阶段。德州扑克的规则看似简单,实际逻辑极其复杂:

  • 发牌顺序、盲注轮转、多轮下注
  • Side pot 计算(多人 All-In 时的边池)
  • 手牌评估(顺子、同花、葫芦……)

我的想法是不要从零实现,降低技术难度,提高 AI 开发效率。 手牌评估直接用 poker-evaluator 库(让 Claude 调研后推荐的)。

UI 交互方面,我根据我的想法,频繁让 AI 改动,但整体下来 AI 实现的还是无法复刻我的想法。索性我放弃了。因为这离 MVP 版本越来越远。后来我使用 stitch 进行了尝试,其中桌面效果和主题色都相当不错,我就将 html 代码复制交给了 AI 来复刻。再融合我的想法,最终看着还不错

第三阶段:用户系统 + AI 对手

在上一阶段,所有数据都在内存,用户数据也通过 localStorage 进行存储。这种方式显然做不到真正的多人联机,和金钱持久化。所以我让 AI 帮我实现了用户系统,并增加了 AI 对手系统,这样方便开发中进行多人游戏测试。

最后采取了 AI 推荐的建议:SQLite + JWT + bcrypt。对 AI 来说是常规操作,几乎一遍过。

第四阶段:语音聊天 + 移动端适配

随后我开始增加必不可少的语音功能,毕竟有语音才能跟朋友侃侃而谈,耍耍小心机。

移动端适配是踩坑最多的地方。微信 WebView 里的 CSS rotation 会导致触摸坐标系错乱——手指往右滑,滑块往左跑。Claude 分析出根本原因后,写了一个 RotationAwareSlider 组件,在检测到 CSS 旋转时把 clientY 映射到视觉横轴。

if (isRotated()) {
  // CSS 旋转 90° 后,视觉水平方向对应原始垂直坐标
  ratio = (clientY - rect.top) / rect.height
} else {
  ratio = (clientX - rect.left) / rect.width
}

这种平台特定的 hack,AI 的调试能力其实很强——它能系统性地分析坐标变换,而不是像人一样瞎猜。

第五阶段:性能优化 + 部署

随后我让 AI 帮忙进行了部署,拿到线上链接交给朋友一起体验,朋友第一次加载以为是访问不了,后来发现只是白屏时间过长,性能存在问题。所以我让 AI 帮忙分析了性能问题,并给出了优化方案。

我:现在访问会白屏很久,有什么优化空间?先不用改代码
Claude:[分析] 1. JS 包 728KB,livekit-client 占大头 2. Railway 冷启动 3. 单入口无分割
建议:代码分割 + loading 骨架屏,改动小效果明显
我:做吧

优化后首屏 JS 从 728KB 降到 200KB(-68%),白屏变成了即时 loading 动画。

部署到 Railway 也是 Claude 一手操办——写 Dockerfile、配 volume、railway up


吸取的一些经验

  1. 在这个过程中不是完全放手不管,而是要适当参与,适当给 AI 提供反馈。要在这个过程中不断思考和学习,有时候 AI 可能会一直错下去,这时可以直接终止,让它先去调研最佳实践,然后再反过来优化本项目。

  2. 过程中一些 AI 可能会提到一些新技术 和 新名词,这时候可以通过 Claude 的 /btw 命令来进行询问和学习,对话不会记录到整个上下文中,避免干扰。

  3. 不要带领 AI 钻进牛角尖,一些边界 case,交互可以等 MVP 版本完成后,再进行单独优化。一上来就追求完美,优化细节很容易使整体流程跑偏。

  4. 控制好上下文大小,上下文过大时模型会变得不稳定,当你完成一个较大的Feature时,可以通过 /compact 命令来压缩上下文后,再去实现下一个Feature

One More Thing

整个项目已开源,你也可以用一条 Claude Code 命令从零复刻:

claude --dangerously-skip-permissions -p "Build a full-stack multiplayer Texas Hold'em poker web game called 'ALL IN'..."

完整 prompt 见 README

如果这篇文章对你有帮助,欢迎 Star 仓库 ⭐️


本文项目地址:github.com/lhz960904/t…

在线体验:texas-holdem-production-c30c.up.railway.app

Go 语言协程

2026年4月6日 18:43

Go 语言协程(Goroutine)及其并发模型的深度指南。


第一部分:协程基础与生命周期控制

如何启动协程、主协程的特性以及最基本的同步工具。

package main

import (
"fmt"
"runtime"
"sync"
"time"
)

/**
 * 知识点 1-10: 基础定义与生命周期
 * 1. 使用 'go' 关键字即可启动一个协程。
 * 2. 协程是用户态轻量级线程,初始栈空间仅 2KB。
 * 3. 主协程 (Main Goroutine) 结束,所有子协程立即强制退出。
 * 4. 协程的执行顺序是随机的,由调度器决定。
 * 5. runtime.Gosched() 用于主动让出 CPU 时间片。
 * 6. runtime.Goexit() 立即终止当前协程,但会执行 defer。
 * 7. runtime.NumGoroutine() 获取当前运行中的协程数量。
 * 8. 闭包捕获问题:协程内访问外部循环变量需传参,否则会引用最终值。
 * 9. sync.WaitGroup 用于等待一组协程完成,是基础同步工具。
 * 10. WaitGroup 的 Add() 数量必须与 Done() 一致,否则会死锁或 Panic。
 */

func basicDemo() {
var wg sync.WaitGroup

// 演示闭包捕获陷阱与正确传参
for i := 0; i < 5; i++ {
wg.Add(1)
go func(id int) { // 必须通过参数传递 i
defer wg.Done()
fmt.Printf("子协程 %d 正在运行\n", id)
}(i)
}

wg.Wait()
fmt.Println("所有基础协程执行完毕")
}

func runtimeControl() {
go func() {
defer fmt.Println("协程退出前的清理工作")
fmt.Println("准备退出协程...")
runtime.Goexit() // 终止协程
fmt.Println("这行代码永远不会执行")
}()

time.Sleep(time.Millisecond * 100)
fmt.Printf("当前活跃协程数: %d\n", runtime.NumGoroutine())
}

func main() {
basicDemo()
runtimeControl()
}

第二部分:通道 (Channel) 深度解析

通道是协程间通信的桥梁,遵循“不要通过共享内存来通信,而要通过通信来共享内存”的哲学。

package main

import (
"fmt"
"time"
)

/**
 * 知识点 11-30: 通道机制
 * 11. 通道是线程安全的,底层自带锁。
 * 12. 无缓冲通道 (Unbuffered):发送和接收必须同时就绪,否则阻塞。
 * 13. 有缓冲通道 (Buffered):在容量范围内发送不阻塞。
 * 14. 关闭通道:close(ch)。重复关闭或关闭 nil 通道会 Panic。
 * 15. 向已关闭通道发送数据会 Panic。
 * 16. 从已关闭通道读取数据:返回零值和 false。
 * 17. 单向通道:chan<- 仅发送,<-chan 仅接收。常用于函数参数约束。
 * 18. select 语句:随机选择一个就绪的通道操作。
 * 19. select default 分支:实现非阻塞发送或接收。
 * 20. 通道可以用于实现信号量 (Semaphore)。
 * 21. range 遍历通道:直到通道被关闭且数据取完才结束。
 * 22. nil 通道的读写会永久阻塞。
 * 23. 内存泄漏:未关闭且无接收者的协程会永久阻塞在发送处。
 */

func channelPatterns() {
// 演示有缓冲通道
ch := make(chan string, 2)
ch <- "消息 1"
ch <- "消息 2"
fmt.Println("有缓冲通道已满,接下来的发送将阻塞")

// 演示 select 超时机制
timeoutCh := make(chan bool, 1)
go func() {
time.Sleep(time.Second * 2)
timeoutCh <- true
}()

select {
case msg := <-ch:
fmt.Println("收到:", msg)
case <-time.After(time.Second * 1):
fmt.Println("请求超时!")
}
}

func worker(id int, jobs <-chan int, results chan<- int) {
for j := range jobs {
fmt.Printf("工人 %d 开始处理任务 %d\n", id, j)
time.Sleep(time.Millisecond * 500)
results <- j * 2
}
}

func workerPoolDemo() {
const numJobs = 5
jobs := make(chan int, numJobs)
results := make(chan int, numJobs)

// 启动 3 个工人
for w := 1; w <= 3; w++ {
go worker(w, jobs, results)
}

// 发送任务
for j := 1; j <= numJobs; j++ {
jobs <- j
}
close(jobs) // 关闭任务通道,告知工人没有新任务了

// 收集结果
for a := 1; a <= numJobs; a++ {
<-results
}
fmt.Println("所有任务处理完成")
}

func main() {
channelPatterns()
workerPoolDemo()
}

第三部分:同步原语与锁 (sync 包)

当必须访问共享资源时,Go 提供了传统的锁机制。

package main

import (
"fmt"
"sync"
"sync/atomic"
)

/**
 * 知识点 31-50: 同步原语
 * 31. sync.Mutex:互斥锁,保护共享资源。
 * 32. 不要拷贝锁:锁被使用后拷贝会导致逻辑失效(Panic)。
 * 33. sync.RWMutex:读写锁。允许多个并发读,但写时互斥。
 * 34. RLock() 与 RUnlock():读锁操作。
 * 35. 性能对比:在读多写少的场景,RWMutex 优于 Mutex。
 * 36. sync.Once:确保函数只执行一次(常用于单例模式)。
 * 37. sync.Cond:条件变量,用于协程间的等待/通知机制。
 * 38. sync.Pool:对象池,减轻 GC 压力。
 * 39. sync.Map:并发安全 Map,优化了读写分离。
 * 40. 原子操作 (sync/atomic):利用 CPU 指令实现无锁并发,性能极高。
 */

type SafeCounter struct {
mu    sync.Mutex
v     map[string]int
}

func (c *SafeCounter) Inc(key string) {
c.mu.Lock()
// Lock 之后务必 defer Unlock,防止 Panic 导致死锁
defer c.mu.Unlock()
c.v[key]++
}

func atomicDemo() {
var count int64 = 0
var wg sync.WaitGroup

for i := 0; i < 1000; i++ {
wg.Add(1)
go func() {
defer wg.Done()
// 原子递增,无需加锁
atomic.AddInt64(&count, 1)
}()
}
wg.Wait()
fmt.Printf("原子计数结果: %d\n", count)
}

var (
instance *SafeCounter
once     sync.Once
)

func GetInstance() *SafeCounter {
once.Do(func() {
fmt.Println("首次初始化单例对象")
instance = &SafeCounter{v: make(map[string]int)}
})
return instance
}

func main() {
atomicDemo()
c := GetInstance()
c.Inc("hits")
fmt.Printf("计数器: %d\n", c.v["hits"])
}

第四部分:上下文控制 (Context Package)

Context 是管理协程树、超时控制和元数据传递的标准方式。

package main

import (
"context"
"fmt"
"time"
)

/**
 * 知识点 51-70: Context 模式
 * 51. Context 负责在协程树中传递取消信号、截止日期和键值。
 * 52. context.Background():根 Context,通常由 main 开启。
 * 53. context.WithCancel():返回可手动取消的 Context。
 * 54. context.WithTimeout():到达指定时间后自动取消。
 * 55. context.WithDeadline():到达某个时刻后自动取消。
 * 56. Done() 通道:当 Context 被取消时,该通道会被关闭。
 * 57. Err():返回取消的原因(Timeout 或 Canceled)。
 * 58. context.WithValue():传递请求作用域内的元数据(慎用,非类型安全)。
 * 59. 最佳实践:将 Context 作为函数的第一个参数传入,名为 ctx。
 * 60. 级联取消:父 Context 取消,所有子 Context 也会同步取消。
 */

func longRunningTask(ctx context.Context, name string) {
for {
select {
case <-ctx.Done():
fmt.Printf("任务 %s 被取消: %v\n", name, ctx.Err())
return
default:
fmt.Printf("任务 %s 正在处理中...\n", name)
time.Sleep(time.Millisecond * 300)
}
}
}

func main() {
// 演示超时控制
ctx, cancel := context.WithTimeout(context.Background(), time.Second*1)
defer cancel() // 释放资源

go longRunningTask(ctx, "Worker-1")

// 等待足够长的时间观察结果
time.Sleep(time.Second * 2)
fmt.Println("主程序退出")
}

第五部分:GMP 调度模型与高级进阶

这部分涉及 Go 运行时的底层逻辑和更高级的并发模式。

package main

import (
"fmt"
"runtime"
"sync"
)

/**
 * 知识点 71-100: GMP 模型与高级实践
 * 71. G (Goroutine):协程,保存任务状态。
 * 72. M (Machine):内核线程,负责执行代码。
 * 73. P (Processor):处理器,保存本地协程队列,连接 G 和 M。
 * 74. 调度策略:Work Stealing(任务窃取),从其他 P 偷取 G。
 * 75. 调度策略:Hand Off(接管),阻塞时 P 与 M 分离,寻找新 M。
 * 76. runtime.GOMAXPROCS():设置 P 的数量,默认为 CPU 核心数。
 * 77. 协程泄露:开启了协程但无法退出,导致内存持续增长。
 * 78. 并发安全检测:使用 'go run -race' 检查数据竞争。
 * 79. 生产者消费者模式:使用管道解耦数据产生和处理。
 * 80. 扇入 (Fan-in):多个管道汇聚到一个管道。
 * 81. 扇出 (Fan-out):一个任务分发到多个协程并行处理。
 * 82. 错误传播:在协程中使用特定的 Result 结构体传递 Error。
 * 83. 优雅退出:通过信号量或 Context 确保协程在关机前完成清理。
 * 84. 无锁编程:尽量使用原子操作或通道,避免锁竞争。
 * 85. 协程栈监控:使用 pprof 工具分析协程堆栈快照。
 */

// 扇入模式演示
func merge(cs ...<-chan int) <-chan int {
var wg sync.WaitGroup
out := make(chan int)

output := func(c <-chan int) {
for n := range c {
out <- n
}
wg.Done()
}

wg.Add(len(cs))
for _, c := range cs {
go output(c)
}

go func() {
wg.Wait()
close(out)
}()
return out
}

func main() {
// 设置最大并行核心数
runtime.GOMAXPROCS(runtime.NumCPU())

c1 := make(chan int, 1)
c2 := make(chan int, 1)
c1 <- 10
c2 <- 20
close(c1)
close(c2)

// 合并两个通道的数据
for n := range merge(c1, c2) {
fmt.Printf("从合并通道获取: %d\n", n)
}
}

核心知识点补充总结

  1. 并发安全检测:在开发过程中,务必使用 go test -race ./...。这是发现隐藏并发 Bug 的利器。
  2. 死锁预防:死锁通常发生在多个协程互相等待对方释放资源(通道或锁)。保持加锁顺序一致,或尽量使用 select 配备超时机制。
  3. Panic 处理:子协程内部如果发生 Panic 且未捕获(recover),会导致整个进程崩溃。在所有重要的长生命周期协程中,务必在开头 defer 一个 recover 函数。
  4. 避免全局变量:并发环境下,全局变量是万恶之源。尽可能通过参数传递或使用单例模式配合锁。
  5. 合理设置缓冲区:过大的缓冲区会掩盖下游处理能力不足的问题,导致系统“虚假健康”并在压力突增时崩溃。
昨天 — 2026年4月6日首页

苹果的罕见妥协:当高危漏洞遇上“拒升”潮 - 肘子的 Swift 周报 #130

作者 Fatbobman
2026年4月6日 22:00

对于 iOS 用户来说,最近或多或少都会看到与 Coruna、DarkSword 有关的高危漏洞消息。两个攻击链均采用水坑攻击的方式,攻击者无需受害者进行任何交互,仅需访问一个被植入恶意 iframe 的合法网站或加载恶意广告,即可触发完整的攻击链,在窃取资料后自动清理攻击痕迹。由于工具链利用的漏洞存在于 iOS 13 至 18.7 的绝大多数版本中,截止目前,已有上亿用户受到影响。

前端看go并发

2026年4月6日 18:02

Go 语言的 协程 (Goroutine) 和 JavaScript 的 Web Workers 都是为了处理并发任务,但它们在底层实现、资源消耗和通信方式上有本质区别。


1. 核心差异对比表

特性 Go 协程 (Goroutine) JS Web Workers
本质 用户态轻量级线程 (M:N 调度) 操作系统级线程 (1:1 映射)
内存消耗 极小 (初始约 2KB) 较大 (通常几 MB)
启动速度 极快 (纳秒级) 较慢 (需要启动独立环境)
通信方式 Channel (管道) 或 共享内存 postMessage (结构化克隆数据)
数据共享 可以共享 (通过指针/引用) 完全隔离 (无法直接操作主线程变量)
数量级 轻松开启 百万级 通常建议 不超过 CPU 核心数

2. Go 协程代码演示

Go 协程的特点是:极其简单、共享内存、通信高效

package main

import (
"fmt"
"time"
)

func task(id int, ch chan string) {
// 协程可以直接访问外部变量,也可以通过 channel 通信
result := fmt.Sprintf("任务 %d 完成", id)
ch <- result
}

func main() {
ch := make(chan string)

// 开启 1000 个协程几乎不占资源
for i := 0; i < 1000; i++ {
go task(i, ch) 
}

// 接收结果
for i := 0; i < 10; i++ {
fmt.Println(<-ch)
}
time.Sleep(time.Second)
}

3. Web Worker 代码演示

Web Worker 的特点是:完全隔离、环境独立、通信开销大

主线程 (main.js):

const worker = new Worker('worker.js');

// 只能通过发送消息通信
worker.postMessage({ id: 1 });

// 监听返回
worker.onmessage = function(e) {
    console.log('收到结果:', e.data.result);
};

工作线程 (worker.js):

onmessage = function(e) {
    // 这里无法访问主线程的 window, document 或任何变量
    const result = `任务 ${e.data.id} 完成`;
    postMessage({ result: result });
};

4. 深度区别详解

A. 内存与上下文切换

  • Go: 协程是协作式调度的。Go 运行时(Runtime)会管理成千上万个协程,并将它们映射到少量的系统线程上。切换协程只涉及少量寄存器的保存,代价极低。
  • JS: 每一个 Web Worker 都是一个真实的操作系统线程,拥有独立的内存空间、独立的 V8 实例。这意味着启动一个 Worker 的代价非常高,且它们之间切换由操作系统控制。

B. 数据通信(关键点)

  • Go: 遵循 “不要通过共享内存来通信,而要通过通信来共享内存” 的哲学。你可以通过 Channel 传递指针(高效),也可以加锁(Mutex)直接修改同一个变量。
  • JS: 遵循 “零共享”postMessage 传递数据时,浏览器会先对数据进行结构化克隆(Structured Clone),即深拷贝。如果你传一个 1GB 的对象,主线程和 Worker 都会占用 1GB 内存,且拷贝过程非常耗时。

C. 适用场景

  • Go 协程: 几乎所有高并发场景。高并发 Web 服务器、微服务、大规模爬虫、实时推送系统。
  • Web Worker: 计算密集型任务。例如在浏览器中处理超大图片、加解密、复杂物理计算、视频转码。它存在的意义是不让耗时计算卡死主线程(UI 渲染)。

总结建议

  • 如果你追求 海量任务、极速响应,Go 的协程是绝对的王者。
  • 如果你在浏览器中为了 不让页面卡顿 而处理耗时逻辑,Web Worker 是唯一的选择。
  • 在 Node.js 服务端,如果需要类似 Go 的并发,通常使用 worker_threads 模块,它的行为更接近 Web Worker,依然是基于线程隔离的。

go 并发 并行 异步

2026年4月6日 17:48

在 Go 语言中,理解 并发 (Concurrency)并行 (Parallelism)异步 (Asynchrony) 的区别是进阶的关键。Go 的设计哲学深受这些概念的影响。

1. 核心概念对比 (Analogy)

我们可以用“咖啡馆”来做类比:

概念 类比场景 关注点
并发 (Concurrency) 一个服务员同时为多桌客人服务。他在 A 桌点完菜,不等菜上桌,就去 B 桌倒水。他是在处理多件事,但某一瞬间只能做一件事。 结构 (Structure):如何组织代码以处理多个任务。
并行 (Parallelism) 多个服务员同时工作。服务员 A 在给 A 桌点菜,服务员 B 同时在给 B 桌倒水。他们在执行多件事。 执行 (Execution):在多核 CPU 上同时运行。
异步 (Asynchrony) 客人点完餐后拿到一个取餐号,然后回座位玩手机。等厨房做好了,会通过广播(回调/信号)通知他。 非阻塞 (Non-blocking):发起请求后立即返回,不原地等待结果。

2. Go 语言中的实现

A. 并发 (Concurrency) —— Go 的强项

Go 通过 Goroutine (协程) 实现并发。Go 的口号是:“不要通过共享内存来通信,而要通过通信来共享内存。” 并发是 Go 程序的设计属性。即使在单核 CPU 上,你也可以开启 100 万个协程。

B. 并行 (Parallelism) —— 硬件支撑

Go 运行时(Runtime)会自动将并发的协程调度到多个系统线程上。如果你的电脑有多个 CPU 核心,Go 就会自动实现并行。 你可以通过 runtime.GOMAXPROCS(n) 来限制并行使用的核心数。

C. 异步 (Asynchrony) —— “伪同步”写法

在 Node.js 中,异步通常通过 callback, Promise, async/await 实现。 在 Go 中,异步逻辑是用同步的方式写的。当你发起一个网络请求时,当前的协程会“阻塞”,但 Go 运行时的底层其实是异步非阻塞的(使用 epoll/kqueue),它会自动把 CPU 让给其他协程。


3. 代码演示与详解

package main

import (
"fmt"
"runtime"
"sync"
"time"
)

func task(name string, wg *sync.WaitGroup) {
defer wg.Done()
for i := 1; i <= 3; i++ {
fmt.Printf("任务 %s: 正在处理第 %d 步\n", name, i)
// 模拟耗时操作(这里会触发协程切换,体现并发)
time.Sleep(time.Millisecond * 100)
}
}

func main() {
// 1. 并行度设置:查看当前系统的 CPU 核心数
cpuCores := runtime.NumCPU()
fmt.Printf("系统核心数: %d\n", cpuCores)
    
// 2. 这里的 WaitGroup 用于同步等待所有协程完成(类似于 Promise.all)
var wg sync.WaitGroup

fmt.Println("--- 程序开始运行 ---")

// 3. 启动两个并发任务
wg.Add(2)
go task("A", &wg) // 开启协程 A
go task("B", &wg) // 开启协程 B

// 这里的代码继续执行,体现了“异步”发起的特性
fmt.Println("主线程:我已经下达了任务,现在我去忙别的了...")

wg.Wait() // 阻塞等待 A 和 B 完成
fmt.Println("--- 所有任务完成 ---")
}

4. 深度对比:Go vs Node.js

特性 Go 语言 Node.js (JavaScript)
模型 CSP (通信顺序进程) Event Loop (事件循环)
线程 多线程 (M:N 调度) 单线程 (通过异步 I/O 模拟并发)
阻塞感 看起来是同步阻塞的,实则异步。代码顺序执行,逻辑清晰。 必须使用 await 或回调,否则会产生异步副作用。
复杂任务 擅长 CPU 密集型 + I/O 密集型。 擅长 I/O 密集型,CPU 密集型会阻塞事件循环。

总结:如何理解?

  1. 并发是逻辑上的:你在代码里写了 go func(),你的程序就具备了并发处理的能力(结构)。
  2. 并行是物理上的:当你的程序运行在多核机器上,Go 自动让这些 go func() 在不同的核心上同时跑(效率)。
  3. 异步是体验上的:在 Go 里,你不需要写复杂的 thencallback。Go 让你用最简单的同步代码,享受高性能的异步底层。

一句话:Go 的伟大之处在于,它用并发(协程)的简单模型,完美利用了并行的硬件能力,并屏蔽了异步编程的复杂性。

科氪 | 荣耀与京东签订战略合作协议 推进AI、机器人、C2M共创合作

2026年4月6日 17:48

4月2日,荣耀与京东签订战略合作协议,正式建立全方位战略合作伙伴关系,双方将围绕产品共创、用户共营、生态共享三大核心领域,构建全面覆盖、深度融合、价值共生的新型合作体系,致力于实现三年累计规模超1000亿元的全领域合作目标。

官方图片

产品共创方面,荣耀与京东将围绕手机、全场景、AIoT、机器人等各领域产品的全生命周期进行深度协作。双方将推进战略新品首发合作,共同打造行业爆品,基于各自优势,联合开展IP与C2M定制项目,推动行业级创新。双方将针对外卖骑手、快递员、游戏玩家等特定用户人群进行产品共创,将荣耀的软硬件定制能力与京东的用户洞察有机结合,打造更多基于场景的产品亮点,同时,双方将协同进行产品的生命周期管理,不断提升合作规模。

用户共营方面,荣耀与京东将整合全链路营销能力与资源,通过联合会员运营、精准人群触达等,为用户提供超预期的焕新体验。同时,双方将在电竞、运动健康等核心场景展开深度合作,探索数据赋能与广告创新的更多可能。

生态共享方面,荣耀与京东将在更广阔的生态领域加深战略合作,共同探索新增长曲线。双方将携手推动AI合作共创与用户体验提升,基于荣耀领先的端侧大模型能力与京东的高质量AI服务、JoyAI大模型和JoyInside等AI生态,共同打造商品导购、生活服务、金融理财等场景的创新体验,并围绕机器人和智能硬件生态领域展开合作,例如,京东线下门店将试点部署荣耀机器人用于引流导购。双方还将深化全渠道与O2O协作,共同提升即时零售业务,依托荣耀终端产品和京东Joybuy平台,携手拓展海外市场,促进国内外物流仓储合作,并在科技、金融、保险等领域进一步加强合作。

作为全球领先的AI终端生态公司,荣耀致力于通过开放、共创、共享不断拓展产业边界,与合作伙伴携手构筑智慧生态,共建智慧世界。此次战略合作中,荣耀与京东将锚定关键业务领域,突破固有限制与瓶颈,共同推动双方业务的实质性、跨越式增长,为全球消费者打造更加极致的产品与服务。

htop Cheatsheet

Basic Usage

Start htop and limit the view when needed.

Command Description
htop Start htop with the default interactive view
htop -u username Show only processes owned by one user
htop -p 1234,5678 Monitor only the specified PIDs
htop -t Start in tree view
sudo htop Run with elevated privileges to manage more processes

Navigation and Search

Move around the process list and find what you need quickly.

Key Description
Arrow keys Move up and down through processes
Page Up / Page Down Scroll one page at a time
Home / End Jump to the top or bottom of the list
F3 or / Search for a process by name
F4 or \\ Filter the process list
Space Tag or untag the selected process
U Clear all tags

Sorting and Views

Change how processes are grouped and sorted.

Key / Command Description
P Sort by CPU usage
M Sort by memory usage
T Sort by running time
F5 Toggle tree view
F6 Choose a sort column
htop -s PERCENT_MEM Start sorted by memory usage
H Toggle display of user threads
K Toggle display of kernel threads

Process Actions

Manage processes directly from inside htop.

Key Description
F7 Decrease nice value (raise priority)
F8 Increase nice value (lower priority)
F9 Send a signal to the selected process
15 SIGTERM Ask a process to exit cleanly
9 SIGKILL Force a process to stop immediately
2 SIGINT Interrupt a process, similar to Ctrl+C
q or F10 Quit htop

Startup Options

Useful options for changing the initial view.

Command Description
htop -d 20 Refresh every 2 seconds
htop -C Use monochrome mode
htop -H Highlight new and old processes
htop --readonly Disable process-kill and renice actions
htop --sort-key PERCENT_CPU Start sorted by CPU usage

Customization

Adjust the display and save the layout.

Key / Path Description
F2 Open the setup menu
Columns Add, remove, or reorder process columns
Meters Change header meters and display style
Display options Toggle tree lines, thread names, and other UI settings
~/.config/htop/htoprc Configuration file where settings are saved

Troubleshooting

Quick checks for common htop issues.

Issue Check
htop: command not found Install htop with apt or dnf first
Cannot renice a process Run htop with sudo to change priorities for other users’ processes
Cannot kill a process Confirm you have permission, then use F9 with SIGTERM first
Process list is too noisy Use F4 to filter or start with -u USER
Fast processes disappear Lower the update interval with -d

Related Guides

Use these guides for the full walkthroughs.

Guide Description
htop Command in Linux Full htop guide with examples
top Command in Linux Monitor processes in real time with top
ps Command in Linux List and inspect processes
kill Command in Linux Send signals to processes by PID
pstree Command in Linux View parent and child process relationships

htop Command in Linux: Monitor Processes Interactively

When a server starts responding slowly or a desktop session feels sluggish, you need to figure out which process is consuming the most CPU or memory. The top command can do this, but its interface is minimal and navigation takes some getting used to. htop is an interactive process viewer that improves on top with color-coded meters, mouse support, and the ability to scroll, search, filter, and kill processes without leaving the viewer.

This guide explains how to install and use htop to monitor system resources and manage processes on Linux.

Installing htop

htop is available in the default repositories of most Linux distributions but is not always pre-installed.

On Ubuntu, Debian, and Derivatives:

Terminal
sudo apt install htop

On Fedora, RHEL, and Derivatives:

Terminal
sudo dnf install htop

Verify the installation by checking the version:

Terminal
htop --version
output
htop 3.4.1

htop Syntax

txt
htop [OPTIONS]

Running htop without arguments opens the interactive process viewer with default settings:

Terminal
htop

Understanding the Interface

The htop screen is divided into three areas: a header with system meters, a process list in the center, and a footer with function key shortcuts.

Header Area

The top section shows system-wide resource usage at a glance:

  • CPU bars: one bar per CPU core, color-coded by usage type. Green is normal user processes, red is kernel (system) activity, blue is low-priority (nice) processes, and cyan is virtualization overhead (steal time)
  • Memory bar: shows used, buffered, and cached memory as a proportion of total RAM. Green is memory in use by applications, blue is buffers, and yellow is file cache
  • Swap bar: shows swap usage. If this bar is consistently full, the system does not have enough physical memory for its workload
  • Tasks: total number of processes and threads, with a count of how many are currently running
  • Load average: the 1-minute, 5-minute, and 15-minute system load averages
  • Uptime: how long the system has been running since the last boot

Process List

Below the header, each row represents one process. The default columns are:

  • PID - process ID
  • USER - the owner of the process
  • PRI - kernel scheduling priority
  • NI - nice value (user-space priority, ranges from -20 to 19)
  • VIRT - total virtual memory the process has allocated
  • RES - resident memory, the portion of physical RAM the process is actually using
  • SHR - shared memory, the portion of RES that is shared with other processes (such as shared libraries)
  • S - process state (R running, S sleeping, D uninterruptible sleep, Z zombie, T stopped)
  • CPU% - percentage of CPU time the process is using
  • MEM% - percentage of physical memory the process is using
  • TIME+ - total CPU time consumed since the process started
  • Command - the full command line that launched the process

Function Keys

The bottom bar shows the available actions:

  • F1 - open the help screen
  • F2 - open the setup menu to customize meters and columns
  • F3 - search for a process by name
  • F4 - filter the process list to show only matching entries
  • F5 - toggle tree view
  • F6 - choose a column to sort by
  • F7 - decrease the nice value (higher priority) of the selected process
  • F8 - increase the nice value (lower priority) of the selected process
  • F9 - send a signal to the selected process
  • F10 - quit htop

Sorting Processes

By default, htop sorts processes by CPU usage, so the heaviest processes float to the top. To change the sort column, press F6 and select a column from the list using the arrow keys.

For quick sorting without opening the menu, use these shortcut keys:

  • P - sort by CPU%
  • M - sort by MEM%
  • T - sort by TIME+

Press the same key again to reverse the sort order. This is useful when you want to find the least active processes or the ones that started most recently.

You can also set the initial sort column from the command line:

Terminal
htop -s PERCENT_MEM

This starts htop with the process list sorted by memory usage, which is handy when you are investigating high memory consumption on a server.

Searching for a Process

Press F3 (or /) to open the search bar at the bottom of the screen. Type part of the process name and htop will highlight the first matching entry in the process list. Press F3 again to jump to the next match.

The search is incremental, so the highlight updates as you type each character. Press Esc to close the search bar and return to normal navigation.

Filtering Processes

Press F4 to activate the filter. Unlike search, which jumps between matches, filtering hides all processes that do not match the text you type. Only matching entries remain visible in the list.

This is especially useful on busy systems with hundreds of running processes. For example, typing postgres after pressing F4 reduces the list to only PostgreSQL worker processes and the postmaster, making it much easier to see their combined resource usage.

Press Esc to clear the filter and restore the full process list.

Tree View

Press F5 to toggle tree view. In this mode, htop groups child processes under their parent and displays the process hierarchy as an indented tree. This makes it straightforward to see which processes were spawned by a service manager, a shell session, or a container runtime.

To start htop in tree view directly from the command line:

Terminal
htop -t

Tree view combines well with filtering. Press F4, type a service name, and the tree shows only that service and its child processes. For a dedicated look at process hierarchies outside of htop, see the pstree command .

Killing a Process

To stop a process from within htop, use the arrow keys to highlight it (or search with F3), then press F9. This opens a signal selection menu on the left side of the screen.

The most commonly used signals are:

  • 15 SIGTERM - asks the process to shut down gracefully. This is the default and the safest first choice
  • 9 SIGKILL - forces the process to terminate immediately. Use this only when SIGTERM does not work, because the process gets no chance to clean up
  • 2 SIGINT - the same signal sent by pressing Ctrl+C in a terminal
  • 1 SIGHUP - often used to tell a daemon to reload its configuration without restarting

Select the signal with the arrow keys and press Enter to send it. For more detail on process signals and how to send them from the command line, see the kill command guide .

Warning
SIGKILL bypasses all cleanup routines. Files and sockets may be left in an inconsistent state. Always try SIGTERM first and wait a few seconds before escalating to SIGKILL.

You can also tag multiple processes with Space and then press F9 to send a signal to all of them at once. Press U to untag all processes when you are done.

Changing Process Priority

You can adjust the scheduling priority (nice value) of a process directly from htop. Select the process and press:

  • F7 - decrease the nice value (give the process higher priority)
  • F8 - increase the nice value (give the process lower priority)

Nice values range from -20 (highest priority) to 19 (lowest priority). Only root can set negative nice values, so you will need to run htop with sudo to raise a process above normal priority.

This is useful when a background task like a large compilation is consuming too much CPU and you want to lower its priority so that interactive services remain responsive.

Showing Only One User’s Processes

To limit the process list to a single user, start htop with the -u option:

Terminal
htop -u www-data

This shows only processes owned by www-data, which is useful when you are debugging a web server or an application service and do not want system processes cluttering the view.

Monitoring Specific Processes

To watch a known set of processes by their PIDs, use the -p option:

Terminal
htop -p 1234,5678

The display is restricted to those two processes, but the header meters still show system-wide resource usage. This gives you a focused view while keeping overall load visible at the top.

Customizing the Display

Press F2 to open the setup screen. From here you can:

  • Rearrange the header meters (move CPU bars, swap positions, switch between bar, text, graph, or LED display styles)
  • Add or remove columns in the process list
  • Change the color scheme
  • Toggle display options like showing kernel threads or custom thread names

Changes are saved to ~/.config/htop/htoprc and persist across sessions.

Command-Line Options

  • -d N - set the update interval to N tenths of a second. For example, -d 20 updates every 2 seconds instead of the default 1.5 seconds
  • -u USER - show only processes belonging to USER
  • -p PID[,PID...] - show only the specified process IDs
  • -t - start in tree view
  • -s COLUMN - sort by the given column name (use names like PERCENT_CPU, PERCENT_MEM, TIME)
  • -C - use monochrome mode (no colors), useful on terminals with limited color support
  • -H - highlight new and old processes

Quick Reference

For a printable quick reference, see the htop cheatsheet .

Key / Command Action
F1 Help
F2 Setup (customize meters and columns)
F3 or / Search for a process
F4 Filter the process list
F5 Toggle tree view
F6 Choose sort column
F7 / F8 Decrease / increase nice value
F9 Send a signal to the selected process
F10 or q Quit
P Sort by CPU%
M Sort by MEM%
T Sort by TIME+
Space Tag a process
U Untag all processes
htop -u USER Show only one user’s processes
htop -p PID,PID Monitor specific PIDs
htop -t Start in tree view
htop -d 20 Update every 2 seconds
htop -s PERCENT_MEM Sort by memory usage

Troubleshooting

htop: command not found
htop is not installed by default on every distribution. Install it with your package manager: sudo apt install htop on Debian-based systems or sudo dnf install htop on Fedora and RHEL.

Cannot change process priority (permission denied)
Setting a nice value below 0 requires root privileges. Run htop with sudo to adjust priority for processes owned by other users or to set negative nice values.

CPU bars show unexpected colors
Each color represents a different type of CPU usage. Green is normal user processes, red is kernel activity, blue is low-priority (nice) processes, and cyan is virtualization steal time. Press F1 inside htop to see the full color legend for your version.

Memory bar looks full but the system is responsive
Linux uses free memory for disk cache and buffers. The memory bar in htop distinguishes between application memory (green), buffers (blue), and cache (yellow). Cached memory is released to applications when they need it, so a full-looking bar does not mean the system is out of memory.

Processes appear and disappear quickly
Short-lived processes can start and exit between screen refreshes. Lower the update interval with -d 5 (half a second) to catch fast processes. Keep in mind that a very short interval increases the CPU usage of htop itself.

FAQ

What is the difference between htop and top?
Both show running processes and system metrics in real time. htop adds color-coded CPU and memory meters, mouse support, horizontal and vertical scrolling, built-in search and filtering, and the ability to kill or renice processes without typing a PID. The top command is pre-installed on virtually every Linux system, while htop may need to be installed separately.

Does htop use more resources than top?
Slightly. htop reads additional process details from /proc, so it uses a bit more CPU and memory than top. On modern hardware the difference is negligible, even on systems with thousands of processes.

What do VIRT, RES, and SHR mean?
VIRT is the total virtual memory the process has mapped, including memory it has allocated but may not be using yet. RES (Resident) is the portion actually held in physical RAM. SHR (Shared) is the subset of RES that is shared with other processes, such as shared libraries loaded by multiple programs.

How do I save my htop configuration?
Press F2 to open the setup screen, make your changes, and press F10 to exit. htop saves the configuration automatically to ~/.config/htop/htoprc.

Can I run htop over SSH?
Yes. htop works in any terminal emulator, including SSH sessions. If you are monitoring a remote server over a long session, consider running htop inside screen or tmux so the session persists if the connection drops.

Conclusion

htop gives you a clear, interactive view of what is running on your system and the resources each process is consuming. For related tools, see the ps command for snapshot process listings, kill for sending signals from the command line, and pstree for visualizing the process hierarchy.

❌
❌