lin

如何判断 AI 生成的代码是可靠的？会从类型、测试、边界条件、性能、安全哪些维度检查？

Mon, 20 Apr 2026 10:23:02 GMT

判断 AI 生成的代码是否可靠：别只看“能跑”，要看“扛不扛打”

一段代码的可靠性，从来不是靠“看起来挺像那么回事”来判断。
真正有分量的标准，通常只有五个字：出了事没崩。

很多 AI 生成代码，第一眼都很顺眼：

命名像样
结构工整
注释完整
主流程还能跑通

问题也恰恰出在这里。
“像代码” 和 “可靠”，中间隔着很远。

判断时，通常会按 5 个核心维度过一遍：

| 维度 | 重点看什么 | 最危险的信号 | | --- | --- | --- | | 类型 | 约束是否清楚 | try?、强解包、魔法字符串满天飞 | | 测试 | 是否真能防回归 | 只测 happy path | | 边界条件 | 异常情况会不会碎 | 空数据、重复点击、失败回滚没处理 | | 性能 | 主路径是否流畅 | 主线程重活、无意义重绘、任务不取消 | | 安全 | 数据和权限是否守住 | 敏感日志、硬编码、输入不校验 |

1. 类型：代码是在表达约束，还是在逃避约束

类型系统最重要的作用，不是“让编译通过”，而是提前限制错误的发生方式。

可靠的代码，通常会有这些特征：

状态清楚，互斥场景用 enum
模型明确，不靠松散字典拼数据
Optional 被认真处理，不靠 ! 硬冲过去
错误有语义，不是随手吞掉
异步代码遵守线程和 actor 语义

最该警惕的几种写法：

到处都是 String、Any、布尔开关
try? 一路吞错，失败像没发生过
if a && !b && c 这种布尔组合在驱动复杂状态
UI 更新和后台任务混在一起

一句话总结：
类型越精确，运行时踩雷的概率越低。

2. 测试：不是看跑了多少，而是看挡不挡得住回归

很多 AI 代码的问题，不是完全没有测试，而是测试只覆盖了最顺的那条路。

例如这种情况就很常见：

页面能打开
按钮能点
提交能成功
测试一片绿色

但下面这些没测：

空数据
重复提交
网络失败
本地保存失败
页面切走时任务取消
旧数据迁移
删除后恢复

真正有价值的测试，通常要覆盖：

正常路径
异常路径
空状态
loading 状态
权限变化
并发触发
回归场景

还有一个很实用的判断标准：

测试是在验证“结果”，还是只是在验证“某个方法被调用过”？

如果只断言某个函数被调过一次，这类测试通常很热闹，但防不住真实问题。

可靠的测试，最好具备两个特点：

稳定：不靠 sleep、不靠真实网络、不靠运气
有针对性：改了什么风险，就测什么风险

3. 边界条件：真正拉开差距的地方

AI 最擅长生成 happy path。
真正决定质量下限的，往往是边界条件。

一段代码是否可靠，至少要问完这些问题：

输入为空怎么办
字段缺失怎么办
数据损坏怎么办
第一次启动怎么办
权限被拒绝怎么办
用户连续点击怎么办
任务还没结束，页面已经退出怎么办
删除失败怎么办
磁盘写满怎么办
同步冲突怎么办
应用进后台再回来怎么办

尤其是数据类产品，边界条件不是附属问题，而是主战场。

比如日记、笔记、清单这类应用，最怕的不是界面偶尔抖一下，而是下面这些：

误删
覆盖失败
自动保存丢失
迁移损坏
恢复不完整

真正可靠的代码，不是“尽量别出错”，而是：

出错时也有明确行为，失败时也能被看见。

4. 性能：不卡，不等于性能没问题

性能问题最容易被忽略，因为很多时候功能确实“能用”。

但“能用”和“顺手”中间，也隔着好几层体验差距。

常见风险点通常有这些：

主线程做 IO、解析、图片处理、排序
SwiftUI 状态设计粗糙，导致整棵树反复刷新
列表没有稳定 identity
搜索输入不做节流
异步任务到处开，不取消
缓存只加不清
动画过重，拖慢滚动和输入

性能判断，不能只看代码长什么样，还得看运行时表现：

首屏是否慢
输入是否跟手
列表是否掉帧
页面切换是否发闷
后台任务是否空转
发热和耗电是否异常

如果是 iOS UI 改动，最稳妥的证据通常是：

模拟器真实交互
截图或录屏
必要时加日志或 Instruments

5. 安全：功能完成，不代表边界安全

AI 写代码时，很容易把“跑通功能”放在第一位，然后把安全问题留在角落。

最常见的坑有这些：

敏感信息打印进日志
token、路径、用户内容被硬编码或暴露
导出、分享、文件访问边界不清楚
外部输入不校验
错误提示暴露内部实现
权限申请过度，解释不足

尤其是内容类应用，下面这些都属于敏感数据：

文本内容
搜索词
时间信息
文件路径
导出记录
同步状态

真正可靠的代码，在安全上通常有两个特点：

默认保守，不默认放开
出错时不泄露不该泄露的东西

6. 最后补一刀：结构能不能撑住下一次修改

有些 AI 代码第一次看不差，第二次改就开始崩。
问题不一定出在功能上，而是出在结构上。

典型信号包括：

View 里塞业务逻辑
ViewModel 里塞持久化
Repository 里塞展示格式化
一个文件越来越大，什么都往里加
复制第三份相似逻辑，而不是抽共用部分

可靠的代码，不只是“当前能跑”，还要满足：

职责边界清楚
后续修改不容易误伤
问题出现时好定位
不会因为小改动把整个模块带乱

这部分不一定立刻炸，但一定会影响长期稳定性。

一份简单的检查清单

看到一段 AI 生成代码时，快速扫这一遍，基本就能判断个八九不离十：

能否完整 build，通过后是否没有新增 warning
类型是否准确表达状态，而不是一堆布尔拼逻辑
是否存在强解包、静默失败、魔法字符串
是否补了针对本次改动的回归测试
是否覆盖异常路径和空状态
边界条件是否被明确处理
主线程是否做了不该做的事
UI 是否可能因为状态变化被过度刷新
是否存在敏感日志、硬编码、输入不校验
文件职责是否仍然清楚，是否新增了新的大而全类型

结尾

判断 AI 代码是否可靠，核心从来不是“像不像专业工程师写的”，而是下面这句话：

类型能不能拦错，测试能不能兜底，边界会不会碎，性能会不会掉，安全会不会漏。

tmux 使用指南

Fri, 27 Mar 2026 16:46:59 GMT

核心定位

终端复用工具，核心解决两大痛点：终端关闭/SSH断开后任务不中断、单终端内多工作区/分屏管理。

一、核心层级概念

| 层级 | 核心说明 | |------|----------| | Session（会话） | 最高级独立工作环境，对应一个完整项目/任务 | | Window（窗口） | 会话内的标签页，一个会话可创建多个 | | Pane（面板） | 窗口内的分屏区域，一个窗口可切分多个 |

二、安装

Mac（Homebrew）：brew install tmux
Linux/WSL（Debian/Ubuntu）：sudo apt update && sudo apt install tmux

三、快捷键规则

所有快捷键需先按前缀键（默认 Ctrl+b），松手后再按功能键。

推荐修改为 Ctrl+a（操作更顺手），修改方法见配置章节。

四、高频命令&快捷键

会话管理（核心）

| 操作 | 终端命令（会话外执行） | 快捷键（会话内） | |------|------------------------|------------------| | 新建命名会话 | tmux new -s <会话名> | - | | 查看所有会话 | tmux ls | Ctrl+b s（可视化切换） | | 恢复指定会话 | tmux attach -t <会话名> | - | | 后台分离会话（任务保留） | - | Ctrl+b d | | 重命名当前会话 | - | Ctrl+b $ | | 关闭指定会话 | tmux kill-session -t <会话名> | - |

窗口管理

| 操作 | 快捷键 | |------|--------| | 新建窗口 | Ctrl+b c | | 关闭当前窗口 | Ctrl+b & | | 切换上/下一个窗口 | Ctrl+b p / Ctrl+b n | | 按数字切换窗口 | Ctrl+b <0-9> | | 重命名当前窗口 | Ctrl+b , |

面板（分屏）管理

| 操作 | 快捷键 | |------|--------| | 垂直左右分屏 | Ctrl+b % | | 水平上下分屏 | Ctrl+b " | | 切换面板 | Ctrl+b <方向键> | | 关闭当前面板 | Ctrl+b x | | 面板临时全屏/还原 | Ctrl+b z | | 调整面板大小 | Ctrl+b Ctrl+<方向键> |

复制粘贴

| 操作 | 快捷键/步骤 | |------|-------------| | 进入复制模式（可滚动） | Ctrl+b [ | | 复制内容 | 空格开始选择，回车完成复制 | | 粘贴内容 | Ctrl+b ] | | 退出复制模式 | q |

五、极简必用配置

编辑配置文件 nano ~/.tmux.conf，粘贴以下内容，保存后执行 tmux source ~/.tmux.conf 生效。

# 1. 修改前缀为 Ctrl+a（可选，保留默认则注释掉）
unbind C-b
set -g prefix C-a
bind C-a send-prefix

# 2. 必开：鼠标支持（点击切换分屏、滚轮滚动、拖动调整大小）
set -g mouse on

# 3. 窗口/面板编号从1开始（默认0，操作更顺手）
set -g base-index 1
setw -g pane-base-index 1

# 4. 256色终端支持
set -g default-terminal "screen-256color"

# 5. 快捷键重载配置（前缀+r 一键生效）
bind r source-file ~/.tmux.conf \; display-message "配置重载成功"

六、TPM 插件管理（极简）

TPM 是 Tmux 官方插件管理器，一键安装/更新插件。

1. 安装

git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm

2. 配置

在 ~/.tmux.conf 最底部添加：

# TPM 插件列表
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-sensible'
# 按需添加插件，例：set -g @plugin 'tmux-plugins/tmux-resurrect'

# TPM 初始化（必须放在文件最底部）
run '~/.tmux/plugins/tpm/tpm'

3. 核心快捷键

| 快捷键 | 功能 | |--------|------| | Ctrl+b I | 安装新增的插件 | | Ctrl+b U | 更新所有插件 | | Ctrl+b Alt+u | 卸载已删除配置的插件 |

4. 高频推荐插件

tmux-resurrect：手动保存/恢复会话，重启电脑也能还原工作现场
tmux-continuum：配合 resurrect 实现会话自动保存、开机恢复
tmux-yank：Tmux 复制内容同步到系统剪贴板

七、新手极简工作流

新建项目会话：tmux new -s dev
新建窗口/分屏：Ctrl+b c 建窗口，Ctrl+b %/" 分屏
临时离开：Ctrl+b d 分离会话，任务后台持续运行
恢复工作：tmux attach -t dev 一键还原所有工作现场

常用skill

Thu, 26 Mar 2026 20:50:18 GMT

核心协作与任务执行

using-superpowers：在每轮任务开始时检查并调用合适的 skill
writing-plans：把多步骤任务写成清晰的实施计划
executing-plans：按已有计划执行，并在关键点做检查
dispatching-parallel-agents：把可并行的独立任务分发给多个 agent
subagent-driven-development：在当前会话里用子 agent 协同开发
verification-before-completion：宣称完成前先做验证
self-improving-agent：复盘对话和执行质量，优化代理表现

创意与产品规划

brainstorming：结构化头脑风暴，用于想点子、命名、产品方向、功能取舍、创意发散与收敛

前端开发与工程化

frontend-design：做高质量前端界面设计与实现，适用于网页、落地页、仪表盘、组件、美化现有 UI
vervel-react-best-practices：React / Next.js 最佳实践、性能和渲染优化
test-driven-development：功能或修复先写测试再实现

自动化与浏览器操作

playwright：用真实浏览器自动化执行页面操作、截图、抓取信息、调试前端流程
Agent Browser：通过结构化浏览器 CLI 导航、点击、输入、抓取页面

GitHub 与 CI/CD

github：处理 GitHub 仓库、PR、issue、review、Actions
gh-fix-ci：排查并修复 GitHub Actions / PR checks 失败
using-git-worktrees：为新任务创建隔离的 git worktree

信息处理与搜索

tavily-search：用 Tavily 做网页搜索和结果提取
summarize：总结文本、日志、文档、会议记录

Skill 管理与开发

skill-vetting：安装前审查 skill 的安全性和可信度
skill-creator：创建或改进新的 skill
writing-skills：编写、编辑、验证 skills

如何写一个 skill

Fri, 20 Mar 2026 22:01:25 GMT

Skill 是什么

skill 可以理解成一组可复用的能力说明。
它通常包含一份主文档 SKILL.md，再按需要带上脚本、参考资料和素材文件。

它适合解决这几类问题：

某类任务有固定流程
某些操作容易出错，最好约束做法
有一批上下文知识，每次重复解释太浪费
需要配套脚本、模板或资源文件

不适合做这几类东西：

一次性方案
项目私有约定
纯靠代码校验就能解决的问题
大而空的“方法论文档”

一个 skill 的最小结构

my-skill/
├── SKILL.md
├── agents/
│   └── openai.yaml
├── scripts/
├── references/
└── assets/

说明：

SKILL.md 是必须的
agents/openai.yaml 建议加，方便在界面里展示
scripts/ 放脚本
references/ 放长文档、规范、接口说明
assets/ 放模板、图标、字体、样例文件

不是每个 skill 都要把这些目录建全。
没有就不要建。

写之前先把边界定清楚

先回答四个问题：

这个 skill 到底解决什么问题
什么情况下应该触发它
什么情况下不该触发它
它需要哪些配套资源

如果这四个问题说不清，先别写正文。

`SKILL.md` 怎么写

1. Frontmatter 只放必要信息

最少保留两个字段：

---
name: editor-studio-ui
description: Use when designing or refining editor-style content studio interfaces, including workspace layout, panels, toolbars, editing flows, and implementation details.
---

要求很简单：

name 用小写加连字符
description 重点写“什么时候用”
不要把完整流程塞进 description
让它覆盖真实会出现的任务词、场景词、文件词

description 决定这个 skill 会不会被选中。
这部分比正文更重要。

2. 正文别写成废话

正文建议写成下面这种结构：

# Editor Studio UI

## Overview

用于设计和实现编辑器工作台类界面，重点处理布局、信息层级、主操作区和侧边面板。

## Workflow

1. 先看现有产品结构，不要直接推翻。
2. 先定主区域、侧栏、工具条，再谈视觉。
3. 优先保证操作路径清楚，再补细节交互。
4. 对桌面端和移动端分别给出布局策略。

## Rules

- 不要做成通用后台面板样式
- 不要把主操作和次要信息混在一个层级
- 不要为了“高级感”牺牲可读性
- 需要保留现有设计体系时，优先沿用已有模式

## Resources

- 需要布局参考时，读取 `references/layout-patterns.md`
- 需要脚手架或检查脚本时，使用 `scripts/`

写正文时注意几件事：

写动作，不写空话
写判断标准，不写口号
写例外情况，不写泛泛原则
需要长说明就拆到 references/
需要重复执行的逻辑就放到 scripts/

一个能直接参考的 `SKILL.md` 示例

---
name: editor-studio-ui
description: Use when designing or refining editor-style content studio interfaces, including workspace layout, panels, toolbars, editing flows, and production-ready frontend implementation details.
---

# Editor Studio UI

## Overview

用于编辑器工作台类页面的设计与实现，覆盖布局组织、操作区划分、面板关系和交互优先级。

## Workflow

1. 先识别主任务区域。
2. 再区分主操作、辅助信息和状态反馈。
3. 先确定布局和层级，再处理视觉样式。
4. 兼顾桌面端与移动端的使用路径。

## Layout Rules

- 主编辑区必须保持视觉中心
- 侧边栏只承载辅助信息，不抢主操作
- 顶部工具栏保留高频动作
- 二级操作尽量下沉，避免界面噪音

## Implementation Notes

- 优先复用现有设计系统
- 没有明确要求时，不引入复杂状态管理
- 样式命名和组件拆分保持可维护性
- 交互动效只服务于信息层级和操作反馈

## Resources

- 需要布局范式时读取 `references/layout-patterns.md`
- 需要模板或资源时查看 `assets/`
- 需要可执行辅助逻辑时使用 `scripts/`

初始化一个 skill

如果当前环境带有初始化脚本，可以直接生成骨架：

python init_skill.py editor-studio-ui --path "$CODEX_HOME/skills" --resources scripts,references,assets

如果没有这类脚本，也可以手动创建目录和文件。
关键不是脚本，而是目录结构和内容质量。

`openai.yaml` 要不要写

如果你希望它在界面里显示得更完整，建议写。

示例：

interface:
  display_name: "Editor Studio UI"
  short_description: "Editor workspace design and implementation"
  default_prompt: "Use $editor-studio-ui to design a production-ready editor workspace."

注意：

字段内容给人看，不要写成内部说明
default_prompt 最好短一点
default_prompt 里明确写出 $skill-name

资源文件怎么分

`scripts/`

适合放这些东西：

初始化脚本
转换脚本
校验脚本
可重复执行的小工具

`references/`

适合放这些东西：

接口说明
数据结构
设计规范
业务规则
长篇流程文档

`assets/`

适合放这些东西：

模板
图标
字体
示例文件
可直接复用的素材

原则只有一个：
能执行的放脚本，太长的放参考，最终产物要用的放素材。

怎么判断这个 skill 写得行不行

看三点：

别人第一次打开，能看懂它什么时候该用
真碰到任务时，它能提供具体帮助
不需要加载一堆无关内容

如果一个 skill 写完之后，正文大半都是“提高效率”“保持一致性”“确保质量”这种话，基本就该重写。

