青火

构建 OpenClaw Docker 镜像的完整方案

admin — Fri, 20 Mar 2026 14:50:00 +0800

好的,我来为你制定一个构建 OpenClaw Docker 镜像的完整方案。

## 📦 OpenClaw Docker 镜像构建方案

根据官方文档和代码分析,我给你提供一个从零开始的构建方案:

### 方案一:使用官方脚本快速构建(推荐)

OpenClaw 提供了官方的 `docker-setup.sh` 脚本,自动化程度高,适合大多数场景:

```bash
# 1. 克隆仓库
git clone https://github.com/openclaw/openclaw.git
cd openclaw

# 2. 运行官方设置脚本(自动化构建镜像)
./docker-setup.sh
```

这个脚本会自动:
- 构建或拉取 Docker 镜像
- 运行 onboarding 向导
- 生成 gateway token
- 启动 Docker Compose 服务

### 方案二:手动构建 Docker 镜像(完全可控)

如果你需要完全自定义构建过程,可以手动构建:

#### 步骤 1: 创建 Dockerfile

在项目根目录创建 `Dockerfile`:

```dockerfile
# 基础镜像使用 Node.js 22 Bookworm
FROM node:22-bookworm

# 安装 Bun(构建脚本需要)
RUN curl -fsSL https://bun.sh/install | bash
ENV PATH="/root/.bun/bin:${PATH}"

# 启用 corepack
RUN corepack enable

# 设置工作目录
WORKDIR /app

# 优先复制依赖相关文件(利用 Docker 缓存层)
COPY package.json pnpm-lock.yaml pnpm-workspace.yaml .npmrc ./
COPY ui/package.json ./ui/package.json
COPY scripts ./scripts

# 安装依赖
RUN pnpm install --frozen-lockfile

# 复制源代码
COPY . .

# 构建
RUN pnpm build
RUN pnpm ui:install
RUN pnpm ui:build

# 设置生产环境
ENV NODE_ENV=production

# 启动命令
CMD ["node","dist/index.js"]
```

#### 步骤 2: 构建 Docker 镜像

```bash
# 基础构建
docker build -t openclaw:local -f Dockerfile .

# 或者使用官方 Dockerfile(如果存在)
docker build -t openclaw:local .
```

#### 步骤 3: 创建 docker-compose.yml

```yaml
version: '3.8'

services:
openclaw-gateway:
image: openclaw:local
container_name: openclaw-gateway
ports:
- "18789:18789"
volumes:
- ~/.openclaw:/home/node/.openclaw
- ~/.openclaw/workspace:/home/node/.openclaw/workspace
environment:
- OPENCLAW_GATEWAY_BIND=lan
- OPENCLAW_GATEWAY_MODE=local
restart: unless-stopped

openclaw-cli:
image: openclaw:local
container_name: openclaw-cli
network_mode: "service:openclaw-gateway"
volumes:
- ~/.openclaw:/home/node/.openclaw
- ~/.openclaw/workspace:/home/node/.openclaw/workspace
environment:
- OPENCLAW_GATEWAY_URL=ws://127.0.0.1:18789
profiles:
- cli
```

#### 步骤 4: 运行容器

```bash
# 启动服务
docker compose up -d openclaw-gateway

# 运行 CLI 命令
docker compose run --rm openclaw-cli onboard

# 查看日志
docker compose logs -f openclaw-gateway

# 停止服务
docker compose down
```

### 方案三:使用官方预构建镜像

OpenClaw 在 GitHub Container Registry 提供了预构建镜像:

```bash
# 拉取官方镜像
docker pull ghcr.io/openclaw/openclaw:latest

# 或者指定版本
docker pull ghcr.io/openclaw/openclaw:2026.3.8

# 创建 docker-compose.yml(将镜像改为 ghcr.io/openclaw/openclaw:latest)
# 然后启动
docker compose up -d
```

### 高级自定义选项

#### 1. 添加额外的系统包

```bash
export OPENCLAW_DOCKER_APT_PACKAGES="ffmpeg build-essential git curl jq"
./docker-setup.sh
```

或者在 Dockerfile 中添加:

```dockerfile
RUN apt-get update && apt-get install -y \
ffmpeg \
build-essential \
git \
curl \
jq \
&& rm -rf /var/lib/apt/lists/*
```

#### 2. 启用 Agent Sandbox

```bash
export OPENCLAW_SANDBOX=1
./docker-setup.sh
```

这会构建 sandbox 镜像并配置环境隔离。

#### 3. 持久化容器数据

```bash
export OPENCLAW_HOME_VOLUME="openclaw_home"
./docker-setup.sh
```

#### 4. 额外挂载目录

```bash
export OPENCLAW_EXTRA_MOUNTS="$HOME/.codex:/home/node/.codex:ro,$HOME/github:/home/node/github:rw"
./docker-setup.sh
```

### 安全配置建议

1. **非 root 用户运行**: 容器默认以 `node` 用户(UID 1000)运行
2. **文件权限**: 确保宿主机挂载目录的权限正确
```bash
sudo chown -R 1000:1000 ~/.openclaw
```
3. **网络绑定**: 使用 `lan` 或 `loopback` 模式,避免暴露到公网

### 验证安装

```bash
# 检查健康状态
curl -fsS http://127.0.0.1:18789/healthz
curl -fsS http://127.0.0.1:18789/readyz

# 打开控制台
http://127.0.0.1:18789/
```

### 故障排查

1. **权限错误**: 调整文件所有权
2. **端口占用**: 检查 18789 端口是否被占用
3. **构建失败**: 确保至少 2GB RAM 可用
4. **网络问题**: 检查 `gateway.bind` 配置

---

**推荐方案**: 如果你是第一次使用,直接用**方案一**(官方脚本)。如果需要深度定制,用**方案二**(手动构建)。如果只是快速部署,用**方案三**(官方镜像)。

你比较倾向哪个方案?我可以针对你选择的方案提供更详细的步骤。

1001-计算机原理-进制的转换

阿布大人 — Mon, 16 Mar 2026 14:24:00 +0800

进制转化可以在chorme的console里面很方便的计算。

比如10进制转任意进制

//(十进制数字)转成N进制 如下142转2进制，结果为'10001110'
(142).toString(2)

任意进制转10进制。

//任意进制转10进制，第一个参数写原数，第二个参数写原数的进制。执行后得到10进制 142
parseInt('10001110',2)

任意进制转任意进制

//先转10进制，然后在转任意进制,以下示例为2进制转16进制，最终结果为8E
parseInt('10001110',2)
(142).toString(16)

软考时候的计算方法

1.任意进制转10进制; 按权展开法

2.10进制转任意进制短除法

3.特殊情况的如第一个二进制转八进制，把每三位截断，不足的补齐。之后把三位的二进制转成10进制，最终得到的就是8进制。

Java ASM系列：（001）ASM介绍

内部账号 — Tue, 27 Jan 2026 15:06:00 +0800

转载自：https://blog.51cto.com/lsieun/2924433

简单来说， ASM是一个操作Java字节码的类库。

为了能够更好的理解ASM是什么，我们需要来搞清楚两个问题：

第一个问题，ASM的操作对象是什么呢？
第二个问题，ASM是如何处理字节码（ByteCode）数据的？
首先，我们来看第一个问题：ASM的操作对象是什么呢？回答：ASM所操作的对象是字节码（ByteCode）数据。

我们都知道，一个.java文件经过Java编译器（javac）编译之后会生成一个.class文件。
在.class文件中，存储的是字节码（ByteCode）数据，如下图所示。ASM所的操作对象是是字节码（ByteCode），而在许多情况下，字节码（ByteCode）的具体表现形式是.class文件。

接着，我们来看第二个问题：ASM是如何处理字节码（ByteCode）数据的？回答：ASM处理字节码（ByteCode）的方式是“拆分－修改－合并”。

ASM处理字节码（ByteCode）数据的思路是这样的：第一步，将.class文件拆分成多个部分；第二步，对某一个部分的信息进行修改；第三步，将多个部分重新组织成一个新的.class文件。

在 Wikipedia上，对ASM进行了如下描述：

ASM provides a simple API for decomposing(将一个整体拆分成多个部分), modifying(修改某一部分的信息), and recomposing(将多个部分重新组织成一个整体) binary Java classes (i.e. ByteCode).

2. ASM的过去和现在
2.1 ASM的过去
对于ASM的过去，主要说明三个问题：

第一个问题，ASM从什么时候开始出现的？
第二个问题，ASM的作者是谁？
第三个问题，ASM的名字有什么含义？
在2002年的时候，Eric Bruneton、Romain Lenglet和Thierry Coupaye发表了一篇文章，名为《 ASM: a code manipulation tool to implement adaptable systems》。在这篇文章当中，他们提出了ASM的设计思路。

一般来说，大写字母的组合，可能是多个单词的缩写形式，例如，JVM表示“Java Virtual Machine”。但是，ASM并不是多个单词的首字母缩写形式。在上面的文章中，记录了下面的话：

The ASM name does not mean anything: it is just a reference to the __asm__ keyword in C,
which allows some functions to be implemented in assembly language.

2.2 ASM的现在
对于ASM的现在，主要说明两个问题：

第一个问题，ASM属于哪一个机构？
第二个问题，ASM的Logo是什么样的？
The ASM library is a project of the OW2 Consortium. OW2 is an independent, global, open-source software community.

作为一个小故事，我们来说一下OW2组织是如何形成的。OW2组织的形成，与中国的一些大学和公司也有很大的关系（原文内容来自这里）：

2002年，ObjectWeb项目启动，它是由INRIA、Bull和France Telecom共同开发的项目，并形成了一个成熟的、开源软件社区。
2004年，Orientware项目启动，由中国的北京大学、北航、国防科技大学、中创软件和中国科学院软件研究所共同研发。
2005年，ObjectWeb和Orientware签署了一份协议，决定共享代码库，一起开发中间件软件。
2006年，ObjectWeb和Orientware两个社区组织融合，形成了OW2组织。OW2组织名字，可能是由ObjectWeb和Orientware名称当中的两组O和W组合而来。
ASM的Logo设计很有特点，它在旋转的过程中，会分别呈现出“A”、“S”和“M”这三个字母，如下图所示：

2.3 ASM的版本发展
对于ASM版本的发展，我们要说明两点：

第一点，Java语言在不断发展，那么，ASM版本也要不断发展来跟得上Java的发展。
第二点，在选择ASM版本的时候，要注意它支持的Java版本，来确保兼容性。
比如说，我们常用的Java版本是Java 8和Java 11。针对Java 8版本，我们需要使用ASM 5.0版本，就能正常工作。对于Java 11版本，我们需要使用ASM 7.0版本，就能正常工作。当然，我们可以尽量使用较高的ASM版本。

ASM Release Release Date Java Support
2.0 2005-05-17 Java 5 language support
3.2 2009-06-11 support for the new invokedynamic code.
4.0 2011-10-29 Java 7 language support
5.0 2014-03-16 Java 8 language support
6.0 2017-09-23 Java 9 language support
6.1 2018-03-11 Java 10 language support
7.0 2018-10-27 Java 11 language support
7.1 2019-03-03 Java 13 language support
8.0 2020-03-28 Java 14 language support
9.0 2020-09-22 Java 16 language support
9.1 2021-02-06 Java 17 language support
3. ASM能够做什么
3.1 通俗的理解
父类：修改成一个新的父类
接口：添加一个新的接口、删除已有的接口
字段：添加一个新的字段、删除已有的字段
方法：添加一个新的方法、删除已有的方法、修改已有的方法
……（省略）
public class HelloWorld extends Object implements Cloneable {
public int intValue;
public String strValue;

public int add(int a, int b) {
return a + b;
}

public int sub(int a, int b) {
return a - b;
}

@Override
public Object clone() throws CloneNotSupportedException {
return super.clone();
}
}

3.2 专业的描述
ASM is an all-purpose(多用途的；通用的) Java ByteCode manipulation and analysis framework.
It can be used to modify existing classes or to dynamically generate classes, directly in binary form.

The goal of the ASM library is to generate, transform and analyze compiled Java classes,
represented as byte arrays (as they are stored on disk and loaded in the Java Virtual Machine).

Program analysis, which can range from a simple syntactic parsing to a full semantic analysis, can be used to find potential bugs in applications, to detect unused code, to reverse engineer code, etc.
Program generation is used in compilers. This includes traditional compilers, but also stub or skeleton compilers used for distributed programming, Just in Time compilers, etc.
Program transformation can be used to optimize or obfuscate programs, to insert debugging or performance monitoring code into applications, for aspect oriented programming, etc.
4. 为什么要学习ASM？
平常，我们使用Java语言进行开发，能够解决很多的问题。我们可以把Java语言解决问题的范围称之为“Java语言的世界”。那么，ASM起什么作用呢？**ASM就是一处位于“Java语言的世界”边界上的一扇大门，通过这扇大门，我们可以前往“字节码的世界”。**在“字节码的世界”里，我们会看到不一样的“风景”，能够解决不一样的“问题”。

ASM往往在一些框架的底层起着重要的作用。接下来，我们介绍两个关于ASM的应用场景：Spring和JDK。这两个应用场景例子的目的，就是希望大家了解到ASM的重要性。

4.1 Spring当中的ASM
第一个应用场景，是Spring框架当中的AOP。在很多Java项目中，都会使用到Spring框架，而Spring框架当中的AOP（Aspect Oriented Programming）是依赖于ASM的。具体来说，Spring的AOP，可以通过JDK的动态代理来实现，也可以通过CGLIB实现。其中，CGLib (Code Generation Library)是在ASM的基础上构建起来的，所以，Spring AOP是间接的使用了ASM。（参考自 Spring Framework Reference Documentation的 8.6 Proxying mechanisms）。

4.2 JDK当中的ASM
第二个应用场景，是JDK当中的Lambda表达式。在Java 8中引入了一个非常重要的特性，就是支持Lambda表达式。Lambda表达式，允许把方法作为参数进行传递，它能够使代码变的更加简洁紧凑。但是，我们可能没有注意到，其实，在现阶段（Java 8版本），Lambda表达式的调用是通过ASM来实现的。

在rt.jar文件的jdk.internal.org.objectweb.asm包当中，就包含了JDK内置的ASM代码。在JDK 8版本当中，它所使用的ASM 5.0版本。

如果我们跟踪Lambda表达式的编码实现，就会找到InnerClassLambdaMetafactory.spinInnerClass()方法。在这个方法当中，我们就会看到：JDK会使用jdk.internal.org.objectweb.asm.ClassWriter来生成一个类，将lambda表达式的代码包装起来。

LambdaMetafactory.metafactory() 第一步，找到这个方法
InnerClassLambdaMetafactory.buildCallSite() 第二步，找到这个方法
InnerClassLambdaMetafactory.spinInnerClass() 第三步，找到这个方法

5. 总结
本文主要是对ASM进行简单的介绍，希望大家能够对ASM有基本的了解，内容总结如下：

第一点，ASM所处理对象是字节码数据，也可以直观的理解成.class文件，不是.java文件。
第二点，ASM能够对字节码数据进行哪些操作呢？回答：analyze、generate、transform。
第三点，ASM可以形象的理解为“Java语言世界”的边缘上一扇大门，通过这扇大门，可以帮助我们进入到“字节码的世界”。
同时，本文当中并没有涉及到“技术性”的知识点，因此也不需要“记忆”任何内容，了解一下就够了。

apache echarts-examples 离线部署攻略，离线开发的童鞋有福了

内部账号 — Wed, 19 Nov 2025 16:36:00 +0800

echarts官网demo界面，可以很方便的查询各种图表的制作方式和代码。但是某些离线场景下，就没那么方便了。

demo界面官网地址

https://echarts.apache.org/examples/zh/index.html

离线部署的帖子很多，不是很老，就是执行不了。本文使用官方开源代码，全新编译，nginx部署，方便后面有需要的兄弟。

1.序目

阅读本文者，默认你本地已安转好nodejs、git、nginx等环境，并有一定的操作基础。

2.准备工作

2.1 下载源码，在官方demo页面右上角，有githup图标，请注意，点击打开的不是echarts-examples的界面，需要在apache下重新搜索echarts，找到echarts-examples，链接为https://github.com/apache/echarts-examples，打不开的时候可以试试https://bgithub.xyz/apache/echarts-examples

#git clone 代码
git clone https://github.com/apache/echarts-examples

2.2 阅读文档

2.3 编译代码并验证

按文档执行相关操作,如果顺利，在联网环境下你访问http://127.0.0.1/ 就已经能看见示例主页面了，如果提示403，可以尝试访问http://127.0.0.1/zh/index.html.示例页面查看也无问题。

