一些不懂的名词的汇总

前言

经常会在各种地方看到自己不懂的名词，然后复制过来问 LLM 这个是什么意思，之后就结束了。但是这样过了一两天就又忘记了，所以这篇 Blog 相当于一个记事本，汇总一下我不懂的这些名词。很多内容会是 LLM 直出，不具备什么真正的可读性，所以只是自用。

AOT 编译

在廖雪峰老师的这篇知乎回答里面看到的。

引用AOT 是 Ahead-Of-Time compilation，中文一般叫 提前编译。 它的意思是：程序在真正运行之前，就已经被编译成目标平台可...

AOT 是 Ahead-Of-Time compilation，中文一般叫 提前编译。

它的意思是：程序在真正运行之前，就已经被编译成目标平台可以执行的机器码，或者接近机器码的形式。

举个简单对比：

传统解释执行：

源代码 → 运行时一边读一边执行

AOT 编译：

源代码 → 提前编译成机器码 → 运行时直接执行

比如 C / C++ 通常就是典型的 AOT 编译：

// hello.c
#include <stdio.h>

int main() {
    printf("Hello\n");
}

你先用编译器编译：

gcc hello.c -o hello

然后得到一个可执行文件：

./hello

运行时系统不需要再理解 C 代码，直接执行已经生成好的机器码。

和它经常一起对比的是 JIT 编译，也就是 Just-In-Time compilation，即时编译。

比如 JavaScript、Java、C# 这类语言或平台，很多时候会在程序运行时，根据实际运行情况，把热点代码编译成本地机器码。大概是：

源代码 / 字节码 → 程序运行 → 运行中发现热点代码 → 编译优化 → 继续运行

所以可以粗略理解为：

AOT：运行前编译
JIT：运行时编译
解释执行：运行时直接解释代码**

其实就是大家最常见的 C 系语言的编译形式，区别于 Java 的 JIT 和 Python 的解释。

不过这个项目是用 C# 写的，那是怎么做到 AOT 编译的呢？

引用对于 C# 项目来说，AOT 编译一般指 .NET Native AOT。 正常的 C#/.NET 程序大致是这样运行的： C# 源码 → 编译...

对于 C# 项目来说，AOT 编译一般指 .NET Native AOT。

正常的 C#/.NET 程序大致是这样运行的：

C# 源码 → 编译成 IL 中间语言 → 运行时由 .NET CLR/JIT 编译成本机机器码 → 执行

也就是说，普通 C# 程序发布后，运行时通常还需要 .NET Runtime，并且会在运行过程中由 JIT 把 IL 编译成机器码。

而 Native AOT 是：

C# 源码 → 发布时直接编译成本机机器码 → 生成原生可执行文件 → 运行时直接执行

微软官方文档里说，Native AOT 发布会把应用直接编译为 native code，并且是 self-contained 的发布方式；启用方式通常是在 .csproj 里加：(Microsoft Learn)

<PropertyGroup>
  <PublishAot>true</PublishAot>
</PropertyGroup>

然后发布，比如 Windows x64：

dotnet publish -c Release -r win-x64

或者 Linux x64：

dotnet publish -c Release -r linux-x64

发布出来的程序更像 C/C++ 编译出来的可执行文件。它不再主要依赖运行时 JIT，所以通常有这些特点：

启动更快，适合 CLI 工具、短生命周期服务、Serverless、容器服务。

内存占用可能更低，因为不需要运行时再做很多 JIT 工作。

部署更方便，通常可以发一个目标平台的可执行文件。

但代价也很明显：

第一，平台绑定更强。比如 win-x64、linux-x64、linux-arm64 要分别发布。

第二，构建更慢，因为编译工作提前做了。

第三，对反射、动态加载、运行时代码生成支持更受限制。很多 C# 生态里的库喜欢用反射，比如 JSON 序列化、ORM、依赖注入、插件系统，这些在 Native AOT 下可能需要额外配置，甚至不兼容。ASP.NET Core 对 Native AOT 有专门的兼容性说明，尤其是 Web API 项目需要注意依赖和框架特性是否支持。(Microsoft Learn)

所以对于你的这个 C# 项目，可以这样理解：

这个项目的 AOT 编译，就是把 C#/.NET 项目在发布阶段提前编译成某个平台的原生可执行程序，减少运行时对 JIT 和完整 .NET Runtime 的依赖。

如果是一个普通控制台工具、后台小服务、CLI 程序，Native AOT 可能很合适。

如果是 ASP.NET Core 后端，也可以用，但要看项目是不是用了大量反射、动态代理、ORM、插件加载、运行时代码生成。比如用了 Entity Framework Core、某些复杂 JSON 序列化配置、动态扫描程序集的框架，AOT 适配成本可能会上升。

最简单的判断方法是看项目文件里有没有：

<PublishAot>true</PublishAot>

或者发布命令里有没有：

/p:PublishAot=true

有的话，这个项目就是在尝试走 .NET Native AOT 发布路线。