OpenClaw 源码分析

Wed, 18 Mar 2026 10:19:46 GMT

先说结论

OpenClaw 这个仓库，不能把它理解成“一个 CLI 工具的源码”。

更准确地说，它是一个 个人 AI 助手平台的 monorepo，里面同时包含了：

Gateway 守护进程
浏览器 Control UI
CLI
多消息渠道接入层
技能系统
插件系统
多设备节点能力
模型认证与路由

项目整体定位

官方 README 对它的定位非常明确：
OpenClaw 是一个运行在你自己设备上的个人 AI 助手，可以通过已经在用的渠道和它交互，而 Gateway 是控制平面。

这句话其实就决定了整个仓库的结构：

它必须有 常驻 Gateway
它必须有 多渠道适配
它必须有 浏览器和 CLI 控制面
它必须有 工作区 / 记忆 / 技能 / 插件
它必须有 设备节点和远程能力

所以 OpenClaw 的复杂度，不是因为“代码写乱了”，而是因为它要解决的问题本来就比普通代码 agent 大很多。

4 个核心概念

1. Gateway

Gateway 是整个系统的中心。

官方架构文档说明：

一个长期运行的 Gateway 持有所有消息面
CLI、macOS app、Web UI 都通过 WebSocket 连接它
节点设备也通过 WebSocket 连它
默认端口是 127.0.0.1:18789

这意味着 OpenClaw 不是“每次输入命令就临时跑一下”的架构，而是：

一个长期在线的 agent control plane。

2. Agent Workspace

官方文档把 workspace 定义成“agent 的家”。

默认位置：

~/.openclaw/workspace

它和 ~/.openclaw/ 的区别很关键：

~/.openclaw/ 更偏系统状态、配置、凭据、会话
~/.openclaw/workspace 更偏 agent 工作区、记忆、技能、上下文

这套设计说明 OpenClaw 把“agent 的长期状态”当成一等公民，而不是把所有内容都塞进进程内存。

3. Skills

OpenClaw 的技能是 AgentSkills-compatible 的目录结构，本质是 SKILL.md + frontmatter + 指令。

这意味着它把“如何使用工具”这件事，显式建模成了可组合、可覆盖、可发布的技能系统，而不是全部硬编码在 prompt 里。

4. Plugins

插件是 OpenClaw 的另一条主线。

官方插件文档写得很清楚，插件可以注册这些能力：

Gateway RPC
HTTP routes
Agent tools
CLI commands
Background services
Context engines
Skills

源码为什么会这么大

OpenClaw 仓库大，不是单一原因造成的，而是多块东西叠加出来的。

1. 多渠道接入

README 里列出的支持面非常多，像：

WhatsApp
Telegram
Discord
Slack
Signal
iMessage
WebChat

这些渠道的接入方式、消息模型、授权模式、媒体处理都不一样。
仅这一层就会拉高很多复杂度。

2. 多端节点能力

官方架构文档里还提到节点可以暴露：

canvas.*
camera.*
screen.record
location.get

也就是说它不仅能“聊天”，还要能和宿主设备能力交互。

3. 插件和技能生态

当一个系统支持：

内置能力
外部插件
工作区技能
本地技能
插件技能

它的目录和加载逻辑天然就会复杂起来。

4. 模型和认证系统

OpenClaw 不是只绑定一个模型提供商。
它还支持模型认证、OAuth、API key、profile rotation、failover。

这部分一旦做成通用平台，复杂度就会明显高于单模型工具。

仓库目录

`src/`

可以把它理解成核心运行时与主流程胶水层。
像 Gateway、CLI 入口、主调度逻辑，通常会围绕这里展开。

`packages/`

更适合放共享模块、公共能力、可复用运行时单元。
这类目录一般是 monorepo 的基础设施层。

`extensions/`

这是 OpenClaw 的重点目录之一。
官方插件文档说明，很多功能是通过插件扩展进来的，所以这里很可能就是内置扩展与 provider / channel / tool 能力的核心承载位置。

`skills/`

这里可以理解成 OpenClaw 自带的技能包。
这些技能负责教 agent 怎样用工具，而不是只靠系统提示死撑。

`ui/`

对应浏览器端 Control UI。
文档明确写了它是一个小型 Vite + Lit 单页应用，由 Gateway 提供静态资源。

`apps/`

这里通常会承载宿主应用层，例如桌面端或其它更高层的运行壳。

`docs/`

官方文档本身也在仓库里。
OpenClaw 的功能面太大，所以 docs 在这个项目里不是“附属品”，而是理解系统不可绕开的主入口。

OpenClaw 的运行链路

如果用一句话概括 OpenClaw 的主链路，大概是：

消息渠道 / Web UI / CLI 把输入交给 Gateway，Gateway 结合会话、工作区、技能、插件、模型与工具执行，再把结果回送到对应表面。

可以把它大致拆成这样：

用户输入
  ↓
渠道适配层 / Web UI / CLI
  ↓
Gateway
  ↓
会话路由 / Agent 选择 / 模型选择
  ↓
技能 + 工具 + 插件能力
  ↓
工作区 / 记忆 / 输出
  ↓
回到聊天界面、浏览器或消息渠道

这套链路和 Codex / Claude Code 那种“终端内 agent”不是一个量级的问题。

Workspace

OpenClaw 的一个重要特点，是它明确区分了：

配置和凭据
工作区和记忆

官方文档把 workspace 当成 agent 的 home，还建议把它作为 私有 Git 仓库 备份。

这意味着 OpenClaw 并不是把长期状态完全交给模型上下文，而是努力把 agent 的“长期记忆”落在磁盘上、文件上、目录结构上。

这个思路非常工程化，也很适合长期运行的 personal assistant。

Skills 和 Plugins 的组合，是 OpenClaw 最像“平台”的地方

很多 agent 项目会在这两件事里偏一边：

要么工具很多，但不会系统化成技能
要么 prompt 很多，但缺少真正的插件边界

OpenClaw 两边都做了：

Skills 负责“怎么教 agent 使用能力”
Plugins 负责“怎么把能力接进系统”

像一个：

带插件宿主、技能加载器、工作区和控制平面的 AI 操作系统雏形。

安全模型也影响了源码结构

OpenClaw 一旦接入真实消息渠道和设备能力，安全模型就不能是“随便跑”。

从官方文档看，有几个安全点会直接影响架构：

1. DM pairing

默认未知发件人不会直接通过，先走配对流程。

2. Dashboard 是管理面

官方文档明确说 Control UI 是 admin surface，不能随便暴露公网。

3. Workspace 不是硬沙箱

文档特别提醒：workspace 是默认 cwd，不等于强隔离。
如果你想要真正隔离，还要开启 sandbox。

这些设计都会反过来影响配置、认证、会话和工具执行层的代码形态。

OpenClaw 使用指南

Wed, 18 Mar 2026 10:19:06 GMT

安装 OpenClaw

官方当前推荐的安装方式是 安装脚本。

macOS / Linux / WSL2

curl -fsSL https://openclaw.ai/install.sh | bash

Windows PowerShell

iwr -useb https://openclaw.ai/install.ps1 | iex

文档里明确建议：Windows 场景优先用 WSL2。

系统要求

根据官方最新文档：

Node 22 或更高
支持 macOS、Linux、Windows
如果从源码运行，还需要 pnpm

第一次运行

安装完成后，官方推荐直接执行引导命令：

openclaw onboard --install-daemon

这个命令会做几件事：

配置模型认证
配置 Gateway
初始化工作区
选择是否接入渠道
安装并启动守护进程

完成后，可以先检查 Gateway 状态：

openclaw gateway status

最快上手方式：先用浏览器 Control UI

官方文档给出的最快路径是直接打开浏览器控制台：

openclaw dashboard

默认本地地址一般是：

http://127.0.0.1:18789/

最基础的使用方式

1. 启动引导

openclaw onboard --install-daemon

2. 检查 Gateway

openclaw gateway status

3. 打开浏览器控制台

openclaw dashboard

4. 前台运行 Gateway 做调试

如果你想本地排查问题，可以直接前台启动：

openclaw gateway --port 18789

常见命令

查看 Gateway 状态

openclaw gateway status

停止 Gateway

openclaw gateway stop

重启 Gateway

openclaw gateway restart

打开浏览器控制台

openclaw dashboard

查看日志

openclaw logs --follow

运行诊断

openclaw doctor

自动修复常见问题

openclaw doctor --repair

给目标发送测试消息

openclaw message send --target +1234567890 --message "Hello from OpenClaw"

直接让 agent 执行任务

openclaw agent --message "Ship checklist" --thinking high

模型和认证怎么配

官方推荐的方式仍然是：优先在 openclaw onboard 里做认证。

如果后面要补充新的模型提供商，也可以直接走命令：

openclaw models auth login --provider <provider-id>

例如 OpenAI Codex 这类支持 OAuth 的提供商，可以直接接入；
Anthropic 则更建议走 API Key 路线，而不是依赖订阅兼容方案。

模型选择本身由 OpenClaw 的模型配置控制。
文档建议把主模型设成能用到的最强一档，再给低成本场景加 fallback。

OpenClaw 的核心概念

1. Gateway

Gateway 是 OpenClaw 的核心守护进程。
它会长期运行，统一管理：

消息渠道
模型调用
会话
技能
插件
控制 UI

它默认监听本地 127.0.0.1:18789。

2. Workspace

OpenClaw 的工作区默认在：

~/.openclaw/workspace

官方文档明确强调：把它当作 agent 的私有记忆空间。
它和 ~/.openclaw/ 不是一回事：

~/.openclaw/ 放配置、凭据、会话状态
~/.openclaw/workspace 放 agent 工作区、技能、记忆和长期上下文

3. Skills

OpenClaw 的技能本质上是 SKILL.md 驱动的能力包，兼容 AgentSkills 格式。

常见位置有：

bundled skills：安装自带
~/.openclaw/skills
<workspace>/skills

如果同名技能冲突，工作区里的优先级最高。

4. Plugins

OpenClaw 的扩展能力大量通过插件提供。
插件可以注册：

Gateway RPC
HTTP 路由
Agent 工具
CLI 命令
后台服务
技能目录

查看当前插件：

openclaw plugins list

安装官方插件示例：

openclaw plugins install @openclaw/voice-call

启用插件示例：

openclaw plugins enable open-prose

Slash Commands 怎么用

OpenClaw 支持两套命令体系：

/... slash commands
! <cmd> 主机 bash 命令

比较常见的 slash commands / directives 包括：

/help
/commands
/status
/model
/compact
/tts

而 bash 相关命令常见的是：

! <command>
!poll
!stop

其中 ! <command> 更接近“让宿主机执行一个命令”。

配置文件在哪里

OpenClaw 的主配置文件是：

~/.openclaw/openclaw.json

它实际支持的是 JSON / JSON5 风格配置。
官方文档里提到，很多情况下不用直接手改，而是优先用：

openclaw onboard
openclaw configure
openclaw config get agents.defaults.workspace
openclaw config set agents.defaults.heartbeat.every "2h"

这样更不容易把配置搞乱。

安全方面

OpenClaw 不是普通的聊天玩具，它会接真实渠道、真实设备、真实自动化能力，所以安全一定要注意。

1. Dashboard 是管理面

官方文档明确写了，Control UI 是一个 admin surface。
不要随便公开暴露到公网。

更稳妥的方式是：

本机 localhost
Tailscale
SSH 隧道

2. 工作区不是硬沙箱

文档里特别说明：workspace 只是默认 cwd，不等于绝对隔离。
如果要强隔离，要单独启用 sandbox 配置。

3. 工作区建议私有 Git 备份

OpenClaw 官方建议把 workspace 当成私有记忆，用 私有仓库 备份。
但注意不要把 secrets 一起提交进去。

4. 不认识的插件和技能别乱装

因为插件和 skills 都能扩展 agent 的工具面，来源不明的第三方扩展要谨慎启用。

一个最小上手流程

第一次使用，建议按这个顺序来：

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon
openclaw gateway status
openclaw dashboard

确认浏览器里能连上 Control UI 以后，再决定是否继续：

接入 Telegram / Discord / WhatsApp
配置模型
加 skills
装 plugins

升级和维护

OpenClaw 官方更新文档里反复强调一件事：
升级后优先跑 openclaw doctor。

最实用的维护习惯是：

openclaw doctor
openclaw gateway status
openclaw logs --follow

如果发现配置漂移、旧服务残留、认证异常或危险 DM 策略，doctor 会给出修复建议。

Claude Code 使用指南

Wed, 18 Mar 2026 10:18:31 GMT

安装 Claude Code

npm install -g @anthropic-ai/claude-code

安装完成后怎么启动

先进入你的项目目录：

cd your-project

然后直接启动：

claude

第一次运行时，Claude Code 会引导你完成登录。
如果你想显式执行登录，也可以用：

claude auth login

登录完成后，建议先确认版本：

claude --version

官方当前支持的登录来源主要有：

Anthropic Console
Claude.ai 账号
Amazon Bedrock
Google Vertex AI

系统要求

根据官方当前文档，Claude Code 的基础要求大致是：

macOS 10.15+
Ubuntu 20.04+ / Debian 10+
Windows 10+（WSL 或 Git for Windows）
至少 4GB 内存
Node.js 18+
需要联网
最好使用 Bash、Zsh 或 Fish

如果你是 Linux 或 macOS 用户，直接终端安装最顺。
如果你是 Windows 用户，优先用 WSL 会省很多兼容性问题。

最基础的使用方式

1. 进入项目后直接对话

claude

接着在交互界面里直接提任务，比如：

先解释这个项目的目录结构

或者：

修复首页搜索框在移动端换行错位的问题

2. 启动时就带上任务

claude "解释这个项目的目录结构"

3. 非交互模式

如果你只想跑一次然后退出，可以用：

claude -p "解释 src/utils/request.ts 的作用"

这个模式很适合脚本化、CI 或快速查询。

常见使用场景

比如解释代码：

claude "解释 src/components/Header.tsx 的职责和调用关系"

比如修 bug：

claude "修复评论组件在深色模式下按钮颜色错误的问题"

比如补测试：

claude "给 userService 增加单元测试，并运行测试确认通过"

比如处理日志或管道输入：

cat logs.txt | claude -p "总结这份日志里的主要错误"

常用 CLI 命令

启动交互式会话

claude

带初始提示启动

claude "explain this project"

非交互执行后退出

claude -p "explain this function"

继续当前目录最近一次会话

claude -c

恢复指定会话

claude -r "auth-refactor" "继续完成这个 PR"

查看登录状态

claude auth status

更新 Claude Code

claude update

管理 MCP

claude mcp

查看子代理

claude agents

交互模式里怎么用

Claude Code 的强项在于它会在同一个终端会话里持续保留上下文。
常见工作流一般是：

先让它分析问题
再让它给出修改计划
然后让它直接改代码
最后要求它运行检查或测试

例如：

先阅读这个仓库，然后告诉我最值得先改的 3 个问题

然后继续：

修复第一个问题，只修改必要文件，完成后运行 npm run check

这种方式比直接说“帮我优化一下”稳定很多。

常用 Slash Commands

Claude Code 的交互界面支持大量 slash commands。比较常用的有：

/help 查看帮助
/compact 压缩上下文，适合长会话
/config 查看或修改配置
/memory 管理 CLAUDE.md 和记忆文件
/model 切换模型
/permissions 查看或修改权限
/review 发起代码审查
/clear 清空当前对话
/mcp 管理 MCP 连接
/init 初始化项目记忆和说明文件
/vim 进入 vim 风格输入模式

如果已经和 Claude Code 聊了很久，优先记住 /compact。
它对控制上下文膨胀非常有用。

配置文件怎么写

Claude Code 的配置核心是 settings.json。

常见位置有：

用户级：~/.claude/settings.json
项目级共享：.claude/settings.json
项目级本地：.claude/settings.local.json

项目级配置适合团队共享规则；本地配置适合个人偏好，不建议提交到仓库。

例如，一个很实用的权限限制配置可以写成这样：

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Read(./build)"
    ]
  }
}

这个配置的作用是：让 Claude Code 直接看不到敏感文件，避免误读到密钥和环境变量。

CLAUDE.md 很重要

Claude Code 会自动读取 CLAUDE.md，它是长期稳定工作流的核心。

常见位置：

项目级：./CLAUDE.md 或 ./.claude/CLAUDE.md
用户级：~/.claude/CLAUDE.md

适合写进去的内容包括：

构建命令
测试命令
命名规范
代码风格
项目架构说明
不允许修改的目录

你也可以直接让 Claude Code 生成一个起始版本：

/init

官方文档说明，/init 会根据当前项目自动生成初版 CLAUDE.md，然后你再手工补充更细的规则。

自定义 Slash Commands

Claude Code 官方当前的可复用命令体系，核心是 custom slash commands。

个人命令目录

~/.claude/commands/

项目命令目录

.claude/commands/

一个最小例子可以这样写：

---
description: 用图解方式解释代码
argument-hint: [file]
---

先用一个类比解释这个文件，再画一个 ASCII 图，最后分步骤讲清楚：$ARGUMENTS

假设文件名是：

.claude/commands/explain-code.md

那你在会话里就可以直接执行：

/explain-code src/auth/login.ts

这套方式很适合沉淀高频动作，比如：

/review-api
/check-performance
/summarize-diff

Subagents 怎么用

如果希望 Claude 在复杂任务里自动分工，可以再配 subagents。

常见位置：

项目级：.claude/agents/
用户级：~/.claude/agents/

官方推荐的最快方式不是手写，而是先在会话里执行：

/agents

然后通过交互界面创建一个子代理。
比如可以单独做一个 code-reviewer，只负责审查安全性、可维护性和回归风险。

Codex 使用指南