#进入目录
cd echarts-examples
#安装依赖，必须--force
npm i --force
#编译代码
npm run compile:example
#将编译好的程序复制到nginx的html目录
cp ./public/*  ${nginx_root}/html

3.离线适配

3.1 下载引用的cdn资源。

因为官方示例引用了10几个cdn资源，当处于离线环境的时候，无法正常访问刚才部署的echarts-examples。（模拟可以尝试拔网线|开发人员工具断网等方式）。

我们需要找到项目引用的cdn资源文件，分两部分

3.1.1 html文件的直接引用资源

参考/html/zh/index.html，可以看到一共引用了7个资源文件，复制链接，将其下载到/html/wai/目录.最终文件大概如图，此图已包含js引用的资源

3.1.2 js文件加载的引用资源

需要浏览器的开发者工具，打开任意一个官方示例，开始录制网络日志。之后搜索https://fastly.jsdelivr.net

需要将这些资源文件分别下载下来，本文为方便也将其下载在/html/wai目录下，注意有些资源需要多级文件夹，比如

https://fastly.jsdelivr.net/npm/echarts/dist/echarts.min.js

需要将其保存在/html/wai/echarts/dist/下。其他类似。

tip:官方示例加载引用的三方js大部分相似，但是也有例外的，所以总共需要多少外部资源文件没去统计，按照3.1.1章节的图去下载，基本上大部分示例都可以运行了。也可以直接去文末下载整理好的buding包。

3.2 调整已编译好的程序。

总计需要调整七个文件，两类。

3.2.1 html类：分别为/html/zh/和/html/en/目录下的六个html文件，使用以下内容，替换原html文件中的head内容。


    
    
    
    ECharts Examples

3.2.2 js文件类 /html/js/example-bundle.js文件，调整代码2687行，用以下代码替换。

var JSDELIVR_ROOT = '../wai/';

3.3离线验证

可以尝试拔网线|开发人员工具断网等方式进行验证，打开本地连接http://127.0.0.1/zh/index.html 对各种示例依次验证，如有示例打不开，重复上述步骤，直到补充完资源文件即可。

3.4现成的文件下载

以下文件可直接下载后覆盖到nginx的html目录，点击下载非离线版本程序。点击下载离线运行补丁文件

下载后直接将内容释放到启动好的nginx html目录下访问即可。

祝离线开发的同学工作顺利。

html实现打印小票效果代码

内部账号 — Fri, 07 Nov 2025 16:09:00 +0800

先上图

代码如下




    选择文件夹


    
    

    
    



 

播 种 面 积
（千公顷）

总　产　量
（万吨）

单位面积产量
（公斤/公顷）


 全国总计

119319.1

70649.9

5921.1


 北　　京

94.2

57.6

6115.5


 天　　津

399.1

270.6

6780.5


 河　　北

6460.1

3908.8

6050.6


 山　　西

3151.6

1468.7

4660.0


 内 蒙 古

7011.8

4100.5

5847.9


 辽　　宁

3577.5

2500.3

6989.1


 吉　　林

5853.8

4266.0

7287.5


 黑 龙 江

14754.0

8001.7

5423.4


 上　　海

130.3

98.3

7542.6


 江　　苏

5475.5

3810.1

6958.4


 浙　　江

1047.0

650.2

6210.2


 安　　徽

7344.9

4184.3

5696.9


 福　　建

844.4

514.4

6091.6


 江　　西

3774.6

2196.0

5818.0


 山　　东

8412.6

5710.2

6787.7


 河　　南

10777.1

6719.4

6234.8


 湖　　北

4722.6

2785.3

5897.9


 湖　　南

4773.4

3078.1

6448.4


 广　　东

2236.8

1313.4

5872.0


 广　　西

2841.8

1403.8

4939.7


 海　　南

272.7

142.4

5222.1


 重　　庆

2031.9

1100.7

5417.2


 四　　川

6405.9

3633.8

5672.6


 贵　　州

2771.4

1146.1

4135.5


 云　　南

4246.8

1993.5

4694.0


 西　　藏

199.4

112.9

5664.7


 陕　　西

3031.9

1352.3

4460.2


 甘　　肃

2715.9

1296.1

4772.3


 青　　海

305.9

118.3

3866.2


 宁　　夏

694.2

385.9

5559.2


 新　　疆

2960.0

2330.2

7872.4


注：此表中部分数据因四舍五入，分省合计数与全国数略有差异。

使用 SSH 动态端口转发（SOCKS5 代理）绕过实现微信登录

内部账号 — Tue, 14 Oct 2025 10:22:00 +0800

问题:我公司封禁了微信相关的网络，但是我可以访问我的阿里云服务器。我想使用阿里云服务器做一个代理，让我的微信使用阿里云代理进行登录。请问我应该怎么做？

正文：使用 SSH 动态端口转发（SOCKS5 代理）实现微信登录

你可以利用你拥有的阿里云服务器搭建一个代理（如 SOCKS5 或 HTTP 代理），然后在本地微信客户端中配置该代理，从而绕过公司网络对微信的限制。这期间理论上不需要安装任何三方软件。以下是详细操作步骤：

🧩 前提条件

你已拥有一台 公网 IP 可访问的阿里云 ECS 实例（建议为 Linux 系统，如 CentOS 或 Ubuntu）。
你本地电脑可以访问这台服务器（SSH 可连通）。
你了解基本的 Linux 命令操作。
公司网络未封禁你阿里云服务器的 IP 或端口（否则代理也无法使用）。

🔧 原理

通过 SSH 连接到你的阿里云服务器，并开启本地的 SOCKS5 代理端口（如 1080），所有流量都会加密转发到服务器，再由服务器访问微信服务器。

🖥️ 步骤一：在本地电脑建立 SSH 动态代理

Windows 用户（推荐使用 PowerShell 或 WSL）

使用 PowerShell（Windows 10/11 自带 OpenSSH 客户端）

打开 PowerShell（以普通用户运行即可）
执行以下命令（替换为你自己的服务器信息）：

ssh -D 1080 -f -N -C root@你的阿里云服务器公网IP

参数说明：

-D 1080：在本地开启 SOCKS5 代理，监听 127.0.0.1:1080
-f：后台运行
-N：不执行远程命令（仅用于端口转发）
-C：启用压缩（可选，提升速度）
root@...：你的服务器登录用户和 IP

⚠️ 首次连接会提示确认指纹，输入 yes 回车。

输入服务器密码（或使用密钥登录更安全）
如果阿里云服务器端的ssh端口不是默认的22,需要在命令行内添加-p [port]参数，例如

ssh -D 1080 -f -N -C -p ssh端口 root@你的阿里云服务器公网IP

✅ 此时，你的本地 127.0.0.1:1080 就是一个 SOCKS5 代理

MAC用户在终端开启 SSH 动态代理

打开 终端（Terminal）
执行以下命令（替换为你的服务器信息）

ssh -D 1080 -f -N -C root@你的阿里云服务器公网IP

🖥️ 步骤二：代理验证

1.检查本地端口是否监听

运行以下命令，查看 1080 端口是否被 SSH 占用：

lsof -i :1080

正常输出类似

COMMAND   PID   USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
ssh      12345  yourname   4u  IPv4 0xabcdef123456789      0t0  TCP localhost:socks (LISTEN)

✅ 有输出 → 本地 SOCKS5 代理已启动
❌ 无输出 → SSH 代理未运行
2.使用 curl 通过 SOCKS5 代理查询公网 IP

curl --socks5-hostname 127.0.0.1:1080 https://ip.xuhaobo.cn

🔍 输出应为你的 阿里云服务器公网 IP，而不是你本地公司网络的 IP。

curl --socks5-hostname 127.0.0.1:1080 https://ip.xuhaobo.cn

{
    "request_info": {
        "ip": "18.147.33.84",
        "user_agent": "curl/7.61.0",
        "referer": "none",
        "method": "GET",
        "url": "https://ip.xuhaobo.cn/",
        "timestamp": "2025-10-14 07:45:12"
    },
    "ip_geo_info": {
        "ip": "18.147.33.84",
        "country": "CN",
        "region": "Beijing",
        "city": "Beijing",
        "org": "AS31963 Hangzhou Alibaba Advertising Co.,Ltd.",
        "hostname": "unknown"
    }
}

✅ 如果返回的是阿里云 IP → 代理生效！
❌ 如果报错或返回本地 IP → 代理未生效。

💡 注意：必须用 --socks5-hostname（不是 --socks5），否则 DNS 会在本地解析，可能被污染或拦截。

🖥️ 步骤三：微信配置代理

打开微信，未登录状态下，点击设置->代理设置，在弹出的窗口填写服务器地址为本机，端口为上述配置时的端口。点击【测试并保存】，当软件提示测试通过时，你就可以当前主机使用代理网络登录微信了。

🛠️ 常见问题排查

问题	可能原因	解决方案
`curl` 返回本地 IP	用了 `--socks5` 而非 `--socks5-hostname`	改用 `--socks5-hostname`
`curl` 超时或拒绝连接	SSH 代理未运行 / 端口被占用	用 `lsof -i :1080` 检查
有进程，但是验证失败	因为网络策略、防火墙或服务器配置问题，-D 转发被禁用	调整阿里云服务器的sshd_config，确保 `AllowTcpForwarding yes`
微信仍无法登录	尝试使用三方软件如ProxyCap进行流量绑定	确认 WeChat.app 路径正确，重启 ProxyCap
SSH 连接断开	网络不稳定	加 `-o ServerAliveInterval=30` 参数保持

基于 Web Speech API 实现网页上的语音合成和语音识别功能

内部账号 — Fri, 10 Oct 2025 15:27:00 +0800



    
    
    
    
    基于 Web Speech API 实现网页上的语音合成和语音识别功能

nginx日志查询top10

内部账号 — Fri, 10 Oct 2025 14:03:00 +0800

nginx日志大流量和大并发的查询

当并发高的时候，先统计某一时间段访问最多的ipTOP10都有哪些，然后查看这些ip都访问了什么？

(1)统计访问最多的ip top10

sed -n '/17:45/,/18:00/p' access_2018-06-30.log|awk '{print $1}'|sort -nr |uniq -c |sort -nr|head -10 
    909 112.14.31.121
    472 123.139.16.179
    423 23.91.100.204
    416 121.30.192.10
    302 101.69.132.78
    281 101.69.132.82
    281 101.69.132.79
    274 101.69.132.81
    269 101.69.132.77
    252 101.69.132.76

(2)查看这些ip访问了些什么

cat access_2018-06-30.log |grep "123.139.16.179"|sort -nr|uniq -c |sort -nr|more

其他的nginx日志各种查询

日志如下：
116.211.124.29 - - [08/Feb/2018:04:58:45 +0800] video.yingyou360.cn "GET /do_not_delete/noc.gif HTTP/1.1" 200 3166 "-" "ChinaCache" "118.118.215.18"

（1）访问量大于1000的ip
awk '{print $1}' access.log | sort -n |uniq -c |awk '{if($1 >1000) print $0}'|sort -rn

（2）当天IP访问量
awk '{print $1}' /alidata/nginx/logs/access.log | sort -n | uniq | wc -l

（3）查询某个 IP 的详细访问情况，按访问频率排序（这里可以使用$1传参）
grep '123.12.11.20' /alidata/nginx/logs/access.log |awk '{print $8}'|sort |uniq -c |sort -rn |head -n 100

（4）查看访问最频的页面(TOP100)
awk '{print $8}' access.log | sort |uniq -c | sort -rn | head -n 100

（5）统计某个网站每分钟的请求数，top100 的时间点(精确到分钟)
awk '{print $4,$6}' access_2018-09-30.log |cut -c 1-18,22-100|grep "img1.yingyou360.cn"|sort -nr|uniq -c|sort -nr|head -10

（6）查看某个网站每秒的请求数，top100(把访问时间排第一列然后统计在同一时刻该网站被访问了了多少次)
awk '{print $4,$6}' access.log |grep "img1.ying360.cn"|sort|uniq -c|sort -nr|head -n 100

（7）查询当天某个时间段的IP访问量,4-5点
grep "07/Apr/2017:0[4-5]" access.log | awk '{print $1}' | sort | uniq -c| sort -nr | wc -l

（8）查询某个ip每秒钟访问某个网址的并发数（把总数加起来除以10求平均值）
cat access_2018-09-30.log|awk '{print $4,$1,$6}'|grep "112.49.26.41"|grep "img1.yingyou360.cn"|sort -nr|uniq -c|sort -nr|head -10

（9）查看某个时间段流量访问最大的日志信息

116.211.124.29 - - [08/Feb/2018:04:58:45 +0800] video.yingyou360.cn "GET /do_not_delete/noc.gif HTTP/1.1" 200 3166 "-" "ChinaCache" "118.118.215.18"
122.228.115.136 - - [08/Feb/2018:08:42:19 +0800] mobile.yingyou360.cn "GET /blr2/blr2_6.0.7.apk?__=1518050443.777 HTTP/1.1" 200 529909274 "-" "Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0; NetworkBench/8.0.1.323-6674224-2856942) like Gecko" "1.83.205.162, 60.165.55.10"

#把文件大小那一行放第一列，然后对第一列进行排序（$11是文件大小，单位是字节，除以2个1024=M）,我这里根具访问的文件大小来推算，文件越大消耗的流量也就越大
# sed -n '/8:40/,/8:45/p' access.log |awk '{print $11,$4,$8,$10,$1,$NF}'|sort -nr|uniq -c|more

其他其他的nginx日志各种查询

[root@jxq-c2-16-1 logs]# cat log.sh 
#!/bin/bash
#统计某个时间段的ip总量 
cat /alidata/nginx/logs/access.log |sed -n '/11\/May\/2017:08:32:00/,/11\/May\/2017:08:35:00/p'| awk '{print $1}' | sort | uniq -c | sort -rn | head
#查看某个时间段针对.apk是否有回源  
#sed -n '/10\/Nov\/2017:17:44:*/,/10\/Nov\/2017:17:58:*/p' access.log|grep -i  "apk" |head -1
sed -n '/17:35/,/18:00/p' access.log|grep -i  "apk" |awk '{print $1,$4,$7,$8,$10,$11,$16}'|more
#查看某个时间段流量访问最大的日志
sed -n '/8:40/,/8:45/p' access.log |awk '{print $11,$4,$8,$10,$1,$NF}'|sort -nr|uniq -c|more
#统计某每分钟ip并发数
cat access_2017-07-26.log |egrep  -v "GET|ChinaCache"|sed -n '/26\/Jul\/2017:16:01:00/,/26\/Jul\/2017:16:59:00/p'|grep "api.mobile.playyx.com" |awk -F "[:| ]"  '{print $1,$4}'|sort |uniq -c | wc -l
#统计某天的总流量
# cat access_2018-10-30.log |awk '{sum=sum+$11} END{print sum/1024^3}'
16.3368
$11是流量列，单位是字节B，除以三个1024得到单位16.3368GB
#统计某天的使用流量峰值
[root@localhost ~]# cat access_2018-10-30.log |awk '{print $11}'|sort -nr|head
683243757
683243757
568808672
370556180
244179717
31216982
27669127
25782956
24267351
21754202
[root@localhost ~]# cat access_2018-10-30.log |awk '{print $11}'|sort -nr|head > ff.txt
[root@localhost ~]# cat access_2018-10-30.log |awk '{print $11/1024^2}'|sort -nr|head
651.592
651.592
542.458
353.39    #去三峰值是353.39M
232.868
29.7708
26.3873
24.5885
23.1431
20.7464
#统计访问量最多的前十个ip，每一个ip一共使用了多少流量
(1)我先列出访问量最多的前十个ip并写入
[root@localhost ~]# cat access_2018-10-30.log |awk '{print $1}'|sort -nr|uniq -c |sort -nr|head|awk '{print $2}' > ip2.txt
[root@localhost ~]# cat ip2.txt   ip2.txt 
23.91.100.204
101.69.132.78
101.69.132.77
101.69.132.82
101.69.132.76
101.69.132.83
101.69.132.80
101.69.132.84
101.69.132.81
101.69.132.79
(2)然后列出ip列和流量列，并筛选出访问量最大的前十个ip对应的ip列和流量列，最后计算每个ip使用了多少流量单位是GB。
[root@localhost ~]# cat ip2.sh   
#!/bin/bash
for i in `cat ip2.txt`
do
    cat access_2018-10-30.log |awk '{print $1,$11}'|grep "$i"|awk '{sum=sum+$2} END{print $1,sum/1024^3}'
done
[root@localhost ~]# sh ip2.sh
23.91.100.204 1.20969
101.69.132.78 0.0809936
101.69.132.77 0.0759132

SpringBoot：记录一次在centos上启动jar包慢的问题及解决方法

内部账号 — Mon, 29 Sep 2025 16:35:00 +0800

问题

项目的springboot的jar在本地开发十几秒就可以正常启动完毕，但是发布到linux服务器上几十秒甚至几百秒才会启动完成。刚启动的时候没有日志没有任何打印，连日志文件都没有生成。

解决

很多文章都是说修改jdk中的java.security这个文文件中的内容：

securerandom.source=file:/dev/random

替换成

securerandom.source=file:/dev/urandom

但是对于我的项目没有任何改变。那就不是这个问题了。

执行 hostname命令发现名称是 host-62-9-48-9 但是在/etc/hosts中只有默认的配置

在/etc/hosts中添加

62.9.48.9 host-62-9-48-9

再试一次重启项目，嗖…由原来的80多秒变成10秒启动了。

小结

遇到jar包在centos环境启动慢的情况，建议查看 hostname 与 /etc/hosts 文件中的hostname，查看hostname 是否存在，名称是否一致，确保俩边hostname 一致，问题可能就解决了，当然导致jar启动慢的情况也有很多种，还是要具体情况，具体分析了。

后端开发学习路线图：从基础原理开始

内部账号 — Sun, 28 Sep 2025 10:37:00 +0800

后端开发学习路线图：从基础原理开始

架构,后端,教程,Web 开发

整体认知
HTTP 协议
路由
序列化与反序列化
身份验证与授权
验证与转换
中间件
请求内容
处理器与控制器
CRUD 深入解析
REST 最佳实践
数据库
业务逻辑层
缓存
事务性电子邮件
任务队列与调度
Elasticsearch
错误处理
配置管理
日志、监控与可观测性
优雅关闭
安全性
扩展与性能
并发与并行
对象存储与大文件处理
实时系统
测试与代码质量
12 因素应用原则
OpenAPI 标准
后端工程师必备的 DevOps 知识

整体认知

后端开发是 Web 开发的服务器端部分，主要关注数据库、脚本编写和网站架构。它是用户界面与数据库之间的桥梁，负责处理业务逻辑、数据处理和系统集成。

核心职责

后端系统必须处理数据存储与检索、执行业务逻辑、管理用户身份验证、确保安全性、处理并发请求并维护系统可靠性。它作为基础支撑，通过提供 API、管理数据流和协调各类服务，使前端应用能够正常运行。

架构模式

现代后端系统通常采用分层架构模式，将关注点分离到表示层、业务逻辑层和数据访问层。这种分离有助于提高可维护性、可测试性和可扩展性。后端作为服务提供者，暴露可供客户端调用的端点，以执行操作和检索数据。

系统组件

一个完整的后端系统由以下组件构成：处理 HTTP 请求的 Web 服务器、执行业务逻辑的应用服务器、用于数据持久化的数据库、提升性能的缓存层、用于异步处理的消息队列，以及各类外部服务集成。

HTTP 协议

HTTP（超文本传输协议）是万维网数据通信的基础。理解 HTTP 对后端开发至关重要，因为它定义了客户端与服务器之间消息的格式和传输方式。

请求 - 响应周期

每一次 HTTP 交互都遵循请求 - 响应模式。客户端向服务器发送请求，服务器处理请求后返回响应。这种无状态协议意味着每个请求都是独立的，且包含服务器完成请求所需的全部信息。

HTTP 方法

HTTP 定义了多种表示期望操作的方法：

GET：检索数据
POST：提交数据以创建资源
PUT：更新整个资源
PATCH：部分更新资源
DELETE：删除资源
HEAD：仅检索响应头
OPTIONS：返回资源支持的方法

状态码

HTTP 状态码用于告知请求的处理结果，主要分为以下几类：

1xx：信息性响应
2xx：成功响应
3xx：重定向响应
4xx：客户端错误
5xx：服务器错误

理解这些状态码对于正确处理错误和与客户端通信至关重要。

头信息与消息体

HTTP 头信息提供请求和响应的元数据，包括内容类型、身份验证信息、缓存指令和自定义应用数据。消息体包含实际传输的数据，其格式由头信息中指定的内容类型决定。

连接管理

现代 HTTP 实现支持持久连接，允许在单个连接上传输多个请求。HTTP/2 引入了多路复用技术，可在无队头阻塞的情况下处理并发请求。理解连接管理对性能优化至关重要。

路由

路由是确定应用如何响应客户端对特定端点（由 URL 路径和 HTTP 方法定义）请求的机制，相当于后端应用的流量控制系统。

路由定义

路由将 URL 模式映射到处理器函数，可包含静态路径、动态参数、查询字符串和通配符。设计良好的路由应直观、一致且符合 REST 规范，使 API 对使用者具有可预测性。

路由匹配

路由系统使用模式匹配算法，将传入的请求与已定义的路由进行匹配。当多个模式可能匹配一个请求时，优先级和特异性规则会决定由哪个路由处理请求。理解路由优先级可避免冲突，确保行为可预测。

路由参数

动态路由支持在 URL 路径中嵌入参数，实现灵活的端点定义。参数可分为必填或可选，且可设置类型约束和验证规则。正确处理参数有助于实现对特定资源的 CRUD 操作。

路由组与命名空间

将路由组织成逻辑组有助于优化代码结构和中间件应用。路由组可共享通用前缀、中间件或配置，减少代码重复并提高可维护性。

高级路由特性

现代路由系统支持多种高级特性，如路由模型绑定、用于性能优化的路由缓存、子域名路由以及路由专用中间件。这些特性支持复杂的 URL 方案和高效的请求处理。

序列化与反序列化

序列化是将对象或数据结构转换为适合存储或传输的格式的过程，反序列化则是其逆过程。这一过程是系统间数据交换和存储机制的基础。

数据格式

常见的序列化格式包括：

JSON：因简洁性和广泛支持，常用于 Web API
XML：适用于结构化文档和遗留系统
Protocol Buffers：用于高性能二进制序列化
MessagePack：高效的类 JSON 二进制格式
YAML：用于人类可读的配置文件

序列化过程

在序列化过程中，复杂数据结构会被扁平化为可传输或存储的线性格式。这一过程需要处理嵌套对象、数组、基本类型以及空值（null）、未定义值（undefined）或无穷大（infinity）等特殊值，且必须保证数据完整性和类型信息不丢失。

反序列化挑战

反序列化需从序列化数据中重构对象，面临多种挑战，如类型转换、处理缺失字段、验证数据完整性以及管理版本兼容性。健壮的反序列化过程应包含错误处理和数据验证机制。

性能考量

序列化性能会影响应用的吞吐量和响应时间。二进制格式通常比文本格式更快、更紧凑，但文本格式在调试和互操作性方面更具优势。应根据性能需求和生态系统兼容性选择合适的格式。

安全隐患

序列化可能通过反序列化攻击引入安全漏洞，即恶意数据利用反序列化过程进行攻击。因此，务必验证和清洗传入数据，避免将不可信数据反序列化为可执行对象，并使用安全的序列化库。

身份验证与授权

身份验证用于验证用户身份，授权则确定已验证用户可访问的资源。这些安全机制是保护资源和维护系统完整性的基础。

身份验证方法