其实像 JVM 和 .NET Runtime 这种东西的优势就是跨平台，AOT 相当于舍弃了。

所谓 Java 的宣传口号「一次编写，到处运行」。

JSONL

引用JSON 和 JSONL 都是用来存结构化数据的文本格式，但组织方式不同。 JSON，全称是 JavaScript Object Notatio...

JSON 和 JSONL 都是用来存结构化数据的文本格式，但组织方式不同。

JSON，全称是 JavaScript Object Notation，通常是一个完整的数据结构，比如一个对象或数组：

{
  "name": "Alice",
  "age": 20,
  "city": "Shanghai"
}

也可以是一个数组：

[
  {
    "name": "Alice",
    "age": 20
  },
  {
    "name": "Bob",
    "age": 22
  }
]

JSONL，全称是 JSON Lines，也叫 NDJSON。它的特点是：一行就是一个 JSON 对象。

{"name": "Alice", "age": 20}
{"name": "Bob", "age": 22}
{"name": "Charlie", "age": 23}

它们最大的区别在于：

JSON 是一个整体。比如上面那个数组，整个文件必须合起来才是合法的 JSON。你不能只读第一行就认为它是完整数据。

JSONL 是一行一条数据。每一行本身都是合法 JSON，所以可以一行一行读取、处理、追加。

举个更直观的区别：

普通 JSON 文件可能长这样：

[
  {"id": 1, "text": "hello"},
  {"id": 2, "text": "world"},
  {"id": 3, "text": "test"}
]

JSONL 文件长这样：

{"id": 1, "text": "hello"}
{"id": 2, "text": "world"}
{"id": 3, "text": "test"}

所以 JSON 更适合配置文件、小规模数据、前后端接口返回值。

JSONL 更适合日志、大量数据、机器学习数据集、爬虫结果、流式处理。因为它可以一边生成一边写入，也可以一行一行读取，不需要一次性把整个文件加载进内存。

比如 Python 读取 JSON：

import json

with open("data.json", "r", encoding="utf-8") as f:
    data = json.load(f)

读取 JSONL：

import json

with open("data.jsonl", "r", encoding="utf-8") as f:
    for line in f:
        item = json.loads(line)
        print(item)

简单记：

.json 是“一个完整 JSON”。

.jsonl 是“很多行 JSON，每行一条记录”。

如果你在做数据集、日志、爬虫保存结果，通常 JSONL 会更方便；如果你在写配置文件或者接口响应，通常 JSON 更常见。

NAS VPS

引用NAS 和 VPS 都可以理解成“放在网络上的一台机器”，但用途很不一样。 NAS 是 Network Attached Storage，网络附...

NAS 和 VPS 都可以理解成“放在网络上的一台机器”，但用途很不一样。

NAS 是 Network Attached Storage，网络附加存储。你可以把它理解成“家里/宿舍/办公室的一块联网硬盘”。它主要用来存文件，比如照片、视频、备份、电影、文档，也可以跑一些轻量服务，比如相册、影音库、下载器、Docker、小型数据库等。

常见场景是：你买一台群晖、威联通、绿联 NAS，插几块硬盘，放在自己家里。然后电脑、手机、平板都能访问它。它的核心价值是：存储、备份、私有云、家庭影音、内网服务。

VPS 是 Virtual Private Server，虚拟专用服务器。你可以把它理解成“云厂商机房里租给你的一台虚拟 Linux 服务器”。比如阿里云、腾讯云、Vultr、Hetzner、DigitalOcean、AWS、Azure 上开的服务器，本质上很多都是 VPS/云服务器。

常见场景是：部署网站、后端 API、数据库、Bot、博客、反向代理、爬虫、监控、CI/CD 等。它的核心价值是：公网访问稳定、部署服务方便、长期在线。

简单对比：

项目	NAS	VPS
放在哪里	通常在你自己家/办公室	云厂商机房
主要用途	存储、备份、私有云	部署网站、后端、服务
硬盘空间	通常很大，几 TB 起	通常较小，几十 GB 起
公网访问	需要公网 IP / 内网穿透 / DDNS	天生有公网 IP
网络速度	取决于你家宽带上传	取决于云服务器带宽
维护内容	硬盘、数据安全、断电、网络	系统安全、服务部署、费用
适合存大量文件吗	很适合	不太划算
适合跑公网后端吗	可以但麻烦	很适合

举个例子：

你想存照片、备份电脑、搭一个自己的网盘，看电影电视剧，适合 NAS。

你想部署 Golang 后端、PostgreSQL、Redis、QQ Bot、博客、API 服务，适合 VPS。

也可以组合使用：VPS 负责公网入口，NAS 负责大容量存储。比如 VPS 上跑反向代理或中转，家里的 NAS 存文件和跑私有服务。这样既能有公网访问能力，又不用把大量文件放在昂贵的云服务器硬盘上。