Wed, 18 Mar 2026 10:17:07 GMT

安装 Codex

官方推荐通过 npm 全局安装：

npm i -g @openai/codex

安装完成后，先检查版本：

codex --version

然后直接启动：

codex

第一次运行时，Codex 会要求你登录。官方支持两种方式：

使用 ChatGPT 账号登录
使用 OpenAI API Key 登录

最基础的使用方式

1. 进入项目目录再启动

cd your-project
codex

这样 Codex 会以当前目录作为工作区，能够直接读取并修改这个项目里的文件。

2. 直接给一个任务

你可以在启动时就带上提示词：

codex "解释这个项目的目录结构"

或者：

codex "为这个项目补充一个登录接口的单元测试"

3. 常见使用场景

比如让它解释代码：

codex "解释 src/utils/request.ts 的作用和调用链"

比如让它修 bug：

codex "修复首页搜索框在移动端换行错位的问题"

比如让它补测试：

codex "给 userService 增加测试，并运行测试确认通过"

交互模式里怎么用

Codex CLI 默认会进入一个交互式终端界面。在这个模式下，你可以：

连续追问
查看它的计划
审核它准备执行的命令
看它修改后的 diff
继续在同一个上下文里迭代

常用命令

启动交互式会话

codex

指定目录运行

codex --cd ./my-project

指定模型

codex -m gpt-5.4

允许工作区写入

codex --sandbox workspace-write

关闭频繁确认，适合你自己完全信任的本地环境

codex --ask-for-approval never

更稳妥的默认值通常是：

codex --ask-for-approval on-request --sandbox workspace-write

会话恢复

Codex 会把本地会话记录保存下来，所以你下次可以继续之前的任务。

恢复最近一次会话：

codex resume --last

打开会话列表再选择：

codex resume

这对做大一点的重构很有用，不用每次都重新解释项目背景。

常用 Slash Commands

在 Codex 交互界面里输入 /，可以看到内置命令。比较常用的有：

/model 切换模型
/permissions 调整权限策略
/diff 查看当前修改差异
/clear 清空当前会话界面
/copy 复制最近一次输出
/compact 压缩上下文，适合长对话
/exit 退出 Codex
/init 在当前目录生成 AGENTS.md 模板

如果已经和 Codex 聊了很久，优先记住 /compact，它能减少上下文膨胀。

AGENTS.md 很重要

如果你希望 Codex 更稳定地按你的习惯做事，建议在仓库根目录加一个 AGENTS.md。

例如：

# AGENTS.md

## Repository rules

- 修改前先阅读相关文件
- 改完后运行 npm run check
- 不要修改与当前任务无关的文件
- 新增依赖前先说明原因

Codex 会在开始工作前读取这些说明。
这比每次手动重复要求更有效。

给 Codex 接入 MCP

MCP 可以理解成“给 Codex 装外部工具”。
比如你可以给它接文档、浏览器、设计工具、数据库代理等。

官方给出的添加方式是：

codex mcp add <server-name> -- <command>

例如接一个文档服务器：

codex mcp add context7 -- npx -y @upstash/context7-mcp

查看 MCP 配置：

codex mcp --help

如果想在会话里查看当前可用 MCP，也可以使用：

/mcp

实战建议

1. 先让它分析，再让它修改

不要一上来就说“全改掉”。
更稳的方式是先让它说明现状、问题点、修改计划，再开始动手。

2. 任务要具体

下面这种提示更有效：

把 editor-studio 页面改成 GitHub Dark 风格，只改配色，不改结构，改完运行 npm run check

而不是：

帮我优化一下

3. 明确限制条件

比如：

不要改接口
不要新增依赖
只改某几个文件
改完必须跑测试

这些边界越清楚，Codex 输出越稳定。

4. 不要默认给它最高权限

danger-full-access 或完全免审批虽然爽，但风险也最大。
大多数本地项目用 workspace-write + on-request 就够了。

一个最小上手流程

第一次使用，你可以直接照这个流程来：

npm i -g @openai/codex
codex

登录完成后，在你的项目目录执行：

codex "先阅读这个项目，然后告诉我最值得先改进的 3 个问题"

确认它理解项目后，再继续：

codex "修复第一个问题，只修改必要文件，并在完成后运行 npm run check"

升级 Codex

官方建议定期升级：

npm i -g @openai/codex@latest

升级后再确认一下版本：

codex --version

React & Vue 发展演变历程

Sun, 01 Mar 2026 13:45:16 GMT

| 时间 | React 核心发展里程碑（细节版） | Vue 核心发展里程碑（细节版） | | :-------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 2013年 | 1. 2013 年，React 在 JSConf US 演讲及随后 2013-06-05 的官方博客中正式对外公开，最初用于解决 Facebook 内部复杂 UI 的组织与更新效率问题；2. 核心理念初步确立：组件化、声明式渲染、单向数据流倾向，以及通过轻量 UI 描述进行高效更新；3. JSX 从一开始就是可选语法扩展，不是 React 的硬性前提；早期重点仍然是 Web 端 UI 视图层能力。 | 1. 尤雨溪开始构思并实现 Vue 的早期原型，目标是在保留响应式和模板能力的同时，做到比当时主流框架更轻量、易上手、易嵌入；2. 早期设计思路受到 Angular 响应式模板机制的启发，同时强调更低的心智负担；3. 此阶段仍属于原型探索期，尚未形成后来完整的版本体系与官方生态。 | | 2014年 | 1. 发布 React 0.12，对 API 与术语进行整理，React.renderComponent 改为 React.render，isValidComponent 改为 isValidElement；2. 组件模型和元素抽象进一步稳定，社区开始更清晰地区分“组件实例”和“React 元素”；3. DevTools 与开发体验持续改进，React 逐步从 Facebook 内部方案走向更广泛的社区采用。 | 1. 2014 年初，Vue 首次公开亮相，并在年内发布 0.10、0.11 等早期版本；2. 核心特性逐渐成型：响应式数据绑定、指令系统、组件雏形，采用基于 Object.defineProperty 的响应式实现；3. 这一阶段仍没有虚拟 DOM，更新机制以指令驱动的 DOM 绑定为主，主打“简单直接、低学习成本”。 | | 2015年 | 1. 2015-03-10，发布 React 0.13，正式支持 ES6 class components；2. 2015-03-26，React Native 开源，提出 “Learn once, write anywhere”，推动 React 向跨平台渲染能力扩展；3. 2015-09，React 0.14 将 react 与 react-dom 拆分，分离核心抽象与 DOM 渲染器；4. 同期正式引入 stateless function components，为后续函数组件和 Hooks 时代埋下基础。 | 1. 2015-06-11，发布 Vue 0.12 “Dragon Ball”，组件语法更统一，paramAttributes 更名为 props，并引入异步组件；2. 2015-10-26，发布 Vue 1.0 正式版 “Evangelion”；3. Vue 1.0 统一并简化模板语法，加入 v-on / v-bind 简写，使用 v-for 取代旧的 v-repeat；4. vue-loader、热更新、scoped CSS 等工具链能力显著增强，Vue 开始具备构建中小型 SPA 的完整基础。 | | 2016年 | 1. 2016-04-07，发布 React 15.0，标志着 React 从 0.x 阶段进入更稳定的主版本节奏；2. React 15 的重点是 DOM 渲染实现重写：更接近原生 DOM 创建方式，减少额外包装，提升 SVG 与标准 DOM 属性支持；3. React 在工程稳定性、控制台警告、渲染一致性方面进一步打磨，生态采用率持续上升。 | 1. 2016 年，Vue 2.0 完成从设计到正式发布的跨越，10 月发布 Vue 2.0 正式版 “Ghost in the Shell”；2. Vue 2.0 的关键升级是引入 虚拟 DOM，在保留模板易用性的同时提升复杂组件树更新性能；3. 渲染层与响应式系统整体重构，SSR、render function、JSX 支持更完善；4. Vue 2 奠定了此后数年 Vue 主流生态的技术基础。 | | 2017年 | 1. 2017-04-07，React 15.5 将 React.PropTypes 与 React.createClass 从核心包中拆出并标记废弃，推动核心包继续精简；2. 2017-09-26，发布 React 16.0，底层全面切换到 Fiber 架构，为可中断渲染、优先级调度等能力建立基础；3. React 16 带来 Error Boundaries、Portals、返回字符串/数组等能力；4. 2017-11-28，React 16.2 正式加入 Fragments，进一步减少无意义的 DOM 包裹层。 | 1. 2017 年是 Vue 2 生态快速成熟的一年，Vue Router、Vuex、单文件组件与工程化工作流逐步成为事实标准；2. “渐进式框架”定位更加清晰，开发者可以只使用核心库，也可以按需叠加路由、状态管理和构建工具；3. Vue 在后台系统、中小型业务前端和企业级组件库场景中加速普及，社区影响力显著提升。 | | 2019年 | 1. 2019-02-06，发布 React 16.8，Hooks 正式稳定；2. useState、useEffect、useContext 等核心 Hooks 让函数组件具备承载状态与副作用逻辑的能力；3. Hooks 解决了类组件中 this、生命周期逻辑分散、复用困难等长期痛点，推动 React 开发范式向函数式全面转移；4. 官方开始更明显地推荐函数组件与 Hooks，但类组件仍被保留并继续可用。 | 1. 2019 年进入 Vue 3 设计与 RFC 推进期，核心目标是提升大型应用中的逻辑复用、类型推断与长期可维护性；2. 官方正式明确 Composition API 方向，用更灵活的组合式写法改善 Options API 在复杂组件中的组织问题；3. Vue 3 的新响应式方案开始转向 Proxy，以突破 Vue 2 在数组索引、属性新增删除等场景的局限；4. 这一年更准确的定位是“Vue 3 方案确立与实验推进”，而不是正式发布年。 | | 2020年 | 1. 2020-10-20，发布 React 17.0；2. React 17 没有新增开发者可见的重大功能，核心任务是为未来版本做底层铺垫；3. 重点包括事件委托系统重构、跨版本嵌套升级支持，以及更平滑的渐进式升级路径；4. 同年推出 新的 JSX Transform，减少对显式 import React 的依赖，改善构建体验。 | 1. 2020-09-18，发布 Vue 3.0 正式版 “One Piece”，完成内核级重构；2. 核心升级包括：使用 Proxy 重写响应式系统、正式推出 Composition API、强化 TypeScript 支持；3. 同时引入更好的 tree-shaking、更小包体，以及对 Fragment、Teleport、Suspense 等能力的支持；4. Vue 3 标志着 Vue 从“易用的响应式框架”进入“兼顾工程规模、类型能力与运行性能”的新阶段。 | | 2022年 | 1. 2022-03-29，发布 React 18.0；2. 核心能力包括：automatic batching、startTransition / useTransition、更完善的 streaming SSR + Suspense；3. 新入口 createRoot / hydrateRoot 取代旧渲染方式，为新能力启用提供基础；4. 需要注意的是，React 18 不是“默认全局开启并发渲染”，而是通过新 API 与特性按需启用并发能力；5. React Server Components 在这一阶段仍主要处于实验和框架集成推进期。 | 1. 2022-02-07 起，Vue 3 成为官方默认版本，Vue 2 进入维护收尾阶段；2. 2022-07-01，发布 Vue 2.7 “Naruto”，将 Composition API、<script setup>、CSS v-bind 等关键能力回移到 Vue 2；3. Vue 3 生态逐步稳定，Pinia、Vite、Volar、Vue Devtools 6 等方案成为主流组合；4. 这一阶段 Vue 的重点从“核心切换”转向“生态全面完成 Vue 3 迁移”。 | | 2023年 | 1. 2023 年 React 没有新的稳定大版本发布，但有两项重要进展：react.dev 新文档体系成熟，以及 Canary 发布通道正式启用；2. React 团队通过 Labs / Canary 持续推进 RSC、Actions、Compiler 等下一阶段能力；3. 需要纠正的是：React 18.2.0 实际发布于 2022 年 6 月，不是 2023 年；useId、useDeferredValue 也不是 2023 年才新增。 | 1. 2023-05-11，发布 Vue 3.3 “Rurouni Kenshin”，重点强化 <script setup> 与 TypeScript 开发体验；2. 3.3 带来 宏中的导入类型支持、泛型组件、defineSlots、更易用的 defineEmits，并以实验形式提供 defineModel 等能力；3. 2023-12-28，发布 Vue 3.4 “Slam Dunk”，重写模板解析器、优化响应式触发精度，并让 defineModel 稳定；4. 2023-12-31，Vue 2 正式结束官方维护（EOL），Vue 生态全面进入 Vue 3 时代。 | | 2024~2026年 | 1. 2024-12-05，发布 React 19 稳定版，重点引入 Actions、useActionState、useOptimistic、useFormStatus、use 等能力，并强化表单与异步提交流程；2. React 19 进一步完善服务端与客户端协同的全栈开发体验，和 Server Components 配套能力结合得更紧密；3. 2025-10-07，React Compiler v1.0 稳定发布，推动自动化性能优化进入正式阶段；4. 2026-02-24，React Foundation 正式成立，React 的治理进一步走向长期化、基金会化；5. 这一阶段 React 的核心方向是：服务端优先协作、编译器优化、全栈整合、进一步降低高性能开发门槛。 | 1. 截至 2026-03-25，Vue 官方已明确的重要后续核心里程碑是 Vue 3.5（2024-09-01）；2. Vue 3.5 重点包括：响应式系统重构优化、更好的 SSR 表现、Lazy Hydration、useId()、useTemplateRef()、onWatcherCleanup() 等；3. 其中响应式系统重构显著改善了内存占用与大规模深层响应式场景下的性能表现；4. 2024 至 2026 年间，Vue 持续沿 3.x 小版本迭代 推进，重点聚焦于 SSR、类型体验、开发者体验、生态协同；5. 这一阶段 Vue 的核心方向是：渐进式体验保持不变，同时继续补强性能、SSR 与现代工具链协同能力。 |

补充说明

两者都起步于“更高效地组织和更新 UI”，但 React 更强调 声明式组件抽象、渲染器解耦、跨平台与全栈协作，Vue 更强调 渐进式采用、模板易用性、开发效率与工程平衡；
核心转折点可概括为：React 16（Fiber）、React 16.8（Hooks）、React 18（并发相关能力）、React 19（Actions / 全栈协作）；以及 Vue 2.0（虚拟 DOM）、Vue 3.0（Proxy + Composition API）、Vue 3.5（响应式与 SSR 再优化）；
未来趋势上，两者都在向 SSR / 服务端协同、编译器辅助优化、更强 TypeScript 支持、更好的开发体验 发展；React 更偏向 Server Components + Compiler + 全栈整合，Vue 更偏向 渐进式升级 + SSR 能力增强 + Vite 生态协同。

Proxy 深度监听与 Vue3 响应式

Tue, 03 Feb 2026 01:15:35 GMT

Proxy 深度监听与 Vue3 响应式

核心机制：懒递归代理

function reactive(target) {
  return new Proxy(target, {
    get(target, key, receiver) {
      track(target, key);  // 依赖收集
      
      const result = Reflect.get(target, key, receiver);
      
      // 懒递归：访问时才深层代理
      return isObject(result) ? reactive(result) : result;
    },
    
    set(target, key, value, receiver) {
      const oldValue = target[key];
      const result = Reflect.set(target, key, value, receiver);
      
      if (hasChanged(value, oldValue)) {
        trigger(target, key);  // 触发更新
      }
      return result;
    }
  });
}

懒递归 vs 深度遍历

| Vue2（defineProperty） | Vue3（Proxy） | |:---|:---| | 初始化递归遍历所有属性 | 访问时才代理深层对象 | | 新增属性需 Vue.set | 自动支持新增/删除 | | 数组重写 7 个方法 | 原生支持索引和 length |

依赖收集与触发

// 全局状态
const targetMap = new WeakMap();
let activeEffect = null;

// 读取时收集
function track(target, key) {
  if (!activeEffect) return;
  
  let depsMap = targetMap.get(target);
  if (!depsMap) targetMap.set(target, depsMap = new Map());
  
  let dep = depsMap.get(key);
  if (!dep) depsMap.set(key, dep = new Set());
  
  dep.add(activeEffect);  // 组件订阅此属性
}

// 修改时触发
function trigger(target, key) {
  const depsMap = targetMap.get(target);
  if (!depsMap) return;
  
  depsMap.get(key)?.forEach(effect => effect());
}

使用示例

const state = reactive({ 
  count: 0, 
  nested: { num: 1 } 
});

effect(() => {
  console.log(state.nested.num);  // 访问时自动代理 nested
});

state.nested.num++;  // 触发更新
state.newProp = 123; // 自动响应，无需 set

git 工作树（worktree）

Tue, 27 Jan 2026 22:23:21 GMT

git 工作树（worktree）

大列表渲染卡顿时，React 项目里怎么优化？

Sun, 25 Jan 2026 10:14:03 GMT

满分答案

大列表卡顿的核心原因是一次性渲染大量 DOM 节点，阻塞主线程。优化方案按优先级：虚拟滚动（核心）、懒加载、分页、列表项 memo 优化、减少渲染节点、时间切片、避免复杂计算，其中虚拟滚动是解决超大数据量最有效的方案。

一、卡顿的根本原因

一次性渲染成百上千个 DOM 节点
主线程被 JS 执行阻塞，页面交互、滚动、输入都会卡顿
重排重绘（reflow）成本极高

二、React 项目实战优化方案（从必用到进阶）

1. 虚拟滚动（最有效、首选）

只渲染可视区域内的节点，可视区域外的 DOM 全部不渲染，节点数从 10000 → 10~20。

成熟库（直接用）

react-window（轻量）
react-virtualized（功能全）
antd / antd-table 自带 virtual 属性