基于密码的身份验证：常见但易受多种攻击
多因素身份验证：通过 “你知道的信息”“你拥有的物品” 或 “你的生物特征” 增加安全层级
基于令牌的身份验证：使用 JWT（JSON Web Token）等令牌实现无状态验证
生物特征和基于证书的身份验证：为高价值系统提供更强安全性

会话管理

传统会话管理：在服务器上存储用户状态，需会话存储和清理机制
基于令牌的无状态身份验证：无需服务器端会话存储，但需妥善管理令牌（包括刷新令牌策略和安全存储）

授权模型

基于角色的访问控制（RBAC）：将权限分配给角色，再将角色分配给用户
基于属性的访问控制（ABAC）：根据用户、资源和环境属性做出授权决策
访问控制列表（ACL）：为单个资源指定权限

应根据复杂度和灵活性需求选择合适的授权模型。

OAuth 与 OpenID Connect

OAuth：提供授权委托功能，允许应用代表用户访问资源而无需暴露凭证
OpenID Connect：在 OAuth 基础上增加身份验证功能，提供身份验证服务

理解这些标准对现代应用集成至关重要。

安全最佳实践

实施安全的密码策略
所有身份验证流量使用 HTTPS
使用强哈希算法存储密码
实施速率限制以防止暴力攻击
定期审计访问模式
绝不要以明文形式存储敏感凭证

验证与转换

数据验证确保传入数据符合应用需求，转换则将数据转换为适合处理或存储的格式。这些过程是维护数据质量和系统可靠性的关键。

输入验证

需验证所有传入数据的类型、格式、长度和业务规则。客户端验证可提升用户体验，但绝不能依赖它保障安全；服务器端验证是必需的，且应全面检查 SQL 注入、XSS（跨站脚本）攻击和数据一致性问题。

验证策略

基于模式的验证：使用预定义模式验证数据结构和类型
基于规则的验证：对数据值应用业务逻辑
基于上下文的验证：考虑当前系统状态和用户权限

应在多个层级实施验证，以实现健壮的保护。

数据转换

转换传入数据以匹配内部格式，包括标准化值、处理不同日期格式、单位转换和字符串清洗。无论输入源如何变化，转换都能确保数据处理和存储的一致性。

错误处理

验证失败时，应提供清晰、可操作的错误信息，且不暴露系统内部细节。在响应前收集所有验证错误，以提升用户体验。同时，记录验证失败情况，用于安全监控和系统改进。

性能优化

验证可能影响性能（尤其是处理大型数据集时）。可通过以下方式优化：

实施早期验证，快速失败
使用高效的验证库
缓存验证模式
对非关键检查考虑异步验证

中间件

中间件是在请求 - 响应周期中执行的函数，可访问请求和响应对象。它们是实现横切关注点和模块化请求处理的强大机制。

中间件概念

中间件函数可在将控制权传递给下一个中间件或路由处理器之前执行操作，能修改请求或响应对象、终止请求 - 响应周期，或调用栈中的下一个中间件。这种责任链模式支持灵活的请求处理。

常见中间件类型

身份验证中间件：验证用户凭证
日志中间件：记录请求详情
压缩中间件：减小响应大小
CORS（跨域资源共享）中间件：处理跨域请求
速率限制中间件：防止滥用

每种中间件针对特定的横切关注点。

中间件顺序

中间件的执行顺序至关重要：

身份验证通常在授权之前
日志通常在早期执行，以捕获所有请求
错误处理中间件通常在最后，以捕获其他中间件的错误
压缩应在内容生成后执行

自定义中间件开发

自定义中间件应遵循单一职责原则，妥善处理错误，并正确调用下一个函数。需考虑性能影响（因中间件会对每个请求执行），设计可复用、可配置的中间件。

全局中间件与路由专用中间件

全局中间件：应用于所有路由
路由专用中间件：仅影响特定端点

全局中间件适用于日志、安全等通用关注点，路由专用中间件适用于特定身份验证需求等专项功能。

请求内容

理解并正确处理不同类型的请求内容，是构建能接受多种数据格式和文件上传的健壮 API 的关键。

内容类型

应用通常处理以下内容类型：

JSON：用于结构化数据交换
表单数据：用于传统 Web 表单
多部分数据（multipart）：用于文件上传
XML：用于遗留系统集成
纯文本：用于简单数据传输

每种内容类型需特定的解析和验证方法。

请求体解析

需根据内容类型解析请求体，并设置大小限制以防止内存耗尽。妥善处理解析错误，验证内容结构，清洗数据以防止注入攻击。对于大型负载，可考虑流式处理以管理内存使用。

文件上传处理

文件上传需在安全、存储和性能方面特殊考虑：

验证文件类型和大小
扫描恶意软件
生成唯一文件名以避免冲突
安全存储文件

可考虑使用云存储服务实现可扩展性。

内容协商

根据客户端在 Accept 头中指定的偏好，支持多种响应格式。实施内容协商以返回 JSON、XML 或其他请求格式；当客户端偏好不明确时，默认使用通用格式。

压缩与编码

支持压缩请求体以减少带宽使用（尤其对大型负载）。正确处理不同字符编码（文本内容默认使用 UTF-8），并根据需要实施相应的解压缩和编码转换。

处理器与控制器

处理器和控制器是处理传入请求并生成响应的组件，包含将输入根据业务需求转换为输出的应用逻辑。

处理器职责

处理器接收解析后的请求、提取必要数据、验证输入、调用业务逻辑服务、格式化响应并处理错误。它们作为 HTTP 协议与应用逻辑之间的接口，实现外部契约与内部表示之间的转换。

控制器组织

控制器将处理相似资源或功能的处理器分组，应遵循单一职责原则（处理一种资源类型或一组相关操作）。按领域概念而非技术层级组织控制器，可提高可维护性。

请求处理流程

典型的处理器流程如下：

提取参数和体数据
验证输入
将处理后的数据传入业务服务
处理服务响应和错误
根据内容协商格式化输出
设置适当的 HTTP 状态码和头信息

处理器中的错误处理

处理器必须妥善处理各类错误情况，包括验证失败、服务错误、数据库连接问题和意外异常。实施一致的错误响应格式，并进行适当日志记录以方便调试和监控。

处理器测试

测试处理器时，需：

模拟依赖项
验证参数提取的正确性
验证错误处理路径
检查响应格式和状态码
确保与中间件的正确集成

测试应聚焦于处理器的职责，而非底层服务。

CRUD 深入解析

CRUD（创建、读取、更新、删除）操作是大多数应用中数据操作的基础。理解 CRUD 原则和最佳实践，是构建可靠数据管理系统的关键。

创建操作（Create）

创建操作向系统中添加新资源，需：

验证所有输入数据
必要时检查重复资源
执行业务规则和约束
处理并发创建尝试
返回包含资源标识符的成功 / 失败响应

读取操作（Read）

读取操作检索现有资源而不修改它们，需：

支持大型数据集的过滤、排序和分页
实施高效查询策略
对敏感数据进行授权处理
无论数据量大小，提供一致的响应格式

更新操作（Update）

更新操作修改现有资源，需：

区分全量更新（PUT）和部分更新（PATCH）
处理并发修改冲突
验证更新是否保持数据一致性
实施原子操作以防止部分失败

删除操作（Delete）

删除操作从系统中移除资源，需：

删除前验证资源是否存在
谨慎处理级联删除
考虑用于审计跟踪的软删除策略
返回表示删除成功或资源不存在的适当状态码

CRUD 最佳实践

在所有层级实施适当验证
使用数据库事务确保一致性
提供有意义的错误信息
记录所有操作以用于审计
设计通过 HTTP 方法和 URL 清晰传达预期操作的 API

REST 最佳实践

REST（表述性状态转移）是设计网络应用的架构风格。遵循 REST 原则可创建可预测、可扩展且可维护的 API。

基于资源的 URL

围绕资源而非操作设计 URL，资源使用名词，操作通过 HTTP 方法表示。例如，使用GET /users/123而非GET /getUser/123，这样可创建直观且一致的 API 接口。

HTTP 方法使用

GET：无副作用地检索数据
POST：创建新资源
PUT：完全替换资源
PATCH：部分更新资源
DELETE：删除资源

选择能准确反映预期操作语义的方法。

状态码一致性

始终返回适当的 HTTP 状态码：

GET/PUT/PATCH 成功：200
POST 创建资源成功：201
DELETE 成功：204
客户端错误：400
身份验证失败：401
授权失败：403
服务器错误：500

响应格式标准

所有端点保持一致的响应格式：

包含分页信息等元数据
使用标准字段名
以一致结构提供错误详情
必要时通过内容协商支持多种响应格式

版本控制策略

实施 API 版本控制以管理随时间的变更，常见策略包括：

URL 版本控制：/v1/users
头信息版本控制：Accept: application/vnd.api+json;version=1
查询参数版本控制：?version=1

选择一种策略并始终如一地应用。

超媒体与可发现性

在响应中包含指向相关资源的链接
提供 API 内的导航路径
文档化资源的可用操作
尽可能使 API 具备自描述性

这可提高 API 可用性，减少客户端与服务器之间的耦合。

数据库

数据库是后端系统中数据持久化的基础。理解数据库概念、类型和最佳实践，对构建可靠且高性能的应用至关重要。

数据库类型

关系型数据库：使用结构化模式和 SQL，适用于复杂查询和事务
NoSQL 数据库：提供灵活模式和水平扩展，包括文档存储、键值存储、列族数据库和图数据库

需根据数据结构和可扩展性需求选择。

数据库设计原则

设计数据库时，通过规范化减少冗余，但可考虑反规范化以提升性能
定义实体间的清晰关系
为查询性能建立适当索引
设计支持应用需求和未来增长的模式

查询优化

通过理解执行计划编写高效查询
使用适当索引
避免 N+1 查询问题
考虑查询复杂度
监控查询性能并优化瓶颈
使用数据库分析工具识别慢查询

事务管理

要理解可靠数据操作所需的 ACID 属性（原子性 Atomicity、一致性 Consistency、隔离性 Isolation、持久性 Durability）。采用合适的事务隔离级别，妥善处理死锁问题，并尽量缩短事务时长，以减少锁定竞争。

连接管理

实现连接池以高效管理数据库连接。根据应用负载和数据库容量配置合适的池大小。妥善处理连接失败问题，并为临时性故障实现重试机制。

数据迁移与版本控制

通过迁移脚本管理数据库模式变更。为所有模式变更添加版本标识，对迁移过程进行全面测试，并制定回滚策略。使用迁移工具实现自动化操作，跟踪不同环境下的模式演进过程。

业务逻辑层

业务逻辑层包含定义数据创建、存储和修改方式的核心规则与流程。该层集中体现了业务领域的特定需求和规则。

领域建模

将业务概念建模为实体，明确其职责与关联关系。采用领域驱动设计原则构建能反映业务认知的模型，将领域逻辑与基础设施相关关注点分离。

服务组织

将业务逻辑组织成服务，每个服务封装一组相关操作。服务应具备清晰的接口，遵循单一职责原则，且可独立进行测试。围绕业务能力而非技术层级设计服务。

业务规则实现

在整个应用中统一实现业务规则。将规则逻辑集中管理以避免重复，在合适场景下将规则设计为可配置形式，并对复杂业务逻辑进行详细文档记录。对于复杂场景，可考虑使用规则引擎。

数据验证与不变性

通过验证和约束机制确保业务不变性。在适当的边界处对数据进行验证，维护相关实体间的一致性，并对验证失败情况进行妥善处理，返回具有明确意义的错误信息。

事务边界

围绕业务操作而非技术操作定义事务边界。确保事务能维护业务一致性，处理分布式事务的补偿机制，并在合适场景下考虑最终一致性模式。

缓存

缓存通过将频繁访问的数据存储在高速存储介质中，可提升应用性能。实施有效的缓存策略能显著缩短响应时间，降低数据库负载。

缓存类型

内存缓存：将数据存储在内存（RAM）中，实现最快访问速度
分布式缓存：在多台服务器间共享数据
浏览器缓存：在客户端设备上存储资源
CDN 缓存：通过地理分布式节点分发内容
数据库查询缓存：存储数据库查询结果

缓存策略

缓存回退（Cache-aside）：当缓存未命中时，从数据源加载数据并写入缓存
写透（Write-through）：数据更新时同时写入缓存和数据源
写回（Write-behind）：延迟将数据写入数据源，先更新缓存
预刷新（Refresh-ahead）：在缓存过期前主动更新缓存数据

需根据数据访问模式和一致性要求选择合适的策略。

缓存失效

实施缓存失效机制以维护数据一致性：

使用 TTL（生存时间）实现缓存自动过期
基于事件触发即时更新缓存（事件驱动失效）
对分组数据采用基于标签的失效策略

缓存失效是计算机科学领域中最具挑战性的问题之一。

缓存性能

监控缓存命中率以衡量缓存有效性
根据内存限制和访问模式调整缓存大小
实施合适的缓存淘汰策略
对关键数据考虑采用缓存预热策略

分布式缓存

使用分布式缓存实现多服务器间的可扩展性
妥善处理缓存节点故障
采用一致性哈希算法实现数据分布
考虑数据分片策略
监控缓存与应用服务器间的网络延迟

事务性电子邮件

事务性电子邮件是由用户操作或系统事件触发的自动化消息，对用户沟通、通知传递和业务流程至关重要。

邮件类型

欢迎邮件：向新用户发送问候
确认邮件：验证用户操作（如注册、订单提交）
通知邮件：告知系统事件（如账户变动、订单状态更新）
密码重置邮件：支持账户找回
收据邮件：确认交易完成

每种类型都满足特定的沟通需求。

邮件服务集成

使用可靠的邮件服务提供商处理邮件发送、身份验证和发件人信誉管理
配置 SPF、DKIM 和 DMARC 记录以实现邮件身份验证
监控邮件送达率，妥善处理退信问题

模板管理

创建可复用的邮件模板，包含动态内容占位符
支持多语言和多种格式（HTML / 纯文本）
保持品牌形象一致性
在不同邮件客户端中测试模板显示效果
对模板进行版本控制，确保更新一致性

队列管理

将邮件加入队列以确保可靠发送
为发送失败的邮件实现重试机制
对紧急邮件设置优先级
处理高并发邮件发送场景
监控队列深度和处理时长，确保邮件及时送达

合规性与隐私

遵循 CAN-SPAM、GDPR 等邮件相关法规
提供退订机制
尊重用户偏好设置
妥善维护订阅者列表
包含法定要求的必要信息
及时处理退订请求

任务队列与调度

任务队列支持对工作项的异步处理，调度则允许在特定时间执行任务。这些模式对构建响应迅速的应用和处理后台操作至关重要。

队列概念

队列实现了生产者与消费者的解耦，支持异步处理：

消息包含任务相关信息，由工作节点（Worker）处理
根据实现方式，队列可提供数据持久性、顺序保证和消息投递语义

队列类型

先进先出（FIFO）队列：按消息接收顺序处理
优先级队列：优先处理高优先级消息
延迟队列：将消息延迟至指定时间后处理
主题型队列：根据内容或路由键路由消息

工作节点管理

工作节点从队列中获取消息并执行关联任务
实施完善的错误处理机制
为临时性故障实现重试机制
为无法处理的消息设置死信队列
根据队列深度和处理需求调整工作节点数量（弹性伸缩）

调度模式

类 Cron 调度：按固定时间间隔执行任务（如每天凌晨 3 点）
一次性调度：在特定时间点执行单次任务
周期性调度：按特定模式重复执行任务（如每周一、三、五）

需考虑时区处理和夏令时变更问题。

可靠性与监控

通过持久化存储确保消息不丢失
实施消息确认机制以保证可靠处理
监控队列深度和任务处理时长
对故障或性能问题设置告警
制定灾难恢复方案

Elasticsearch

Elasticsearch 是基于 Apache Lucene 构建的分布式搜索与分析引擎，提供全文检索、实时分析和可扩展数据存储能力。

搜索基础

Elasticsearch 使用倒排索引实现快速文本搜索
支持结构化和非结构化数据
为搜索结果提供相关性评分
支持多种查询类型，包括精确词查询（term）、匹配查询（match）、范围查询（range）和布尔查询（bool）

索引管理

根据数据访问模式设计索引结构
为不同数据类型配置合适的字段映射（Mapping）
使用索引模板确保配置一致性
对时间序列数据考虑实施索引生命周期管理

查询优化

理解查询执行过程和性能特征
精确匹配场景使用过滤器（Filter），相关性评分场景使用查询（Query）
实施合适的缓存策略
监控慢查询，寻找优化机会

聚合与分析

使用聚合功能进行数据分析、指标计算和报表生成
桶聚合（Bucket Aggregation）：对数据进行分组
指标聚合（Metric Aggregation）：计算统计指标（如平均值、求和）
管道聚合（Pipeline Aggregation）：对聚合结果进行二次处理

集群管理

配置集群以实现高可用性和高性能
实施合理的分片（Shard）和副本（Replica）策略
监控集群健康状态和资源使用情况
规划集群容量和扩展需求

错误处理

完善的错误处理能确保应用妥善应对故障，为用户和系统提供有意义的反馈，对系统可靠性和可维护性至关重要。

错误分类

区分不同类型的错误并采用差异化处理策略：

用户错误：如无效输入、身份验证失败
系统错误：如数据库连接异常、服务不可用
编程错误：如代码漏洞、逻辑错误

错误响应标准

提供一致的错误响应格式，包含错误码、人类可读的错误信息，必要时附加上下文信息
包含关联 ID（Correlation ID），便于跨系统追踪错误
避免暴露敏感系统信息（如数据库结构、代码路径）

异常处理策略

在可能出错的操作周围实现 try-catch 代码块
为不同错误场景使用特定的异常类型
在适当层级处理异常，避免过度捕获
允许严重错误向上传递，以便上层处理

重试与熔断器模式

为临时性故障实现带指数退避（Exponential Backoff）的重试机制
使用熔断器（Circuit Breaker）防止故障级联传播
在可能的情况下提供降级方案（Fallback）
监控故障发生率，动态调整策略

错误日志与监控

记录错误时包含足够的调试上下文
使用结构化日志便于分析
为严重问题设置错误告警
跟踪错误模式，寻找系统改进机会

配置管理

配置管理将应用设置与代码分离，无需修改代码即可实现部署灵活性和环境特定定制。

配置来源

支持多种配置来源，包括：

环境变量
配置文件（如 JSON、YAML）
命令行参数
外部配置服务（如配置中心）

需定义配置优先级规则，处理配置冲突。

环境特定配置

为开发、测试（Staging）和生产环境维护独立配置
避免在代码中硬编码环境特定值
使用配置模板或生成工具确保一致性

密钥管理

使用专用密钥管理系统安全存储敏感配置（如数据库密码、API 密钥）
绝不要将密钥提交到版本控制系统
定期轮换密钥
对敏感配置数据进行加密

配置验证

在应用启动时验证配置有效性
对无效配置提供清晰的错误提示
对配置值实施类型检查
对复杂配置考虑采用基于 schema 的验证

动态配置

在可能的情况下支持无需重启应用即可更新配置
实现配置监听机制，自动应用配置变更
妥善处理可能影响运行中操作的配置变更

日志、监控与可观测性

可观测性通过日志（Logging）、指标（Metrics）和追踪（Tracing）实现对系统行为和性能的理解，对维护可靠的生产系统至关重要。

日志最佳实践

使用结构化日志并保持格式一致
在日志消息中包含相关上下文信息
实施合适的日志级别（DEBUG、INFO、WARN、ERROR）
避免记录敏感信息（如密码、个人身份数据）
使用关联 ID（Correlation ID）追踪跨服务请求

指标与监控

收集应用指标，包括请求率、响应时间、错误率和业务指标
监控基础设施指标，如 CPU 使用率、内存占用、磁盘空间和网络流量
为关键阈值和异常情况设置告警
建立性能基准，跟踪性能变化趋势

分布式追踪

实施分布式追踪以跟踪跨多服务的请求流转
识别性能瓶颈
理解服务间依赖关系
使用追踪采样（Sampling）平衡性能开销与可见性

健康检查

实现健康检查端点，用于监控系统状态
包含对数据库、外部服务等依赖的检查
提供详细的健康信息，便于问题排查
结合负载均衡器配置，实现故障自动切换