你最近说的“阿里云服务器部署后端项目”，更接近 VPS/云服务器，不是 NAS。NAS 更像是你自己买一台设备放家里做私有存储。

Minisearch

引用MiniSearch 一般指一个 JavaScript 的轻量级全文搜索库。 它可以让你在浏览器或 Node.js 里，对一批本地数据做搜索。官...

MiniSearch 一般指一个 JavaScript 的轻量级全文搜索库。

它可以让你在浏览器或 Node.js 里，对一批本地数据做搜索。官方介绍里说，它是一个 “tiny but powerful in-memory fulltext search engine”，也就是小型、内存中的全文搜索引擎，可以运行在 Node 和浏览器里。(GitHub)

举个例子，你有一组文章：

const documents = [
  { id: 1, title: 'ARP 协议解析', text: 'ARP 用来根据 IP 地址找到 MAC 地址' },
  { id: 2, title: 'TCP 三次握手', text: 'SYN 会消耗一个序号' },
  { id: 3, title: 'Elasticsearch 入门', text: 'ES 适合做全文搜索和日志分析' }
]

你可以用 MiniSearch 建一个索引，然后搜：

miniSearch.search('三次握手')

它就能返回和“三次握手”相关的文档。

和 Elasticsearch 对比的话，可以这样理解：

Elasticsearch 是一个独立的搜索服务，适合大规模数据、日志分析、后端搜索系统。

MiniSearch 是一个 JS 库，通常直接嵌入前端或 Node 项目里，适合小到中等规模的数据，比如文档站搜索、博客搜索、离线搜索、前端本地搜索。

它支持的功能包括全文搜索、前缀搜索、模糊匹配、字段权重、自动建议等。作者的介绍中也提到它支持 prefix search、fuzzy match、boosting、auto suggestions，并且没有运行时依赖，适合客户端搜索场景。(lucaongaro.eu)

所以一句话概括：

MiniSearch 是一个轻量级的 JavaScript 本地全文搜索库，适合在前端页面、静态网站、文档站或小型项目里实现搜索功能。

边缘节点、ESA

引用这几个词放在一起，其实是在讲一种现代网站部署方式：把网站的一部分逻辑、缓存、搜索索引、静态资源放到离用户更近的网络节点上处理，这样访问会更快，也...

这几个词放在一起，其实是在讲一种现代网站部署方式：把网站的一部分逻辑、缓存、搜索索引、静态资源放到离用户更近的网络节点上处理，这样访问会更快，也不用自己维护很多服务器。

先说“边缘节点”。

传统网站访问大概是：

用户浏览器 → 你的源站服务器

比如你的服务器在美国，国内用户访问就要跨很远的网络，延迟高，速度可能慢。

用了 CDN / 边缘网络之后，大概变成：

用户浏览器 → 附近的边缘节点 → 必要时再回源站服务器

这里的“边缘节点”就是 CDN 厂商部署在各地的数据中心节点。它们位于网络的“边缘”，更靠近最终用户。比如用户在上海，边缘节点可能在上海、杭州、南京；用户在新加坡，边缘节点可能在新加坡。它可以缓存静态文件，比如图片、JS、CSS、HTML，也可以做安全防护、请求转发、简单计算。

这里的“边缘”指的不是地理边境，而是相对于“中心服务器/源站”的概念。

“中心”是你的源站服务器，比如一台 VPS、一个云服务器、一个后端服务。

“边缘”是靠近用户的一层网络节点，比如 Cloudflare、阿里云 CDN、阿里云 ESA 的节点。

所以“边缘计算”就是：不要所有请求都回到中心服务器处理，一部分逻辑直接在靠近用户的节点上处理。

举个很具体的例子。

假设你的博客搜索功能需要读取一个搜索索引。如果索引文件在源站，每次用户搜索都要请求源站。用了边缘方案之后，你可以把搜索索引放在 Cloudflare KV 里，或者缓存到边缘节点附近。用户搜索时，由 Worker 在边缘节点读取 KV，然后直接返回搜索结果。这样访问路径会短一些，响应可能更快。

再说 ESA。

这里的 ESA 大概率是阿里云的 Edge Security Acceleration，中文可以理解为“边缘安全加速”。阿里云官方介绍里说，ESA 是一个统一管理网络和边缘基础设施的云服务，提供互联网内容、应用、数据中心、企业网络、AI 工作负载的加速与防护能力；它也提供加速、边缘计算和安全能力。

你可以粗略把 ESA 理解成：

CDN 加速 + 安全防护 + 边缘计算 + 域名接入管理

它有点像阿里云版的 Cloudflare。以前很多人说 CDN，主要想到的是“缓存静态资源”；而 ESA 这类产品会更综合一些，除了加速，还包括 WAF、防 DDoS、访问控制、边缘函数、KV 存储、规则配置等。阿里云产品页也提到 ESA 支持 serverless 部署、键值存储、边缘函数等能力。