import { FixedSizeList } from 'react-window';

const VirtualList = ({ data }) => {
  return (
    <FixedSizeList
      height={500}        // 可视区域高度
      width="100%"
      itemCount={data.length}
      itemHeight={50}     // 每项高度
    >
      {({ index, style }) => (
        <div style={style}>{data[index]}</div>
      )}
    </FixedSizeList>
  );
};

2. 列表项使用 React.memo 缓存

防止父组件更新导致所有列表项重复渲染。

const Item = React.memo(({ item }) => {
  return <div>{item.name}</div>;
});

3. 分页加载 / 滚动加载（懒加载）

不一次渲染所有数据：

分页
滚动到底加载更多（无限滚动）

useEffect(() => {
  // 监听滚动，触底加载下一页
  window.addEventListener('scroll', handleScroll);
}, []);

4. 使用正确、稳定的 key

千万不要用 index 做 key，会导致：

错误复用
大量不必要的 DOM 销毁重建
列表 Diff 极慢

// ✅ 正确
{item.id}

// ❌ 错误
{index}

5. 时间切片（Time Slicing）

利用 React Fiber 把渲染任务分片执行，不阻塞主线程：

ReactDOM.createRoot（React 18 默认开启）
配合 useDeferredValue / Suspense

import { useDeferredValue } from 'react';

const deferredList = useDeferredValue(list);

6. 减少列表项内部计算

用 useMemo 缓存列表项内部的过滤、排序、格式化。

const content = useMemo(() => formatData(item), [item]);

7. 图片懒加载

列表中的图片延迟加载，减少渲染压力。

三、优化优先级

虚拟滚动（1000条以上数据必用）
分页/无限加载
列表项 memo 优化
稳定 key
时间切片（React 18）
减少内部计算 & 图片懒加载

四、一句话总结

大列表卡顿是因为一次性渲染太多 DOM。最优方案是虚拟滚动，只渲染可视区域；其次是分页、懒加载、memo 缓存、稳定 key，配合 React 18 时间切片，可彻底解决卡顿问题。

总结

万条数据不卡顿 = 虚拟滚动 + memo + 正确key + 时间切片

React 中如何获取 DOM 节点？

Sun, 25 Jan 2026 10:10:05 GMT

满分答案

在 React 中获取真实 DOM 节点，首选使用 useRef() 钩子：

创建 ref 对象 → const ref = useRef(null)
绑定到元素上 → <div ref={ref} />
在 useEffect / 事件回调 中通过 ref.current 获取真实 DOM
函数组件获取子组件 DOM，需搭配 forwardRef

一、最标准、最常用方法：useRef

1. 获取当前组件内的 DOM（最简单）

import { useRef, useEffect } from 'react';

function App() {
  // 1. 创建 ref
  const domRef = useRef(null);

  // 2. DOM 渲染完成后才能拿到（ useEffect ）
  useEffect(() => {
    // 真实 DOM 节点
    console.log(domRef.current); 
    // 可以操作：聚焦、样式、获取宽高、滚动等
    domRef.current.focus();
  }, []);

  // 3. 绑定到元素
  return <input ref={domRef} />;
}

二、获取子组件的 DOM 节点

子组件必须用 forwardRef 把 ref 转发出去

import { useRef, forwardRef } from 'react';

// 子组件
const Child = forwardRef((props, ref) => {
  return <div ref={ref}>子组件 DOM</div>;
});

// 父组件
function Parent() {
  const childDomRef = useRef(null);

  useEffect(() => {
    console.log(childDomRef.current); // 拿到子组件的 div DOM
  }, []);

  return <Child ref={childDomRef} />;
}

三、获取 DOM 的时机（非常重要）

渲染完成后获取 → useEffect（最安全）
事件触发时获取 → 点击/输入等事件里
useLayoutEffect → DOM 更新后、浏览器绘制前（获取布局）

千万不要在组件渲染期间直接拿，会是 null！

四、类组件写法（了解即可）

class App extends React.Component {
  componentDidMount() {
    console.log(this.domRef);
  }
  render() {
    return <div ref={(el) => (this.domRef = el)} />;
  }
}

五、总结

获取 DOM 统一用 useRef
绑定：ref={domRef}
获取：domRef.current
必须在 useEffect 或事件里拿

一句话记忆

创建 ref → 绑定元素 → useEffect 里拿 current

useContext 有什么使用场景和性能风险？

Sun, 25 Jan 2026 10:06:53 GMT

满分答案

useContext 用于跨层级组件共享数据，解决 props 逐层传递问题；但只要 context 的 value 变化，所有使用该 context 的组件都会全部重渲染，容易造成大面积无效渲染，这是最大的性能风险。

一、useContext 适用场景

全局通用状态 主题（亮色/暗色）、语言、用户信息、全局配置
多层级传值 爷→父→子→孙，不想一层层 props 透传
组件库内部状态共享 表单、弹窗、步骤条等跨组件通信

二、useContext 最大性能风险

风险：value 一变，全体消费者重渲染！

只要 Provider 的 value 改变
所有用到 useContext(MyContext) 的组件都会重渲染
即使组件只用到一小部分数据，也会被迫渲染
项目越大，性能浪费越严重

根本原因

React 对 value 做引用比较（===） 每次父组件渲染，若直接写：

<MyContext.Provider value={{ a:1, b:2 }}>

会创建新对象 → 引用变化 → 所有消费者重渲染。

三、如何避免性能问题？

1. 拆分 Context

把经常变和不经常变的状态分开存放

<UserContext.Provider value={user}>
  <ThemeContext.Provider value={theme}>

2. 用 useMemo 缓存 value

const value = useMemo(() => ({ user, theme }), [user, theme]);

3. 组件结合 memo + 只取需要的值

让组件只在真正用到的数据变化时才渲染

4. 复杂状态用状态库

Redux、Zustand、Jotai 等，它们可以精准更新，不会全量渲染

四、满分总结

场景：

跨层级共享全局状态（主题、语言、用户信息），解决 props 逐层传递。

性能风险：

context 的 value 变化会导致所有使用它的组件全部重渲染，造成大面积无效渲染。

优化：

拆分 Context、缓存 value、组件拆分、使用专业状态库。

总结

适用：全局/跨层共享数据
风险：value 变 → 所有消费者全量重渲染
优化：拆分 + 缓存 + 专业状态库

react父子组件通信有哪些方式？

Sun, 25 Jan 2026 10:00:02 GMT

满分答案

React 父子组件通信主要有四种核心方式：

父传子：通过 props 直接传递数据；
子传父：父组件通过 props 传递回调函数，子组件调用并传参；
父调用子组件方法/获取DOM：使用 useRef + forwardRef，配合 useImperativeHandle 控制暴露内容；
跨层级父子通信：使用 Context API 避免 props 逐层透传。兄弟组件通信则以父组件为中间媒介进行转发。

一、最基础、最常用（90% 场景）

1. 父 → 子：props 传值

// 父
<Child name="小明" age={18} />

// 子
function Child({ name, age }) {
  return <div>{name}</div>
}

2. 子 → 父：props 传回调函数

// 父
const handleMsg = (msg) => console.log(msg)
<Child onSend={handleMsg} />

// 子
function Child({ onSend }) {
  return <button onClick={() => onSend("来自子组件")}>发送</button>
}

二、进阶用法（ref 相关）

3. 父获取子实例 / 调用子方法

useRef + forwardRef

// 父
const childRef = useRef(null)
const callChild = () => childRef.current.sayHi()

<Child ref={childRef} />

// 子
const Child = forwardRef((props, ref) => {
  const sayHi = () => alert("hello")
  return <div>子组件</div>
})

4. 子可控暴露方法：useImperativeHandle

useImperativeHandle(ref, () => ({
  sayHi: () => alert("hello")
}))

三、跨层级通信

5. Context API（爷孙/深层组件）

const MyContext = createContext()

// 父
<MyContext.Provider value={数据}>
  <Child />
</MyContext.Provider>

// 后代组件
const data = useContext(MyContext)

四、兄弟组件通信

兄弟A → 父 → 兄弟B
本质还是：props + 回调函数

常见 Hooks 有哪些？分别适合什么场景？

Sun, 25 Jan 2026 09:49:16 GMT

一、最基础必备 Hooks

1. useState

作用：定义组件状态变量，修改状态触发视图更新
场景：所有需要组件内状态管理的地方
- 开关、计数器、表单输入、显示隐藏等

const [count, setCount] = useState(0)

2. useEffect

作用：处理副作用（异步、DOM 操作、定时器、请求）
场景：
- 发送网络请求
- 订阅/取消订阅
- 操作真实 DOM
- 定时器/延时器

useEffect(()=>{
  // 请求、定时器
}, [])

3. useContext

作用：跨组件共享数据，告别 props 层层传递
场景：
- 全局主题、语言
- 用户信息
- 多层组件需要共享的数据

const value = useContext(MyContext)

二、性能优化 Hooks

4. useMemo

作用：缓存计算结果
场景：
- 耗时计算（过滤、排序大量数据）
- 缓存对象/数组，防止子组件重渲染

const total = useMemo(()=>count*1000, [count])

5. useCallback

作用：缓存函数本身
场景：
- 函数传递给子组件时
- 配合 React.memo 防止子组件重复渲染

const handleClick = useCallback(()=>{}, [])

6. React.memo

作用：缓存整个组件
场景：
- 子组件频繁被父组件触发重渲染
- 纯展示组件，props 不变就不更新

const Child = React.memo(Child)

三、DOM & 引用 Hooks

7. useRef

作用：
1. 获取真实 DOM 元素
2. 存储不需要渲染的变量（定时器 ID、上次值）
场景：
- 获取 input、div 等 DOM
- 存定时器、计数器，修改不触发渲染

const inputRef = useRef(null)
const timerRef = useRef(null)

8. useLayoutEffect

作用：DOM 更新后、浏览器绘制前同步执行
场景：
- 需要获取 DOM 最新尺寸/位置
- 避免页面闪烁、布局抖动

useLayoutEffect(()=>{
  // 读取 DOM 布局
}, [])

四、状态管理增强 Hooks

9. useReducer

作用：复杂状态逻辑替代 useState
场景：
- 状态多、逻辑复杂
- 一个动作修改多个状态
- 状态依赖之前的值

const [state, dispatch] = useReducer(reducer, initialState)

10. useImperativeHandle

作用：子组件向父组件暴露方法
场景：
- 父组件调用子组件函数
- 自定义表单组件、弹窗组件

useImperativeHandle(ref, () => ({
  open, close
}))

超清晰总结表

| Hooks | 核心功能 | 最常用场景 | |------|--------|----------| | useState | 状态管理 | 开关、输入、计数 | | useEffect | 副作用处理 | 请求、定时器、DOM 操作 | | useContext | 跨组件共享 | 全局主题、用户信息 | | useMemo | 缓存计算值 | 耗时计算、缓存对象/数组 | | useCallback | 缓存函数 | 函数传给子组件 | | useRef | 存储引用/DOM | 获取 DOM、存不渲染变量 | | useReducer | 复杂状态 | 多状态、复杂逻辑 | | useLayoutEffect | 同步布局 | 读取 DOM 尺寸、防闪烁 |

一句话记忆口诀

状态修改用useState，副作用用useEffect，跨组件传值useContext，缓存数值useMemo，缓存函数useCallback，获取 DOM 用useRef。

useMemo 和 useCallback 的区别是什么？

Sun, 25 Jan 2026 09:40:26 GMT

一句话终极结论

useMemo 缓存「函数返回的值」，useCallback 缓存「函数本身」 两者都是为了防止重复创建引用，解决 React 重复渲染问题。

1. 核心对比表

2. 代码直观对比

① useCallback（缓存函数）

给函数做缓存，保证函数引用不变 主要用于传递给子组件的函数，配合 React.memo 防止子组件重渲染。

// 缓存函数本身，依赖不变，函数地址就不变
const handleClick = useCallback(() => {
  console.log(count);
}, [count]); 

// 传递给子组件，引用不变 → 子组件不重渲染
<Child onClick={handleClick} />

② useMemo（缓存值）

给计算结果做缓存，避免每次渲染都重算 主要用于耗时计算、对象、数组。

// 缓存计算出来的值，依赖不变，值就不变
const expensiveValue = useMemo(() => {
  return count * 1000; // 模拟耗时计算
}, [count]);

// 缓存对象，保证引用不变
const userInfo = useMemo(() => ({ name: 'Tom', age: 20 }), []);

3. 最核心的本质

React 靠「引用地址」判断是否变化

useCallback：让函数地址不变
useMemo：让数据/对象地址不变

地址不变 → React.memo 判定 props 不变 → 子组件不重渲染

4. 最佳使用场景

✅ useCallback 场景

需要把函数传给子组件时：

const fetchData = useCallback(() => {
  axios.get('/api');
}, []);
// 传递给被 memo 包裹的子组件
<Table fetchData={fetchData} />

✅ useMemo 场景

耗时计算（过滤、排序大量数据）
传递给子组件的对象/数组

const options = useMemo(() => ({ pageSize: 10 }), []);
<Filter options={options} />

5. 满分答案

useCallback 缓存函数本身，用于优化子组件渲染；
useMemo 缓存计算结果，用于优化重复计算；
两者都是依赖驱动，依赖不变，缓存就不变；
核心目的都是保持引用地址稳定，配合 React.memo 防止无效重渲染。

总结

想缓存函数 → 用 useCallback
想缓存数据/计算值 → 用 useMemo
都是性能优化工具，不要滥用

React 组件为什么会重复渲染

Sun, 25 Jan 2026 09:38:43 GMT

一句话结论

React 组件默认：父组件渲染 → 所有子组件自动跟着渲染！不管子组件的 props 变没变，都会重新渲染。

这就是 99% 的重复渲染来源。

一、组件重复渲染的 4 大核心原因

1. 父组件渲染，子组件默认无条件重渲染（最常见）

React 没有自动给子组件做优化，父一更新，子全更。

function Parent() {
  const [a] = useState(0)
  return <Child /> // 父渲染 → 子一定渲染
}

2. 自身 state 变化

只要执行 setState，组件一定重渲染。即使值没变，也会渲染：

setCount(1)
setCount(1) // 依然会触发渲染

3. props 引用变化（对象/数组/函数）

因为 React 用 === 比较

<Child list={[1,2,3]} /> // 每次都是新数组 → 子组件渲染
<Child fn={() => {}} />  // 每次都是新函数 → 子组件渲染

4. context value 变化

只要 context.Provider 的 value 变了 所有用到这个 context 的后代组件全部重渲染

二、最关键知识点：

React 组件渲染 ≠ DOM 更新

组件渲染 = 运行函数 / 生成 VDOM
DOM 更新 = 真实改变页面

组件重复渲染 ≠ 页面卡 但渲染太多 = 浪费性能 = 页面卡

三、如何判断组件在重复渲染？

加一句 console.log 就行：

function Child() {
  console.log("子组件渲染了") // 打印多了就是重复渲染
  return <div></div>
}

四、如何解决重复渲染？（最实用）

1. 子组件包 `React.memo()`

让子组件只有 props 真正变化时才渲染

const Child = React.memo(function Child() { ... })

2. 用 `useMemo` 缓存对象/数组

const list = useMemo(() => [1,2,3], [])

3. 用 `useCallback` 缓存函数

const fn = useCallback(() => { ... }, [])

4. 拆分组件

把会变的 state 和不变的 UI 拆分开。

总结

React 组件重复渲染主要有 4 个原因：

父组件渲染，子组件默认无条件重渲染（最主要）
自身 state 被更新
props 是引用类型（对象/数组/函数），每次都创建新引用
使用的 context value 发生变化

优化方式： React.memo、useMemo、useCallback、组件拆分。

父渲染 → 子默认渲染 引用变化 → 子一定渲染 自身 setState → 自身一定渲染

useState 更新为什么看起来有时是异步的？

Sat, 24 Jan 2026 14:48:24 GMT

一句话结论： useState 更新本身不是异步函数，但它是「批量延迟执行」的，所以代码写起来感觉像异步。

1. 先看最经典的迷惑代码

const [count, setCount] = useState(0)

function handleClick() {
  console.log(count) // 0
  setCount(count + 1)
  console.log(count) // 还是 0！！！
}

明明调用了 setCount，但值立刻拿不到最新的，这就是「看起来异步」。

2. 真正原因：闭包 + 队列机制

核心 1：useState 是快照式的

每次组件渲染，state 都是一个独立的快照
事件函数里拿到的 count，永远是本次渲染的旧值
调用 setCount 不会修改当前快照，只会触发下一次渲染

核心 2：React 会合并、延迟更新

React 为了性能，不会一调用 setState 就立刻更新：

把更新放进队列
等当前函数执行完
再批量更新 state
最后重新渲染组件

所以： 在 set 之后立刻打印，拿到的还是「旧快照」。

3. 一句话总结原理

不是异步，是闭包快照 + 批量延迟更新 → 导致不能同步拿到最新值。

它和真正的异步（Promise/定时器）完全不是一回事。

4. 3 种场景帮你彻底理解

场景 1：同步事件里（看起来异步）

setCount(1)
console.log(count) // 旧值

✅ 原因：更新被延后了

场景 2：set 传函数（立刻用最新值）

setCount(prev => prev + 1) // 这个能拿到最新值

✅ 原因：函数式更新不依赖当前快照

场景 3： useEffect 里（能拿到最新值）

useEffect(()=>{
  console.log(count) // 最新值
},[count])

✅ 原因：渲染完成后才执行

5. 超级好记的口诀

State 是快照，更新会排队；当前拿不到，下次渲染见。想立刻用值，就传函数式。

总结

useState 更新不是异步，而是：