告警策略

基于用户影响而非技术指标设计告警规则
为严重告警制定升级流程
通过合理设置阈值和告警管理，避免告警疲劳
确保告警信息包含足够的上下文，便于快速响应

优雅关闭

优雅关闭确保应用能干净地停止运行：完成正在处理的请求、正确释放资源，并实现无数据丢失、无服务中断的平滑部署。

关闭信号处理

监听来自操作系统或容器编排工具的关闭信号（如 SIGTERM、SIGINT）
实现信号处理器，触发优雅关闭流程
提供可配置的关闭超时时间

正在处理请求的处理

停止接收新请求，同时允许正在处理的请求完成
实现请求排空（Request Draining）机制，并设置合理超时
提供状态端点，向负载均衡器指示应用正处于关闭状态

资源清理

干净地关闭数据库连接
刷新待写入数据和缓存
停止后台任务和定时任务
释放文件句柄和网络连接
为所有托管资源实现清理流程

依赖服务关闭

与依赖服务协调关闭流程
妥善处理外部服务依赖
实现熔断器，防止关闭过程中因外部服务不可用导致的挂起

容器与编排集成

在容器编排工具中配置合适的终止宽限期
在关闭过程中返回正确的健康检查响应
确保关闭流程能在配置的超时时间内完成

安全性

安全性是贯穿后端开发各层级的核心关注点，需保护数据安全、防止未授权访问、维护系统完整性。

输入安全

验证并清洗所有输入数据，防止注入攻击
采用正确的参数绑定方式，防止 SQL 注入
对输出数据进行适当转义，防止 XSS（跨站脚本）攻击
尽可能使用白名单（Allowlist）而非黑名单（Blocklist）进行过滤

身份验证安全

实施严格的密码策略，使用可靠的哈希算法存储密码
对敏感操作启用多因素认证（MFA）
采用安全的会话管理实践
通过速率限制（Rate Limiting）防止暴力破解攻击

通信安全

所有通信均使用 HTTPS
实施完善的证书管理
使用 HSTS、CSP 等安全头部
定期验证 SSL/TLS 配置
对传输中和静态存储的敏感数据进行加密

访问控制

遵循最小权限原则
在所有访问点实施适当的授权检查
验证所有操作的权限
定期审计访问模式
设计安全的故障处理机制（安全失效）

安全监控

监控安全事件和异常行为
实施入侵检测机制
记录与安全相关的事件
制定事件响应流程
通过定期安全审计和渗透测试识别漏洞

扩展与性能

扩展与性能优化使应用能在负载增长的情况下保持响应能力，包括垂直扩展（增强单节点硬件）和水平扩展（增加节点数量）两种方式。

性能指标

监控关键性能指标：响应时间、吞吐量、错误率和资源利用率
建立性能基准
根据用户需求和业务目标设定合理的性能目标

垂直扩展

通过增加 CPU、内存或存储资源提升单个服务器性能
该方式实现简单，但存在物理限制和单点故障风险
在扩展前使用性能分析工具识别资源瓶颈

水平扩展

通过增加服务器实例数量分散负载
要求应用设计为无状态模式
需制定负载均衡策略
考虑多实例间的数据一致性问题
提供更好的容错能力

负载均衡

使用多种算法（如轮询、最少连接、加权分配）在多服务器间分发请求
实施健康检查，仅将流量路由到健康实例
支持会话亲和性（Session Affinity）（如需要）
考虑使用硬件或软件负载均衡解决方案

数据库扩展

对读密集型工作负载使用只读副本
对写密集型工作负载使用数据库分片（Sharding）
使用连接池提高资源使用效率
针对特定扩展需求考虑 NoSQL 数据库

缓存策略

在多个层级实施缓存：应用级缓存、数据库查询缓存、CDN 缓存
使用合适的缓存失效策略维护数据一致性
针对热点数据优化缓存配置

并发与并行

并发使应用能同时处理多个任务，并行则指同时执行多个任务。理解这些概念对构建响应迅速、高效的后端系统至关重要。

并发模型

基于线程的并发：在单个进程中使用多个线程
事件驱动并发：使用事件循环和回调机制
基于 Actor 的并发：将状态封装在 Actor 中，通过消息通信

需根据问题特征选择合适的模型。

线程安全

通过同步机制（如互斥锁、锁、原子操作）确保多线程访问共享资源时的数据一致性
尽量减少共享可变状态
优先使用不可变数据结构

异步处理

使用异步编程模式处理 I/O 操作，避免线程阻塞
实施非阻塞 I/O 提高资源利用率
使用回调模式或 async/await 语法编写易读的异步代码
避免回调地狱（Callback Hell）

并行处理

将计算任务分配到多个处理器或核心
使用线程池高效管理工作线程
对 CPU 密集型任务考虑使用并行算法
平衡并行带来的性能提升与额外开销

竞态条件与死锁

通过适当的同步机制识别并防止竞态条件
通过一致的锁顺序和超时机制避免死锁
使用测试和分析工具检测并发问题
实施死锁检测和恢复机制（如需要）

对象存储与大文件

对象存储为存储大文件、媒体内容和非结构化数据提供了可扩展的解决方案。对于处理用户生成内容和大型数据集的现代应用程序而言，对象存储至关重要。

对象存储概念

对象存储系统将文件作为带有元数据的对象存储在扁平命名空间中，提供用于访问的 REST API，具备近乎无限的可扩展性，并包含版本控制、生命周期管理和访问控制等功能。

文件上传策略

直接向对象存储上传文件，以减轻服务器负载
使用预签名 URL 实现安全的临时访问
为大文件支持断点续传功能
验证文件类型和大小，保障安全性

内容分发

使用内容分发网络（CDN）实现文件的全球分发
为静态内容配置适当的缓存头
考虑使用图像优化和转换服务，实现响应式内容交付

文件处理

异步处理上传的文件，避免阻塞用户界面
实施病毒扫描，确保安全
为媒体文件生成缩略图或预览图
处理文件格式转换需求

存储优化

制定生命周期策略，将旧文件迁移到成本更低的存储层级
在合适的情况下对文件进行压缩
对相同文件进行去重处理
监控存储成本和使用模式

实时系统

实时系统支持客户端与服务器之间即时的双向通信，适用于聊天应用、实时更新和协同编辑等场景。

实时技术

WebSockets 通过 TCP 连接提供全双工通信
服务器发送事件（Server-Sent Events）支持服务器到客户端的流传输
轮询（Polling）技术是一种简单但效率较低的替代方案
应根据通信模式和浏览器支持情况选择合适的技术

连接管理

处理连接建立、身份验证和生命周期管理
实现连接池技术
采用心跳机制检测断连情况
在实时功能不可用时，实现平滑降级

消息路由

高效地在客户端之间路由消息
实现发布 / 订阅（pub/sub）模式以进行消息广播
为离线客户端考虑消息持久化方案
根据需求处理消息排序和交付保证

实时系统扩展

使用消息代理实现跨多个服务器实例的扩展
为连接亲和性实现粘性会话（sticky sessions）或共享状态
对于复杂需求，考虑使用专用的实时平台

性能与可靠性

监控连接数量和消息吞吐量
实施速率限制，防止滥用
妥善处理网络故障
为关键功能提供备用机制

测试与代码质量

测试可确保代码正确性，支持放心的代码重构；而代码质量实践则能提高可维护性并减少漏洞。两者对于可持续的软件开发都至关重要。

测试金字塔

单元测试：孤立地验证单个组件
集成测试：验证组件间的交互
端到端测试：验证完整的用户流程
需根据成本和反馈价值平衡不同层级的测试

测试驱动开发（TDD）

在实现功能前先编写测试，以此指导设计决策
确保全面的测试覆盖率
在开发过程中提供即时反馈
有助于编写更具可测试性和针对性的代码

模拟与测试替身（Test Doubles）

使用模拟对象（mocks）、存根（stubs）和伪对象（fakes）将被测单元与依赖项隔离
对外部服务、数据库和复杂对象进行模拟，以创建可靠且快速的测试
避免过度模拟，否则会导致测试变得脆弱

测试环境管理

维护具有受控数据的独立测试环境
使用数据库事务或清理程序维持测试隔离性
实现测试数据工厂，确保一致的测试设置

代码质量指标

通过循环复杂度、代码覆盖率、重复率和可维护性指数等指标监控代码质量
使用静态分析工具识别潜在问题并强制执行编码标准

持续集成（CI）

在 CI/CD 流水线中实现测试自动化
每次代码变更后运行测试
测试失败时阻止部署
在自动化流水线中包含代码检查、安全扫描和性能测试

十二因素应用原则（12 Factor App Principles）

十二因素应用方法论为构建软件即服务（SaaS）应用提供了指导方针，使应用在现代云环境中具备可移植性、可扩展性和可维护性。

代码库（Codebase）

维护一个通过版本控制追踪的代码库，支持多个部署实例
使用分支开发功能，但从单个主分支部署
避免为同一应用维护多个代码库

依赖（Dependencies）

使用依赖管理工具明确声明并隔离依赖项
绝不依赖系统级包
确保不同环境中依赖项版本一致

配置（Config）

将配置存储在环境变量中，而非代码里
将不同部署实例间存在差异的配置与应用代码分离
复杂场景下使用配置管理工具

后端服务（Backing Services）

将数据库、队列、缓存等后端服务视为附加资源，通过 URL 或连接字符串访问
实现服务可替换性，无需修改代码

3 构建、发布、运行（Build, Release, Run）

严格分离构建、发布和运行三个阶段
构建阶段：创建部署工件
发布阶段：将构建产物与配置结合
运行阶段：在执行环境中启动应用

进程（Processes）

将应用作为无状态进程执行，进程间不共享任何数据
在后端服务中存储持久化数据
Web 应用使用外部会话存储

端口绑定（Port Binding）

通过端口绑定对外提供服务，而非依赖运行时注入的 Web 服务器
应用应具备自包含性，通过端口接口提供服务

并发（Concurrency）

通过进程模型实现应用扩展，而非进程内线程
为不同工作负载使用不同类型的进程
由进程管理器负责扩展工作

可处置性（Disposability）

设计可快速启动且优雅关闭的进程
妥善处理终止信号
确保启动迅速、关闭干净的稳健运行机制

开发 / 生产环境一致性（Dev/Prod Parity）

保持开发、预发布和生产环境尽可能相似
最大限度减少环境间在时间、人员和工具方面的差异

日志（Logs）

将日志视为事件流，输出到标准输出（stdout）
由执行环境负责日志的路由、存储和分析
使用结构化日志，便于更好地分析

管理进程（Admin Processes）

管理任务作为一次性进程，在与常规应用进程相同的环境中运行
管理任务使用与应用相同的代码库和配置

OpenAPI 标准

OpenAPI（前身为 Swagger）是用于描述 REST API 的规范，支持自动生成文档、客户端 SDK 和 API 测试自动化。

API 文档

创建全面的 API 文档，描述端点、请求 / 响应格式、身份验证要求和错误响应
保持文档与实现同步更新

规范结构

构建 OpenAPI 规范时，需包含清晰的 API 信息、服务器配置、路径定义、组件模式和安全方案
使用引用减少重复内容

模式定义（Schema Definition）

使用 JSON Schema 定义请求和响应模式
指定数据类型和约束条件
为所有属性添加描述和示例文档
对复杂模式采用组合方式定义

代码生成

从 OpenAPI 规范生成客户端 SDK 和服务器存根，确保文档与实现的一致性
使用代码生成工具减少手动编码工作量

API 版本控制

在 OpenAPI 规范中清晰标注 API 版本
尽可能保持向后兼容性
为破坏性变更提供迁移指南
对 API 版本采用语义化版本控制

验证与测试

根据 OpenAPI 模式验证 API 响应
使用基于规范的测试工具
实施契约测试，确保 API 符合文档描述的行为

后端工程师的 DevOps 实践

DevOps 实践使后端工程师能够有效部署、监控和维护应用程序。理解 DevOps 概念对于现代后端开发至关重要。

基础设施即代码（Infrastructure as Code）

用代码定义基础设施，而非手动配置
对基础设施定义进行版本控制
实现自动化配置和资源供应
确保一致性和可重复性

容器化（Containerization）

使用 Docker 等容器技术将应用与其依赖项打包
容器提供一致的运行时环境
简化部署流程
实现高效的资源利用

容器编排（Container Orchestration）

使用 Kubernetes 等编排平台大规模管理容器化应用
实现服务发现、负载均衡
支持自动扩展和滚动更新

CI/CD 流水线

实施持续集成，自动构建和测试代码变更
实施持续部署，自动发布应用
采用 “流水线即代码” 的方式，实现可维护的自动化

监控与告警（Monitoring and Alerting）

使用适当工具监控应用和基础设施健康状况
为需要人工干预的问题设置全面告警
创建系统仪表盘，提升系统可见性

配置管理（Configuration Management）

使用配置管理工具自动化服务器配置和软件安装
保持各环境一致性
实现快速的环境供应

DevOps 中的安全（Security in DevOps）

在开发和部署流水线中融入安全实践
实施漏洞扫描
安全管理密钥
遵守安全策略合规要求

备份与灾难恢复（Backup and Disaster Recovery）

为数据和配置制定全面的备份策略
定期测试恢复流程
制定灾难恢复计划，明确恢复时间目标（RTO）和恢复点目标（RPO）

性能优化（Performance Optimization）

监控生产环境中的应用性能
实施自动化性能测试
根据实际负载模式优化资源使用

云服务集成（Cloud Services Integration）

利用云服务提升可扩展性和可靠性
实施多区域部署，确保高可用性
使用托管服务减少运维开销

结语

本指南从基础原理出发，为后端开发提供了全面的知识框架。每个主题都建立在之前概念的基础上，形成了涵盖现代后端工程所有关键领域的结构化学习路径。

从理解基本 HTTP 协议到实现复杂分布式系统，这一过程需要专注投入和实践操作。在深入学习特定技术或框架之前，应先注重理解底层原理 —— 无论你选择何种技术栈，这些知识都将发挥重要作用。

请记住，后端开发是一个不断发展的领域，新的技术、模式和最佳实践层出不穷。本指南中的原则提供了坚实的基础，但持续学习和适应变化对于长期成功至关重要。

从基础知识开始，通过实际项目积累经验，随着信心和经验的提升逐步挑战更复杂的主题。后端技术的精进是一个迭代过程 —— 随着你理解的加深和需求的复杂化，你会发现需要多次回顾并深化对各个主题的认识。

最重要的是，专注于构建能够可靠、可维护地解决实际问题的系统。最佳的后端系统既能为用户提供高效服务，又能让开发和维护它的团队可持续地开展工作。

tomcat的那些默认配置

阿布大人 — Mon, 23 Jun 2025 08:56:00 +0800

前些天在qq群，一位同学在使用富文本编辑器的时候，遇见了莫名其妙的错误。对应字段明明填写了，但是总是提示不能为空。

经过多方面排查，发现是因为tomcat的最大post表单大小是2M，他这个富文本的内容远远超过了2M..

所以整理一下springboot项目中server.tomcat默认配置的整理，供大家学习使用。

线程配置

server.tomcat.threads.max：最大工作线程数，默认值为200。每一次HTTP请求到达Web服务，Tomcat都会创建一个线程来处理该请求，此参数决定了Web服务容器可以同时处理多少个请求。不过，增加线程是有成本的，更多的线程会带来更多的线程上下文切换成本，并且意味着更多的内存消耗。例如，JVM中默认情况下在创建新线程时会分配大小为1M的线程栈。线程数的经验值为：1核2G内存，线程数经验值200；4核8G内存，线程数经验值800。
server.tomcat.threads.min-spare：最小工作空闲线程数，默认值为10。

连接配置

server.tomcat.max-connections：服务器在任何给定时间接受和处理的最大连接数。对于Java的阻塞式BIO，默认值是max-threads的值；如果在BIO模式使用定制的Executor执行器，默认值将是执行器中max-threads的值。对于Java新的NIO模式，默认值是10000；对于windows上APR/native IO模式，默认值为8192 ，这是出于性能原因，如果配置的值不是1024的倍数，max-connections的实际值将减少到1024的最大倍数。如果设置为 -1，则禁用max-connections功能，表示不限制Tomcat容器的连接数。
server.tomcat.accept-count：等待队列的最大队列长度，默认值为100。当所有可能的请求处理线程都在使用时，传入连接请求会被放进队列中等待。如果等待队列也被放满了，这时再来新的请求就会被Tomcat拒绝（connection refused）。

编码配置

server.tomcat.uri-encoding：用于解码URI的字符编码，默认值为UTF-8。

请求大小配置

server.tomcat.max-http-form-post-size：任何HTTP POST请求中表单内容的最大大小，默认值为2MB。理论上POST请求的大小是无限制的，但是Tomcat设定了请求大小为2MB，如要取消限制，则应该将值设为 -1。
server.tomcat.max-swallow-size：请求正文的大小，默认值为2MB。

超时配置

server.tomcat.connection-timeout：连接器在接受连接后将等待呈现请求URI行的时间，即socket调用read()等待读取的时间，如果在设置的时间内没有请求，则会主动断开连接，默认值为60000ms。
server.tomcat.keep-alive-timeout：在连接关闭之前等待另一个HTTP请求的时间，默认和connection-timeout的值一样，设置为 -1 时不会超时。

其他配置

server.tomcat.max-keep-alive-requests：在连接关闭之前可以通过管道传输的最大HTTP请求数。当设置为0或1时，长连接和管道被禁用，可以避免Tomcat产生大量的TIME_WAIT连接，从而从一定程度上避免Tomcat假死。当设置为 -1 时，允许无限数量的管道或长连接请求，默认值为100。
server.tomcat.accesslog.enabled：是否启用访问日志，默认值为false。
server.tomcat.basedir：存放Tomcat的日志、Dump等文件的临时文件夹，默认为系统的tmp文件夹（如：C:\Users\Angel\AppData\Local\Temp）。
server.tomcat.max-http-header-size：HTTP消息头的最大大小，默认值为0，表示使用连接器的容器特定默认值。
server.tomcat.max-http-post-size：HTTP POST内容的最大大小，默认值为2097152字节（即2MB）。
server.tomcat.redirect-context-root：是否应通过在路径后附加 / 来重定向到上下文根的请求，默认值为 true。
server.tomcat.use-relative-redirects：HTTP 1.1及更高版本的 sendRedirect 调用生成的位置头是否使用相对或绝对重定向，默认未设置。
server.tomcat.accesslog.buffered：是否缓冲输出，使其仅定期刷新，默认值为 true。
server.tomcat.accesslog.check-exists：是否检查日志文件是否存在，以便在外部进程重命名它时可以重新创建它，默认值为 false。
server.tomcat.accesslog.condition-if：仅在 ServletRequest.getAttribute(conditionIf) 不产生 null 时才启用请求的日志记录，默认未设置。
server.tomcat.accesslog.condition-unless：仅在 ServletRequest.getAttribute(conditionUnless) 产生 null 时才启用请求记录，默认未设置。
server.tomcat.accesslog.directory：创建日志文件的目录，可以是绝对的或相对于Tomcat基本目录，默认值为 logs。
server.tomcat.accesslog.encoding：日志文件使用的字符集，默认为系统默认字符集。
server.tomcat.accesslog.file-date-format：放置在日志文件名中的日期格式，默认值为 .yyyy-MM-dd。
server.tomcat.accesslog.ipv6-canonical：是否使用RFC 5952定义的IPv6规范表示格式，默认值为 false。
server.tomcat.accesslog.locale：用于格式化日志条目和日志文件名后缀中的时间戳的语言环境，默认为Java进程的默认语言环境。
server.tomcat.accesslog.max-days：删除访问日志文件之前保留的天数，默认值为 -1，表示不删除。
server.tomcat.accesslog.pattern：访问日志的格式模式，默认值为 common。
server.tomcat.accesslog.prefix：日志文件名前缀，默认值为 access_log。
server.tomcat.accesslog.rename-on-rotate：是否推迟在文件名中包含日期戳，直到轮换时间，默认值为 false。
server.tomcat.accesslog.request-attributes-enabled：是否为请求使用的IP地址、主机名、协议和端口设置请求属性，默认值为 false。
server.tomcat.accesslog.rotate：是否启用访问日志轮换，默认值为 true。
server.tomcat.accesslog.suffix：日志文件名后缀，默认值为 .log。
server.tomcat.additional-tld-skip-patterns：逗号分隔的附加模式列表，匹配jar以忽略TLD扫描，特殊的 ? 和 * 字符可以在模式中使用，以分别匹配一个和一个字符以及零个或多个字符，默认未设置。
server.tomcat.background-processor-delay：调用 backgroundProcess 方法之间的延迟，如果未指定持续时间后缀，则将使用秒，默认值为10秒。
server.tomcat.mbeanregistry.enabled：是否应该启用Tomcat的MBean Registry，默认值为 false。
server.tomcat.processor-cache：将保留在缓存中并在后续请求中重用的最大空闲处理器数，当设置为 -1 时，缓存将不受限制，理论上的最大大小等于最大连接数，默认值为200。