所以聊天里说“阿里云那个 ESA 的 CDN”，意思就是：他把 ESA 当成一种更高级的 CDN / 边缘加速平台来看。

DAU

Daily Active User 日活

UIUX

UIUX 通常是 UI / UX 的合写，指和产品界面、交互体验相关的方向。

UI = User Interface，用户界面。 主要关注“界面长什么样”：按钮、颜色、排版、图标、视觉风格、页面布局等。

UX = User Experience，用户体验。 主要关注“用户用起来顺不顺”：流程是否清晰、操作是否方便、用户能不能快速完成目标、有没有卡点等。

所以 UIUX 岗 一般可以理解为：界面设计 / 交互设计 / 用户体验设计相关岗位。

PTY TTY ttyrec 和 ttyplay asciinema .cast

引用可以按“从终端是什么 → 怎么伪装一个终端 → 怎么录制终端”这条线理解。 最底层先看 TTY。 TTY 原本是 teletypewriter，...

可以按“从终端是什么 → 怎么伪装一个终端 → 怎么录制终端”这条线理解。

最底层先看 TTY。

TTY 原本是 teletypewriter，电传打字机。早期计算机没有现在这种图形界面，人通过一种像打字机一样的设备和计算机交互：你敲字，机器把字符发给计算机；计算机输出字符，设备打印出来。

后来虽然物理打字机没了，但操作系统里还保留了这个概念。现在说 TTY，通常指“终端设备”或“终端会话”。

简单理解：

TTY = 操作系统眼里的一个终端

在 Linux / Unix 里，很多程序会判断自己是不是连着一个 TTY。比如：

ls

如果 ls 发现自己输出到终端，可能会显示颜色、按列排版；如果它发现自己输出到管道或文件，可能会去掉颜色，变成普通文本。

例如：

ls
ls > out.txt

这两种输出表现可能不同，因为前者面对的是 TTY，后者面对的是普通文件。

然后是 PTY。

PTY 是 pseudo terminal，伪终端。它不是真实硬件终端，而是操作系统模拟出来的一对终端接口。

它一般分成两端：

PTY master 端：由控制程序持有
PTY slave 端：让被运行的 shell / CLI / TUI 程序以为自己连接到了真实终端

可以这样想：

真实人类终端：
你 ↔ 终端 ↔ shell / vim / top / htop

PTY：
控制程序 ↔ 伪终端 ↔ shell / vim / top / htop

为什么 PTY 很重要？因为很多命令行程序只有在检测到自己连接的是终端时，才会输出完整效果。比如颜色、进度条、交互式提示、TUI 界面、密码输入、光标移动，都依赖终端能力。

如果你只是用普通管道执行：

some-cli > output.txt

程序可能会发现“我没有连接到终端”，于是关闭颜色、关闭交互、改变输出格式。

但如果你用 PTY 启动它，它会觉得自己正在一个真实终端里运行：

some-cli 看到的是 PTY slave
所以它以为：我正在终端里运行

要复刻终端截图，不能只抓 stdout，最好让程序运行在 PTY 里。

接着看 ttyrec。

ttyrec 是一个终端录制工具。它会启动一个终端会话，然后记录这个终端里发生的输出。

典型用法：

ttyrec demo.ttyrec

然后你在里面执行命令。结束后输入：

exit

它会生成一个录制文件，比如：

demo.ttyrec

这个文件记录的大致是：

什么时间点
终端输出了哪些字节

这里的“字节”不只是普通文字，也包括 ANSI 转义序列，比如颜色、清屏、移动光标等。

所以 ttyrec 录到的东西大概是：

0.10 秒：输出 "$ ls\r\n"
0.20 秒：输出 "README.md  src  package.json\r\n"
0.30 秒：输出 "$ "

它不是视频。它没有记录字体、像素、终端窗口边框，也没有记录你屏幕上的真实画面。它记录的是终端字符流。

然后是 ttyplay。

ttyplay 是配合 ttyrec 使用的回放工具。

ttyplay demo.ttyrec

它会读取 demo.ttyrec，按照当初记录的时间，把终端输出重新播放出来。

所以二者关系很简单：

ttyrec  = 录制终端会话
ttyplay = 回放 ttyrec 录制文件

可以类比成：

摄像机  = ttyrec
播放器  = ttyplay
录像文件 = .ttyrec 文件

只是这里的“录像”不是画面录像，而是“终端字符流录像”。

然后看 asciinema。

asciinema 也是终端录制工具，目标和 ttyrec / ttyplay 很像，但更现代，也更适合分享、网页嵌入和自动化处理。

常见用法是：

asciinema rec demo.cast

这会录制一个终端会话。

回放：

asciinema play demo.cast

asciinema 也有网页播放器，你可以把录制上传到 asciinema.org，或者嵌入自己的网页/README 文档中。

它和 ttyrec 的核心区别在于文件格式更现代、更容易处理。

ttyrec 的文件更像老式二进制记录；asciinema 的 .cast 文件通常是文本格式，具体说是 JSON Lines / NDJSON，也就是一行一条 JSON 数据。