state 是 immutable 不可变的，每次渲染都是独立快照
setState 只会把更新加入队列，不会立即修改当前值
React 为了性能会批量合并更新，等同步代码执行完才统一更新、重渲染
所以在同步代码里无法立即获取最新 state，看起来像异步

不是异步，是批量延迟 + 闭包快照
当前渲染的 state 永远不变
想立即用最新值：函数式更新
想监听最新值：useEffect

需要我给你演示如何立刻拿到最新 state的 3 种正确写法吗？

React 和 Vue 的核心区别是什么？

Sat, 24 Jan 2026 14:43:44 GMT

一句话总纲

React 是「函数式+数据驱动」，Vue 是「响应式+视图驱动」 一个靠重新渲染更新，一个靠精准劫持更新。

1. 数据响应式原理（最核心区别）

React

数据不可变（Immutable 思想）
状态更新必须用 setState / useState
不会劫持数据，状态变了 → 重新执行组件函数 → 生成新 VDOM
靠 diff 对比 找到变化

Vue

数据响应式劫持
Vue2：Object.defineProperty
Vue3：Proxy
自动追踪依赖，数据变了 → 精确通知对应组件/节点更新
不需要手动 setState，直接修改数据

口诀： React 是暴力重渲染，Vue 是精准点对点更新。

2. 模板与渲染写法

React

JSX 一统天下（JS + HTML 混合）
一切都是 JS，循环用 map，条件用 if/&&
灵活度极高，贴近原生 JS

Vue

模板（template）+ 脚本（script）分离
内置指令：v-if / v-for / v-model
上手更简单，对新手友好

口诀： React All in JS，Vue 模板更直观。

3. 组件更新机制

React

自动重新渲染：父组件更新 → 子组件默认全部跟着更新
需要手动优化：React.memo / useMemo / useCallback
渲染量大 → 所以需要 Fiber 架构

Vue

组件自动追踪依赖
数据变 → 只更新用到这个数据的组件
组件更新默认优化好，基本不需要手动优化
渲染量极小 → 不需要 Fiber

口诀： React 需要手动优化，Vue 自带优化躺平用。

4. 设计哲学与生态

React

函数式编程（FP）
专注 UI 层，路由、状态管理靠社区（React Router / Redux / Zustand）
自由度极高，适合大型项目、团队定制

Vue

渐进式框架
全家桶一站式（Vue Router / Pinia 官方内置）
开箱即用，约束更强，开发效率高
更适合中后台、快速开发

总结

响应式不同：React 靠 setState 重新渲染，Vue 靠 Proxy 自动劫持精准更新。
渲染机制不同：React 父更新子必更新，需要手动优化；Vue 自动追踪依赖，自带优化。
写法不同：React 用 JSX，一切皆 JS；Vue 用模板 + 指令，更易上手。
架构不同：React 渲染量大，需要 Fiber 防止卡顿；Vue 更新精准，不需要 Fiber。

React：灵活、函数式、全靠 JS、需要手动优化、有 Fiber
Vue：简单、响应式、模板友好、自动优化、无需 Fiber

react为什么需要虚拟 DOM？

Fri, 23 Jan 2026 10:17:29 GMT

满分答案

虚拟 DOM 就是用普通 JS 对象模拟真实 DOM 树。它的核心价值是：批量、高效更新视图，避免直接操作 DOM 带来的性能损耗，同时实现跨平台渲染，并让开发者专注于数据和UI。

一、核心原因

真实 DOM 操作非常昂贵、慢 真实 DOM 节点属性非常多，频繁操作、修改、重排重绘会严重卡顿。虚拟 DOM 是轻量 JS 对象，操作极快。
实现 DOM 批量更新，减少重排重绘 虚拟 DOM 不会立即操作 DOM，而是在内存中做 diff，收集所有变更后一次性更新真实 DOM，把多次 DOM 操作合并成一次。
提供跨平台能力（React 最关键） 虚拟 DOM 是一层抽象，不依赖浏览器环境 → 可渲染成小程序、React Native、桌面端 → 一次编写，多端运行
声明式开发，不用手动操作 DOM 只需要关心数据变化，React 自动更新 UI 代码更简洁、可维护性更强

二、通俗理解

真实 DOM = 复杂、笨重、操作慢
虚拟 DOM = 轻量、简单、纯 JS 对象
Diff 算法 = 只改变化的部分

虚拟 DOM 相当于真实 DOM 的“草稿纸”，先在草稿纸上改好，再一次性誊写到 DOM 上。

三、虚拟 DOM 工作流程

状态更新 → 生成新虚拟 DOM
和旧虚拟 DOM 做 diff
找到最小差异
一次性更新真实 DOM

四、满分总结

真实 DOM 操作性能差，虚拟 DOM 是轻量对象，操作更快；
批量更新 DOM，减少重排重绘，提升性能；
跨平台渲染，支持 React Native、小程序等；
声明式编程，让开发者不用手动操作 DOM，专注业务。

一句话终极记忆

虚拟 DOM = 用 JS 对象模拟 DOM → 批量更新 → 高性能 → 跨平台

函数组件和类组件的区别是什么？

Thu, 22 Jan 2026 10:12:14 GMT

满分答案

函数组件使用 Hooks 管理状态与副作用，代码更简洁、逻辑更易复用；类组件使用 class、this、生命周期，代码冗余且难以优化。 React 官方推荐函数组件，未来趋势完全以函数组件为主。

一、核心区别（最清晰对比）

1. 编写方式

函数组件：普通 JS 函数，返回 JSX
类组件：继承 React.Component 的 class，必须写 render()

2. 状态管理

函数组件：useState / useReducer
类组件：this.state / this.setState

3. 副作用/生命周期

函数组件：useEffect 统一管理
类组件：componentDidMount / update / unmount

4. this 指向

函数组件：没有 this，完全不用管
类组件：必须处理 this 绑定，容易出 bug

5. 逻辑复用

函数组件：自定义 Hooks，完美复用
类组件：高阶组件、render-props，嵌套复杂

6. 性能 & 未来

函数组件：轻量、易编译、React 未来主推
类组件：相对笨重，未来会逐步减少使用

二、最直观代码对比

函数组件（简洁）

function App() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    // 逻辑
  }, []);

  return <div>{count}</div>
}

类组件（繁琐）

class App extends React.Component {
  constructor() {
    super();
    this.state = { count: 0 };
  }

  componentDidMount() {}
  componentDidUpdate() {}
  componentWillUnmount() {}

  render() {
    return <div>{this.state.count}</div>
  }
}

三、满分总结

函数组件是函数，类组件是 class；
函数组件用 Hooks 管理状态，类组件用 this.state；
函数组件无 this，类组件必须处理 this 指向；
函数组件逻辑复用靠自定义 Hooks，类组件靠高阶组件；
函数组件代码更简洁、性能更好，是 React 官方未来标准。

一句话记住

函数组件 = 简洁 + Hooks + 无this + 未来主流类组件 = 繁琐 + 生命周期 + this + 逐步淘汰

ref 和 reactive 的区别？什么时候用哪个？

Tue, 20 Jan 2026 16:40:43 GMT

ref vs reactive

| | ref | reactive | |:---|:---|:---| | 数据类型 | 任意（推荐基础类型） | 仅对象/数组 | | 访问方式 | .value | 直接访问属性 | | 解构/展开 | 保持响应式（需 .value） | 丢失响应式 | | 适用场景 | 单个值、原始类型、需要替换整个对象 | 复杂对象、表单数据 |

代码对比

// ref: 包装成对象，通过 .value 读写
const count = ref(0);
console.log(count.value);  // 读取
count.value++;             // 修改

const user = ref({ name: 'Tom' });
user.value.name = 'Jerry';  // 修改属性
user.value = { name: 'Bob' }; // 替换整个对象 ✅

// reactive: 代理对象，直接访问
const state = reactive({ count: 0, name: 'Tom' });
console.log(state.count);  // 直接读
state.count++;             // 直接改

// 不能替换整个对象
state = { count: 1 };  // ❌ 报错

关键陷阱：解构丢失响应式

// reactive 解构 = 响应式丢失
const state = reactive({ x: 1, y: 2 });
const { x, y } = state;  // x, y 变成普通数字

// ref 解构 .value 也丢失
const pos = ref({ x: 1, y: 2 });
const { x, y } = pos.value;  // 同样丢失

// ✅ 解决方案：toRefs
import { toRefs } from 'vue';
const { x, y } = toRefs(reactive({ x: 1, y: 2 }));
// x, y 是 ref，保持响应式

选择指南

| 场景 | 推荐 | 原因 | |:---|:---|:---| | 数字、字符串、布尔 | ref | 语义清晰 | | 对象需要整体替换 | ref | user.value = newUser | | 复杂对象、嵌套数据 | reactive | 代码简洁，不用写 .value | | 表单数据 | reactive | 字段多，直接访问方便 | | 从函数返回响应式数据 | ref | 解构安全 |

一句话

简单值用 ref（记得 .value），复杂对象用 reactive（别解构）。

db9.ai

Mon, 19 Jan 2026 17:11:57 GMT

dbb.ai 是什么？

把本地 SQLite 数据库变成云端 API 服务

一句话解释

不用装 MySQL/Postgres，直接用 SQLite 文件，但通过网址访问

传统: 本地 app → 读写 local.db 文件

dbb.ai: 你的代码 → HTTP 请求 → 云端 SQLite → 返回 JSON

代码对比

传统 SQLite（本地）

// 只能本机用，无法多人同时访问
const sqlite3 = require('sqlite3');
const db = new sqlite3.Database('./local.db');

db.get('SELECT * FROM users', (err, row) => {
  console.log(row);
});

dbb.ai（云端）

// 任何设备、任何语言都能访问
const db = createClient({
  url: 'https://xxx.dbb.ai',
  token: '你的密钥'
});

// 一样的 SQL，返回 Promise
const { rows } = await db.execute('SELECT * FROM users');
// rows = [{id: 1, name: 'Tom'}, ...]

解决什么问题？

| 场景 | 方案 | |:---|:---| | 快速搭个后端 | 不用买服务器，dbb.ai 直接当数据库 | | 小程序/APP | 前端直接调 API，不用写后端代码 | | 边缘函数 (Worker) | SQLite 轻量，冷启动快 | | 原型开发 | 5 分钟上线，按量付费 |

实际例子：留言板

// Cloudflare Worker + dbb.ai = 完整后端
export default {
  async fetch(request) {
    const db = createClient({ url, token });
    
    // GET /messages → 查留言
    if (request.method === 'GET') {
      const { rows } = await db.execute(
        'SELECT * FROM messages ORDER BY time DESC'
      );
      return Response.json(rows);
    }
    
    // POST /messages → 写留言
    const { text } = await request.json();
    await db.execute(
      'INSERT INTO messages (text, time) VALUES (?, ?)',
      [text, Date.now()]
    );
    return Response.json({ ok: true });
  }
};

结果：没买服务器，没配数据库，一个 Worker 文件搞定。

核心优势

| 对比 | 结果 | |:---|:---| | vs MySQL/Postgres | 零配置，按请求付费，不是按实例 | | vs Firebase | 标准 SQL，不用学新语法 | | vs 自己搭 SQLite | 自动备份、多并发、全球访问 |

dbb.ai = SQLite 文件 + HTTP 接口 = 最简单的云端数据库

Resend API

Mon, 19 Jan 2026 17:09:06 GMT

Resend API

开发者友好的邮件发送服务，简洁 API + 高送达率。

核心特性

| 特性 | 说明 | |:---|:---| | 极简 API | 一行代码发邮件 | | React Email | JSX 编写邮件模板 | | 高送达率 | 自动 DKIM/SPF/DMARC | | 免费额度 | 3,000 封/月 |

快速开始

npm install resend

import { Resend } from 'resend';

const resend = new Resend('re_xxxxxxxx');

// 发送纯文本
await resend.emails.send({
  from: 'onboarding@yourdomain.com',
  to: 'user@example.com',
  subject: 'Hello',
  text: '欢迎！',
});

// 发送 HTML
await resend.emails.send({
  from: 'noreply@yourdomain.com',
  to: ['user1@a.com', 'user2@b.com'],
  subject: '订单确认',
  html: '<h1>感谢您的订单</h1>',
});

React Email（推荐）

npm install @react-email/components

// emails/Welcome.tsx
import { Html, Button, Text } from '@react-email/components';

export default function Welcome({ name, url }) {
  return (
    <Html>
      <Text>Hi {name},</Text>
      <Button href={url}>确认邮箱</Button>
    </Html>
  );
}

// 发送 JSX 邮件
import Welcome from './emails/Welcome';

await resend.emails.send({
  from: 'team@yourdomain.com',
  to: 'user@example.com',
  subject: '欢迎加入',
  react: <Welcome name="John" url="https://verify.com" />,
});

批量发送

// 批量 + 延迟
await resend.batch.send([
  { from, to: 'a@a.com', subject, html },
  { from, to: 'b@b.com', subject, html },
  { from, to: 'c@c.com', subject, html },
]);

与 Cloudflare Worker 结合

export default {
  async fetch(request, env) {
    const resend = new Resend(env.RESEND_API_KEY);
    
    await resend.emails.send({
      from: 'alert@yourdomain.com',
      to: 'admin@example.com',
      subject: '服务器告警',
      text: await request.text(),
    });
    
    return new Response('Sent');
  }
};

总结

Resend = 极简代码发邮件 + React JSX 写模板，3分钟集成，3千封免费。

Cloudflare Email Routing + Worker

Mon, 19 Jan 2026 17:07:59 GMT

Cloudflare Email Routing + Worker

架构

收到邮件 → Email Routing → 触发 Worker → 自定义处理
                ↓
           转发/丢弃/回复/存储/调用API

1. Email Routing 配置

Cloudflare Dashboard → Email → Email Routing
    ↓
Catch-all 地址: *@yourdomain.com → 转发到 Worker

2. Worker 接收邮件

// worker.js
export default {
  async email(message, env, ctx) {
    // message: 邮件对象
    const {
      from,      // 发件人
      to,        // 收件人
      headers,   // 原始头
      raw,       // 原始内容
      rawSize,   // 大小
    } = message;

    // 读取内容
    const text = await message.text();
    const html = await message.html();

    // 处理逻辑
    if (text.includes('验证码')) {
      await env.DB.prepare('INSERT INTO codes (email, code) VALUES (?, ?)')
        .bind(from, extractCode(text)).run();
    }

    // 转发到 Gmail
    await message.forward('backup@gmail.com');
    
    // 或回复
    await message.reply({
      from: 'bot@yourdomain.com',
      subject: 'Re: ' + message.headers.get('subject'),
      text: '收到，处理中...',
    });
  }
};

3. wrangler.toml 配置

name = "email-worker"
main = "worker.js"

[[email]]
name = "catch-all"
destination = "worker"

# 绑定存储
[[d1_databases]]
binding = "DB"
database_name = "emails"
database_id = "xxx"

典型场景

| 场景 | 代码 | |:---|:---| | 自动回复 | message.reply({...}) | | 过滤垃圾 | if (spamCheck(raw)) message.setReject('Spam') | | 提取数据 | await message.text() 正则匹配 | | 存储归档 | await env.R2.put(key, raw) | | 触发 webhook | fetch('https://api.com/notify', {body: json}) |

总结

Email Routing 收邮件 → Worker 写代码处理 → 转发/回复/存存储/调API，无服务器邮件自动化。

raise

Fri, 16 Jan 2026 14:38:26 GMT

`raise` 的本质

raise = 触发异常 + 中断当前执行流 + 向上层传递错误

基础语法

1. 抛出异常实例（最常用）

raise HTTPException(status_code=404, detail="Not found")
#     └───────────┘  └─────────────────────────────┘
#       异常类           构造函数的参数

2. 抛出异常类（自动实例化）

raise ValueError          # 等价于 raise ValueError()
raise ValueError("msg")   # 带消息的实例

3. 重新抛出当前异常（在 except 块中）

try:
    risky()
except:
    print("记录日志")
    raise   # ← 不加参数，把捕获的异常继续向上抛

执行流程：程序如何"炸"

正常执行流 ─────────────────────────►
              │
              ▼
         遇到 raise
              │
              ▼
    ┌─────────────────┐
    │  创建异常对象      │
    │  携带错误信息      │
    └─────────────────┘
              │
              ▼
    ┌─────────────────┐
    │  中断当前函数      │  ◄── 后面代码不执行！
    │  开始向上层逃逸    │
    └─────────────────┘
              │
              ▼
    每层检查: 有 try-except? ──► 有 → 捕获处理
              │                    │
              无                    ▼
              │              继续向上层逃逸
              ▼
         到达最顶层
              │
              ▼
         程序崩溃/500错误

代码示例：层层逃逸

# 第3层：最底层，抛出异常
def get_item(item_id):
    if item_id > 10:
        raise HTTPException(status_code=404, detail="Not found")
    return item_id

# 第2层：中间层，继续抛（或处理）
def process(item_id):
    result = get_item(item_id)  # ← 这里可能收到异常
    return result * 2

# 第1层：最上层，最终处理
@app.get("/items/{item_id}")
async def read_item(item_id: int):
    try:
        value = process(item_id)   # ← 异常向上传到这儿
        return {"value": value}
    except HTTPException:
        raise                      # ← 再抛给 FastAPI 处理

调用 read_item(99) 的执行栈：

get_item(99) 中 raise HTTPException
        │
        ▼ 向上逃逸
process(99) 的 get_item(item_id) 调用点
        │
        ▼ 继续向上
read_item(99) 的 process(item_id) 调用点
        │
        ▼ 被 try-except 捕获
except HTTPException 捕获到
        │
        ▼ 重新 raise
FastAPI 异常处理器捕获 → 返回 404 JSON

与其他语言对比