这些默认配置可以通过在application.yml或application.properties文件中进行修改，以满足不同的项目需求。

（原创）dify实现@效果

阿布大人 — Mon, 16 Jun 2025 15:23:00 +0800

在基础版的dify中，使用基础回话与AI交流。当编制的chatflow非常复杂的时候，我们期望通过@xx助手，实现在chatflow中进行if判断，然后通过不同分支进行响应恢复的效果。但是原生的dify是不支持@的。本文通过魔改添加代码实现基础@效果，适用于1.4.1之前的任何docker版本。之后的版本兴许也适用，但是还没出。

添加@功能操作步骤如下，本文默认你已经通过docker compose安装dify。

1.在volumes/certbot/www 目录下创建haobo56目录，新建diao.js 。内容见代码。

let checkCount = 0;
const maxChecks = 5;

function checkAndBindEvent() {
    const messageInput = document.querySelector('textarea');
    const c_pathname = window.location.pathname;
    console.log(messageInput);
    console.log(c_pathname);
    if (messageInput && c_pathname.startsWith('/chat')) {
        let currentFocus;
        let suggestionsList;

        messageInput.onkeyup = function(e) {
            let val = this.value;
            closeAllLists();
            if (!val) return false;
            currentFocus = -1;

            if (val === '@') {
                suggestionsList = document.createElement('ul');
                suggestionsList.style.position = 'absolute';
                suggestionsList.style.border = '1px solid #ccc';
                suggestionsList.style.backgroundColor = 'white';
                suggestionsList.style.width = '200px';
                suggestionsList.style.listStyleType = 'none';
                suggestionsList.style.padding = '0';
                suggestionsList.style.margin = '0';
                suggestionsList.style.zIndex = '1000';

                for (let user of customer_users) {
                    const item = document.createElement('li');
                    item.textContent = user;
                    item.onclick = function() {
                        replaceAtCursor(messageInput, `@${user}`);
                        closeAllLists();
                    };
                    item.style.padding = '5px';
                    item.style.cursor = 'pointer';
                    item.onmouseover = function() {
                        removeActive(suggestionsList.getElementsByTagName("li"));
                        this.classList.add("active-suggestion");
                    };
                    suggestionsList.appendChild(item);
                }

                document.body.appendChild(suggestionsList);

                // Position the suggestions list at the top-right corner of the textarea
                const rect = messageInput.getBoundingClientRect();
                suggestionsList.style.left = `${rect.left + 30}px`; // Adjust width to match ul width
                suggestionsList.style.top = `${rect.top - 110}px`;

                // Handle arrow keys and enter key within onkeyup event
                if (e.key === "ArrowDown") {
                    currentFocus++;
                    addActive(suggestionsList.getElementsByTagName("li"));
                } else if (e.key === "ArrowUp") {
                    currentFocus--;
                    addActive(suggestionsList.getElementsByTagName("li"));
                } else if (e.key === "Enter") {
                    if (currentFocus > -1) {
                        if (suggestionsList && suggestionsList.getElementsByTagName("li").length > currentFocus) {
                            suggestionsList.getElementsByTagName("li")[currentFocus].click();
                        }
                    }
                }
            } else {
                closeAllLists();
            }
        };

        window.onclick = function(e) {
            if (e.target !== messageInput) {
                closeAllLists();
            }
        };

        function closeAllLists() {
            if (suggestionsList) {
                document.body.removeChild(suggestionsList);
                suggestionsList = null;
            }
        }

        function replaceAtCursor(myField, myValue) {
            const startPos = 0; // Always start at the beginning since we check for '@' at the start
            const endPos = 1;   // End at the position after '@'
            myField.value = myField.value.substring(0, startPos) + myValue + ' ' + myField.value.substring(endPos, myField.value.length);
            myField.selectionStart = myField.selectionEnd = startPos + myValue.length + 1; // Move cursor after the inserted text
            myField.focus();
        }

        function addActive(x) {
            if (!x) return false;
            removeActive(x);
            if (currentFocus >= x.length) currentFocus = 0;
            if (currentFocus < 0) currentFocus = (x.length - 1);
            x[currentFocus].classList.add("active-suggestion");
        }

        function removeActive(x) {
            for (let i = 0; i < x.length; i++) {
                x[i].classList.remove("active-suggestion");
            }
        }

        clearInterval(checkInterval); // Stop checking once the element is found and events are bound
    }else{
            //防止定时搞的浏览器很卡
            checkCount++;
            if (checkCount >= maxChecks) {
            clearInterval(checkInterval); // 达到最大检查次数时停止检查
        }
    }
}

const customer_users = ['小精灵', '大头兵', 'qwen', 'deepseek'];
const checkInterval = setInterval(checkAndBindEvent, 2000);

2.修改nginx模版文件 nginx/conf.d/default.conf.template，见代码，以下代码为新增代码

  location ~ ^/chat {
         proxy_pass http://web:3000;
         add_header xx-job-key "test1";
         proxy_set_header Accept-Encoding "";
         sub_filter '' ' ';  
         sub_filter_once off;
         sub_filter_types *;
         include proxy.conf;
     }

     location /haobo56/ {
       root /var/www/html;
     }

3.之后重启docker compose restart，在聊天框输入@就看到效果了

4.编排chatflow的时候你可以这样判断了

本文为原创内容：转载请注明出处

https://blog.xuhaobo.cn/%E7%A7%81%E6%9C%89%E5%88%86%E7%B1%BB/75.html

lenna 图像识别原图

阿布大人 — Mon, 26 May 2025 14:53:00 +0800

原文链接点这里

感谢贡献

数据治理为何屡屡无果，却又屡屡重启？

阿布大人 — Fri, 16 May 2025 10:05:00 +0800

在今天的文章里，我们来探讨一下：为何企业在数据治理这件事上，总是陷入一种治标不治本的循环。

我留意到一个颇为有趣的现象：当下的企业在数据治理的征程中，仿佛一直在做“生死轮回”。一方面，企业在多数时间多数人对数据质量问题视而不见，选择“躺平”；但另一方面，少部分人包括经营者又不得不直面数据杂乱无章、企业运营缺乏可用数据的困境。

在存量时代的竞争中，数据已然成为企业绕不开的关键要素。这就造成了一种局面，每隔一两年，企业内部就会掀起一场数据治理的热潮，召开大型会议、制定新规则、引入新工具。然而，最终的结果往往是有始无终，治理的成果难以长久维持。

一家xx企业的CTO曾感慨道：“我们的数据治理项目，似乎每隔两年就得重启一次，问题总是反复出现，始终无法得到有效解决。”

再看看互联网大厂，情况也并无二致。几乎每家企业都经历过类似的困境：数据治理就像一阵风，项目结束后留下一地鸡毛，数据问题依旧如影随形。

为什么数据治理总是陷入这种“周期性运动”呢？其背后的核心原因是什么？又该如何解决呢？

一、数据治理困境的根本原因

企业在数据治理方面反复折腾，主要是因为治理方式“治标不治本”。治理项目看似声势浩大，但往往缺乏持续性和系统性，尤其是在数据标准方面存在明显不足。

常见的问题主要有以下几个方面：

1、局部治理，缺乏全局观当某个部门的数据出现问题时，企业就集中力量治理该部门的数据，缺乏对整体数据的全局视角。局部的过度处理一定会导致数据的不合群。整体看数据还是乱糟糟。

2、缺少顶层设计许多企业没有将数据治理提升到战略层面，仅仅是被动地应对业务中出现的问题。更多的情况是数据管理者没有权限去要求规范数据，企业也未提供一体化的数据工作环境。

3、过度依赖工具企业认为购买了数据治理平台就万事大吉，却忽略了数据标准和流程的建设。要知道，事在人为，在牛逼的工具也是人来驱动的。

4、关键人才匮乏数据治理需要既懂技术、又懂业务和管理的综合性人才，但企业内部往往缺乏这样的人才。很多企业的数据治理工作由IT部门牵头，但搞了半年，连数据治理要服务的业务场景和目的都没弄清楚，结果可想而知。

这些问题既涉及组织层面，也涉及人才层面，但归根结底，还是因为缺乏统一的数据标准。如果没有统一的数据标准，数据治理就如同建造房屋没有打好地基，看似搭建起来了，但很快就会崩塌。

二、数据标准对数据治理为何至关重要

什么是数据标准呢？

简单来说，数据标准就是企业内部对数据的统一定义和规范，包括数据的命名、格式、口径、分类等规则。

数据标准贯穿于数据的整个生命周期——从数据的采集、存储，到处理、分析和应用。如果没有数据标准，各个部门的数据就会各自为政，口径不一致，指标之间相互矛盾，数据分析的结果自然也就难以令人信任。

想象一下，如果一个城市没有交通规则，每辆车都按照自己的方式行驶，城市的交通会变得多么混乱？同样的道理，企业的数据也需要“交通规则”，而数据标准就是企业数据的“红绿灯”和“分道线”。

这么说可能还是比较抽象，我们来看一个简单的例子。一个完整的数据标准，涵盖了字段的命名规则、数据格式、业务口径、分类分级、数据质量要求等方面。下面以“手机号码”为例进行说明。

字段标准样例：手机号码（MOBILE_NUMBER）
字段属性	标准要求
字段名称	MOBILE_NUMBER
字段含义	员工的个人手机号码，用于联系员工及发送通知
命名规则	全部采用大写字母+下划线分隔，字段名要体现业务含义。例如，MOBILE表示手机，NUMBER表示号码。
数据类型	CARCHAR
数据格式	长度为 11 位，必须是纯数字
数据分类	个人敏感数据
数据分级	高敏感级别，涉及员工个人隐私信息，需严格保护
数据质量要求	唯一性：每个员工的手机号码必须唯一，不得重复格式校验：必须为11位有效手机号码，且只能包含数字必填性：入职时必须填写，不允许为空有效性：定期检查号码有效性，剔除无效号码
数据用途	用于通知发送、权限管理、紧急联系等场景

通过制定上述数据标准，可以有效地提高数据质量，确保数据的可用性，提高数据的长期可维护性，更重要的是能够显著提升数据的一致性，实现数据的一致共享。

三、数据标准有哪些应用场景

很多人可能会有疑问，制定了一堆标准到底有什么用呢？接下来，我们一起看看在数据治理过程中，数据标准有哪些应用场景。

在数据治理的实践中，数据标准的应用场景非常广泛，主要体现在以下几个方面：

1、规范建模许多企业在进行数据建模时，会遇到业务口径不一致的问题。例如，财务部门和供应链部门对“成本”这个指标的定义可能完全不同，导致分析结果出现偏差。通过数据标准，可以建立统一的模型定义模板，确保每个指标的口径一致。

2、数据研发规范在数据开发过程中，企业经常会遇到脚本不符合规范的情况，从而导致数据质量问题。某零售企业在引入数据标准后，通过事前阻断机制杜绝了不规范脚本上线，从源头上提升了数据质量。

3、数据质量规则数据标准可以用于数据质量的事前控制和事后治理。在数据采集环节，设置事前阻断规则，避免错误数据流入系统；在数据分析环节，进行事后稽核，清理不合规数据。

4、数据安全管理通过数据标准对数据进行分类分级管理，可以有效保护企业的数据资产。比如，对敏感数据进行特征识别和监控，设置不同的访问权限，确保数据安全。

四、数据标准如何发挥价值

“我们明明已经制定了很多数据标准，但是，最终数据治理项目还是失败了，实在搞不懂啊！”我相信这不是一个人的心声。

为什么有了数据标准，数据治理还是会失败呢？尽管数据标准非常重要，但很多企业在实际操作中仍然会“踩坑”。主要有以下几个原因：

1、一次性工程很多企业将数据标准的建设视为一次性工程，标准制定好之后就不再关注，没有动态更新和维护机制。随着业务的发展，标准逐渐失去了有效性。

2、乙方撤场后甲方运维困难数据治理项目结束后，外部顾问团队撤离，企业内部缺乏持续运维数据标准的人才，导致标准无法真正落地，成为一堆无用的标准。

3、标准落标率缺乏监控企业没有对标准的执行情况进行监控和考核，导致数据标准成为“纸面规则”，各部门执行不严格，久而久之就被遗忘了。

总结来说，就是标准没有随着业务的发展进行持续的运营迭代，逐渐无法跟上业务的节奏，最终被业务抛弃，企业又回到了没有数据标准的时代。

那么，如何让数据标准真正发挥作用呢？要想让数据标准真正落地，企业必须在以下几个方面下功夫：

1、建立数据标准委员会设立专门的团队，负责数据标准的制定、更新和维护工作，确保标准始终与业务需求保持一致。

2、培养内部数据治理人才减少对外部乙方的依赖，建立企业内部的数据治理能力，培养既懂业务又懂技术的复合型人才。

3、引入标准落标率监控机制在数据平台中设置标准落标率的监控功能，将各部门的标准执行情况量化，纳入绩效考核指标。

这些措施其实并不难实施，但很少有企业能够真正做到。国外企业已经很少讨论数据标准了，因为对于他们来说，制定数据标准是一项基础且必要的工作，已经成为一种共识，无需再进行讨论。

而我国很多企业仍处于数字化转型的初期，缺乏对数据要素的前期治理投入和重视，相关人才储备也不足，这就导致企业反复推进数据治理工作。说得好听点，这是在实战中学习；说得不好听点，就是……（这里实在难以用合适的词来表达，大家自行想象吧！）

五、小结

没有数据标准的治理，都是治标不治本。数据治理不是一次性的项目，而是一场漫长的马拉松，需要持续优化、动态维护数据标准。只有让数据标准融入企业的日常数据管理，成为其中的一部分，数据治理才能真正发挥出应有的价值。

看了我常用的数据库设计技巧，同事们都开始悄悄模仿……

阿布大人 — Fri, 21 Mar 2025 15:39:00 +0800

对于后端开发同学来说，访问数据库，是代码中必不可少的一个环节。

系统中收集到用户的核心数据，为了安全性，我们一般会存储到数据库，比如：mysql，oracle等。

后端开发的日常工作，需要不断的建库和建表，来满足业务需求。

通常情况下，建库的频率比建表要低很多，所以，我们这篇文章主要讨论建表相关的内容。

如果我们在建表的时候不注意细节，等后面系统上线之后，表的维护成本变得非常高，而且很容易踩坑。

今天就跟大家一起聊聊，数据库建表的15个小技巧，希望对你会有所帮助。

一、名字

建表的时候，给表、字段和索引起个好名字，真的太重要了。

1、见名知意

名字就像表、字段和索引的一张脸，可以给人留下第一印象。

好的名字，言简意赅，见名知意，让人心情愉悦，能够提高沟通和维护成本。

坏的名字，模拟两可，不知所云。而且显得杂乱无章，看得让人抓狂。

反例：

用户名称字段定义成：yong_hu_ming、用户_name、name、user_name_123456789

你看了可能会一脸懵逼，这是什么骚操作？

正例

用户名称字段定义成：user_name

温馨提醒一下，名字也不宜过长，尽量控制在30个字符以内。

2、大小写

名字尽量都用小写字母，因为从视觉上，小写字母更容易让人读懂。

反例：

字段名：PRODUCT_NAME、PRODUCT_name

全部大写，看起来有点不太直观。而一部分大写，一部分小写，让人看着更不爽。

正例：

字段名：product_name

名字还是使用全小写字母，看着更舒服。

3、分隔符

很多时候，名字为了让人好理解，有可能会包含多个单词。

那么，多个单词间的分隔符该用什么呢？

反例：

字段名：productname、productName、product name、product@name

单词间没有分隔，或者单词间用驼峰标识，或者单词间用空格分隔，或者单词间用@分隔，这几种方式都不太建议。

正例：

字段名：product_name

强烈建议大家在单词间用_分隔。

4、表名

对于表名，在言简意赅，见名知意的基础之上，建议带上业务前缀。

如果是订单相关的业务表，可以在表名前面加个前缀：order_。

例如：order_pay、order_pay_detail等。

如果是商品相关的业务表，可以在表名前面加个前缀：product_。

例如：product_spu，product_sku等。

这样做的好处是为了方便归类，把相同业务的表，可以非常快速的聚集到一起。

另外，还有有个好处是，如果哪天有非订单的业务，比如：金融业务，也需要建一个名字叫做pay的表，可以取名：finance_pay，就能非常轻松的区分。

这样就不会出现同名表的情况。

5、字段名称

字段名称是开发人员发挥空间最大，但也最容易发生混乱的地方。

比如有些表，使用flag表示状态，另外的表用status表示状态。

可以统一一下，使用status表示状态。

如果一个表使用了另一个表的主键，可以在另一张表的名后面，加_id或_sys_no，例如：

在product_sku表中有个字段，是product_spu表的主键，这时候可以取名：product_spu_id或product_spu_sys_no。

还有创建时间，可以统一成：create_time，修改时间统一成：update_time。

删除状态固定为：delete_status。

其实还有很多公共字段，在不同的表之间，可以使用全局统一的命名规则，定义成相同的名称，以便于大家好理解。

6、索引名

在数据库中，索引有很多种，包括：主键、普通索引、唯一索引、联合索引等。

每张表的主键只有一个，一般使用：id或者sys_no命名。

普通索引和联合索引，其实是一类。在建立该类索引时，可以加ix_前缀，比如：ix_product_status。

唯一索引，可以加ux_前缀，比如：ux_product_code。

二、字段类型

在设计表时，我们在选择字段类型时，可发挥空间很大。

时间格式的数据有：date、datetime和timestamp等等可以选择。

字符类型的数据有：varchar、char、text等可以选择。

数字类型的数据有：int、bigint、smallint、tinyint等可以选择。

说实话，选择很多，有时候是一件好事，也可能是一件坏事。

如何选择一个合适的字段类型，变成了我们不得不面对的问题。

如果字段类型选大了，比如：原本只有1-10之间的10个数字，结果选了bigint，它占8个字节。

其实，1-10之间的10个数字，每个数字1个字节就能保存，选择tinyint更为合适。

这样会白白浪费7个字节的空间。

如果字段类型择小了，比如：一个18位的id字段，选择了int类型，最终数据会保存失败。

所以选择一个合适的字段类型，还是非常重要的一件事情。

以下原则可以参考一下：

尽可能选择占用存储空间小的字段类型，在满足正常业务需求的情况下，从小到大，往上选。
如果字符串长度固定，或者差别不大，可以选择char类型。如果字符串长度差别较大，可以选择varchar类型。
是否字段，可以选择bit类型。
枚举字段，可以选择tinyint类型。
主键字段，可以选择bigint类型。
金额字段，可以选择decimal类型。
时间字段，可以选择timestamp或datetime类型。

三、字段长度

前面我们已经定义好了字段名称，选择了合适的字段类型，接下来，需要重点关注的是字段长度了。

比如：varchar(20)，biginit(20)等。

那么问题来了，varchar代表的是字节长度，还是字符长度呢？

答：在mysql中除了varchar和char是代表字符长度之外，其余的类型都是代表字节长度。

biginit(n) 这个n表示什么意思呢？

假如我们定义的字段类型和长度是：bigint(4)，bigint实际长度是8个字节。

现在有个数据a=1，a显示4个字节，所以在不满4个字节时前面填充0（前提是该字段设置了zerofill属性），比如：0001。