最后是 .cast。

.cast 是 asciinema 录制出来的文件，也叫 asciicast 文件。

比如：

asciinema rec demo.cast

会生成：

demo.cast

这个 .cast 文件里面大概长这样：

{"version":2,"width":80,"height":24,"timestamp":1710000000,"env":{"SHELL":"/bin/bash","TERM":"xterm-256color"}}
[0.1,"o","$ echo hello\r\n"]
[0.3,"o","hello\r\n"]
[0.5,"o","$ "]

第一行是元信息：

version   格式版本
width     录制时终端宽度，单位是列
height    录制时终端高度，单位是行
timestamp 录制时间
env       环境信息，比如 SHELL、TERM

后面的每一行是事件：

[时间, 事件类型, 内容]

例如：

[0.3,"o","hello\r\n"]

意思是：

录制开始后 0.3 秒，终端输出了一段内容：hello

这里的 "o" 一般表示 output，也就是终端输出。

所以 .cast 可以理解成：

.cast = asciinema 的终端录像文件

整体关系可以串起来：

代码TEXT · 20 行

TTY
= 操作系统里的“终端”概念

PTY
= 程序模拟出来的“伪终端”
= 让 CLI / TUI 程序以为自己真的跑在终端里

ttyrec
= 老牌终端录制工具
= 记录终端输出字节流和时间戳

ttyplay
= ttyrec 文件的回放工具

asciinema
= 更现代的终端录制、播放、分享工具

.cast
= asciinema 录出来的文件格式
= 文本化、JSONL 风格的终端录制文件

一句话总结：

TTY 是终端概念；
PTY 是模拟出来的终端；
ttyrec/asciinema 是录制终端的工具；
ttyplay 是回放 ttyrec 的工具；
.cast 是 asciinema 的录制文件。

CRLF LF

引用CRLF 和 LF 都是换行符，区别在于换行使用的字符不同。 名称 字符 字节表示 常见系统 LF \n 0A Linux、macOS、Unix...

CRLF 和 LF 都是换行符，区别在于换行使用的字符不同。

名称	字符	字节表示	常见系统
LF	\n	0A	Linux、macOS、Unix
CRLF	\r\n	0D 0A	Windows

具体来说：

LF 是 Line Feed，意思是“换到下一行”：

hello\nworld

CRLF 是 Carriage Return + Line Feed，意思是“回到行首 + 换到下一行”：

hello\r\nworld

历史上，CR 是打字机“回车到行首”，LF 是“纸张进一行”。Windows 沿用了 CRLF，Unix 系统则主要使用 LF。

常见影响：

# Linux/macOS 下查看文件换行类型
file xxx.txt

如果一个脚本在 Linux 上报错：

/bin/bash^M: bad interpreter

通常就是文件用了 Windows 的 CRLF，其中 ^M 对应 \r。

Git 中也经常遇到这个问题。可以用 .gitattributes 统一换行：

* text=auto
*.sh text eol=lf
*.bat text eol=crlf

简单记忆：

Windows 常用 CRLF，Linux/macOS 常用 LF。写代码、脚本、配置文件时通常推荐统一用 LF。

cron

引用cron 是 Linux/Unix 系统里的定时任务工具。 它可以让系统在指定时间自动执行某个命令或脚本，比如： 每天凌晨 2 点备份数据库 每...

cron 是 Linux/Unix 系统里的定时任务工具。

它可以让系统在指定时间自动执行某个命令或脚本，比如：

• 每天凌晨 2 点备份数据库
• 每 5 分钟检查一次服务状态
• 每周清理一次日志
• 每月生成报表

cron 的任务通常写在 crontab 里。

例如：

0 2 * * * /home/app/backup.sh

意思是：每天凌晨 2 点执行 /home/app/backup.sh。

cron 时间格式一般是：

分 时 日 月 星期 要执行的命令

例如：

*/5 * * * * command

表示：每 5 分钟执行一次 command。

简单理解： cron = 服务器上的闹钟 + 自动执行命令。

RSS

引用RSS 是一种内容订阅格式，常用于自动获取网站更新。 你可以把它理解成： RSS = 网站更新的订阅源 比如你关注一个博客、新闻网站、播客网站，...

RSS 是一种内容订阅格式，常用于自动获取网站更新。

你可以把它理解成：

RSS = 网站更新的订阅源

比如你关注一个博客、新闻网站、播客网站，如果它提供 RSS，你就可以把 RSS 地址添加到 RSS 阅读器里。以后这个网站一更新文章，阅读器里就会自动出现，不用你每天手动打开网站查看。

常见用途：

新闻订阅
博客订阅
播客更新
技术文章更新
公告通知

RSS 通常是一个链接，看起来可能像：

https://example.com/rss
https://example.com/feed

你需要用 RSS 阅读器来订阅，比如 Feedly、Inoreader、NetNewsWire、FreshRSS 等。