| 语言 | 语法 | 特点 | |------|------|------| | Python | raise ValueError("msg") | 必须抛异常对象或类 | | Java | throw new Exception("msg") | 必须抛对象 | | JavaScript | throw "msg" / throw new Error() | 可抛任何值 | | Go | return err | 无 raise，显式返回错误 |

高级用法

异常链（保留原始错误）

try:
    int("not a number")
except ValueError as e:
    raise HTTPException(400, "Invalid ID") from e
#     └────────────────────────────────────────┘
#              新异常 ← 原始异常

效果： 日志显示完整链条：

HTTPException: Invalid ID
caused by ValueError: invalid literal for int()

自定义异常 + raise

class BusinessError(Exception):
    def __init__(self, code, message):
        self.code = code
        self.message = message

# 使用
raise BusinessError(1001, "库存不足")

关键记忆点

raise = 扔出一个"炸弹"
        │
        ├── 立即炸停当前函数
        │
        ├── 携带错误信息向上飞
        │
        └── 直到被 try-except 接住，或炸毁程序

一句话总结

raise 是 Python 的错误信号弹，触发后立即中断当前执行，携带错误信息向上层传递，直到被捕获处理或导致程序终止。

yield

Mon, 12 Jan 2026 14:19:41 GMT

`yield` 的核心作用：暂停与恢复

普通 return: 函数执行 → 返回值 → 函数结束（内存释放）
yield:       函数执行 → 产出值 → 暂停等待 → 被唤醒后继续执行

具体对比

❌ 如果用 `return`（错误）

def get_db():
    db = "数据库连接"
    return db           # ← 函数到这里就结束了！
    # 下面这行永远不会执行
    db = "关闭连接"     # ❌ 死代码，资源无法释放

结果： 数据库连接永远无法关闭，造成连接泄漏

✅ 用 `yield`（正确）

def get_db():
    db = "数据库连接"
    try:
        yield db        # ← 暂停！产出值，但函数不结束
    finally:
        db = "关闭连接" # ← 路由结束后，从这里继续执行

执行流程可视化

时间线 ─────────────────────────────────────────►

get_db() 开始
    │
    ▼
db = "数据库连接"  ◄── 创建资源
    │
    ▼
yield db           ◄── 【暂停点】产出值给路由函数
    │                  │
    │                  ▼
    │            read_items(db=...) 执行中
    │                  │
    │                  ▼
    │            路由函数完成
    │
    ▼ 【恢复执行】
finally:
    db = "关闭连接"  ◄── 清理资源（一定执行）

关键特性：上下文保持

def get_db():
    db = create_expensive_connection()  # 第1步：创建
    print("连接已创建")
    
    yield db                            # 第2步：交出控制权（暂停）
    
    # ↓↓↓ 路由结束后，从这里继续 ↓↓↓
    print("准备清理")
    db.close()                          # 第3步：清理
    print("连接已关闭")

输出顺序：

连接已创建      ← yield 之前
[路由函数执行中]  ← yield 暂停期间
准备清理        ← 路由结束后恢复
连接已关闭      ← 最终清理

类比理解

| 类比 | 解释 | |------|------| | 游戏存档点 | yield = 存档，下次从存档点继续，不是从头开始 | | 租借物品 | 借出（yield）→ 对方使用 → 归还后你做检查（finally）| | 协程/生成器 | Python 生成器的基础机制，支持双向通信 |

配合 `try...finally` 的威力

def get_db():
    db = connect()
    try:
        yield db
        # 如果路由函数正常完成，执行到这里
    except Exception:
        # 如果路由函数抛出异常，也能捕获
        raise
    finally:
        db.close()  # ✅ 无论成功/失败，100%执行

这是 Python 中资源管理的最佳实践模式，比 __enter__/__exit__ 上下文管理器更简洁。

一句话总结

yield 让函数变成"可暂停的"，使得 FastAPI 能在请求处理前后自动执行 setup/teardown 逻辑，实现声明式的资源生命周期管理。

Vue 2 和 Vue 3 的核心区别

Thu, 01 Jan 2026 16:46:12 GMT

Vue 2 vs Vue 3 核心区别

| | Vue 2 | Vue 3 | |:---|:---|:---| | 响应式 | Object.defineProperty | Proxy | | 新增属性 | 需 Vue.set | 自动响应 | | 数组索引 | 检测不到 | 原生支持 | | API 风格 | Options API | Options + Composition API | | 逻辑复用 | Mixins（易冲突） | Composables（清晰） | | TypeScript | 支持差 | 原生支持 | | 性能 | 初始化递归遍历 | 懒代理，更快 | | Tree-shaking | 差 | 更好（按需编译）| | 多根节点 | ❌ 单根 | ✅ 多根 <template> | | Teleport | ❌ | ✅ | | Suspense | ❌ | ✅ |

代码对比

响应式

// Vue 2
Vue.set(obj, 'newKey', value);  // 新增属性需特殊方法
arr[0] = 1;  // 检测不到

// Vue 3
obj.newKey = value;  // 直接赋值，自动响应
arr[0] = 1;  // 正常检测

API 风格

// Vue 2: Options API
export default {
  data() { return { count: 0 }; },
  methods: { increment() { this.count++; } },
  computed: { double() { return this.count * 2; } }
};

// Vue 3: Composition API
import { ref, computed } from 'vue';

export default {
  setup() {
    const count = ref(0);
    const double = computed(() => count.value * 2);
    const increment = () => count.value++;
    
    return { count, double, increment };
  }
};

一句话

Vue 3 = Proxy 响应式 + Composition API + 更好的 TS 支持 + 新特性（Teleport/Suspense）

React.memo vs useMemo 区别

Thu, 04 Dec 2025 23:59:17 GMT

一句话总结：React.memo 是缓存「整个组件」，useMemo 是缓存「组件内的计算值/函数」，一个管组件，一个管数据，用途完全不同。

1. 核心定义与本质

🧩 React.memo

类型：高阶组件 (HOC)
作用：缓存组件本身，防止组件不必要的重新渲染
使用场景：给函数组件做性能优化，避免父组件渲染时子组件无脑跟着重渲染
缓存目标：组件的渲染结果（UI）

🧮 useMemo

类型：React Hook
作用：缓存「昂贵计算的结果」，避免每次渲染都重复计算
使用场景：组件内耗时的计算逻辑、需要稳定引用的对象/数组
缓存目标：变量/值

2. 语法对比

React.memo（包裹整个组件）

// 缓存整个子组件，props 不变就不重新渲染
const Child = React.memo(function Child({ name }) {
  return <div>{name}</div>;
});

useMemo（组件内使用，缓存值）

function Parent() {
  const [count, setCount] = useState(0);

  // 缓存昂贵计算结果，依赖项不变就不重新计算
  const expensiveValue = useMemo(() => {
    console.log("只在依赖变化时执行");
    return count * 2; // 模拟耗时计算
  }, [count]); // 依赖数组

  return <div>{expensiveValue}</div>;
}

3. 关键区别对照表

4. 最直观的使用场景

✅ 用 React.memo 的场景

子组件是纯展示组件，props 不变就不需要重新渲染：

// 父组件渲染时，Child 只要 props 不变就不重渲染
const Parent = () => {
  const [num, setNum] = useState(1);
  return (
    <>
      <button onClick={() => setNum(num+1)}>加一</button>
      {/* 子组件被 memo 缓存 */}
      <Child name="小明" />
    </>
  );
};
// 包裹子组件
const Child = React.memo(({ name }) => {
  console.log("子组件渲染"); // 只有 props 变才会打印
  return <div>{name}</div>;
});

✅ 用 useMemo 的场景

组件内有耗时计算，不想每次渲染都重新算：

const List = ({ data }) => {
  // 过滤大量数据是耗时操作，用 useMemo 缓存结果
  const filteredList = useMemo(() => {
    return data.filter(item => item.value > 100);
  }, [data]); // 仅 data 变化时重新过滤

  return <div>{filteredList.map(item => <div key={item.id}>{item.name}</div>)}</div>;
};

5. 重要注意事项

不要滥用：
- 简单组件、轻量计算，用它们反而增加性能开销（缓存本身有成本）
- 只给频繁重渲染的子组件用 React.memo
- 只给耗时计算用 useMemo
都是浅比较：
- React.memo 浅比较 props
- useMemo 浅比较依赖项
- 传递对象/数组时，需要配合 useMemo/useCallback 保证引用不变
本质不同：
- React.memo = 组件级缓存
- useMemo = 数值级缓存

总结

React.memo：给组件瘦身，防止子组件无效重渲染
useMemo：给计算瘦身，防止重复执行昂贵逻辑
二者互补，不是二选一，可在项目中配合使用

useEffect 依赖数组判断机制

Fri, 28 Nov 2025 13:40:25 GMT

一句话核心结论

React 对依赖数组里的每一项，都做「全等比较（===）」，只要有任意一项变了，effect 就重新执行。

1. 底层判断规则

每次组件渲染，React 都会做这 3 步：

记录上一次的依赖数组 [a, b, c]
拿到本次新的依赖数组 [a, b, c]
逐项进行 === 比较
- 全部相等 → 不执行 effect
- 任意一个不等 → 执行 effect

关键：是「全等比较」，不是「值相等」

// 基本类型：值相同 → === 相等 → 判定不变
1 === 1 → true
'abc' === 'abc' → true

// 引用类型：地址相同 → === 相等
// 地址不同 → 即使内容一样，也判定变化！
{} === {} → false
[] === [] → false
()=>{} === ()=>{} → false

2. 不同数据类型的判断结果

① 基本类型（数字、字符串、布尔、null、undefined）

直接比较值，值不变 → 判定不变

// 只会在 count 真正变化时执行
useEffect(() => {
  console.log(count);
}, [count]);

② 引用类型（对象、数组、函数）

比较内存地址，地址变了 → 判定变化 这是 90% 的 bug 来源！

// 每次渲染都创建新对象 → 地址变 → effect 每次都执行！
useEffect(() => {
  console.log('我每次渲染都跑！');
}, [{ name: 'react' }]); 

// 每次渲染都创建新数组 → effect 每次执行
useEffect(() => {
  console.log('我每次渲染都跑！');
}, [[1,2,3]]);

3. 最容易踩坑的 3 个场景

坑 1：直接在依赖里写对象/数组

function App() {
  const [count, setCount] = useState(0);

  // ❌ 错误：每次渲染都是新对象，effect 无限执行
  useEffect(() => {
    console.log('执行');
  }, [{ id: 1 }]);
}

解决方案：用 useMemo 缓存对象/数组

const obj = useMemo(() => ({ id: 1 }), []);
useEffect(() => {
  console.log('执行');
}, [obj]); // ✅ 地址不变

坑 2：依赖里写函数（每次渲染都是新函数）

// ❌ 错误
useEffect(() => {
  fetchData();
}, [fetchData]);

解决方案：用 useCallback 缓存函数

const fetchData = useCallback(() => { ... }, []);
useEffect(() => {
  fetchData();
}, [fetchData]); // ✅ 地址不变

坑 3：空依赖数组 `[]`

所有项都不变 → 只在组件挂载执行一次，卸载清理一次

4. 完整执行流程图

组件初次渲染 → 执行 effect
组件更新 → 生成新依赖数组
React 逐项 === 对比新旧依赖
- 全相等 → 不执行
- 有一个不等 → 先执行清理函数 → 再执行新 effect

总结

useEffect 依赖判断用 === 全等比较
基本类型比数值，引用类型比内存地址
对象/数组/函数必须用 useMemo / useCallback 缓存，否则会重复执行
空依赖 [] = 只执行一次

Fiber 架构工作原理

Sat, 22 Nov 2025 03:08:44 GMT

一句话总结： Fiber 就是把原来一次性同步阻塞的渲染，改成可中断、可恢复、可调度的异步任务，让浏览器不卡顿。

1. 为什么要有 Fiber？

React 16 之前叫 Stack Reconciler（栈协调器）

虚拟 DOM diff 是同步递归执行的
一旦开始，就必须执行完，中途不能停
计算量大时，JS 会阻塞浏览器渲染、交互（掉帧、卡顿）

Fiber 要解决的核心问题： 让 React 的更新任务可以被打断、优先保证高优任务（点击、输入），再回头继续渲染。

2. Fiber 核心概念

① Fiber Node

每个 React 元素，都会对应一个 Fiber 节点，它是一个普通 JS 对象，包含：

type：组件类型
props：属性
child / sibling / return：构成链表树
alternate：新旧 Fiber 树的连接（双缓冲）
effectTag：标记要做什么操作（新增、删除、更新）
priority：任务优先级

② Fiber 树 = 链表结构

不再是递归树，而是单链表：

child：第一个子节点
sibling：兄弟节点
return：父节点

这样遍历不需要递归栈，可以随时暂停/继续。

3. Fiber 两大阶段（最关键）

Fiber 把整个更新流程切成两阶段：

阶段一：Reconciliation / Render 阶段（可中断）

做 diff，生成 Fiber 树，标记副作用

遍历 Fiber 树
对比新旧节点
标记每个节点：增/删/改
此阶段可以被高优任务打断
可能执行多次，不操作真实 DOM

阶段二：Commit 阶段（不可中断）

一次性把所有修改同步到真实 DOM

执行所有 effectTag
操作 DOM
执行生命周期 / useEffect
一旦开始必须执行完，保证 DOM 一致性

4. 调度机制：Scheduler（调度器）

Fiber 配合调度器实现：

给任务分优先级
- Immediate（最高，同步）
- UserBlocking（点击、输入）
- Normal（普通更新）
- Low
- Idle（最低）
利用 requestIdleCallback / MessageChannel 模拟时间切片
每执行一小段任务，就让出主线程给浏览器
有空再回来继续执行

一句话： 把一大坨计算，切成一小片一小片，浏览器有空就做，没空就先响应用户。

5. 工作流程（极简版）

触发更新（setState、props 变化）
Scheduler 分配优先级
进入 Render 阶段：
- 从根节点开始遍历 Fiber 链表
- diff 标记更新
- 时间片用完 → 暂停
- 高优任务来了 → 打断，先处理高优
Render 完成，得到副作用列表
进入 Commit 阶段：
- 一次性更新 DOM
- 执行 useEffect、useLayoutEffect

6. 与老架构 Stack 的区别

| 特性 | Stack 架构 | Fiber 架构 | |----|----|----| | 执行方式 | 同步递归 | 异步可中断 | | 能否暂停 | 不能 | 能 | | 能否恢复 | 不能 | 能 | | 优先级 | 无 | 支持优先级调度 | | 主线程阻塞 | 严重 | 极小 | | 遍历结构 | 树递归 | 链表循环 |

7. 一句话记住 Fiber

Fiber = 链表结构 + 可中断 Render + 优先级调度 + 不可中断 Commit 让 React 从“卡死式同步渲染”变成“流畅异步协作式渲染”。

为什么 React 需要 Fiber 而 Vue 不需要？

Sat, 08 Nov 2025 09:29:37 GMT

一句话结论

不是 Vue 不需要，而是两者解决卡顿的思路完全不一样： React 用 Fiber 做「异步可中断渲染」， Vue 用「响应式精准追踪」做到根本不需要大规模 diff，自然不卡。

1. 核心原因：两者更新机制天差地别

React：粗放式更新 → 必须 Fiber

React 是组件级更新：

setState 后，整个组件树从头开始重新渲染
要递归 diff 整棵虚拟 DOM 树
节点一多，diff 计算量巨大 → 主线程阻塞、页面卡顿

所以 React 必须搞 Fiber： 把大计算切碎、可中断、可调度，保证不卡死 UI。

Vue：精准式更新 → 不需要大规模 diff

Vue 是响应式依赖追踪：

数据变更时，Vue 精确知道哪个组件、哪个变量变了
只更新对应组件，不扩散渲染
diff 范围极小、计算极轻 → 计算量本来就小，根本不会阻塞主线程

所以 Vue 天然不需要 Fiber 这种重型架构。

2. 更本质的区别

React

函数式思想：UI = f(state)
状态变 → 重新跑函数 → 重新生成 VDOM
全量对比 → 计算量大 → 必须 Fiber 来“异步分片”解决卡顿

Vue

响应式思想：依赖收集
状态变 → 通知精确的组件更新
局部对比 → 计算量极小 → 同步渲染完全足够，不卡

3. 那 Vue 就完全没有类似机制吗？

有，但轻得多：

Vue 3 引入了：

Scheduler 调度队列
微任务批量更新
组件更新有优先级

但它不是 Fiber：

没有可中断渲染
没有时间切片
没有链表遍历结构
没有双缓冲树

因为根本用不上。

4. 超精简总结

React 更新是粗放的 setState → 整棵树重渲染、重 diff → 计算量大 → 必须用 Fiber 做异步可中断分片，防止卡顿。
Vue 更新是精准的 响应式依赖收集 → 只更新变化的组件 → diff 极轻 → 同步渲染足够流畅 → 不需要 Fiber。
不是 Vue 更高级，而是设计哲学不同： React 追求函数式简洁，代价是渲染量大，需要架构兜底； Vue 用响应式换精准更新，代价是代理/依赖收集复杂，但运行时更快更轻。

Vue3 响应式 vs Vue2

Sat, 27 Sep 2025 04:33:53 GMT

Vue3 vs Vue2 响应式核心差异

| 特性 | Vue2 | Vue3 | |:---|:---|:---| | 实现方式 | Object.defineProperty | Proxy | | 拦截范围 | 已有属性 | 整个对象（含新增/删除） | | 数组支持 | 重写 7 个方法（push/pop等） | 原生支持索引和 length | | Map/Set | ❌ 不支持 | ✅ 原生支持 | | 性能 | 初始化递归遍历 | 懒代理（访问时才创建）| | 兼容性 | IE9+ | 现代浏览器（IE 不支持）|