当满了4个字节时，比如现在数据是a=123456，它会按照实际的长度显示，比如：123456。

但需要注意的是，有些mysql客户端即使满了4个字节，也可能只显示4个字节的内容，比如会显示成：1234。

所以bigint(4)，这里的4表示显示的长度为4个字节，实际长度还是占8个字节。

四、字段个数

我们在建表的时候，一定要对字段个数做一些限制。

我之前见过有人创建的表，有几十个，甚至上百个字段，表中保存的数据非常大，查询效率很低。

如果真有这种情况，可以将一张大表拆成多张小表，这几张表的主键相同。

建议每表的字段个数，不要超过20个。

五、主键

在创建表时，一定要创建主键。

因为主键自带了主键索引，相比于其他索引，主键索引的查询效率最高，因为它不需要回表。

此外，主键还是天然的唯一索引，可以根据它来判重。

在单个数据库中，主键可以通过AUTO_INCREMENT，设置成自动增长的。

但在分布式数据库中，特别是做了分库分表的业务库中，主键最好由外部算法(比如：雪花算法）生成，它能够保证生成的id是全局唯一的。

除此之外，主键建议保存跟业务无关的值，减少业务耦合性，方便今后的扩展。

不过我也见过，有些一对一的表关系，比如：用户表和用户扩展表，在保存数据时是一对一的关系。

这样，用户扩展表的主键，可以直接保存用户表的主键。

六、存储引擎

在mysql5.1以前的版本，默认的存储引擎是myslam，而mysql5.1以后的版本，默认的存储引擎变成了innodb。

之前我们还在创建表时，还一直纠结要选哪种存储引擎？

myslam的索引和数据分开存储，而有利于查询，但它不支持事务和外键等功能。

而innodb虽说查询性能，稍微弱一点，但它支持事务和外键等，功能更强大一些。

以前的建议是：读多写少的表，用myslam存储引擎。而写多读多的表，用innodb。

但虽说mysql对innodb存储引擎性能的不断优化，现在myslam和innodb查询性能相差已经越来越小。

所以，建议我们在使用mysql8以后的版本时，直接使用默认的innodb存储引擎即可，无需额外修改存储引擎。

七、NOT NULL

在创建字段时，需要选择该字段是否允许为NULL。

我们在定义字段时，应该尽可能明确该字段NOT NULL。

为什么呢？

我们主要以innodb存储引擎为例，myslam存储引擎没啥好说的。

主要有以下原因：

在innodb中，需要额外的空间存储null值，需要占用更多的空间。
null值可能会导致索引失效。
null值只能用is null或者is not null判断，用=号判断永远返回false。

因此，建议我们在定义字段时，能定义成NOT NULL，就定义成NOT NULL。

但如果某个字段直接定义成NOT NULL，万一有些地方忘了给该字段写值，就会insert不了数据。

这也算合理的情况。

但有一种情况是，系统有新功能上线，新增了字段。上线时一般会先执行sql脚本，再部署代码。

由于老代码中，不会给新字段赋值，则insert数据时，也会报错。

由此，非常有必要给NOT NULL的字段设置默认值，特别是后面新增的字段。

例如：

alter table product_sku add column  brand_id int(10) not null default 0;

八、外键

在mysql中，是存在外键的。

外键存在的主要作用是：保证数据的一致性和完整性。

例如：

create table class (  id int(10) primary key auto_increment,  cname varchar(15));

有个班级表class。

然后有个student表：

create table student(  
      id int(10) primary key auto_increment, 
      name varchar(15) not null,  
      gender varchar(10) not null,  
      cid int,  
      foreign key(cid) references class(id)
);

其中student表中的cid字段，保存的class表的id，这时通过foreign key增加了一个外键。

这时，如果你直接通过student表的id删除数据，会报异常：

a foreign key constraint fails

必须要先删除class表对于的cid那条数据，再删除student表的数据才行，这样能够保证数据的一致性和完整性。

顺便说一句：只有存储引擎是innodb时，才能使用外键。

如果只有两张表的关联还好，但如果有十几张表都建了外键关联，每删除一次主表，都需要同步删除十几张子表，很显然性能会非常差。

因此，互联网系统中，一般建议不使用外键。因为这类系统更多的是为了性能考虑，宁可牺牲一点数据一致性和完整性。

除了外键之外，存储过程和触发器也不太建议使用，他们都会影响性能。

九、索引

在建表时，除了指定主键索引之外，还需要创建一些普通索引。

例如：

create table product_sku(  
     id int(10) primary key auto_increment,
    spu_id int(10) not null,
    brand_id int(10) not null,
   name varchar(15) not null
);

在创建商品表时，使用spu_id（商品组表）和brand_id（品牌表）的id。

像这类保存其他表id的情况，可以增加普通索引：

create table product_sku (
  id int(10) primary key auto_increment,
  spu_id int(10) not null,
  brand_id int(10) not null,
  name varchar(15) not null,
  KEY `ix_spu_id` (`spu_id`) USING BTREE,
  KEY `ix_brand_id` (`brand_id`) USING BTREE
);

后面查表的时候，效率更高。

但索引字段也不能建的太多，可能会影响保存数据的效率，因为索引需要额外的存储空间。

建议单表的索引个数不要超过：5个。

如果在建表时，发现索引个数超过5个了，可以删除部分普通索引，改成联合索引。

顺便说一句：在创建联合索引的时候，需要使用注意最左匹配原则，不然，建的联合索引效率可能不高。

对于数据重复率非常高的字段，比如：状态，不建议单独创建普通索引。因为即使加了索引，如果mysql发现全表扫描效率更高，可能会导致索引失效。

十、时间字段

时间字段的类型，我们可以选择的范围还是比较多的，目前mysql支持：date、datetime、timestamp、varchar等。

varchar类型可能是为了跟接口保持一致，接口中的时间类型是String。

但如果哪天我们要通过时间范围查询数据，效率会非常低，因为这种情况没法走索引。

date类型主要是为了保存日期，比如：2020-08-20，不适合保存日期和时间，比如：2020-08-20 12:12:20。

而datetime和timestamp类型更适合我们保存日期和时间。

但它们有略微区别。

timestamp：用4个字节来保存数据，它的取值范围为1970-01-01 00:00:01 UTC ~ 2038-01-19 03:14:07。此外，它还跟时区有关。
datetime：用8个字节来保存数据，它的取值范围为1000-01-01 00:00:00 ~ 9999-12-31 23:59:59。它跟时区无关。

优先推荐使用datetime类型保存日期和时间，可以保存的时间范围更大一些。

温馨提醒一下，在给时间字段设置默认值是，建议不要设置成：0000-00-00 00:00:00，不然查询表时可能会因为转换不了，而直接报错。

十一、金额字段

mysql中有多个字段可以表示浮点数：float、double、decimal等。

而float和double可能会丢失精度，因此推荐大家使用decimal类型保存金额。

一般我们是这样定义浮点数的：decimal(m,n)。

其中n是指小数的长度，而m是指整数加小数的总长度。

假如我们定义的金额类型是这样的：decimal(10,2)，则表示整数长度是8位，并且保留2位小数。

十二、唯一索引

唯一索引在我们实际工作中，使用频率相当高。

你可以给单个字段，加唯一索引，比如：组织机构code。

也可以给多个字段，加一个联合的唯一索引，比如：分类编号、单位、规格等。

单个的唯一索引还好，但如果是联合的唯一索引，字段值出现null时，则唯一性约束可能会失效。

创建唯一索引时，相关字段一定不能包含null值，否则唯一性会失效。

十三、字符集

mysql中支持的字符集有很多，常用的有：latin1、utf-8、utf8mb4、GBK等。

这4种字符集情况如下：

latin1容易出现乱码问题，在实际项目中使用比较少。

而GBK支持中文，但不支持国际通用字符，在实际项目中使用也不多。

从目前来看，mysql的字符集使用最多的还是：utf-8和utf8mb4。

其中utf-8占用3个字节，比utf8mb4的4个字节，占用更小的存储空间。

但utf-8有个问题：即无法存储emoji表情，因为emoji表情一般需要4个字节。

由此，使用utf-8字符集，保存emoji表情时，数据库会直接报错。

所以，建议在建表时字符集设置成：utf8mb4，会省去很多不必要的麻烦。

十四、排序规则

不知道，你关注过没，在mysql中创建表时，有个COLLATE参数可以设置。

例如：

CREATE TABLE `order` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `code` varchar(20) COLLATE utf8mb4_bin NOT NULL,
  `name` varchar(30) COLLATE utf8mb4_bin NOT NULL,
  PRIMARY KEY (`id`),  UNIQUE KEY `un_code` (`code`),
  KEY `un_code_name` (`code`,`name`) USING BTREE,
  KEY `idx_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

它是用来设置排序规则的。

字符排序规则跟字符集有关，比如：字符集如果是utf8mb4，则字符排序规则也是以：utf8mb4_开头的，常用的有：utf8mb4_general_ci、utf8mb4_bin等。

其中utf8mb4_general_ci排序规则，对字母的大小写不敏感。说得更直白一点，就是不区分大小写。

而utf8mb4_bin排序规则，对字符大小写敏感，也就是区分大小写。

说实话，这一点还是非常重要的。

假如order表中现在有一条记录，name的值是大写的YOYO，但我们用小写的yoyo去查，例如：

select * from order where name='yoyo';

如果字符排序规则是utf8mb4_general_ci，则可以查出大写的YOYO的那条数据。

如果字符排序规则是utf8mb4_bin，则查不出来。

由此，字符排序规则一定要根据实际的业务场景选择，否则容易出现问题。

十五、大字段

我们在创建表时，对一些特殊字段，要额外关注，比如：大字段，即占用较多存储空间的字段。

比如：用户的评论，这就属于一个大字段，但这个字段可长可短。

但一般会对评论的总长度做限制，比如：最多允许输入500个字符。

如果直接定义成text类型，可能会浪费存储空间，所以建议将这类字段定义成varchar类型的存储效率更高。

当然，我还见过更大的字段，即该字段直接保存合同数据。

一个合同可能会占几Mb。

在mysql中保存这种数据，从系统设计的角度来说，本身就不太合理。

像合同这种非常大的数据，可以保存到mongodb中，然后在mysql的业务表中，保存mongodb表的id。

作者丨苏三呀

第一次把 https 原理讲得那么清楚

阿布大人 — Fri, 21 Mar 2025 15:23:00 +0800

有位朋友校招面试了字节的后端岗位，问到这道面试题：https 原理。

这道题其实比较简单，我们如何更好地回答呢？我来跟大家聊聊。可以从这几个维度逐层扩展来讲

http为什么不安全？
对称算法加密+HTTP
非对称加密+HTTP
非对称加密+对称加密+HTTP
数字签名，给你的公钥盖个章
完整的HTTPS运行流程图

一、http为什么不安全？

我们先来看看HTTP传输：

客户端，把一条消息，以明文的方式，发送到服务器。
服务的响应报文，也是以明文的方式，发回给客户端。

Http 明文传输，主要有这些缺点：窃听风险、篡改风险、冒充风险

请君试想，如果HTTP请求被某个不怀好意的中间人窃听截取，并且，消息包含银行密码等敏感信息的话，造成的后果不堪设想吧。

二、对称算法加密+HTTP

既然，明文传输不安全，那我们加密是不是就可以了。比如用对称加密算法加密。

对称加密算法：需要对加密和解密使用相同密钥的加密算法。由于其速度快，对称性加密通常在消息发送方需要加密大量数据时使用。对称性加密也称为密钥加密。

常见的对称加密算法有：DES、3DES、AES

看看用对称算法加密后，HTTP流程又是怎样的：

客户端把要发送的消息，用密钥加密成密文。
客户端把密文发送到服务器。
服务器收到密文消息，用同一把密钥把密文解密成明文。
同理，服务端把消息报文返回给客户端，处理过程类似。

这种方式还是有问题：

一开始客户端怎么把密钥发过去呢？如果不怀好意的中间人截取到了密钥，发送的消息还是会被盗取和利用呢。

三、非对称加密+HTTP

既然对称算法加密+HTTP 还是不够安全，那我们用非对称加密+HTTP。

什么是非对称加密算法？

非对称加密算法需要两个密钥：公开密钥和私有密钥。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

常用非对称加密算法：RSA、ECC

使用非对称加密算法之后，HTTP流程又是怎样的，如下图：

客户端向服务器发起HTTP请求
服务端将自己的公钥返回到客户端。
客户端使用返回的公钥，给要发送的消息加密。
客户端将加密之后的消息密文发送给服务器。
服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后得到消息数据。

这种方式依然有问题:

非对称算法（如：RSA）有个弊端，它很慢。试想一下，如果你用浏览器请求，它很久才响应，你能接受吗？

四、非对称加密+对称加密+HTTP

既然非对称加密慢。对称加密会快好多。我们可以使用非对称加密+对称加密双剑合璧的流程图如下：

客户端向服务器发起HTTP请求
服务端将自己的公钥返回到客户端。
客户端产生对称加密密钥，并用服务端返回的公钥对它加密
客户端会发起第二个HTTP请求，将加密之后的客户端密钥发送给服务器。
服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后得到客户端密钥，然后用客户端密钥对返回数据进行对称加密，这样数据就变成了密文。
服务器将加密后的密文返回给客户端。
客户端收到服务器发返回的密文，用自己的密钥（客户端密钥）对其进行对称解密，得到服务器返回的数据。

这种方式还是有问题，没完没了了……

如果中间人又来搞事情呢？要是中间人截取公钥，把公钥进行篡改呢? 打个比喻，把公钥比喻你自己的手机号，它是公开的，谁都可以给你打电话。假设你发消息给你朋友，告诉他你的手机号，然后消息被中间人截取修改了，改为110，然后你朋友不知情的情况下，拨通110，打电话给你……

五、数字签名，给你的公钥盖个章

为了避免公钥被篡改，引入了数字证书，如图所下：

公钥和个人信息，经过Hash算法加密，形成消息摘要；将消息摘要拿到拥有公信力的认证中心（CA），用它的私钥对消息摘要加密，形成数字签名.

公钥和个人信息、数字签名共同构成数字证书。

证书验证

拿到数字证书之后，用同样的Hash算法，先再次生成消息摘要；
然后用CA的公钥对数字签名解密，得到CA创建的消息摘要，两者对比，就知道有没有人篡改了。

六、完整的HTTPS运行流程图

用户在浏览器里输入一个https网址，然后连接到server的443端口。
服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过。这套证书其实就是一对公钥和私钥。
服务器将自己的数字证书（含有公钥）发送给客户端。
客户端收到服务器端的数字证书之后，会对其进行检查，如果不通过，则弹出警告框。如果证书没问题，则生成一个密钥（对称加密），用证书的公钥对它加密。
客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。
服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后得到客户端密钥，然后用客户端密钥对返回数据进行对称加密，这样数据就变成了密文。
服务器将加密后的密文返回给客户端。
客户端收到服务器发返回的密文，用自己的密钥（客户端密钥）对其进行对称解密，得到服务器返回的数据。

作者丨捡田螺的小男孩

来源丨公众号：捡田螺的小男孩（ID：gh_3d11c9893ca0）

ai 已经能编出很完美的程序，程序员这个行业以后是不是会消失？

阿布大人 — Thu, 13 Mar 2025 10:46:00 +0800

Caption1 用结果说话

ai已经能编出很完美的程序了。

那世面上一定有很多纯ai开发的App了吧？

你一定ai做了很多成功大项目赚了不少钱吧？

你一定做出了自己想要的软件了，不用再买激活码之类的智商税了吧？

你毕设一定一天就搞完，从软件到论文分分钟搞定，不用在网上哭爹喊娘求代做了吧？

你CS课后大作业一定科科满分，学分绩点那到手软了吧？

对吧？是这样吧？我没理解错吧？

Caption2 从哲学角度看

这是来自于非行业人的想象，看着一会就根据你的描述生成一串眼花缭乱的代码，让你觉得比人厉害多了，实际上你如果做过项目，并用过ai，就会明白，目前ai仍是辅助工具，只是越来越强，都在调侃程序员是cv工程师，能cv完成任务说明解决了三个问题，从哪找，在哪改，往哪贴。

ai目前让“从哪找”和“在哪改”这两个问题变的更简单，“往哪贴”还没解决。不用担心程序员会消失，如果ai能代替多数程序员的工作，那在这之前多数办公室工作已经被替代了。

Caption3 引经据典

James Martin 在 1982 年出了一本书，叫《Application Development without Programmers》（没有程序员的应用程序开发）。

这个 James Martin 是英国信息技术顾问和作家，以其在信息技术工程方面的工作而闻名。

这本书中正式提到了一个术语：A fourth-generation programming language(4GL)，第四代编程语言，也被称为 “非过程式” 或 “程序生成式” 语言，

4GL 的目的在于提供更高级别的抽象，以便让编程语言对程序员更加友好、功能更加强大、用途更加广泛 ------ 说人话，就是少写（最好不用写）代码也能把活儿给干了......

嗯，听起来是不是很耳熟？

那么实现了吗？

一定程度上实现了！

比如出了一种叫 “表驱动”（table-driven）的编程，开发人员不使用代码，而是通过在预定义的内存或 “数据表操作命令列表” 中选择操作来定义程序逻辑。

更著名的大概是 SQL（结构化查询语言），虽然老师们仍会建议你认真学习 “复杂且隐晦” 的数据库及计算机专业知识，但你也可以完全不学...... 然后在不懂 bits 和 bytes 的前提下，尽情的使用 DBMS（数据库管理系统）瞎 JB 操作一通......

然后就是最！最！最！最！著名的 “低代码”（low-code）和 “无代码”（no-code）......

至于 C#、Java、JavaScript、Python 这些 3GL，当它们结合了一些具备 4GL 特性的库时，如果不深究的话，大约也可以被称为 4GL，至少是 3GL + 4GL 的混合模式。

既然如此，从时间上推算，4GL 已经出来四十多年了......

实际上远不止四十多年，在上世纪 60 年代已经有 Mark IV 了，它可以自动读取输入文件并转换其中的数据，这个 “报告生成器” 其实也是 4GP，只不过当时还没这个概念罢了。

那么程序员这个 “行业” 消失了吗？

哼哼~

时间嘀嗒嘀嗒嘀，GenAI 又来了！

两年前我在技术论坛上看过这么一篇论文，标题叫《Large Language Models: Compilers for the 4th Generation of Programming Languages》，作者探讨了大语言模型（LLMs）作为 4GP 编译器的可能性。

大概意思是说，像 ChatGPT 这样的 LLMs 可以被视为一种 “编译器”，可以将人类的提示 “翻译” 成 Python、Java 这种第三代编程语言。

这些 “提示” 并不完全是人类自然语言，而是一种特定的写作形式，旨在从 LLM 中获取所需的输出。

于是，整个这套模式和流程就成了所谓的 “第四代编程语言”，而 LLM 就是其中的编译器。

......

我不是相关从业者，所以论文中的很多专属名词和理论我都看不懂，但我瞅见了一个 “华点”

------ 折腾半天，“输出” 的不还是 3GP 嘛，一堆编程语言代码！

那这一大堆代码是给谁看的？

程序员！

......

对了，我还没提 “他们以为软件开发的唯一难点是写代码” 这个事儿呢！

这个事儿又能写一大篇......

Caption4 秒杀

说个残忍的事实，没有代码基础的人即使使用AI也写不出完整的代码；

The end!!

AI 正在培养一代 “文盲程序员”

阿布大人 — Tue, 18 Feb 2025 08:56:00 +0800

最近一段时间，国外技术社区有一个关注度很高的话题。它由一篇文章引发了大量的讨论，事情的起因是2025年1月底 ChatGPT 宕机，作者有感而发写下了下面这篇文章：https://nmn.gl/blog/ai-illiterate-programmers

几天前，由于ChatGPT宕机，Cursor 也无法使用了。

我盯着终端，面对那些我讨厌看到的红色错误信息。一个 AWS 错误信息直勾勾地回瞪着我。我不想在没有 AI 帮助的情况下解决它。

经过 12 年的编程，我发现自己变得越来越不擅长自己的工作了。这不是夸大其词，而是当代软件开发者正在面临的新现实。

技能的退化

这种退化是不知不觉中发生的。

首先，我不再阅读文档了。既然 AI 可以即时解释问题，那又何必多此一举呢？

接着，我的调试能力也开始退化。没有AI的帮助，堆栈跟踪信息现在看起来难以理解。我甚至连错误信息都懒得细看，只会复制粘贴到 AI 那里。

然后，我就变成了一个“人形剪贴板”，充当着我的代码与大语言模型（LLM）之间的中转站。

以前，每一条错误信息都能给我一些启发。现在呢？解决方案神奇地出现了，我却什么也没学到。即时答案带来的多巴胺快感取代了对问题真正理解带来的成就感。

接踵而至的是 “深入理解” 的能力也出现了问题。还记得以前花几个小时去理解一个解决方案为什么有效吗？现在，我只是简单地实现 AI 的建议。如果它们不起作用，我就改进上下文，然后再次询问 AI。如此循环，依赖越来越深。

再就是情感上的变化。以前，解决新问题是编程乐趣的一部分。现在，如果 AI 在5分钟内没有给出解决方案，我就会感到沮丧。

最可怕的是，我正在构建一个由 AI 驱动的开发工具，但我无法摆脱一种感觉：我在亲手助长这一问题，让我们的集体技能不断被退化。

“戒瘾”计划

我并不是建议做出什么激进的决定，比如完全不使用 AI - 这是不现实的。相反，我决定先尝试一周一天的“无 AI 日”，要求自己在这一天里：

完整阅读每一条错误信息
重新使用真正的调试工具
从零开始编写代码
阅读源代码，而不是询问AI

不瞒你说，这样做并不好受。相比借助 AI，我感觉这样更慢、更笨、更令人沮丧。

但我也能感受到一些微妙的变化：我对自己编写的代码更有把控，也重新找回了那种久违的自主感，而这些却在使用 AI 的过程中一点点地消失。而且，我学到的东西也更多了。

令人不安的真相

我们并不是在借助 AI 成为 10 倍的开发者。

我们在变成了 10 倍依赖 AI 的人。这是有本质区别的。

每当我们让 AI 解决一个我们本可以自行解决的问题时，我们是在用长期的理解力换取短期的生产力；是在追求今天能写出多少行代码，却牺牲了未来真正解决问题的能力。

我并不是建议我们放弃 AI 工具——这已经不可能了。但我们需要一套使用规则。以下是我的一些想法：

对于你尚未尝试去理解的问题，不要使用 AI
阅读并理解所有AI建议的解决方案
定期进行无 AI 辅助的编程
专注于学习模式，而不仅仅是解决眼前的问题

坦率地讲，我自己也无法做到一直遵守这些规则。但这只是一个开始，我坚信任何刚接触编程的人都应该严格遵守这些规则。

此时此刻，在某个地方，一位新手程序员正在学习编程。他们永远不会体会到真正独立解决问题的成就感。他们永远不会体验到与 bug 奋斗几个小时后所获得的深刻理解。

我们正在造就一代可以向 AI 提出正确问题却无法理解答案的开发人员。每次AI宕机时，他们都会暴露出越来越无助的一面。目前，AI 的能力还不足以完全取代程序员，但随着它的进步，这种情况只会变得更糟。真正的问题不是人工智能是否会取代程序员。而是我们是否正在取代自己。

试着在没有 AI 的情况下编码一天。结果可能会让你大吃一惊

- EOF -

我们为什么要放弃永生

admin — Wed, 05 Feb 2025 10:38:00 +0800

本文由小号特约作者独家原创发布

zhuanlan.zhihu.com/p/22879351

本文是系列文章《天启四骑士》的最后一篇，在之前的系列文章中，瘟疫骑士在中世纪的欧洲降临，灾荒骑士在光绪年间的山西降临，屠杀骑士在94年的卢旺达降临。

在这篇文章里，最后一位天启骑士“死亡骑士”也终于降临了，由于是完结篇，所以本文较长，阅读全文大概需要15分钟。

每年有一天是你忌日

人们对死亡通常会有一种误解，认为死亡从生命诞生的那一刻起就如影随形，有生就有死，这一切看起来天经地义理所当然。其实严格来说，真正意义上不可避免的死亡是生命演化出来的，死亡归根结底是笔交易。

很不幸，人类的历史中充斥着浩劫，我们倒霉的祖先在各种天灾人祸的打击下苟且偷生。

即使有些人特别幸运，没有死于瘟疫，没有死于灾荒，没有死于屠杀，也很幸运地没有死于诸如落水，中毒，雷击，坠崖等等意外事故，可人们最终还是会死的，衰老会逐渐地侵蚀人们的肉体，直到死亡最终降临。

其实我们仔细想想，我们每年都会过一次自己的忌日，只不过在死之前我们不知道是几月几日而已。

长寿一些的生物比如巨龟能活到300岁（从康熙五十五年一直活到今天），但是死亡还是会在生命的尽头等待着它。

加利福尼亚巨杉最高可超过100米，寿命可能超过3000岁，时间跨度几乎相当于从牧野之战到北京奥运会开幕，可是最终死亡还是会不可抗拒地降临。

这给人一种感觉，那就是死亡是不可避免的，是一切生命不可逃避的终结。

然而，事实并非如此

今天这个世界上，有一种小生命名叫阿米巴虫，是一种单细胞原生生物，人们可以通过显微镜观察到它。

这种小生命的细胞质和细胞器被包裹在细胞膜中，没有固定的形状，结构非常简单，但是它却能做到一件让古今无数帝王将相都梦寐以求的事，那就是永生不朽。

阿米巴虫之所以能够做到这点，是由它的生殖方式决定的，阿米巴虫可以由一个个体分裂成两个完全相同的个体来实现繁殖，对于这种无性生殖的生物来说，“死亡”两字有着完全不同的意义。

因为只要这些小家伙足够幸运，躲开各种致命的意外，理论上它们可以将自己的生命永远地延续下去，当它们的身体到达临界尺寸时，它们就一分为二，然后再等着二分为四，四分为八……

对于阿米巴虫来说，并没有衰老的概念，更没有不可避免的死亡。

只要环境允许，它们就能一直这么繁育下去，直到天荒地老海枯石烂*，而这个由它们引出的有关性和永生的故事，需要我们从很久很久以前开始讲起。

且让我们翻回生命之书的第一页，那是一片距今38亿年前的浩瀚汪洋。

在最初数十亿年的时间里，地球还是单细胞生物的家园，彼时的大自然倾向于准确地复制所有存在的生命形式，因为那时地球上还没有性的概念，那些水中微小的，只能用显微镜看到的生物都是中性的，靠着阿米巴虫一样的无性生殖延续着自己永恒的生命*。

也许是造物主对千篇一律的复制感到了厌倦，更有可能是大自然那不可捉摸的意志做出了选择，大约在距今12亿年前的某一天，地球上的第一次有性生殖出现了。

有性生殖

有性生殖是如何开始？

这一直是一个困扰了科学家们很久的谜题。

学者们提出了各种理论来解释“性”的开始，但是仍然没有一种理论可以说服所有学者，因为无论怎样，有性生殖的代价看起来实在是太大了，因为当“性”出现在这个世界上之后，不可避免的死亡也就出现了（生命只交出配子，而自身会衰朽死亡），对于一些生物来说，不仅自己的基因只能传承一半（雌雄各贡献一半的基因），原来的那种靠无性分裂维系永生的好日子也一去不复返了。

可是学者们发现，几乎所有的真核生物都会在生命周期的某一时刻“纵情声色”一把，而绝大部分动植物都是有性生殖的。

为什么有性生殖的代价如此巨大，可是生命却宁可放弃永生也要前仆后继地选择性？

因为性带来的好处更大。

美国遗传学家赫尔曼·穆勒（Hermann Muller）因为发现X射线能诱使基因突变而获得了1946年诺贝尔生理或医学奖。

他本人也亲自在果蝇中诱发了成千上万次突变，他发现，对于一个物种来说，绝大多数的突变都是负面的，有益的突变只占很小很小的比例，而如何处理这些突变则成为了一个很棘手的问题。

对于无性生殖的生物来说，一旦基因里出现了一个有害突变，这个有害突变就会被原封不动地复制下去，除非发生一次超级幸运的回复突变（概率极低），否则这个有害突变就会像冤鬼一样纠缠在基因里，怎么甩都甩不掉。

而有益突变也没有得到很好的发挥，因为它的扩散受到了无性生殖的限制，举个例子，要想把A和B两种有益突变都收集到一套基因里，无性生殖的个体不得不进行两次突变，先发生A突变，然后复制扩散，然后再在A突变的基础之上发生B突变。

可是有益突变的概率太低了，完全是可遇不可求的事，这无异于连续两次中彩票大奖。

再加上突变之间还存在着此消彼长的竞争关系，一个有益突变很可能会因为扩散不过另外一个有益突变而被怼死，这就更糟了。

（有益突变使得a变成A，b变成B，但是有益突变的扩散却受到无性生殖的限制，同时有益突变之间也存在着此消彼长的竞争关系）

在这种情况下，就轮到有性生殖大显身手了。

因为有性生殖不是单纯地复制父辈的基因，而是不同的基因之间进行交流融合，这使得有益突变和那些没有受到有害突变侵扰的基因得以迅速地富集在一起，这效率比无性生殖不知道高到哪里去了。

性也可以用同样的逻辑把有害突变富集起来，然后把承载着有害突变的个体交给环境去毁灭，实现对基因的净化。

虽然性只能传承父辈基因的一半，但是子辈的适应度却高出不止一倍，对于生命来说，“性”可以说是个稳赚不赔的买卖。

这一切就好像一个汽车修理工处理两辆二手车，工人把两辆二手车上运转良好的零件组装在一起形成好车，运转不良的零件组装在一起形成烂车，好车继续上路，烂车则拖去销毁。

正是有性生殖可以快速地积累起增强物种适应性的创新，才使得生命开始了复杂化的进程，生命也同时开始面对不可避免的，真正意义上的死亡。

（有益突变使得a变成A，b变成B，并且在有性生殖的帮助下迅速富集）

04 性

“性”就好像是在生命的原野上立起一栋砖墙，这栋砖墙一直延伸到地平线的远方，将整个生命界一分为二。

砖墙的一侧是沉默而孤寂的世界，一个个面无表情的自我复制者维系着自己不朽的生命，而砖墙的另一侧则是色彩缤纷，花香鸟语的美好乐园，各种动植物在性的狂欢中享受着速朽的青春，同时也面对着不可避免的死亡。

可恶的是，那栋砖墙不高，好些物种从墙的一侧翻到另一侧，然后再从另一侧翻回来。

更有的物种干脆一屁股骑在了墙上。

鞭毛虫类里的一些小家伙就搞出了一种excited的生殖方式，被有的学者称为“无性的性行为”，它们就好像是有性与无性之间的骑墙派。

这些小家伙身体呈梨子状，在水中通过类似于毛发的鞭毛振动来移动自己，它们通常以自我分裂的方式进行繁殖。

然而有的时候，这些小家伙会用它身体较尖的一端戳进另一个同类身体较圆的一端（就好像用自己的“尖脑袋”去戳别人的“圆屁股”），并且藏身其中，这样一来两个小家伙就合二为一了，融合成一个新的个体。

这个新的个体融合了双方各自的成分，之后不久又会开始自我分裂。尽管这些小家伙没有清晰的性别，但是它们已经开始出现雌雄分化的苗头。

科学家通过显微镜发现，它们的“圆屁股”上有一个深色的圆圈，那是一种供伙伴瞄准用的“靶子”。

有靶子的个体通常会表现出雌性的倾向，没有靶子的则更倾向于雄性。

可是，有时候一些小个子雄性也会戳进大个子雄性的身体里，大小悬殊的雌性之间也会出现类似的“误会”，不过科学家并没有观察到小雌性戳大雄性的事情（截至文献完成之时）。

由此可以推测，并不是双方都可以自由转换“性别”角色的。

除了骑墙派以外，还有一些物种在有性和无性的砖墙上翻来翻去，一会有性生殖一会又无性生殖，水螅就是“翻墙党”之一。

一般情况下，水螅是通过“芽生”的方式繁殖后代的，它们的身体上会长出一个芽状的突起，而这个突起会逐渐地变成一个水螅宝宝，最终脱离母体。

除此之外，水螅如果被斩断一只触手，那么原来触手所在的位置就会长出几只新的触手，而被斩下来的触手则会再长成一只完整的水螅。

如果我们将一只水螅粉碎成100段，那么就会有100段水螅再生出来，水螅也因此被赋予了一个希腊神话中怪物的名字Hydra：

一种被斩了头却可以再生新头的九头蛇怪。

让人惊奇的是，当一片水域里的水螅繁殖过多时，水螅呼吸出的二氧化碳就会刺激水螅生成一种性刺激素，水螅也会因此临时出现性别，雄性和雌性会将精子和卵子排入水中，是否形成受精卵就要看机遇了，水螅也正是通过临时转变成有性生殖的方式来控制群体数量的。

蚜虫也是“骑墙派”的代表之一，在气候温暖之际，雌性蚜虫会通过一种名叫“孤雌生殖”的方式直接产出小蚜虫。

因为基因全部来自母亲，所以这些小蚜虫也全部都是雌性，在基因上和它们的母亲一模一样。

等到天气转凉时，雌蚜虫就会开始调整自己后代的性染色体，生出一些雄性后代，而这些雄蚜虫会找雌蚜虫们（它们的“母亲”和“姐妹”）交配使其生下虫卵，因为只有虫卵可以熬过寒冷的冬天，等到第二年气温转暖以后再孵化出雌蚜虫，让种群重新繁盛起来。

在温暖的地方，雌蚜虫甚至会保持全年的无性生殖，因此雄蚜虫就根本没有存在的必要。

没有雄性就自己生出雄性再与之交配的繁殖手段并不是蚜虫的专利，有的竹节虫类和蛾类会在雄性短缺的情况下自己动手，用孤雌生殖的方式给自己生出一大堆雄性再与之交配，相当于自己给自己生“丈夫”。

这种在有性和无性之间切换的生殖方式被动物学家们称为“异质生殖交替”。

有的读者都到这的时候可能会想一个人静一静，认为无性生殖圈似乎太乱了点，还是我们人类这样的有性生殖规矩一些。

雌雄难辨

事实上，大自然就好像是一个巨大的生殖实验室，不同的物种在自然界中演化出了各种各样的生殖策略，这些物种根本不care人类那套自以为是的道德准则，在有性生殖的领域里，它们会做出一些在人类看来更加疯狂的事情。

在美国佛罗里达群岛中，有一个小小的珊瑚岛，名叫鳄鱼礁（Alligator Reef），那是一个由棕榈树，沙滩，阳光和海浪构成的美妙天堂。

在礁石之间游弋着一种五彩斑斓的小鱼，名叫佛罗里达鮨（Serranus subligarius，亦称“带鮨” dài yì）。

这一天，一只雄性带鮨正在一条雌鱼的身边徘徊求偶，为了把接下来的事说清楚，咱们就暂且把雄鱼称为“小刚”，雌鱼称为“小美”好了。

小刚看起来就像是一道在水中游弋的绚丽火焰，一身鳞片闪烁着明亮的橙色，深蓝色的斑点点缀其中。

而小美看起来则朴素低调的多，靛蓝色的身体点缀着一点紫色，深色的边缘让它更加暗淡。

正当小刚和小美齐头并进时，它们的身体开始像鼓一样振动起来，于此同时，小美开始排出卵泡，小刚则在卵泡上洒下一股乳白色的精液，给那些卵受精。

接下来，令人惊奇的一幕发生了，在那些卵受精之后的几秒钟后，小刚身上明亮的橙色开始熄灭，转而变成暗淡的靛蓝色，而小美身上的颜色则“燃烧起来”，呈现出明亮的橙色，好似一道火焰。

紧接着，小刚开始排出卵泡，而小美则冲上去往卵泡上喷洒精液让其受精。就这样，这两条带鮨在交配过程中通过瞬间变性既充当了父亲，又充当了母亲。事实上，这种鱼是雌雄同体的，可以根据各种实际情况改变自己的性别，当两条同性相遇时，其中一条会瞬间变性和对方交配，然后双方性别倒置再交配一次，最让人震惊的是，如果这条鱼找不到伴侣的话，它们就会自己先排卵，然后再变性，往自己排出的卵泡上喷洒自己的精液，自己和自己交配…….

其实这种雌雄同体可以变性的情况在鱼类里并不罕见，在其他的物种中也能找到类似的情况。欧洲北海附近生活着一种海虫名叫绿沙蚕（Nereis virens）。

当它们的身体少于20节时，就会维持自己的雄性身份并且产生精子，而当它们生长到超过20节时，它们就会变成雌性产生卵子，可是如果我们故意刁难它们，把它们斩断到20节以下的话，它们又会变成雄性。

通常来说，这种沙蚕年轻时都是雄性，长大了就会变成雌性，可是如果我们把两条雌性沙蚕放进一个瓶子里，较短的一条就会变成雄性，这样它们就能交配了。

由此可见，即使在有性生殖的领域里，也没有什么一定之规，大自然千变万化，总是会有人类经验之外的境况出现，大自然不仅通过性向我们展现神奇的一面，也向我们展现残酷的一面。

德国著名动物行为学家维托斯·德吕舍尔（Vitus B.Dröscher）曾经在他的著作《从相残到相爱：两性行为的自然演化》中表达过一个极具争议性的观点。

德吕舍尔先生认为，这个世界上的动物，最开始是先有雌性，然后有雌雄同体的双性，最后才有雄性的。雄性实际上是雌性为了解决环境的适应性问题而“发明”出来的。

这个观点饱受争议，同时也让很多男性感到惊讶和尴尬，但是德吕舍尔先生也确实给了我们一个新的思路让我们重新思考这个世界上的两性关系。

可惜的是，并不是雄性被“发明”出来以后就万事大吉了，像童话故事结尾那样的情节“从此王子就和公主幸福地生活在了一起”也只能存在于童话中。

以我们今天人类社会的主流道德标准看来，理想的伴侣关系应该是稳定，持久，忠诚，甜蜜的。

臭虫

可是一个物种要是想维持这种理想的两性关系，需要平衡好三种本能，分别是“性本能”，“攻击本能”以及“亲和性结对本能”，实现这种平衡是一个漫长而复杂的过程，而有的物种甚至连最基本的问题，“应该和谁交配”这件事都没搞太清楚。

臭虫就经常被这个简单的问题所困扰，臭虫的交配方式非常危险，雄性的性器官看起来就像一把匕首，它并不会将其插入雌性的生殖器开口中，而是直接插入雌性的背部，往雌性的血液里射精，通过血液把精子带入生殖系统。

这种交配方式被成为“创伤性受精”。通常来说，雌性在每次交配之后伤口会康复并且在背上留下一道“刀疤”，但是有的时候雄性如果交配时太卖力，就会把雌性当场插死。

让人尴尬的是，糊涂的雄臭虫会和任何看起来像臭虫大小，黑色的，平面状的东西发起交配。

这就使得有的雄臭虫会被别的雄性“强暴”，乃至有可能被别的雄性内射甚至插死。

在巴西有另外一个让人印象深刻的例子，在巴西桑托斯市附近的沼泽地不远处曾经建起了一座变电站。当工人接通电流时，附近沼泽里无数的蚊子铺天盖地地朝变电站飞来，然后落在烫手的机器上被成片烤死。

最后工作人员不得不用推土机将成堆的蚊子尸泥清理走。这一切的原因在于那个变电站发出的振动频率为每秒500—550次，和雌蚊发出的声音一样，搞不清楚该和谁交配的雄蚊听到这种声音，就把变电站当作了雌蚊，不顾一切地飞向死亡。

同样的问题有时候也困扰着阿德利企鹅，这种企鹅的眼睛是为了在水下使用而设计的，所以上岸以后每只企鹅都是严重的近视眼。

到了求偶的时节，雄性阿德利企鹅会用嘴把自己心爱的小石头推到自己的意中人脚下示好，如果它的意中人抬起它的小翅膀扇它的话，表示自己拒绝和它交配。如果它的意中人接受示好，它就会围着这只雄性跳舞，并且和它开始抒情的二重唱。当然还有一种情况是这样的，意中人俯下身子冲着那只雄性愤怒地尖叫，这尖叫声的意思是“QNMD！老子是雄性！”

搞清楚应该和谁交配只是第一步，离真正和谐美满的两性关系还差的很远。攻击本能和亲和性结对本能是两种相对的本能，它们和性本能一起左右着一个物种内的配偶关系。

可惜的是，很多物种完全无法抑制住自己的攻击本能，因此攻击本能和性本能共振出来的强奸行为在自然界中是普遍存在的。

陆龟就是一个典型的例子，在交配季节，雌陆龟会吃的很胖，这使得它们无法把身体全部缩入壳里，只能顾头不顾腚，这就给雄陆龟以可乘之机。雄陆龟会在交配前疯狂地追打雌性，踩它们咬它们，而雌陆龟会不顾一切地逃命。在这个过程中，雌陆龟随时可能会被雄性杀死。

最后，几个小时的追打终于耗尽了雌龟最后一点体力，它决定放弃抵抗，把头部缩进壳里，于是不得不露出的屁股就只能被雄龟侵犯了。

陆龟的交配是彻彻底底的强奸行为，没有半点感情涉入其中。

蜘蛛

配偶间的攻击本能无法被抑制时，雌性并不永远处于被强奸的弱势地位。蜘蛛里就有一些雌性找回了面子。

众所周知，不少雌蜘蛛会因为无法克制自己的本能而在交配后吃掉自己的丈夫（其实在蜘蛛里同类相食的情况并不是常态）。

可是盗蛛科（Pisauridea）里有一种雄蛛非常鸡贼，它为了不让自己在交配时成为自己老婆的口粮，会先抓一只虫子用蛛丝捆好做成礼物，在它老婆享用礼物的时候赶紧交配然后溜之大吉，但是有的雄蛛完事的非常快，交配完了之后发现它老婆还没开始吃礼物，它就会先抢回礼物然后再逃之夭夭。这样一来雌蛛既没吃到礼物也没吃到丈夫，只能一脸懵逼地愣在原地：“大意了！妹想到！”

老虎的交配非常生动地向我们展示了三种本能是如何相互作用的。老虎的攻击本能要远远强于亲和性结对本能，因此它们对彼此都怀着深深的敌意，这种远远大于引力的斥力也使得老虎平时过着独居生活。

但是当它们需要交配时，它们不得不走到一起，母老虎会表现的像个幼崽躺在地上做撒娇状，而公老虎则站在远处静静地看着，接着，母虎会围着公虎走动，嘴里发出呼噜呼噜的声音，然后用自己的下巴蹭公老虎的脸。如果此时公虎不识趣地做出任何回应的话，母虎会立即暴跳如雷并且疯狂咆哮，因为它的攻击本能太强了，稍不注意就会失控，把公老虎当作敌人。于是，母老虎只得继续调情，慢慢进入性兴奋状态，用性本能和一点极微弱的亲和性结对本能压制住自己的攻击本能，最后完成交配。要命的是，交配结束之后，母老虎的性本能会立即退散，攻击本能再度占据上风，母老虎会因此立即对公老虎发动致命的进攻。公老虎通常比母老虎强壮，如果它还手的话，可以轻而易举地将这个“疯婆子”扇倒在地。可是公老虎在交配之后，性本能和结对本能却没有立即消散，它依然对母老虎心存温情，这使得它不忍还手，甚至不忍自卫，只能转身逃进森林深处。在老式动物园的小笼子里，老虎在交配之后，母虎会立即杀死无处可逃的公虎，一些老式动物园也因此拒绝让老虎们交配，而在诸如德国哈根贝克这样的新式动物园里，生活在圈养区的公虎会在交配后立即逃跑，而母虎则会到池子里泡一会平息自己的怒火。

文章写到这里时，大家或许会明白，过强的攻击本能对于形成人类期许的那种美满的两性关系是负面的，如果我们人类（智人）的攻击本能过强的话，情侣们稍一接近就会疯狂地撕打起来，美满的配偶关系自然无从谈起。

那么我们彻底摒弃攻击本能吼不吼哇？

大自然也姿瓷吗？

不，大自然没有任何这个意思。

大家要是有这样的想法我要负责的。

因为如果我们过于温柔，人和人之间清晰的边界也就消失了，我们人类就会像爱好和平性情温顺的长颈鹿那样*，凭借着意愿和任意一个性成熟的异性交配而不需要冒着被骂非礼，被扇耳光，被防狼器电击的风险。

我们可能会因为失去攻击本能而在任何时间任何地点和任何自己中意的人做爱而不会有人介意。

什么？

你问会不会有人来阻止你？

他们自己的裤子还没提上来呢，哪有空管你呢？

攻击性是非常微妙的东西，如果太强的话，不要说无法形成理想的配偶关系，就连整个社会都会因为成员之间的敌意太强而崩溃（大型社会可能根本就无法形成，人类会在霍布斯世界里徘徊，甚至成为老虎和北极熊那样的独居物种），而攻击性太弱的话，人和人之间又会失去清晰的边界而搞的一塌糊涂。

性和死亡

归根结底，是“性本能”，“亲和性本能”和“攻击本能”这三种本能之间微妙的平衡造就了我们主流社会价值观所期许的那种配偶关系，任何一种本能走极端都是不可取的。

话说回来，人类所在的地理环境也会对人类形成强烈的影响，因此一夫一妻制是不是人类这个物种的常态，目前还没有清晰明确的定论。

无论我们以怎样的方式结成配偶，在我们开始享受性的时候，死亡也自动开始了它的进程，生命的倒计时在交配的欢愉之中开始了。

最后一位天启骑士，挎上冰凉的镰刀，骑上惨白的骨马，走入性爱的乐园，去兑现一份12亿年前签下的契约。

尽管我们并不清晰具体地知道其中的原理，但是性和死亡就好像一枚硬币的两面，互为表里。

蜉蝣的幼虫可以活一个月，然后变态为没有口器也没有消化道的成虫，然后它们可以有一天的时间享受死前的狂欢滥交，就算勉强活过了一天，也会因为没有消化系统而活活饿死。

太平洋鲑鱼又如何呢？

它们迁徙几百甚至上千公里，回到它们出生的小溪，然后陷入性爱的狂欢之中。它们短短几天之内就会燃尽自己的生命之火，然后成为一片安静的浮尸。

蜂后在十六年的时间里仿佛进入了时间的真空之中，身体没有任何衰老的迹象，可当它储存的精子用完之后，它立刻就会被它的孩子们撕个粉碎。

事实上，人们通过观察，早就发现了性和死亡之间有着某种不同寻常的联系，比如人们发现溪鳟被引入内华达山脉的寒冷，缺乏营养的高山湖之后，性成熟推迟了，但是寿命足足翻了两倍。法国著名生物学家查尔斯·布朗-塞卡德就在1889年向巴黎生物学协会报告说，自从他把狗和豚鼠的睾丸提取物注射到自己身体里以后，他感到自己体力充沛，精神焕发。不久以后，全世界的外科医生都开始着手给患者植入山羊，猴子甚至囚犯的睾丸。

但是没有任何证据证明这种手术的价值。

得益于技术的进步，今天的学者们抛弃了之前对性和死亡主观粗暴的认识，得以以更加微观的视角来解释性和死亡之间的关系。

伦敦大学生物化学家尼克·莱恩（Nick Lane）表示，所有的衰老基因(gerontogenes)都有一个奇怪的特征，那就是一旦突变，后果全都是延长寿命，而非缩短。后来学者发现，其实这些基因控制的根本就不是衰老，而是性成熟。

动物如果想发育到性成熟，需要摄入大量的营养，但是当营养不足的时候，最好的策略就是暂缓发育，等营养足够之后再说（还记得溪鳟的例子吗）。

这意味着，当营养充足的时候，身体里一个象征着丰饶的生化信号就会通知细胞们：“小的们，现在食物大大滴有！交配的时候到啦！”这个象征着丰饶的生化信号其实是胰岛素，当营养充足时，这些胰岛素类激素就会发挥作用，上演一系列发育变化，为性做好准备。

当营养匮乏的时候，通路就会陷入沉寂，性发育推迟，生命就会“暂停”。

长时间的饥肠辘辘会延长动物的寿命，但是相应的代价却是不孕不育（这就是为啥糖尿病伴随的胰岛素紊乱往往伴随着不孕不育）。

另外，如果我们回顾生命的历史，我们就会发现，死亡和性在很久以前就纠缠在一起了。

三十亿年前的地球，天空还是一片朦胧的红色，空气中几乎没有氧，要想等到微生物们把天空变成蓝色，还需要好几亿年的时间。尽管当时地球上还没有飞鸟走兽，但是生命之间的殊死搏杀却已经在微观的层面上开始了。

噬菌体是一种病毒，专门感染细菌，在现代海洋中，它们的数量要比细菌高出两个数量级。这些阴险狡诈的噬菌体会用自己仅有的一点基因来编码一些毒素用以杀死宿主细菌，然后又产生一种抗毒素来确保细菌不会被毒死。毒素本身是长效的，但是抗毒素却却是短效的，所以噬菌体就用这种方式绑架了它感染的细菌。就好像一个人一边喂你吃长效性的毒药，一边给你喂短效性的解药，如果你把他赶走，你就会被毒死。细菌为了对付噬菌体，就把抗毒基因整合到自己身体里获得抗毒性，而噬菌体却不依不饶地演化出更先进的毒素反制，双方就这么互相抬杠，开始了一场数十亿年的军备竞赛。学者推测，正是这场军备竞赛缔造出了胱天蛋白酶(caspase enzyme)家族。这种“死亡蛋白”会在细胞内形成连锁反应，把细胞从内部“切开”，就好像是细胞的自毁程序。一旦细菌感到形势不对，族群面临团灭威胁时。族群里最优质的细胞就会发育成顽强的孢子，而剩下的个体则纷纷启动自毁程序，以鱼死网破的方式将一切归零重来。等危机过后，孢子再重新萌发，make it great again。这一切就好比人类社会在各种危机下面临崩溃，一小撮人类精英藏进地下掩体，剩下的人毁灭一切集体自杀，等时机成熟之后精英们再从掩体出来重新建设。

然而，这种细胞的自毁行为，正是衰老以及死亡的本质。

今天绝大多数动物包括我们人类在内，体内复杂的真核细胞实际上是两种细胞的融合，宿主细胞，以及线粒体。

但今天非常多的学者坚信，我们体细胞里的线粒体其实在大约17亿年前是一种在外部环境里独自生活的细菌。当它们被宿主细胞吞噬后并没有被消化，反而与宿主细胞成为了好搭档。线粒体从宿主那摄取营养，宿主又从线粒体那获得能量。

线粒体就好像给宿主细胞安上了一台大功率发动机，从此生命的演进一日千里。

要命的是，线粒体被引入宿主细胞之前也是一种细菌，它的基因里也存留着细胞用以自我毁灭的“死亡蛋白”——胱天蛋白酶。令人惊奇的是，这种“死亡蛋白”并没有直接将生命推向毁灭，反而使得生命开始了复杂化的进程。一个人体内的每一个细胞（除生殖细胞外）基因都是相同的。但即使是基因相同的细胞，也会在不同的环境下发育成不同的样子，这种现象被成为细胞分化。同样基因的细胞分化成不同种类的细胞，而这些不同种类的细胞在各自的岗位上各司其职，让它们所属的复杂生命体（比如正在读此文的你）得以正常运转。多亏了“死亡蛋白”，这一切才成为可能，那些不顾集体安排自行其是的细胞会被胱天蛋白酶执行死刑，从我们的身体里被消灭掉。胱天蛋白酶正是这样冷酷地消灭我们身体里各种不服的“刺头”，维护着我们身体得以正常运行的秩序。我们的身体也正是建立在这种细胞再生和细胞死亡的平衡之上，但是由于某种我们目前还不明确的原因（一种观点认为是多效性基因的效应），这种平衡会随着时间的推移被渐渐打破，如果最终“生”压倒了“死”，癌症就会出现，细胞将以疯狂的增殖毁灭一切，如果“死”压倒了“生”，细胞会被胱天蛋白酶超量地杀死，我们的身体会渐渐凋零枯萎，像神经元细胞那样的特化细胞一旦被杀死就再也没有了，我们会在凛冽的岁月中逐渐地失去自我，最后死亡。

这一切正如侦探小说最终指认凶手时会让人大吃一惊一样。当初那慷概地赋予我们能量，陪我们走过十几亿年的光阴，帮助我们演化成智慧生命的大功臣和好朋友，甚至可以说缔造了我们并且依然存在于我们每个人身体里的线粒体，其实就是死亡骑士本人。

在十几亿年前的浩瀚汪洋中，生命通过“性”高效率地积累起各种增强适应性的创新，开始了生命复杂化的进程。

“死亡”又随之降临，确保复杂化的生命得以正常的维持。生命的世界从几十亿年前的一片混沌，到今天这般绚丽缤纷，“性”和“死亡”缺一不可。

“性”和“死亡”是一枚硬币的两面，在地球还是一片洪荒时，造物主面无表情地将它弹向空中，十几亿年过去了，那枚硬币却依然在空中久久回转……

总有一天，我也会离开这个世界。

在我生命尽头的白光之中，死亡骑士走到我身后问：“后悔吗？”

我转过头回望他身后的那个美丽世界，看着漫山遍野的鲜花，看着采蜜授粉的蜜蜂，看着追逐嬉戏的角马，看着绚烂开屏的孔雀，看着温情相伴的天鹅，看着月下叫春的猫儿，看着产房里大汗淋漓的母亲，看着产房外欣喜若狂的父亲，看着我们的子孙相识相恋，看着他们的爱情创造未来。

我回答：“不后悔，谢谢你。”

（完）

后记：

《天启四骑士》是国家博物馆开发的专题课程，分别对应的是灾荒，屠杀、瘟疫、死亡骑士。

他们分别是：

灾荒：《地狱看起来就像光绪初年的山西一样》

瘟疫：《飞翔的尸体与一次欧洲人口灭绝》

屠杀：《每10秒杀一人，杀满100天》

死亡：《我们为什么要放弃永生》

相信国家博物馆做这样的主题肯定是用心良苦，能教育国民，因为扣击震撼到老王的认知边界，而且前晚再次提及时同学们表示很喜欢，所以再次推送。

使用OLLAMA+ChatBoxAi.app5分钟体验deepseek-r1模型

阿布大人 — Sat, 01 Feb 2025 15:16:00 +0800

某些场景下可能希望构建一个完全本地离线可用的大模型，方法很多，模型也很多，比如 qwen、qwen2、llama3等，最简单快捷的首推使用 ollama 部署，模型选用 qwen 或 qwen2，针对中文任务效果更好。

首先下载 ollama 双击安装(277MB)
ollama下载地址： www.ollama.com/download

下载后双击安装

安装完毕后打开命令行黑窗口
开始菜单中找到命令提示符，点击打开

或者随便打开任意一个文件夹，然后在文件夹地址栏中输入 cmd 按回车。

都能打开一个黑窗口

找到想要使用的模型，推荐 qwen系列
打开这个网址 www.ollama.com/library 可以选择要使用的模型

比如使用 qwen，点击进入后，会看到如下

点击下拉框，可选择模型版本列表，4b 代表该模型有40亿参数，当然参数越大效果越好，但同样也要求你的电脑配置越高，不够高的话不仅运行慢，还可能卡死机。

如果你有英伟达显卡，并且独立显存不低于12G，可以选择 14b / 32b 版本，否则建议选择 7b

选择后，右侧会显示对应的下载命令，点击复制图标复制该命令，以7b为例命令是 ollama run qwen:7b

复制后回到黑窗口，点击鼠标右键粘贴该命令，然后回车，就开始了下载，耐心等待下载完毕。

直接在黑窗口交互方式使用

上面下载完毕后，就可以直接在黑窗口中使用了，试试先询问它是谁吧

关闭了黑窗口，如何在次使用呢
还记得怎么打开cmd吗，用同样方法去打开它，然后同样去粘贴命令。7b的命令是ollama run qwen:7b

就自动打开了。

还想使用其他模型怎么办
同样方法，去 www.ollama.com/library 这个地址找到想用的模型，点击进入，选择模型版本，复制右侧命令，到 cmd黑窗口中粘贴回车。

cmd黑窗口太难用了，有没有ui界面
搭配 ollama 最好用的ui界面首推ollama官方的 docs.openwebui.com(使用的化建议使用docker快速安装)

如果你懂 docker部署或略懂代码，可参考手动安装。

如果你只想下载一个exe鼠标点点就能使用，可下载 chatbox，双击安装，同安装其他软件一样方法

chatboxai.app/zh

第一次运行点击设置

然后点击“显示”，再从下拉框里选择 “ollama”

然后在模型下拉框里选择你要使用的模型，所有通过 ollama run 命令安装的模型都会在此显示，选择好后点击保存

如果找不到模型，需要参考如何配置ollama远程模式配置环境变量，

在 MacOS 上配置

打开命令行终端，输入以下命令：

launchctl setenv OLLAMA_HOST "0.0.0.0"
launchctl setenv OLLAMA_ORIGINS "*"

重启 Ollama 应用，使配置生效。

在 Windows 上配置

在 Windows 上，Ollama 会继承你的用户和系统环境变量。

通过任务栏退出 Ollama。
打开设置（Windows 11）或控制面板（Windows 10），并搜索“环境变量”。
点击编辑你账户的环境变量。

为你的用户账户编辑或创建新的变量 OLLAMA_HOST，值为 0.0.0.0；为你的用户账户编辑或创建新的变量 OLLAMA_ORIGINS，值为 *。
点击确定/应用以保存设置。
从 Windows 开始菜单启动 Ollama 应用程序。

在 Linux 上配置

如果 Ollama 作为 systemd 服务运行，应使用 systemctl 设置环境变量：

调用 systemctl edit ollama.service 编辑 systemd 服务配置。这将打开一个编辑器。

在 [Service] 部分下为每个环境变量添加一行 Environment：

[Service]
Environment="OLLAMA_HOST=0.0.0.0"
Environment="OLLAMA_ORIGINS=*"

保存并退出。
重新加载 systemd 并重启 Ollama：
```
systemctl daemon-reload
systemctl restart ollama
```
环境变量配置好后，就可以选择对应模型之后进行聊天了。

	播种面积（千公顷）	总　产　量（万吨）	单位面积产量（公斤/公顷）
全国总计	119319.1	70649.9	5921.1
北　　京	94.2	57.6	6115.5
天　　津	399.1	270.6	6780.5
河　　北	6460.1	3908.8	6050.6
山　　西	3151.6	1468.7	4660.0
内蒙古	7011.8	4100.5	5847.9
辽　　宁	3577.5	2500.3	6989.1
吉　　林	5853.8	4266.0	7287.5
黑龙江	14754.0	8001.7	5423.4
上　　海	130.3	98.3	7542.6
江　　苏	5475.5	3810.1	6958.4
浙　　江	1047.0	650.2	6210.2
安　　徽	7344.9	4184.3	5696.9
福　　建	844.4	514.4	6091.6
江　　西	3774.6	2196.0	5818.0
山　　东	8412.6	5710.2	6787.7
河　　南	10777.1	6719.4	6234.8
湖　　北	4722.6	2785.3	5897.9
湖　　南	4773.4	3078.1	6448.4
广　　东	2236.8	1313.4	5872.0
广　　西	2841.8	1403.8	4939.7
海　　南	272.7	142.4	5222.1
重　　庆	2031.9	1100.7	5417.2
四　　川	6405.9	3633.8	5672.6
贵　　州	2771.4	1146.1	4135.5
云　　南	4246.8	1993.5	4694.0
西　　藏	199.4	112.9	5664.7
陕　　西	3031.9	1352.3	4460.2
甘　　肃	2715.9	1296.1	4772.3
青　　海	305.9	118.3	3866.2
宁　　夏	694.2	385.9	5559.2
新　　疆	2960.0	2330.2	7872.4
注：此表中部分数据因四舍五入，分省合计数与全国数略有差异。