简单说： RSS 就像给网站内容装了一个“自动提醒和收件箱”。

backend R&D

Backend R&D 通常指 后端研发，也就是 Backend Research & Development。

Next.js

引用Next.js 是一个基于 React 的 Web 开发框架，主要用来做网站和 Web 应用。它由 Vercel 维护，是开源项目。官方把它定位...

Next.js 是一个基于 React 的 Web 开发框架，主要用来做网站和 Web 应用。它由 Vercel 维护，是开源项目。官方把它定位为用于构建全栈 Web 应用的 React 框架。(维基百科)

简单说：

React 主要负责写页面组件，Next.js 在 React 之上补齐了“做完整网站/应用”需要的能力。

它常见功能包括：

• 路由：按文件夹/文件自动生成页面路由。
• 服务端渲染 SSR：页面可以先在服务器生成 HTML，再发给浏览器。
• 静态生成 SSG：提前生成静态页面，访问速度快。
• API / 后端能力：可以在同一个项目里写前端页面和部分后端接口。
• SEO 更友好：相比纯前端 React 应用，更容易被搜索引擎理解。
• 性能优化：图片优化、代码分割、缓存、预加载等。

一个类比：

React 像是“造页面组件的工具箱”，Next.js 像是“用 React 盖完整网站的施工框架”。

常见用途有：官网、博客、电商网站、后台系统、SaaS 产品、AI 应用前端等。如果你已经会一点 HTML/CSS/JavaScript，学习路线通常是：

JavaScript → React → Next.js → 数据库/部署/全栈开发。

ORM

引用ORM（Object-Relational Mapping，对象关系映射）框架是一类帮助程序把面向对象代码和关系型数据库表对应起来的工具。 简单...

ORM（Object-Relational Mapping，对象关系映射）框架是一类帮助程序把面向对象代码和关系型数据库表对应起来的工具。

简单说：它让你不用频繁手写 SQL，而是用“对象”的方式操作数据库。

比如数据库里有一张表：

users
id | name | age

在代码里可以对应成一个类：

class User {
    Long id;
    String name;
    Integer age;
}

有了 ORM 框架后，你可以这样操作：

User user = new User();
user.setName("Alice");
user.setAge(20);

userRepository.save(user);

ORM 会帮你转换成类似：

INSERT INTO users (name, age) VALUES ('Alice', 20);

ORM 框架主要做什么

它通常负责：

1. 类和表的映射 把 User 类对应到 users 表。
2. 对象和记录的映射 把数据库的一行数据转换成一个对象。
3. 自动生成 SQL 比如插入、查询、更新、删除。
4. 管理对象关系 比如一对一、一对多、多对多关系。
5. 简化数据库操作 让开发者更关注业务逻辑，而不是重复写 SQL。

常见 ORM 框架

不同语言里都有 ORM 框架：

• Java：Hibernate、MyBatis、JPA
• Python：SQLAlchemy、Django ORM
• PHP：Laravel Eloquent、Doctrine
• JavaScript/TypeScript：TypeORM、Prisma、Sequelize
• C#：Entity Framework

ORM 的优点

ORM 的好处是开发效率高，代码更面向对象，也更容易维护。对于常见的增删改查操作，ORM 可以减少大量重复 SQL。

ORM 的缺点

ORM 也不是万能的。复杂查询、性能优化、批量操作时，自动生成的 SQL 可能不够高效。开发者如果完全不了解 SQL，也容易写出性能不好的代码。

一句话理解

ORM 框架就是：把数据库表映射成代码里的对象，让你用操作对象的方式操作数据库。

JD

求职里的 JD 通常是 Job Description 的缩写，意思是 职位描述 / 岗位说明。

一般 JD 会包含：

• 岗位名称：比如产品经理、数据分析师
• 工作职责：入职后主要做什么
• 任职要求：需要哪些技能、经验、学历等
• 加分项：不是必须，但有会更好
• 薪资福利 / 工作地点 / 汇报关系：有些 JD 会写

比如别人说“把 JD 发我看看”，意思就是“把这个岗位的职位描述发我看看”。

scp 上传

引用SCP 上传到服务器 的意思是：用 scp 这个命令，通过 SSH 安全连接，把本地或 CI 里构建好的文件复制到远程服务器上。 在你的 CI/...

SCP 上传到服务器 的意思是：用 scp 这个命令，通过 SSH 安全连接，把本地或 CI 里构建好的文件复制到远程服务器上。

在你的 CI/CD 语境里，它通常指：

GitHub Actions 里构建好的前端 dist/ 和后端发布产物
        ↓
通过 SCP 上传
        ↓
放到服务器上的某个临时目录，比如 /var/www/cd_tmp

比如概念上类似：

scp -r frontend/dist user@server:/var/www/cd_tmp/frontend
scp -r backend/publish user@server:/var/www/cd_tmp/backend

含义分别是：