关键代码对比

Vue2：递归劫持

// 初始化时遍历所有属性
function observe(obj) {
  Object.keys(obj).forEach(key => {
    defineReactive(obj, key, obj[key]);
    if (typeof obj[key] === 'object') {
      observe(obj[key]); // 递归
    }
  });
}

// 数组需特殊处理
const arrayMethods = ['push', 'pop', 'splice' /*...*/];
arrayMethods.forEach(method => {
  // 重写方法以触发更新
});

痛点：新增属性需 Vue.set，数组索引修改检测不到。

Vue3：Proxy 懒代理

function reactive(target) {
  return new Proxy(target, {
    get(target, key, receiver) {
      track(target, key);           // 依赖收集
      const result = Reflect.get(target, key, receiver);
      return isObject(result) 
        ? reactive(result)          // 懒递归：访问时才代理
        : result;
    },
    set(target, key, value, receiver) {
      const result = Reflect.set(target, key, value, receiver);
      trigger(target, key);         // 触发更新
      return result;
    }
    // 自动支持 delete、has、ownKeys 等
  });
}

优势：新增/删除属性自动响应，数组原生支持。

Vue3 不需要时间分片的原因

Tue, 23 Sep 2025 15:18:25 GMT

Vue3 不需要时间分片的原因

// React：不知道谁变了，必须遍历整棵树
function App() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <A />      // 必须检查
      <B />      // 必须检查
      <C count={count} />  // 只有这里变
    </div>
  ); // 更新路径：App → A → B → C（全走一遍）
}

// Vue3：精确追踪，只更新用到的
<template>
  <A />        <!-- 不更新 -->
  <B />        <!-- 不更新 -->
  <C :count="count" />  <!-- 只有这里更新 -->
</template>

// 响应式系统建立依赖图谱
count: [C组件]  // 只通知C

核心对比

| | React | Vue3 | |:---|:---|:---| | 更新粒度 | 组件级（粗） | 依赖级（细） | | 遍历范围 | 整棵树 | 仅订阅组件 | | 时间分片 | 需要（遍历可能阻塞） | 不需要（路径极短） |

Vue3 的异步批处理（足够用了）

const state = reactive({ count: 0 });

state.count++;  // 加入队列
state.count++;  // 合并
state.count++;  // 合并

// 微任务阶段：只渲染一次
Promise.resolve().then(() => {
  // 批量更新 DOM
});

React 遍历成本高 → 需要中断
Vue3 更新成本天然低 → 无需中断

Vue 有了响应式为何还要 Diff？

Wed, 10 Sep 2025 21:06:13 GMT

Vue 有响应式为何还要 Diff？

响应式知道哪个组件要更新，Diff 决定怎么更新 DOM。

两者职责

| | 作用 | 解决什么问题 | |:---|:---|:---| | 响应式 | 追踪数据 → 定位组件 | 哪个组件需要更新 | | Diff | 对比 VDOM → 最小化 DOM 操作 | 如何高效更新该组件 |

代码示例

// 响应式：知道 Child 组件要更新
const state = reactive({ list: [{ id: 1, text: 'a' }] });

// 状态变化
state.list.push({ id: 2, text: 'b' });  // 通知 Child 更新

// Child 渲染新 VDOM
// 旧: [li#a]  
// 新: [li#a, li#b]

// Diff：对比新旧 VDOM，只插入新 li，复用旧 li
// 而非清空整个 ul 重新创建

Teleport 与 Suspense

Wed, 27 Aug 2025 09:40:24 GMT

Teleport vs Suspense

| | Teleport | Suspense | |:---|:---|:---| | 作用 | 改变渲染位置（DOM 移动） | 处理异步依赖（加载状态） | | 解决 | 模态框/通知等脱离父组件层级 | 异步组件/数据加载的优雅降级 | | 状态 | 同步，立即渲染 | 异步，等待完成 |

代码对比

Teleport：DOM 位置转移

<!-- 组件内声明，渲染到 body 下 -->
<template>
  <div class="parent">
    <!-- 遮罩层逻辑在组件内，但 DOM 跑到 body 下 -->
    <Teleport to="body">
      <div class="modal">弹窗内容</div>
    </Teleport>
  </div>
</template>

<!-- 结果 DOM -->
<body>
  <div id="app">...</div>
  <div class="modal">弹窗内容</div>  <!-- 在这里！ -->
</body>

场景：模态框、通知、全屏遮罩（避免 z-index 嵌套问题）

Suspense：异步加载状态

<template>
  <Suspense>
    <!-- 默认：异步完成显示 -->
    <AsyncComponent />
    
    <!-- 加载中显示 -->
    <template #fallback>
      <div>Loading...</div>
    </template>
  </Suspense>
</template>

<script setup>
// 异步组件
const AsyncComponent = defineAsyncComponent(() => 
  import('./HeavyComponent.vue')
);
</script>

场景：代码分割、数据获取、骨架屏

组合使用

<template>
  <Suspense>
    <template #default>
      <AsyncModal />
    </template>
    <template #fallback>
      <Teleport to="body">
        <div class="loading-overlay">加载中...</div>
      </Teleport>
    </template>
  </Suspense>
</template>

Teleport = 去哪儿渲染
Suspense = 什么时候渲染

type vs interface 关键区别

Thu, 17 Jul 2025 16:19:12 GMT

`type` vs `interface` 关键区别

| 特性 | interface | type | |:---|:---|:---| | 扩展方式 | extends（声明合并） | &（交叉类型） | | 同名声明 | ✅ 自动合并 | ❌ 报错（重复定义） | | 适用场景 | 对象结构、类实现 | 联合类型、元组、复杂类型运算 | | 性能 | 更快（声明合并优化） | 稍慢（需解析类型表达式） |

核心差异示例

1. 扩展方式

// interface: extends 声明式扩展
interface Animal { name: string }
interface Dog extends Animal { breed: string }

// type: & 交叉类型
type Animal = { name: string }
type Dog = Animal & { breed: string }

2. 同名合并（interface 独有）

// ✅ interface 自动合并
interface User { name: string }
interface User { age: number }  // 合并为 { name, age }

// ❌ type 报错
type User = { name: string }
type User = { age: number }     // Error: 重复标识符

3. type 独有能力

// 联合类型（interface 做不到）
type Status = 'pending' | 'success' | 'error';

// 元组
type Point = [number, number];

// 条件类型
type IsString<T> = T extends string ? true : false;

// 映射类型
type ReadonlyUser = Readonly<User>;

选择建议

| 场景 | 推荐 | |:---|:---| | 定义对象结构、类 | interface | | 需要多次扩展同一类型 | interface | | 联合类型、元组、条件类型 | type | | 第三方库类型声明 | interface（支持用户扩展） |

Webpack 5 模块联邦（Module Federation）

Sun, 29 Jun 2025 07:12:50 GMT

Webpack 5 模块联邦（Module Federation）

核心能力：运行时动态加载远程模块，实现微前端独立部署。

架构角色

| 角色 | 作用 | 配置 | |:---|:---|:---| | Host（宿主） | 消费远程模块 | remotes | | Remote（远程） | 暴露自身模块供他人使用 | exposes | | Shared（共享） | 依赖共享，避免重复加载 | shared |

代码示例

Remote 暴露模块（独立部署）

// webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'remoteApp',           // 远程应用名称
      filename: 'remoteEntry.js',   // 入口文件
      exposes: {
        './Button': './src/Button', // 暴露的模块
        './utils': './src/utils',
      },
      shared: ['react', 'react-dom'], // 共享依赖
    }),
  ],
};

Host 消费远程模块

// webpack.config.js
module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'hostApp',
      remotes: {
        // 运行时动态加载
        remoteApp: 'remoteApp@http://localhost:3001/remoteEntry.js',
      },
      shared: ['react', 'react-dom'],
    }),
  ],
};

// 组件中使用远程模块
import React, { lazy, Suspense } from 'react';

// 动态导入远程组件
const RemoteButton = lazy(() => import('remoteApp/Button'));

function App() {
  return (
    <Suspense fallback="Loading...">
      <RemoteButton />  {/* 来自另一个部署！ */}
    </Suspense>
  );
}

共享依赖机制

场景：Host 和 Remote 都依赖 React

无 shared：各自打包 React，页面加载 2 份（体积大）
有 shared：运行时协商版本，只加载 1 份（自动降级/升级）

shared: {
  react: { 
    singleton: true,      // 强制单例
    requiredVersion: '^18.0.0',
    version: '18.2.0',    // 自身版本
  },
}

顺序表 + 链表

Thu, 10 Apr 2025 13:43:34 GMT

先记住一句话

线性表 = 一排排好队的东西。 就像：

排队买饭
一串珠子
一排座位

特点只有 3 个：

排成一条直线
有头有尾
中间每个人只有前面一个、后面一个

这就叫线性表。

线性表有两种排队方式

1. 顺序表（像一排固定座位）

想象：电影院一排座位，连在一起、不能拆开。

优点：

想找第 5 个人，直接走过去，很快。

缺点：

中间要加人、走人，所有人都要挪位置，麻烦。

对应：数组

2. 链表（像手拉手排队）

每个人只知道：

我是谁
我后面是谁

大家不坐在一起，但手拉手连起来。

优点：

中间加人、走人，只要改一下谁拉谁的手，很快。

缺点：

想找第 5 个人，必须从头一个一个数，慢。

对应：链表

最简单总结（必背）

线性表 = 一排东西
顺序表 = 连续座位，找得快，插删慢
链表 = 手拉手，插删快，找得慢

Cookie / Session / JWT 的差异是什么？登录态方案怎么选？

Wed, 09 Apr 2025 17:11:32 GMT

先澄清一个常见误区：Cookie 是“存/带数据的方式”，Session 和 JWT 是“登录态实现方式”。

| 项目 | Cookie | Session | JWT | |---|---|---|---| | 本质 | 浏览器存储+自动随请求发送 | 服务端保存登录状态 | 自包含的签名令牌 | | 状态存哪 | 客户端（浏览器） | 服务端（Redis/内存/DB） | 主要在令牌里（客户端持有） | | 服务端每次查库/查存储 | 视内容而定 | 通常要（按 sessionId 查） | 通常不用（验签即可） | | 失效/登出控制 | 通过过期或删除 | 很容易，删 session 即可 | 较难，常靠短期过期+黑名单/轮换 | | 典型风险 | 被窃取、CSRF（若自动带） | 会话固定、会话存储压力 | 泄露后可被重放到过期，撤销困难 |

关键差异：

Session：最容易做“可控下线/封禁/踢人”，但有服务端状态成本。
JWT：跨服务、无状态扩展好，但撤销难，设计不当安全风险更高。
Cookie：可承载 sessionId 或 JWT；不是 Session/JWT 的对立面。

怎么选（实战）：

传统 Web 后台、管理系统：优先 Session + HttpOnly + Secure + SameSite Cookie。
多端/API 网关/微服务：短期 Access JWT + Refresh Token（刷新令牌要轮换）。
安全要求高且要随时失效：优先 Session 或“opaque token + introspection”。
Web 端尽量不要把长期 token 放 localStorage（XSS 风险高）。

TypeScript 里 any / unknown / never 的区别和典型使用场景？

Wed, 09 Apr 2025 17:09:27 GMT

最短理解：

any：放弃类型检查（“我不管了”）
unknown：暂时不知道类型，但必须先判断再用（“先验明身份”）
never：不可能有值（“走不到这里”）

any

含义：可赋给任何类型，也可接收任何类型；基本跳过 TS 保护。
场景：迁移旧代码、临时兜底、第三方无类型声明时短期过渡。
风险：错误容易溜进运行时。

unknown

含义：类型安全版“未知值”；不能直接调用属性/方法，必须先缩小类型。
场景：接口返回不可信数据、catch (e)、解析外部输入（JSON/表单/消息）。
优点：强制你做类型守卫，更安全。

never

含义：永远不会出现的值类型。
场景：
- 永不返回的函数（throw / 死循环）
- switch 穷尽检查（确保联合类型每种分支都处理了）
- 条件类型中表示“被过滤掉的分支”

典型示例（never 做穷尽检查）：

type Shape = { kind: 'circle'; r: number } | { kind: 'square'; s: number };

function area(shape: Shape) {
  switch (shape.kind) {
    case 'circle': return Math.PI * shape.r ** 2;
    case 'square': return shape.s ** 2;
    default: {
      const _exhaustive: never = shape; // 新增 kind 未处理会在这里报错
      return _exhaustive;
    }
  }
}

实践建议：

默认优先 unknown，少用 any。
any 用在边界层并尽快收口。
对联合类型养成 never 穷尽检查习惯。

useEffect 依赖项写错常见会引发哪些 bug？如何避免闭包陷阱？

Wed, 09 Apr 2025 17:06:45 GMT

useEffect 依赖写错，最常见会出这几类 bug：

值“过期”（stale closure）
effect 里拿到旧的 state/props，比如定时器里 count 永远是旧值。
不触发更新
漏了依赖，参数变了但 effect 不重跑，请求/订阅不更新。
死循环或频繁重跑
把每次 render 都新建的对象/函数放进依赖，导致反复请求、反复 setState。
资源泄漏
重跑时没正确清理，出现重复订阅、重复定时器、内存泄漏。
异步竞态
前一次慢请求后返回，覆盖后一次快请求结果（显示“旧数据”）。

避免闭包陷阱的实用做法：

开启并遵守 eslint-plugin-react-hooks 的 exhaustive-deps。
effect 里用到的响应式值（props/state）都写进依赖。
需要“基于上次值更新”时，用函数式更新：setCount(c => c + 1)。
不想因某值变化而重跑 effect，但又要读最新值时，用 useRef 保存最新值。
对对象/函数依赖做稳定化：useMemo / useCallback。
一个 effect 只做一件事，拆分副作用，减少错误依赖。
异步请求加取消/忽略机制（AbortController 或 ignore 标记）并在 cleanup 里处理。
如果是 React 19，可用 useEffectEvent 读取最新值，减少闭包问题。

示例（典型闭包坑）：

useEffect(() => {
  const id = setInterval(() => {
    setCount(count + 1); // count 是旧值
  }, 1000);
  return () => clearInterval(id);
}, []); // 漏依赖

改法：

useEffect(() => {
  const id = setInterval(() => {
    setCount(c => c + 1); // 永远基于最新值
  }, 1000);
  return () => clearInterval(id);
}, []);

React 里为什么不建议用数组下标当 key？会导致什么问题？

Wed, 09 Apr 2025 17:04:18 GMT

key 在 React 里是“这个列表项是谁”的身份证。
用数组下标（index）当 key，一旦有插入、删除、排序，身份证就会“串号”。

会导致的问题：

组件状态错位
比如第 2 行输入框内容/勾选状态跑到别的行。
UI 交互异常
光标跳动、输入中断、动画错位、展开/收起状态错乱。
副作用绑定到错误项
useEffect 订阅/清理可能对应错对象。
性能变差
React 不能正确复用节点，出现不必要重渲染或重挂载。

推荐做法：

用稳定且唯一的业务 ID（如数据库 id）当 key。
没有 ID 时，在“创建数据时”生成一次 ID，不要在渲染时临时生成。
只有“完全静态、不会增删改排”的列表，才勉强可用 index。

什么是重排(reflow) 和重绘(repaint)？怎么优化页面渲染性能？

Wed, 09 Apr 2025 16:47:08 GMT

概念区别

重排（Reflow / Layout）
浏览器要重新计算元素的几何信息：位置、宽高、布局关系。
典型触发：改 width/height/padding/margin、改 display、增删 DOM、窗口 resize。
重绘（Repaint）
不改几何信息，只改外观，浏览器重新“上色”。
典型触发：改 color/background/box-shadow 等。
关系
重排一定会引发重绘，重绘不一定重排。
所以重排通常更贵、性能影响更大。

怎么优化渲染性能

少做会触发布局的改动
尽量用一次性改 class，避免频繁逐条改样式。
读写分离，避免布局抖动（layout thrashing）
先批量读布局（如 offsetWidth），再批量写样式，不要读写交替。
动画优先用 transform 和 opacity
尽量避免动画改 top/left/width/height。
批量更新 DOM
用 DocumentFragment、一次性插入；复杂更新可先隐藏容器再显示。
减少渲染范围和复杂度
简化 DOM 层级，长列表用虚拟列表（只渲染可视区）。
合理使用新特性隔离开销
可用 contain、content-visibility 限制重排影响范围；will-change 谨慎使用。
用 DevTools 定位热点
在 Performance 面板看 Layout/Paint 开销，优先优化高频和长耗时操作。

浏览器 Event Loop 中，宏任务和微任务的执行顺序是什么？

Wed, 09 Apr 2025 16:44:31 GMT

执行顺序可以记成一句话：

先跑一个宏任务，再把微任务队列清空，再进行渲染，然后进入下一个宏任务。

简化流程：

取出并执行 1 个宏任务（script、setTimeout、I/O、UI 事件等）
执行完后，立即把当前所有微任务全部执行完（Promise.then、queueMicrotask、MutationObserver）
微任务清空后，浏览器才有机会做一次渲染
进入下一轮，继续取下一个宏任务

补充重点：

微任务会“插队”到下一个宏任务之前。
如果微任务不断自我追加，可能长期阻塞渲染和后续宏任务。

HTTPS 相比 HTTP 多了哪些核心步骤？证书校验主要在防什么？

Wed, 09 Apr 2025 16:42:01 GMT

HTTPS 比 HTTP 多的核心步骤

HTTP 通常是：TCP 连接 -> 直接发 HTTP 明文请求

HTTPS 通常是：TCP(或 QUIC)连接 -> TLS 握手 -> 再发 HTTP(加密) 多出来的关键是 TLS 握手：