scp        安全复制文件的命令
-r         递归复制整个目录
frontend/dist  要上传的本地目录
user       登录服务器的用户名
server     服务器地址或 IP
/var/www/cd_tmp/frontend  服务器上的目标路径

在 GitHub Actions 里一般不会直接手写 scp 命令，而是用现成的 action，例如：

- name: Upload files to server
  uses: appleboy/scp-action@v0.1.7
  with:
    host: ${{ secrets.SERVER_HOST }}
    username: ${{ secrets.SERVER_USERNAME }}
    key: ${{ secrets.SERVER_SSH_KEY }}
    port: ${{ secrets.SERVER_PORT }}
    source: "frontend,backend"
    target: "/var/www/cd_tmp"

它做的事情就是：把 GitHub Actions runner 里的文件，通过 SSH 私钥认证，复制到你的服务器目录里。

所以这句话：

SCP 上传到服务器 /var/www/cd_tmp

可以理解为：

把 CI 构建出来的新版本文件，安全地复制到服务器的临时部署目录 /var/www/cd_tmp，后续再通过 SSH 执行脚本，把这些文件移动到正式运行目录。

SCP 只负责“传文件”；真正“重启服务、替换目录、启动后端”的动作通常是后面的 SSH 执行部署脚本 来做。

GitHub PR 的 Tasks

这些 tasks 是什么？

看红框

答：是这些 Checkbox，有多少个，分母就是多少，勾了就是分子的个数：

OrcaTerm

腾讯云出品的一款终端，支持本地客户端以及网页版，主要是服务腾讯云连接的。

目前来看感觉协作这方面做的还可以，但是有缺点就是本地终端不好用，还是回去用 WT 吧。

VNC

Virtual Network Computing

VNC = 远程屏幕。

它不是普通命令行，而是像“远程桌面”一样，直接看到服务器的屏幕/控制台。

但你的服务器是 Linux 服务器，不一定有图形桌面，所以 VNC 进去后也可能还是一个黑框登录界面。

它主要用于救急，比如：

SSH 登录不上
防火墙配错了
网络配置搞坏了
服务器启动异常
需要看系统控制台报错

日常部署项目基本不用 VNC。

Ruff

「工具说明文档也补好了。接下来我会再次跑完整测试、Ruff，并做一个启动 smoke test，确认 uv 环境下应用能起来。」这里的 Ruff 是什么？

这里的 Ruff 指的是一个用于 Python 项目的代码检查/格式化工具，常见用途包括：

1. Lint 检查 检查代码里是否有风格问题、潜在 bug、未使用变量、导入顺序问题等。类似 ESLint 之于 JavaScript。

2. 格式化代码 Ruff 也可以像 Black 一样自动格式化 Python 代码。

3. 速度很快 它用 Rust 写的，所以比传统 Python lint 工具快很多，很多项目会用它替代或整合 Flake8、isort、pyupgrade、部分 Pylint 规则等。

你这句话里的意思是：

文档补好了。接下来会重新跑完整测试、跑 Ruff 代码检查/格式化检查，并做一个启动冒烟测试，确认用 uv 管理的环境里应用能正常启动。

其中 “跑 Ruff” 通常可能是类似这些命令：

ruff check .
ruff format --check .

或者自动修复：

ruff check . --fix
ruff format .

HAR

HAR 是 HTTP Archive，可以理解成浏览器 Network 面板的一份“请求记录包”。

它通常包含：

• 请求 URL、方法：GET / POST
• 请求头：User-Agent、Accept、Cookie 等
• 查询参数：?id=...&t=...
• POST 请求体：比如 form data
• 响应状态码：200、302、401
• 响应头
• 响应内容摘要或正文
• 请求耗时、重定向链、资源类型

Chrome DevTools 的 Network 面板里可以右键导出 HAR。它对摸清一个接口非常有用，因为能看到“浏览器到底发了什么”。

不过 HAR 也很敏感，里面可能有 Cookie、sessionid、X-Token、登录 token 这些东西。

RPD 流程

在产品/研发管理语境里，RPD 流程通常指 Rapid Product Development，即“快速产品开发流程”。它是一套面向产品从需求到交付的端到端开发方法，常借鉴 IPD、敏捷开发、阶段评审等做法，核心是用更短周期、更强协同，把客户需求快速转化为可交付产品。

它的核心思想一般包括：

1. 以客户需求为中心：产品开发目标不是“把功能做完”，而是满足真实客户/市场需求。
2. 快速验证：尽早做概念验证、原型验证，避免后期才发现方向错了。
3. 迭代开发：不是一次性瀑布式交付，而是边验证、边优化。
4. 跨部门协作：产品、研发、测试、运营、供应链、市场等共同参与。
5. 阶段性评审：通过关键评审点决定项目继续、调整或终止。

常见的 RPD 阶段可以概括为：