客户端发 ClientHello（支持的 TLS 版本、加密套件、SNI、ALPN 等）
服务端回 ServerHello + 证书链（并选定加密参数）
客户端做证书校验（域名、有效期、签名链、是否受信任等）
双方做密钥交换（常见 ECDHE），生成会话密钥
发送 Finished，后续 HTTP 数据全部加密传输

证书校验主要在防什么

核心是在防 “你以为连的是A站，实际连到攻击者”，也就是：

中间人攻击（MITM）
假冒网站/伪造服务器身份
DNS/路由劫持后被导向假站

本质上保障三件事：

身份真实性（确实是目标域名对应服务器）
传输机密性（内容不被窃听）
传输完整性（内容不被篡改）

TCP 三次握手为什么不是两次？TIME_WAIT 的意义是什么？

Wed, 09 Apr 2025 16:33:21 GMT

为什么 TCP 要三次握手，不是两次？

三次握手的目标是：双方都确认“我能发、我能收”，并且同步各自初始序号。
流程是：

客户端发 SYN(seq=x)
服务端回 SYN+ACK(seq=y, ack=x+1)
客户端再回 ACK(ack=y+1)

如果只有两次，会有两个问题：

服务端无法确认客户端是否收到了第 2 步（SYN+ACK）。
旧的、延迟到达的 SYN 可能让服务端误建连接（“幽灵连接”）。

第 3 次 ACK 本质上是客户端给服务端的“确认回执”，证明这次连接是有效且双向可用的。

TIME_WAIT 的意义是什么？

TIME_WAIT 出现在主动关闭连接的一方，停留约 2MSL（实现相关，通常几十秒到几分钟）。

主要有两大作用：

保证连接可靠结束
如果最后一个 ACK 丢了，对方会重发 FIN；TIME_WAIT 期间还能再回 ACK。
防止旧报文污染新连接
等旧连接中的延迟包在网络中自然过期，避免和同四元组（源/目的 IP+端口）的新连接混淆。

所以 TIME_WAIT 是 TCP 为了“正确性和安全性”付出的必要代价，不是无意义等待。

说下 HTTP 强缓存和协商缓存的区别，分别看哪些响应头/请求头？

Wed, 09 Apr 2025 16:27:07 GMT

核心区别一句话：

强缓存：浏览器自己判断“还没过期”，不发请求，直接用本地副本。
协商缓存：浏览器会发请求问服务器“资源变没变”，由服务器决定用旧的还是新的。

分别看哪些头：

强缓存

主要看响应头：
- Cache-Control（最重要，尤其 max-age）
- Expires（老方案，兼容用）
请求头：
- 命中强缓存时通常没有对应网络请求（所以也就没有验证类请求头）
- 若用户强刷/禁缓存，可能带 Cache-Control: no-cache、Pragma: no-cache

协商缓存

服务器下发的响应头：
- ETag
- Last-Modified
浏览器下次请求带的请求头：
- If-None-Match（对应 ETag）
- If-Modified-Since（对应 Last-Modified）

返回结果：

未变化：304 Not Modified（通常无响应体，继续用本地）
已变化：200 OK + 新内容（并更新 ETag/Last-Modified）

补充：实际流程通常是先看强缓存，强缓存不命中再走协商缓存。

从输入 URL 到页面渲染完成，关键链路有哪些阶段？

Wed, 09 Apr 2025 16:15:16 GMT

1. 关键链路阶段

URL 解析
浏览器解析地址（协议、域名、路径、参数等），确认要访问什么资源。
浏览器预检查
先检查是否可直接使用本地结果：缓存、Service Worker、HSTS、已有连接复用。
DNS 解析
把域名（如 example.com）转换成服务器 IP 地址。
建立连接
根据协议建立网络通道：TCP + TLS（HTTP/1.1、HTTP/2）或 QUIC（HTTP/3）。
发送 HTTP 请求
浏览器发送请求，请求里包含 Headers、Cookie 等信息。
服务端处理并返回首包
服务器处理请求并开始返回数据，直到收到首字节（TTFB）。
流式接收 HTML 并发现子资源
浏览器边收 HTML 边解析，同时继续请求 CSS、JS、图片、字体等资源。
构建页面模型并执行脚本
构建 DOM 和 CSSOM，执行 JS（某些 JS 会阻塞解析和渲染）。
生成可渲染结构并计算布局
合成渲染树（Render Tree），做 Layout（计算元素大小和位置）。
绘制与合成上屏
先 Paint（绘制像素），再 Composite（图层合成）显示到屏幕，后续继续补齐剩余内容。

2. 专有名词解释

| 名词 | 解释 | |---|---| | URL | 网页地址，如 https://example.com/a?b=1 | | Service Worker | 网页的本地代理脚本，可拦截请求、做离线缓存 | | HSTS | 强制使用 HTTPS 的安全策略，防止降级到不安全 HTTP | | DNS | 域名解析系统，把域名翻译成 IP | | IP | 服务器在网络中的数字地址 | | TCP | 可靠传输协议，保证数据按序到达 | | TLS | 传输加密层，保证通信安全（HTTPS 基础） | | QUIC | 基于 UDP 的现代传输协议，HTTP/3 使用它 | | HTTP/1.1、HTTP/2、HTTP/3 | 浏览器与服务器通信协议的不同版本 | | Headers | 请求/响应附带的元信息（语言、压缩、缓存策略等） | | Cookie | 浏览器保存的小数据（登录态、会话、偏好） | | TTFB | Time To First Byte，收到响应首字节的时间 | | Layout | 计算每个元素的位置和尺寸（回流） | | Paint | 把文本、颜色、边框等绘制成像素 | | Composite | 把多个图层合成为最终画面并显示 | | FCP | 首次内容绘制，用户第一次看到内容 | | LCP | 最大内容绘制，主内容出现的关键时刻 | | load | 页面 load 事件触发，通常表示资源基本加载完成 |

Vi/Vim 编辑文件的核心常用命令

Thu, 20 Mar 2025 15:45:46 GMT

Vi/Vim 编辑文件的核心常用命令

一、基础模式切换（最核心）

| 操作 | 命令 | 说明 | |------|------|------| | 进入插入模式（编辑文本） | i | 在光标当前位置插入（最常用） | | 进入插入模式 | a | 在光标下一个字符后插入 | | 进入插入模式 | o | 在光标下一行新建一行并插入 | | 进入插入模式 | I | 跳到当前行行首插入 | | 进入插入模式 | A | 跳到当前行行尾插入 | | 退出插入模式（回到命令模式） | Esc | 按一次即可，编辑完必按 | | 进入末行模式（保存/退出/查找） | : | 命令模式下按 :，底部会出现 : 提示符 |

二、文本编辑（命令模式下）

1. 光标移动（不用鼠标！）

| 命令 | 说明 | |------|------| | h/j/k/l | 左/下/上/右移动（替代方向键，老手必备） | | 0 | 跳到当前行行首（数字 0） | | $ | 跳到当前行行尾 | | gg | 跳到文件第一行 | | G | 跳到文件最后一行 | | 5G | 跳到第 5 行（替换数字可跳任意行） | | w | 跳到下一个单词开头 | | b | 跳到上一个单词开头 |

2. 复制/粘贴/删除

| 命令 | 说明 | |------|------| | yy | 复制当前行（最常用，「yank」缩写） | | 5yy | 复制从当前行开始的 5 行 | | p | 粘贴到光标下一行（「paste」缩写） | | P | 粘贴到光标上一行 | | dd | 删除当前行（「delete」缩写，最常用） | | 5dd | 删除从当前行开始的 5 行 | | x | 删除光标所在字符（按 Delete 键效果一样） | | dw | 删除光标所在单词 | | u | 撤销上一步操作（「undo」，改错必用） | | Ctrl + r | 恢复撤销的操作（「redo」） |

3. 快速修改

| 命令 | 说明 | |------|------| | r | 替换光标所在字符（比如 ra 把当前字符改成 a） | | cc | 清空当前行并进入插入模式 | | cw | 清空当前单词并进入插入模式 |

三、保存/退出（末行模式下，先按 `:` 再输命令）

| 命令 | 说明 | |------|------| | :w | 保存文件（「write」，只保存不退出） | | :w test.txt | 另存为 test.txt（指定新文件名） | | :q | 退出编辑器（文件未修改时可用） | | :q! | 强制退出，放弃所有修改（改错不想保存必用） | | :wq | 保存并退出（最常用，等价于 :x） | | :x | 保存并退出（比 :wq 更智能：文件没修改时不会额外写入） |

四、查找/替换（末行模式下）

1. 查找

| 命令 | 说明 | |------|------| | :/关键词 | 从光标处向下查找「关键词」（比如 :/codex 查找 codex） | | :?关键词 | 从光标处向上查找「关键词」 | | n | 跳转到下一个匹配结果 | | N | 跳转到上一个匹配结果 |

2. 替换（新手必学）

| 命令 | 说明 | |------|------| | :%s/旧内容/新内容/g | 全局替换（整个文件的旧内容换成新内容）比如 :%s/codex/CODEX/g 把所有 codex 换成 CODEX | | :1,10s/旧内容/新内容/g | 替换 1-10 行的旧内容 | | :s/旧内容/新内容/g | 只替换当前行的旧内容 | | 补充 | g 表示「全局」，不加则只替换每行第一个匹配项；加 c 表示确认替换（:%s/旧/新/gc），避免误替换 |

闭包

Sat, 01 Mar 2025 15:11:35 GMT

闭包（Closure）：
就是“函数 + 它定义时所在作用域里的变量”打包在一起。
即使这个函数在作用域外执行，仍然能访问当时的变量。

例子（JavaScript）

function outer() {
  let count = 0;
  return function inner() {
    count++;
    return count;
  };
}

const fn = outer();
console.log(fn()); // 1
console.log(fn()); // 2

这里 inner 就是闭包：
它记住了 outer 里的 count，所以 outer 执行完后，count 还在。

iPhone Files 连接 Windows 共享文件夹完整指南（含重启IP提醒）

Tue, 28 Jan 2025 18:41:15 GMT

⚠️ 核心重要提醒

电脑重启后，若未设置静态IP，系统会通过DHCP自动获取新的IP地址，直接导致iPhone Files中保存的旧地址失效，出现「Socket is not connected」「无法连接服务器」等报错，这是重启后连接失败的最常见诱因。本指南优先提供静态IP固定方案，彻底规避此问题。

一、前期准备

iPhone与Windows电脑必须连接同一个Wi-Fi网络，确保处于同一局域网内
Windows电脑建议使用本地账户登录（Microsoft在线账户连接时易出现权限校验失败问题）
提前确定需共享的文件夹，建议命名为纯英文/数字，无空格、特殊字符，避免连接异常

二、Windows电脑端完整配置

1. 固定电脑IP地址（彻底解决重启换IP问题）

两种方案任选其一，优先推荐路由器端绑定，稳定性更强。

方案A：路由器端静态IP/MAC地址绑定（推荐）

打开浏览器，输入路由器管理后台地址（通常为192.168.1.1/192.168.0.1，可在路由器机身背面查看），登录管理账号
在后台找到「DHCP静态分配」「IP与MAC地址绑定」或同类功能入口（不同品牌路由器命名略有差异）
Windows端按下Win+R，输入cmd打开命令提示符，执行ipconfig /all，找到当前连接的Wi-Fi/以太网适配器，记录下**物理地址（MAC地址）**与当前IPv4地址
在路由器绑定页面，填入电脑的MAC地址、想要固定的IPv4地址（与当前网段一致，如192.168.1.100），保存设置并重启路由器生效
生效后，无论电脑如何重启，路由器都会给该设备分配固定的IP地址，不会出现地址变动

方案B：Windows系统手动设置静态IP

打开Windows「设置」→「网络和Internet」，选择当前连接的Wi-Fi/以太网，点击「属性」
找到「IP设置」板块，点击「编辑」，将自动获取(DHCP)切换为「手动」
开启IPv4选项，按以下规则填写参数：
- IP地址：填写与路由器同网段的固定地址（如192.168.1.100）
- 子网前缀长度：24（对应子网掩码255.255.255.0）
- 网关：填写路由器管理后台地址（如192.168.1.1）
- 首选DNS：114.114.114.114
- 备用DNS：8.8.8.8
点击「保存」，IP地址固定完成

2. 开启并配置共享相关服务

按下Win+R，输入services.msc打开系统服务面板
在服务列表中找到Server服务，双击打开属性面板：
- 启动类型设置为「自动」
- 若服务未运行，点击「启动」
- 切换到「恢复」选项卡，将第一次/第二次/后续失败的操作均设置为「重新启动服务」，点击应用保存
同路径找到TCP/IP NetBIOS Helper服务，同样设置为「自动」启动，并确保服务处于运行状态

3. 防火墙放行共享连接

打开「Windows安全中心」→「防火墙和网络保护」→「允许应用通过防火墙」
点击页面上方的「更改设置」获取管理员权限
在应用列表中找到文件和打印机共享，勾选对应的网络类型（家庭/工作网络勾选「专用」，公共网络可按需勾选「公用」）
确认后保存设置，避免防火墙拦截iPhone的SMB连接请求

4. 关闭网卡节能设置（避免休眠断连）

右键开始菜单，选择「设备管理器」
展开「网络适配器」列表，找到当前使用的Wi-Fi/以太网卡，双击打开属性面板
切换到「电源管理」选项卡，取消勾选允许计算机关闭此设备以节约电源
点击确定保存，避免电脑休眠或重启后网卡被系统关闭导致断连

5. 配置共享文件夹权限

右键需要共享的文件夹，选择「属性」，切换到「共享」选项卡
点击「共享」按钮，在下拉菜单中选择要授权的用户（推荐选择当前登录的Windows本地账户，或选择Everyone）
点击「添加」，将用户加入列表后，将权限级别设置为「读取/写入」
点击「共享」完成基础配置，记录下系统提示的共享地址
回到属性面板，点击「高级共享」，勾选「共享此文件夹」，设置简洁的共享名（无空格、特殊字符）
点击「权限」按钮，添加授权用户，勾选「完全控制」「更改」「读取」权限，点击应用保存
切换到「安全」选项卡，确认授权用户已在列表中，且拥有对应的读写权限，全部设置完成后点击确定保存

三、iPhone Files端连接配置

打开iPhone自带的「文件」App，点击右上角的「···」图标，选择「连接服务器」
在服务器地址栏，输入smb://+你固定好的Windows电脑IP地址（例如smb://192.168.1.100），点击「连接」
连接方式选择「注册用户」，输入Windows电脑的本地账户用户名和登录密码
勾选「在钥匙串中保存此密码」，避免后续重复输入，点击「下一步」
连接成功后，共享文件夹会出现在「文件」App的「共享」列表中，可直接进行文件的查看、传输、编辑等操作

四、常见问题排查

报错「Socket is not connected」
- 优先检查电脑IP地址是否变动，确认当前IP与连接地址一致
- 检查Windows的Server服务是否正常运行，防火墙是否放行共享
连接提示权限不足
- 确认共享文件夹的「共享」和「安全」两个选项卡中，都已给登录用户配置了读写权限
- 优先使用Windows本地账户登录，避免Microsoft在线账户的权限校验问题
找不到服务器/连接超时
- 确认iPhone和Windows电脑处于同一个Wi-Fi网络，无AP隔离等路由器限制
- 关闭电脑的VPN、代理软件，避免局域网路由异常

lin

如何判断 AI 生成的代码是可靠的？会从类型、测试、边界条件、性能、安全哪些维度检查？

判断 AI 生成的代码是否可靠：别只看“能跑”，要看“扛不扛打”

1. 类型：代码是在表达约束，还是在逃避约束

2. 测试：不是看跑了多少，而是看挡不挡得住回归

3. 边界条件：真正拉开差距的地方

4. 性能：不卡，不等于性能没问题

5. 安全：功能完成，不代表边界安全

6. 最后补一刀：结构能不能撑住下一次修改

一份简单的检查清单

结尾

tmux 使用指南

核心定位

一、核心层级概念

二、安装

三、快捷键规则

四、高频命令&快捷键

会话管理（核心）

窗口管理

面板（分屏）管理

复制粘贴

五、极简必用配置

六、TPM 插件管理（极简）

1. 安装

2. 配置

3. 核心快捷键

4. 高频推荐插件

七、新手极简工作流

常用skill

核心协作与任务执行

创意与产品规划

前端开发与工程化

自动化与浏览器操作

GitHub 与 CI/CD

信息处理与搜索

Skill 管理与开发

如何写一个 skill

Skill 是什么

一个 skill 的最小结构

写之前先把边界定清楚

SKILL.md 怎么写

1. Frontmatter 只放必要信息

2. 正文别写成废话

一个能直接参考的 SKILL.md 示例

初始化一个 skill

openai.yaml 要不要写

资源文件怎么分

scripts/

references/

assets/

怎么判断这个 skill 写得行不行

热门 skills

前端开发

后端 & 数据库

浏览器自动化

SEO & 营销

中文内容创作

AI 开发 & 提示工程

文档处理

安全 & 运维

其他

OpenClaw 源码分析

先说结论

项目整体定位

4 个核心概念

1. Gateway

2. Agent Workspace

3. Skills

4. Plugins

源码为什么会这么大

1. 多渠道接入

2. 多端节点能力

3. 插件和技能生态

4. 模型和认证系统

仓库目录

src/

packages/

extensions/

skills/

ui/

`SKILL.md` 怎么写

一个能直接参考的 `SKILL.md` 示例

`openai.yaml` 要不要写

`scripts/`

`references/`

`assets/`

`src/`

`packages/`

`extensions/`

`skills/`

`ui/`

`apps/`

`docs/`