阶段	含义
需求/概念阶段	明确客户需求、产品目标、商业价值
方案/原型阶段	做技术方案、原型、可行性验证
开发测试阶段	研发实现、系统测试、集成测试
试点/小批量阶段	在真实客户或场景中验证
正式发布阶段	达到发布标准后规模化上市或交付

一些资料里还会提到类似 CR、DR、ER、GA 这样的评审节点：例如立项、开发发布、早期发布、正式可用等，用来控制资源投入、质量风险和商业节奏。

一句话理解：RPD 流程就是一种“以客户需求驱动、快速验证、跨部门协作、分阶段评审”的快速产品开发机制。

SDK

SDK 是 Software Development Kit 的缩写，中文叫 软件开发工具包。

它是一套帮助开发者快速接入某个系统、平台或服务的工具集合。通常包括：

组成	作用
API 接口	让你的程序调用某个平台的功能
示例代码	告诉你怎么用
开发文档	说明功能、参数、调用方式
工具/库文件	帮你省去底层开发工作
调试工具	方便测试和排查问题

举个例子：

如果你想在 App 里接入微信登录，微信会提供 微信 SDK。你不需要自己从零实现登录流程，只要按照 SDK 文档调用相关方法，就可以完成“微信授权登录”。

再比如：

• 支付 SDK：接入支付宝、微信支付、Stripe 等支付能力
• 地图 SDK：接入高德地图、Google Maps
• 短信 SDK：发送验证码短信
• AI SDK：调用语音识别、图像识别、大模型能力
• 游戏 SDK：接入账号、充值、广告、数据统计等功能

一句话理解：SDK 就是平台方提供给开发者的一套“现成工具箱”，用来更快、更标准地开发或接入功能。

glob

glob 是一种文件路径匹配规则，用通配符一次匹配一批文件。

例如：

*.js

表示当前目录下所有 .js 文件。

常见写法：

*        匹配任意数量字符，但通常不跨目录
?        匹配任意一个字符
[abc]    匹配 a、b、c 中任意一个字符
[0-9]    匹配一个数字
**       递归匹配多级目录，具体是否支持取决于工具

例子：

src/*.js

匹配：

src/app.js
src/index.js

但通常不匹配：

src/utils/helper.js

要递归匹配，可以写：

src/**/*.js

这会匹配 src 下面任意层级的 .js 文件。

在 GitHub Actions 里很常见：

on:
  push:
    paths:
      - "src/**/*.js"

意思是：只有 src 目录下的 JavaScript 文件发生变化时，才触发 workflow。

它和正则表达式不一样。glob 更简单，主要用于文件路径；正则表达式更强，主要用于文本匹配。

需要注意，不同工具对 glob 的实现可能略有差异，尤其是 **、隐藏文件和否定规则。例如 GitHub Actions 里：

paths:
  - "**/*.js"
  - "!test/**"

表示匹配所有 JavaScript 文件，但排除 test 目录。

同步原语

“同步原语”可以理解为：编程语言提供的一类基础工具，用来协调多个并发任务之间的先后顺序、等待和通知。

这里有两个并发执行的角色：

Agent goroutine：请求权限后，停下来等待
UI 主循环：显示对话框，等用户按键

它们需要约定一种可靠的“交接方式”：

Agent：我需要一个决定，先等着
UI：用户选了 Allow，把决定交给 Agent
Agent：收到，继续执行

在 Go 中，最适合这里的同步原语就是 channel。

项目大致是这样做的：

respCh := make(chan PermissionResponse, 1)

eventCh <- PermissionRequestEvent{
    ToolName:   tc.ToolName,
    ResponseCh: respCh,
}

resp := <-respCh

含义是：

1. respCh 是一个“只能传递权限决定”的小通道。
2. Agent 把它随 PermissionRequestEvent 一起发给 UI。
3. resp := <-respCh 会阻塞当前工具 goroutine，直到有人往 respCh 放入决定。
4. UI 收到事件、展示确认框后，用户按键时执行：

m.permRespCh <- agent.PermAllow

这会把 PermAllow 送进 channel；Agent 的 <-respCh 随即解除等待，拿到结果并继续执行工具。

这里 channel 同时承担了两件事：

• 传数据：传递 PermAllow、PermDeny 之类的具体决定；
• 同步时序：Agent 必须等 UI 回答后才能继续。

常见同步原语还有：

• sync.Mutex：一次只允许一个 goroutine 修改共享数据；
• sync.WaitGroup：等待一批 goroutine 全部做完；
• sync.Cond：一个 goroutine 等待某个条件成立，另一个 goroutine 通知它；
• context.Context：传递取消、超时等控制信号；
• channel：goroutine 之间传数据或等待通知。

PRD

PRD 是 Product Requirements Document，中文叫 产品需求文档。

它主要说明：

• 要做什么功能
• 为什么要做
• 用户怎么使用
• 业务规则是什么
• 什么情况算开发完成

例如登录功能的 PRD 会写：登录流程、验证码规则、异常提示和验收标准。

可以简单理解为：

PRD = 产品功能的说明书。