使用Gradle构建项目,尝试用的属性,与数据库、缓存,MQ搭配,以及构建模板。

Gradle介绍

Gradle 是一个构建自动化工具

用来做三件事：

• 编译 Java / Kotlin
• 管理依赖（类似 Maven）
• 组织多模块工程

一个 Gradle 项目本质是：

1

Gradle = 一堆 Project + 每个 Project 的 build.gradle

每个 build.gradle 里都是“配置块”。

Gradle核心模型

Gradle 有 3 个核心对象：

Project（项目）

每个模块都是一个 Project：

1
2
3
4

root project
 ├── api
 ├── service
 ├── repository

每个 build.gradle = 一个 Project

Task（任务）

Gradle 的执行单位：

1
2
3
4

compileJava
test
bootJar
build

Dependency（依赖）

Java 代码依赖：

1

implementation 'org.springframework.boot:spring-boot-starter'

生命周期

1
2
3

1. 初始化（init）
2. 配置（configuration）
3. 执行（execution）

关键点： build.gradle 在“配置阶段”全部执行

所以：

1

println("hello")

会在执行 task 之前就打印。

一个项目结构让设计如下

1
2
3
4
5
6
7

purchase-system
│
├── common          （基础模型）
├── contract        （RPC接口）
├── repository      （DAO）
├── service         （业务 + Dubbo provider）
└── api             （HTTP + Dubbo consumer）

插件块

给 build.gradle 这个脚本本身加依赖,通过buildscript或者plugins.给项目“增加能力”

比如：

• java → 可以编译 Java
• spring boot → 可以打 bootJar

plugins {}：现代插件机制（声明式、Gradle 官方推荐）
buildscript {}：旧插件机制（手动把依赖塞进构建脚本 classpath）

1
2
3
4
5
6
7
8

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath "org.springframework.boot:spring-boot-gradle-plugin:3.3.0"
    }
}

通过repositories中的仓库查找对应插件并放到classpath.然后才apply plugin使用插件. Gradle本身自带一些插件,比如java,可以直接apply

而`plugins自己去“插件仓库”下载 plugin

然后自动解析 plugin marker,找找 implementation jar,自动 apply. 配置下载仓库在settings.gradle中,默认使用Gradle官方的

1
2
3

plugins {
    id "org.springframework.boot" version "3.3.0"
}

仓库块

1
2
3
4

repositories {
    mavenCentral()
    maven { url "https://maven.aliyun.com/repository/public" }
}

告诉 Gradle 去哪里下载依赖

依赖块

1
2
3

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter'
}

给 Java 代码引入库

ext

1
2
3
4

ext {
    lombokVersion = '1.18.34'
    dubboVersion = '3.2.15'
}

作用： 定义“全局变量

现在推荐替代方案

1

gradle.properties

allprojects

1
2
3
4
5

allprojects {
    repositories {
        mavenCentral()
    }
}

作用： 对“所有 project（包括 root + 子模块）”生效

subprojects

1
2
3
4
5
6
7

subprojects {
    apply plugin: 'java'

    dependencies {
        testImplementation 'org.junit.jupiter:junit-jupiter:5.10.2'
    }
}

作用： 只对“子模块”生效（不包括 root）

作用:

统一 Java plugin

统一 Lombok

统一 test 配置

project(“:xxx”)

1
2
3
4
5

project(":api") {
    dependencies {
        implementation project(":common")
    }
}

配置“某一个指定模块”

dependencyManagement {}

1
2
3
4
5

dependencyManagement {
    imports {
        mavenBom "org.springframework.boot:spring-boot-dependencies:3.3.0"
    }
}

作用：统一版本号（不在 dependencies 写版本）

tasks （任务块）

1
2
3
4
5

tasks.register('hello') {
    doLast {
        println("hello gradle")
    }
}

作用：定义构建步骤

常用插件

自带插件

1）java（最重要）

1
2
3

plugins {
    id 'java'
}

提供能力：

• compileJava

• jar

• test

• sourceSets

  Java 项目基础插件

2）java-library（更专业）

1
2
3

plugins {
    id 'java-library'
}

多了：

• api / implementation 区分

• 更适合模块化项目

  推荐多模块项目用这个

maven-publish

Gradle Maven Publish Plugin

1
2
3

plugins {
    id 'maven-publish'
}

用于发布 jar 到 Maven 仓库

数据库 / ORM 常见插件

MyBatis Generator

1
2
3

plugins {
    id 'org.mybatis.generator'
}

自动生成 mapper / entity

Spring 生态插件

Spring Boot Plugin

Spring Boot Gradle Plugin

1
2
3

plugins {
    id 'org.springframework.boot' version '3.3.0'
}

提供：

• bootJar（fat jar）
• bootRun
• 自动依赖管理

Spring Dependency Management

1
2
3

plugins {
    id 'io.spring.dependency-management'
}

提供：BOM 管理（不写版本号）

基于Spring-boot-starter与Mybatis整合

mybatis-spring-boot-autoconfigure – 简介

1
2
3

dependencies {
  implementation("org.mybatis.spring.boot:mybatis-spring-boot-starter:3.0.2")
}

MyBatis-Spring-Boot-Starter 将会：

• 自动探测存在的 DataSource
• 将使用 SqlSessionFactoryBean 创建并注册一个 SqlSessionFactory 的实例，并将探测到的 DataSource 作为数据源
• 将创建并注册一个从 SqlSessionFactory 中得到的 SqlSessionTemplate 的实例
• 自动扫描你的 mapper，将它们与 SqlSessionTemplate 相关联，并将它们注册到Spring 的环境（context）中去，这样它们就可以被注入到你的 bean 中

数据源是基础底层，SqlSessionFactory 利用数据源创建连接并作为核心工厂，生产出具体的执行器 SqlSessionTemplate，而 SqlSessionTemplate 在幕后真正驱动并支撑 Mapper 接口的方法执行。

它们之间的分层依赖与调用关系如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

[DataSource (数据源)]
       ▲
       │ 提供数据库连接池 (如 HikariCP)
       │
[SqlSessionFactory (会话工厂)]
       ▲
       │ 作为单例核心引擎，用来创建会话
       │
[SqlSessionTemplate (会话模板)]
       ▲
       │ 线程安全，代理并管理实际的 SqlSession 会话与生命周期
       │
[Mapper 接口 (动态代理对象)]

mybatis-spring-boot-autoconfigure – 简介

配置

引入依赖

在 pom.xml 中引入 MyBatis 自己的 Starter（它会顺着依赖把需要的工厂类和模板类全部下载下来）：

1
2
3
4
5

<dependency>
    <groupId>org.mybatis.spring.boot</groupId>
    <artifactId>mybatis-spring-boot-starter</artifactId>
    <version>3.0.3</version>
</dependency>

1. 核心配置文件 (application.yml)

只需要配置两部分：一是数据源（让它能自动探测到 DataSource），二是告诉它你的 SQL 映射文件（XML）放在哪。

1
2
3
4
5
6
7
8
9
10
11
12
13

spring:
  datasource:
    # 1. 对应第一句：“自动探测存在的 DataSource”
    url: jdbc:mysql://localhost:3306/your_db?useUnicode=true&characterEncoding=utf-8
    username: root
    password: your_password
    driver-class-name: com.mysql.cj.jdbc.Driver

mybatis:
  # 2. 对应第四句：告诉系统你的 XML 映射文件在哪里，好让它自动扫描并关联
  mapper-locations: classpath:mapper/*.xml
  configuration:
    map-underscore-to-camel-case: true # 顺便开启驼峰命名转换（下划线转驼峰）

1. 在代码中打个“招呼”

最后在Spring Boot 启动类（或者配置类）上，加上一个 @MapperScan 注解。

这是为了告诉它：“我的 Mapper 接口都放在这个包底下了，你快去自动扫描它们，把它们和 SqlSessionTemplate 关联起来吧！”

Java

1
2
3
4
5
6
7

@SpringBootApplication
@MapperScan("com.example.ecommerce.mapper") //  告诉系统扫描哪里的 Mapper 接口
public class EcommerceApplication {
    public static void main(String[] args) {
        SpringApplication.run(EcommerceApplication.class, args);
    }
}

整合springBoot与Redis

快速导览 :: Spring Kafka - Spring 框架

在 Spring Boot 中，spring-boot-starter-data-redis（通常简称为 spring-redis-starter）是整合 Redis 的核心组件。它不仅引入了 Redis 客户端驱动，还通过 Spring Boot 的 Auto-Configuration（自动装配） 机制，让开发者几乎可以零配置直接使用。

1. 默认客户端驱动：Lettuce

• 在老的 Spring Boot 1.x 版本中，默认使用的是 Jedis 客户端。
• 从 Spring Boot 2.x/3.x 开始，官方默认将驱动切换为了 Lettuce。
• 为什么用 Lettuce？ Jedis 的多线程并发是基于连接池的（线程不安全），而 Lettuce 是基于 Netty 的，它的连接可以在多个线程间共享，属于异步非阻塞的架构，在高并发场景下性能更优、资源消耗更小。

1. 自动装配类：RedisAutoConfiguration

当你引入了 Starter 后，Spring Boot 的类路径扫描会激活 RedisAutoConfiguration 这个自动配置类。它在幕后默默做了两件事：

• 自动创建连接工厂（RedisConnectionFactory）：它会读取你在 yml 中配置的 host、port 等参数，实例化一个 LettuceConnectionFactory，负责建立与 Redis 服务器的物理连接。
• 自动注入两个核心模板类：
  • RedisTemplate<Object, Object>：通用模板，键值对都可以是任意对象。
  • StringRedisTemplate：专门处理 String 类型的模板（因为 Redis 中 90% 的场景都是字符串）。

1. 序列化机制（关键踩坑点）

Redis 底层只存储字节数组（byte[]），而 Java 是一门面向对象的语言。因此，Java 对象存入 Redis 必须经过序列化。

• StringRedisTemplate：默认使用 StringRedisSerializer。它存进去的就是人类直观可见的普通字符串。
• RedisTemplate：默认使用 JdkSerializationSerializer。这会导致两个严重问题：
  1. 存入 Redis 的 Key 和 Value 前面会带有一串乱码般的十六进制前缀（如 \xac\xed\x00\x05t\x00...）。
  2. 难以通过可视化工具（如 RDM）直接查看，且跨语言（如 Python 读写）极不友好。

配置

引入依赖 (POM)

除了 Starter 本身，如果需要配置连接池，必须引入 commons-pool2。

1
2
3
4
5
6
7
8
9

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<!-- 必须引入，否则 lettuce 连接池配置无法生效 -->
<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-pool2</artifactId>
</dependency>

1. 核心配置文件 (application.yml)

标准 Lettuce 连接池配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

spring:
  data:
    redis:
      host: 127.0.0.1
      port: 6379
      password: your_password
      database: 0                # 默认使用 0 号库
      timeout: 5000ms            # 连接超时时间
      connect-timeout: 5000ms    # 路由建立连接超时时间
      lettuce:
        pool:
          max-active: 32         # 连接池最大连接数（高并发下调大）
          max-idle: 16           # 连接池中的最大空闲连接
          min-idle: 4            # 连接池中的最小空闲连接
          max-wait: 2000ms       # 连接耗尽时，消费者最大等待时间

1. 自定义配置类：重写 RedisTemplate（必做步骤）

为了解决上面提到的 “JDK 序列化乱码” 问题，在实际开发中，我们必须自己写一个配置类，把默认的序列化方式替换为 JSON 序列化。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

@Configuration
public class RedisConfig {

    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(factory);

        // 1. 使用 JSON 工具（这里以 GenericJackson2JsonRedisSerializer 为例）
        GenericJackson2JsonRedisSerializer jsonSerializer = new GenericJackson2JsonRedisSerializer();

        // 2. 设置 Key 和 HashKey 采用 String 序列化（保证人类可读，无乱码）
        template.setKeySerializer(RedisSerializer.string());
        template.setHashKeySerializer(RedisSerializer.string());

        // 3. 设置 Value 和 HashValue 采用 JSON 序列化
        template.setValueSerializer(jsonSerializer);
        template.setHashValueSerializer(jsonSerializer);

        template.afterPropertiesSet();
        return template;
    }
}

三、 总结：如何选择 RedisTemplate 和 StringRedisTemplate？

在代码中注入并使用它们时，遵循以下基本原则：

1. 如果你只存纯文本、数字、或者你自己手动转好的 JSON 字符串： 直接使用 StringRedisTemplate。它免去了任何框架层的序列化开销，性能最高，且在 Redis 内呈现最干净的字符串。
2. 如果你想直接把一个 Java 对象（如 User 实体、Order 实体）丢进 Redis： 使用你刚才自定义好序列化器的 RedisTemplate<String, Object>。它会在底层自动帮你把对象转成标准 JSON 串存入，取出来时自动反序列化回 Java 对象，开发体验最顺畅。

整合springBoot与Kafka

引入依赖

1
2
3

<dependency>  
<groupId>org.springframework.kafka</groupId>  <artifactId>spring-kafka</artifactId>  <version>4.0.0</version> 
</dependency>

spring-kafka 的自动装配核心是 KafkaAutoConfiguration 类，它在项目启动时主要帮你完成了以下几件大事：

1. 自动构建三大工厂（基础层）

它会读取 yml 中的集群地址等参数，在后台自动实例化：

• ProducerFactory：生产者工厂，负责专门创建、管理和复用低层的 Kafka 生产者实例（KafkaProducer）。
• ConsumerFactory：消费者工厂，负责配置消费组 ID、反序列化器，并创建原生的 KafkaConsumer。
• KafkaListenerContainerFactory：监听器容器工厂（最核心）。它负责把你的 @KafkaListener 注解转换为后台不断轮询（poll()）消息的异步线程池容器。

1. 自动注入核心发送模板：KafkaTemplate

类似于 RedisTemplate，Spring 自动为你提供了一个 KafkaTemplate<K, V>。

• 它对原生的生产者进行了高级封装。
• 它默认是线程安全的，你可以在任何 Service 里直接注入并调用 .send(topic, message)。
• 支持同步发送（等待 Broker 回应）和异步发送（通过 CompletableFuture 回调接收发送结果）。

1. @KafkaListener 幕后的死循环轮询

当你在某个方法上加上 @KafkaListener(topics = "my-topic") 时：

1. Spring 启动后，监听器容器工厂会为这个方法单独开启独立的线程。
2. 线程内部会进入一个 while(true) 的死循环，源源不断地调用 Kafka 原生的 consumer.poll(timeout) 方法去拉取消息。
3. 一旦拉取到消息，通过反射调用你写的方法，将消息作为参数传入。

引入依赖 (POM)

1
2
3
4

<dependency>
    <groupId>org.springframework.kafka</groupId>
    <artifactId>spring-kafka</artifactId>
</dependency>

1. 核心配置文件 (application.yml)

在实际的业务场景中，我们必须精细控制ACK应答级别以防丢消息，以及关闭自动提交改为手动提交。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

spring:
  kafka:
    bootstrap-servers: 127.0.0.1:9092        # Kafka 集群地址，多个用逗号隔开
    
    # ==================== 1. 生产者配置 ====================
    producer:
      retries: 3                             # 消息发送失败后的重试次数
      acks: all                              # 应答级别。all(或-1) 代表所有副本都同步完才算成功，最安全
      batch-size: 16384                      # 批量发送大小 (16KB)，提升吞吐量
      buffer-memory: 33554432                # 生产端本地缓冲区大小 (32MB)
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.apache.kafka.common.serialization.StringSerializer
      
    # ==================== 2. 消费者配置 ====================
    consumer:
      group-id: ecommerce-order-group       # 默认消费组 ID
      enable-auto-commit: false              # 关闭自动提交！推荐手动提交，防止业务代码报错时消息丢失
      auto-offset-reset: earliest            # 当各分区没有初始偏移量时的策略：earliest/latest
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      max-poll-records: 500                  # 单次 poll 轮询最大拉取条数
      
    # ==================== 3. 监听Container配置 ====================
    listener:
      # 手动立即提交偏移量。配合 enable-auto-commit: false 使用。
      # 业务代码正常执行完后，Spring 会自动帮你调用 commitSync()
      ack-mode: manual_immediate             
      concurrency: 3                         # 消费者并发度。建议设置为和你 Topic 的 Partition（分区）数量一致，充分利用多线程并行消费

三、 核心代码使用示例

1. 生产者：发送消息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

@RestController
@RequestMapping("/order")
public class OrderController {

    @Autowired
    private KafkaTemplate<String, String> kafkaTemplate;

    @GetMapping("/create")
    public String createOrder() {
        String orderJson = "{\"orderId\": 10023, \"amount\": 299.00}";
        
        // 异步发送消息
        CompletableFuture<SendResult<String, String>> future = kafkaTemplate.send("order-topic", orderJson);
        
        // 绑定发送结果回调（非阻塞）
        future.whenComplete((result, ex) -> {
            if (ex == null) {
                System.out.println("消息发送成功，偏移量为：" + result.getRecordMetadata().offset());
            } else {
                System.err.println("消息发送失败：" + ex.getMessage());
            }
        });

        return "Order processing...";
    }
}

1. 消费者：监听并手动确认（Ack）

当你在上面配置了 ack-mode: manual_immediate，你的消费方法里可以引入 Acknowledgment 对象。当业务代码顺利跑完，调用 ack.acknowledge() 告诉 Kafka：“这条消息我吃下了，你可以推进 Offset 了”。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

@Component
public class OrderConsumer {

    // concurrency = "3" 表示启动 3 个线程同时消费，对应 yml 中的全局配置，也可以在这里局部覆盖
    @KafkaListener(topics = "order-topic", groupId = "ecommerce-order-group", concurrency = "3")
    public void onMessage(ConsumerRecord<String, String> record, Acknowledgment ack) {
        try {
            // 1. 收到消息，打印日志
            System.out.printf("线程 %s 收到消息 -> 分区: %d, 消息体: %s%n", 
                    Thread.currentThread().getName(), record.partition(), record.value());
            
            // 2. 执行你的电商核心业务逻辑（如：扣减库存、发送通知等）
            // doYourBusiness(record.value());

            // 3. 业务成功，手动提交
            ack.acknowledge(); 
        } catch (Exception e) {
            // 4. 业务异常，这里千万别 ack！可以流转到死信队列（DLQ）或者触发重试机制
            System.err.println("消费异常，暂不提交偏移量: " + e.getMessage());
        }
    }
}

最近正式开始使用Claude Code/Codex/Gemini CLI+CC-Switch+API的Agent Coding的方式构建项目。之前是直接用Copilot和Trae这种跟IDE结合更紧密,也提供了编辑文件,浏览目录以及测试命令的功能，但Claude Code明显提供了更好的体验以及更先进的AI编程工程范式。
这里做一些实战总结,主要是Claude Code使用上。

Claude Code是什么

Claude Code 是一个代理编码工具，可以读取你的代码库、编辑文件、运行命令，并与你的开发工具集成。可在终端、IDE、桌面应用和浏览器中使用。Claude Code 是一个由 AI 驱动的编码助手，可帮助你构建功能、修复错误和自动化开发任务。它理解你的整个代码库，可以跨多个文件和工具工作以完成任务。

考虑到国内充值付费问题,使用方式可参考国内丝滑落地 Claude Code/Codex Agent 编程的硬核指南.使用第三方中转站

如何工作

通过Agent循环工作,而这个循环中包含模型推理和工具调用。ClaudeCode提供工具、上下文管理以及执行环境。

模型

执行引擎。在会话期间使用 /model 切换或使用 claude --model <name> 启动。

工具

没有工具，Claude 只能用文本回应。有了工具，Claude 可以采取行动：读取您的代码、编辑文件、运行命令、搜索网络并与外部服务交互.

内置工具通常分为五个类别，每个类别代表不同类型的代理能力。

工具调用时机本质还是利用模型根据提示和沿途学到的内容选择使用哪些。

可以使用 skills 扩展 Claude 知道的内容、使用 MCP 连接到外部服务、使用 hooks 自动化工作流，以及将任务卸载给 subagents。

平台集成

本身可以直接在终端运行，也可以跟VS Code,JetBrains IDEs 结合

事实上，可以通过终端、桌面应用、IDE 扩展、claude.ai/code、远程控制、Slack 和 CI/CD 管道访问 Claude Code。

claude配置主要是两个地方,一个是用户目录,另一个是项目目录

扩展Claude

使用 CLAUDE.md 文件为 Claude 提供持久指令，并让 Claude 通过自动记忆功能自动积累学习内容。

每个 Claude Code 会话都从一个全新的上下文窗口开始。两种机制可以跨会话传递知识：

• CLAUDE.md 文件：你编写的指令，为 Claude 提供持久上下文Claude 如何记住你的项目 - Claude Code Docs
• 自动记忆：Claude 根据你的更正和偏好自己编写的笔记

Claude Code 读取 CLAUDE.md，而不是 AGENTS.md。如果你的存储库已经为其他编码代理使用 AGENTS.md，创建一个导入它的 CLAUDE.md

1. 加载时机。在每个会话开始时加载到上下文窗口中。CLAUDE.md 文件无论长度如何都完整加载。
2. 语法规则。通过@引用，每个 CLAUDE.md 文件目标在 200 行以下；编写具体到足以验证的指令；模块化加载。

自动记忆让 Claude 跨会话积累知识，无需你编写任何内容。Claude 在工作时为自己保存笔记：构建命令、调试见解、架构笔记、代码样式偏好和工作流习惯。Claude 不会每个会话都保存内容。它根据信息在未来对话中是否有用来决定什么值得记住。

本质是存储在~/.claude/projects/<project>/memory/的各种文件,比如

1
2
3
4
5

~/.claude/projects/<project>/memory/
├── MEMORY.md          # 简洁索引，加载到每个会话
├── debugging.md       # 关于调试模式的详细笔记
├── api-conventions.md # API 设计决策
└── ...                # Claude 创建的任何其他主题文件

MEMORY.md 的前 200 行或前 25KB（以先到者为准）在每次对话开始时加载。超过该阈值的内容在会话开始时不加载。Claude 在你的会话中读取和写入记忆文件。当你在 Claude Code 界面中看到”Writing memory”或”Recalled memory”时，Claude 正在主动更新或读取 ~/.claude/projects/<project>/memory/。

.claude目录

Claude Code 读取 CLAUDE.md、settings.json、hooks、skills、commands、subagents、rules 和自动内存的位置。

.claude目录包括个人的~/.claude以及项目的.claude.~/.claude 中的文件是个人配置，适用于所有项目。

上下文窗口与prompt caching

运行 /context 以获取按类别的实时分解和优化建议。运行 /memory 以检查在启动时加载了哪些 CLAUDE.md 和自动内存文件。探索上下文窗口查看一个上下文的组成

既然每次跟模型的对话都会重发一些内容, 有哪些方式可以优化以节约成本呢。目前常用的技术还是prompt caching和/compact裁剪

每次在 Claude Code 中发送消息时，它都会发出新的 API 请求。模型在请求之间不记得任何东西，所以 Claude Code 重新发送完整的上下文：系统提示、您的项目上下文、每条先前的消息和工具结果，以及您的新消息。新内容附加在末尾，这意味着每个请求的大部分与前一个请求相同。Prompt caching 是 API 避免重新处理未更改部分的方式。

为了充分利用前缀匹配，Claude Code 组织每个请求，使回合之间很少更改的内容首先出现：

权限模式

每种模式在便利性和监督之间做出不同的权衡。

在会话期间：按 Shift+Tab 循环切换 default → acceptEdits → plan。当前模式显示在状态栏中。并非每种模式都在默认循环中：

• auto：当您的账户满足 auto mode 要求时出现；循环到 auto 会显示一个选择加入提示，直到您接受它，或选择不，不再询问以从循环中移除 auto
• bypassPermissions：在您使用 --permission-mode bypassPermissions、--dangerously-skip-permissions 或 --allow-dangerously-skip-permissions 启动后出现；--allow- 变体将模式添加到循环中而不激活它
• dontAsk：永远不会出现在循环中；使用 --permission-mode dontAsk 设置它

会话管理

会话是与项目目录关联的已保存对话。Claude Code 在您工作时将其本地存储，因此您可以从中断处恢复、分支以尝试不同的方法，或在任务之间切换。每次在一个项目目录启动claude都视为一次独立的会话,在~/.claude/projects/下有不同项目下的若干个会话。

对于会话,可以进行恢复,命名,分支会话,导出以及管理会话内的上下文.

恢复会话通过/resume进行选择,命名通过/rename,管理上下文通过\clear清除以及/compact压缩

实操

扩展能力

1. 创建commands,在项目中.claude/commands下创建*.md文件

Claude Code 里的 slash commands 大致分四类：

• Built-in commands：Claude Code 自带的命令，如 /help、/clear、/model
• Skills 形式的命令：通过 SKILL.md 定义，仍然可以用 /name 调用
• Plugin commands：安装 plugin 后带来的命令
• MCP prompts：由 MCP server 暴露出来的命令

*.md文件中包含内容,frontmatter 包含描述,允许的工具等,此外还有工作流程。

1. 更改memory

包括CLAUDE.md和自动内存.

CLAUDE.md包含内容如下。可以通过/init常见,/memory查看或编辑

• 哪些目录最重要
• 哪些规则最容易被忽略
• 提交前必须做什么
• 哪些工具是本项目默认用法
• 哪些文件不要乱动
• 测试和验证的最低标准

3.skiils

skill可以理解成：

• 一个带 frontmatter 的 SKILL.md
• 可附带脚本、模板、参考资料
• 会被 Claude 自动发现和按需加载
• 更适合长期复用的工作流能力

skill基本结构

1
2
3
4
5

skill-name/
├── SKILL.md
├── templates/
├── scripts/
└── references/

SKILL.md负责

• 定义 skill 名称
• 说明 skill 在什么情况下应该触发

• 告诉 Claude 该怎么做

• templates/：输出模板

• scripts/：辅助脚本
• references/：参考规则或背景知识

4.subagents

subagents 是 Claude Code 里做复杂任务拆分的关键能力。你可以把它理解成“主 Claude 把某个子任务交给一个更专业、上下文更独立的助手去做”。

subagent 具备这些特点：

• 有自己的角色定位
• 有自己的上下文窗口
• 可以限制可用工具
• 可以使用单独的 system prompt
• 适合做任务拆分和专业分工

subagent 文件通常是：

1. YAML frontmatter
2. 后面跟 Markdown 形式的 system prompt

1
2
3
4
5
6

---
name: code-reviewer
description: Review recent changes for quality issues
tools: Read, Grep, Glob, Bash
model: inherit
---

• subagents：主 Claude 委派一个边界清晰的子任务，等它把结果带回来
• Agent Teams：多个 Claude Code 实例协作，彼此有独立上下文窗口，还能直接通信

本质上是分配一个新角色,它有独立的上下文,职责不同,执行完后能返回结果。

5.mcp使用

如果没有 MCP，Claude 只能基于你提供的上下文回答。
有了 MCP，它可以：

• 获取实时数据
• 调用外部工具
• 访问项目外的信息源
• 把结果带回当前工作流

MCP 常见应用场景

• GitHub PR / issue 查询
• 数据库读写
• 文件系统访问
• Slack / Docs / 其他 SaaS 工具集成

在.mcp.json中配置

1
2
3
4
5
6
7
8
9
10
11

{
  "mcpServers": {
    "database": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-database"],
      "env": {
        "DATABASE_URL": "postgresql://user:pass@localhost/mydb"
      }
    }
  }
}

6.hooks

hooks 是 Claude Code 的“事件触发自动化”机制。它允许你在某些时机自动做点事情，例如：

• 调工具前先检查风险
• 写完文件后自动格式化
• 提交前跑测试
• 结束前记录日志或上下文

可以把 hook 理解成一条规则：

1. 某个事件发生
2. 匹配某个工具或场景
3. 自动执行一个动作

这些动作可以是：

• shell command
• HTTP webhook
• prompt 型判断
• agent 型评估

hooks 最大的价值，是把“你本来每次都要手动做的检查”变成自动流程。

配置位置

• ~/.claude/settings.json：用户级，对所有项目生效
• .claude/settings.json：项目级，适合团队共享
• .claude/settings.local.json：本地项目配置，不建议提交
• plugin 内的 hooks/hooks.json

一般结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "hooks": {
    "EventName": [
      {
        "matcher": "ToolPattern",
        "hooks": [
          {
            "type": "command",
            "command": "your-command-here",
            "timeout": 60
          }
        ]
      }
    ]
  }
}

hooks有匹配工具,类型,执行的命令等

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

"hooks": {
   "SessionStart": [
     {
       "matcher": "startup",
       "hooks": [
         {
           "type": "command",
           "command": "python .claude/hooks/session-start.py",
           "timeout": 30
         }
       ]
     },
     {
       "matcher": "clear",
       "hooks": [
         {
           "type": "command",
           "command": "python .claude/hooks/session-start.py",
           "timeout": 30
         }
       ]
     },
     {
       "matcher": "compact",
       "hooks": [
         {
           "type": "command",
           "command": "python .claude/hooks/session-start.py",
           "timeout": 30
         }
       ]
     }
   ],
   "PreToolUse": [
     {
       "matcher": "Task",
       "hooks": [
         {
           "type": "command",
           "command": "python .claude/hooks/inject-subagent-context.py",
           "timeout": 30
         }
       ]
     },
     {
       "matcher": "Agent",
       "hooks": [
         {
           "type": "command",
           "command": "python .claude/hooks/inject-subagent-context.py",
           "timeout": 30
         }
       ]
     }
   ],
   "UserPromptSubmit": [
     {
       "hooks": [
         {
           "type": "command",
           "command": "python .claude/hooks/inject-workflow-state.py",
           "timeout": 15
         }
       ]
     }
   ]
 },

7.plugins

anthropics/claude-plugins-official

plugin 通常会组合这些内容：

• commands
• skills
• subagents
• hooks
• .mcp.json
• 辅助脚本与模板

所以它特别适合：

• 团队统一工作流
• 跨项目复用
• 把一套最佳实践做成可分发单元

plugin配置如下

1
2
3
4
5
6
7
8
9
10
11

my-plugin/
├── .claude-plugin/
│   └── plugin.json
├── commands/
├── agents/
├── skills/
├── hooks/
├── .mcp.json
├── scripts/
├── templates/
└── docs/

8.checkpoints

可以把 checkpoint 理解成当前会话状态的快照，通常包括：

• 对话消息
• 文件改动
• 工具使用历史
• 会话上下文

当你需要回退时，就使用 rewind 返回到某个 checkpoint。Claude Code 会自动创建 checkpoints，所以你不需要手动先“存档”才能用。

常见有这些：

1. Restore code and conversation：代码和对话都回退
2. Restore conversation：只回退对话
3. Restore code：只回退代码
4. Summarize from here：从这一点开始压缩总结，释放上下文窗口
5. Never mind：取消

1
2
3
4

先让 Claude 改
→ 如果结果好，继续
→ 如果不满意，/rewind
→ 换一种实现路线

这在这些任务里尤其好用：

• UI 重构
• API 重构
• auth / permission 变更
• 大批量文档整理

9.高级功能

权限模式

通过--dangerously-skip-permissions切换到bypassPermissions,可以通过shift+tab切换,也可以通过claude --permission-mode plan.也可以通过\config配置。

claude -p输出模式适合shell脚本以及CI/CD等人物。此外还有后台任务\background让耗时任务后台跑，不阻塞当前会话.

10.CLI功能

CLI 常见会和这些配置一起使用：

• --model
• --fallback-model
• --effort
• --settings
• --append-system-prompt

示例：

1
2
3

claude --model opus "design a caching strategy"
claude -p --fallback-model sonnet "summarize this diff"
claude --append-system-prompt "Always explain tradeoffs" "review this plan"

工具与权限相关 flags

• --permission-mode
• --dangerously-skip-permissions
• --allowedTools
• --disallowedTools
• --tools

学习资料

1. Claude Code: A Highly Agentic Coding Assistant - DeepLearning.AI
2. Spec-Driven Development with Coding Agents - DeepLearning.AI
3. lhfer/claude-howto-zh-cn: Claude Code 中文全面上手指南。基于 luongnv89/claude-howto 本土化重写，面向中国小白用户，保留命令与配置兼容性，并附学习路径与本地化校验护栏。
4. Claude Code 权限配置 | 菜鸟教程
5. Claude Code Docs
6. Trellis 技术分享资料：大模型科普与 AI Coding 框架 | Koi’s Blog
7. 让 Claude Code 在你睡觉时持续运行：完整实战指南 · 唐巧的博客
8. claude->/powerup

介绍一些网络协议,主要内容来自极客时间趣谈网络协议.

直播中用到的协议

直播主要是视频,本质可以看作图片流。假设30帧的视频，像素1024*768，每个像素由RGB组成，每个8位，共24位。一秒钟的数据量30帧 × 1024 × 768 × 24 = 566,231,040Bits = 70,778,880Bytes达到4个G.

因此需要通过压缩或者说编解码减少数据传输，既然压缩，就要规定编解码协议

频流中的图片进行压缩，因为视频和图片有这样一些特点。

1. 空间冗余：图像的相邻像素之间有较强的相关性，一张图片相邻像素往往是渐变的，不是突变的，没必要每个像素都完整地保存，可以隔几个保存一个，中间的用算法计算出来。
2. 时间冗余：视频序列的相邻图像之间内容相似。一个视频中连续出现的图片也不是突变的，可以根据已有的图片进行预测和推断。
3. 视觉冗余：人的视觉系统对某些细节不敏感，因此不会每一个细节都注意到，可以允许丢失一些数据。
4. 编码冗余：不同像素值出现的概率不同，概率高的用的字节少，概率低的用的字节多，类似霍夫曼编码（Huffman Coding）的思路。

视频编码流派

流媒体协议名称如下

• 名词系列一：AVI、MPEG、RMVB、MP4、MOV、FLV、WebM、WMV、ASF、MKV。 视频封装格式
• 名词系列二：H.261、 H.262、H.263、H.264、H.265。 视频编码格式

• 名词系列三：MPEG-1、MPEG-2、MPEG-4、MPEG-7。 MPEG指定的标准

• 流派一：ITU（International Telecommunications Union）的VCEG（Video Coding Experts Group），这个称为国际电联下的VCEG。既然是电信，可想而知，他们最初做视频编码，主要侧重传输。名词系列二，就是这个组织制定的标准。

• 流派二：ISO（International Standards Organization）的MPEG（Moving Picture Experts Group），这个是ISO旗下的MPEG，本来是做视频存储的。例如，编码后保存在VCD和DVD中。当然后来也慢慢侧重视频传输了。名词系列三，就是这个组织制定的标准。

后来，ITU-T（国际电信联盟电信标准化部门，ITU Telecommunication Standardization Sector）与MPEG联合制定了H.264/MPEG-4 AVC

视频文件介绍

简单来说，一个视频文件是由“集装箱（封装格式）”和包装在里面的“货物（编码格式）”共同组成的

视频文件后缀名（如 .mp4、.mkv、.avi、.mov），在技术上被称为封装格式（Container Format）。

• 它的本质：它就像一个集装箱或文件夹。
• 它的作用：负责把视频轨道（只有画面）、音频轨道（只有声音）、字幕轨道以及视频的发布时间、导演等元数据（Metadata）打包、同步并粘合在一起，变成一个独立的文件。

常见的封装格式

MP4：目前最流行的封装格式，兼容性最强。无论是手机、电脑、电视、网页、汽车中控，几乎 100% 都能完美播放。

MKV：它的特点是容纳能力极强，一个文件里可以塞进好几种语言的音轨、十几国语言的特效字幕，电影高清爱好者最喜欢它。

MOV：苹果公司（Apple）开发的集装箱，苹果生态和专业影视剪辑（如 ProRes 编码）的常用格式。

AVI ：微软（Microsoft）推出的一种封装格式。

视频封装格式（也就是视频文件集装箱/后缀名）

它们不负责压缩画面，只负责把视频（画面）、音频（声音）\和*字幕打包组合成一个文件。这 10 个格式记录了从 1990 年代 PC 刚兴起，到如今移动互联网、网页高清视频的整个多媒体进化史*。

阵营一：现代全能霸主（目前最主流）

1. MP4 (.mp4) —— 地表最强兼容性

• 背景：由顶级组织 MPEG 推出（技术学名 MPEG-4 Part 14）。
• 特点：没有任何缺点就是它最大的优点。它完美平衡了文件体积、画质和网络流媒体传输。
• 现状：绝对的统治者。不管是苹果、安卓、Windows、电视、网页还是车载系统，100% 完美支持，网络上 90% 的视频都是它。

1. MKV (.mkv) —— 高清电影收藏家

• 背景：著名的开源开放封装格式（Matroska）。
• 特点：号称“万能集装箱”。它最大的本事是“极能塞”。一个 MKV 文件里可以塞进好几条不同语言的音轨（国语、粤语、英语）、十几国语言的特效字幕，并且支持最新的高性能编码。
• 现状：电影发烧友、动漫高清资源、PT 下载的最爱。

阵营二：互联网流媒体阵营（为了在线看视频而生）

1. FLV (.flv) —— 网页网页视频的青春

• 背景：Adobe 公司当年为了配合 Flash 播放器推出的格式。
• 特点：体积小、加载快。在那个网络很慢的时代，它实现了“不需要下载完，点开就能在线看”的功能。
• 现状：随着网页端 Flash 插件被历史彻底淘汰，FLV 已经退出了舞台，但在直播领域（如 HTTP-FLV 协议）仍有部分残留。

1. WebM (.webm) —— 现代网页与动图杀手

• 背景：由 Google 牵头主导的开源免专利费网页视频格式。
• 特点：天生为了现代 HTML5 网页而生。它可以用极小的体积实现超高清画质，并且完美支持动态透明通道（Alpha Channel）。
• 现状：现在网页上的高画质动态表情包（取代低清 GIF）、网页背景短视频，大多是 .webm 格式。

阵营三：老牌操作系统巨头（当年的门户之见）

1. MOV (.mov) —— 苹果生态的基石

• 背景：苹果公司（Apple） 开发的专用多媒体格式。
• 特点：结构设计极其先进（后来的 MP4 就是参考 MOV 的架构制定的）。它能完美容纳影视工业级的高码率无损/半无损编码（如 Apple ProRes）。
• 现状：iPhone 录制高质量视频、专业影视后期剪辑、Mac 生态的首选。

1. WMV (.wmv) —— 微软早期的视频王牌

• 背景：微软（Microsoft） 专门为了和苹果 MOV、以及 Real 竞争推出的网络流媒体格式。
• 特点：在 Windows 系统上拥有极高的兼容性，压缩率在当年很优秀，保护版权的 DRM 机制很严。
• 现状：基本属于历史遗产，现在的微软自己也全面倒向了 MP4。

1. ASF (.asf) —— WMV 的底层外壳

• 背景：微软推出的高级流格式（Advanced Systems Format）。
• 特点：严格来说，ASF 是集装箱，而 WMV 是里面的货物。ASF 是微软为了在网络上传输音视频而设计的。
• 现状：极为少见，偶尔在早期的网络直播或老旧微软系统中能看到。

阵营四：历史的眼泪（基本已被淘汰）

1. AVI (.avi) —— 1990年代的原生巨兽

• 背景：微软在 1992 年（Windows 3.1 时代）推出的极其古老的格式。
• 特点：架构太老。它不支持流媒体点播（必须全部下载完才能播放）、不支持特效字幕、不支持动态帧率。
• 现状：已经彻底落伍。现在除了某些特殊行业的老设备、行车记录仪外，基本见不到了。

1. RMVB / RM (.rmvb) —— 中国互联网初期的“盗版电影之王”

• 背景：RealNetworks 公司推出的格式。
• 特点：那个用电话线拨号上网、网速只有几百 KB 的时代，RMVB 靠着惊人的压缩率实现了“小体积、能看清”。它统治了当年的电影下载网站（如各种影音先锋、天天动听时代）。
• 现状：由于它闭源、收费，且随着网速变快、高清时代来临，其画质上限不足的缺点暴露无遗，如今已彻底绝迹。

阵营五：行业最高法院

1. MPEG (.mpg / .mpeg) —— 国际标准的鼻祖

• 背景：ISO 国际标准组织（MPEG 组织）制定的初代官方格式。
• 特点：它是 VCD（MPEG-1） 和 DVD（MPEG-2） 光盘时代的底层封装格式。
• 现状：作为独立的文件后缀已经很少见，但它的家族后代（MPEG-4 也就是 MP4）正在统治世界。

常见编码格式

为什么要编码？：未经压缩的原始视频极其恐怖。一部 1080P、2小时的原始电影可能高达 几百GB 甚至上万GB，互联网根本无法传输。为了能让大家在网上流畅看视频，必须对画面进行极限压缩。

H.264 ：它是一套极其经典的视频压缩算法标准（又称 AVC）。它能把巨无霸一样的原始视频，在保证肉眼看不出明显画质损失的前提下，压缩掉 90% 以上的体积。

H.265 (HEVC)：H.264 的升级版。它的压缩效率翻倍，在同等画质下，体积只有 H.264 的一半。现在的 4K 高清电影、iPhone 的高效率录像基本都在使用它，缺点是对播放设备的 CPU 解码性能要求更高。

AV1：一种全新的、开源免专利费的下一代编码格式，各大互联网巨头（谷歌、奈飞、微软等）正在全力推广，各大新显卡也已经全面支持硬件解码。

1. H.261（1988年）—— 视频压缩的“开山鼻祖”

• 诞生背景：当时互联网还没普及，大家通信靠的是昂贵且带宽极低的 ISDN 电话线。
• 核心突破：它是人类历史上第一个流媒体视频压缩标准。它首次确立了现代视频压缩的核心框架：混合编码架构（将画面切成 $16 \times 16$ 的“宏块”，并引入了帧内预测和运动补偿）。直到今天的 H.265，依然在沿用这一套核心思想。
• 应用场景：最早期的早期电视电话会议。它的分辨率低得可怜（只有 $352 \times 288$），但在当时能看到会动的真人画面，已经是科技奇迹了。

1. H.262（1994年）—— 广播电视与 DVD 的功臣

• 诞生背景：单纯的电视会议标准满足不了人们对高质量电影、电视节目的渴望。于是 ITU-T 与 ISO 组织联手，将该技术同时命名为 MPEG-2 Part 2。
• 核心突破：首次支持隔行扫描（Interlaced Video）和多声道音频，大幅度提升了高动态画面（如体育比赛）的清晰度。
• 应用场景：统治了整个 DVD 光盘时代。直到今天，全球各国的无线数字电视、有线电视广播，底层依然有很大一部分在用 H.262/MPEG-2 进行传输。

1. H.263（1996年）—— 早期移动网络与视频通话的先驱

• 背景与突破：专为低码率（低带宽）的网络环境深度优化。它改进了运动补偿算法，让视频在极烂、极卡的网络下，也能勉强保持连贯，不至于满屏马赛克。

• 应用场景：它是 3G 时代手机视频通话（如 3GPP 规范）的绝对主力，也是早期 Flash 视频（FLV 格式）、早期的腾讯 QQ 视频聊天、

  3GP 格式手机视频背后的压缩功臣。

1. H.264 / AVC（2003年）—— 统治世界的“格式之王”

• 核心突破：技术跨代升级，同样命名为 MPEG-4 Part 10 (AVC)。相比 H.263，它的压缩效率直接翻倍。它引入了更精细的像素运动估计、多帧参考和更高级的熵编码。
• 应用场景：它彻底开启了现代互联网视频时代。 如今你手机录的视频、B站/YouTube/抖音上的短视频、网络高清直播、蓝光光盘（Blu-ray），超过 80% 依然在用 H.264。它的硬件解码芯片已经做到了所有手机、电脑、电视的底层，播放它最省电、最流畅。

1. H.265 / HEVC（2013年）—— 超高清 4K/8K 的基石

• 核心突破：同样命名为 MPEG-H Part 2 (HEVC)。面对 4K/8K 时代动辄数十 GB 的体积，H.265 将传统的 $16 \times 16$ 宏块升级为了最大 $64 \times 64$ 的 CTU（编码树单元）。
• 惊人效果：在画质完全一样的前提下，体积比 H.264 再缩减 50%！
• 应用场景：现代智能手机（如 iPhone 的“高效格式”）、4K/8K 超高清电影、各大视频网站的“极清 4K”档位。

H.265 极其优秀，但因为它的专利授权费极其昂贵且混乱，导致谷歌、奈飞、亚马逊等互联网巨头非常不满。

于是，业界在 H.265 之后分化出了两条路：

1. 官方正统续作：ITU 组织在 2020 年推出了 H.266 (VVC)，压缩率比 H.265 再提升 50%，专为未来 8K 和 VR 视频准备。
2. 开源免费联盟：巨头们联合搞出了 AV1 编码，完全免专利费，压缩率看齐甚至超越 H.265。目前 B站、YouTube、Netflix 正在疯狂把后台视频转码为 AV1。

网络协议将编码好的视频流，从主播端推送到服务器，在服务器上有个运行了同样协议的服务端来接收这些网络包，从而得到里面的视频流，这个过程称为接流。

服务端接到视频流之后，可以对视频流进行一定的处理，例如转码，也即从一个编码格式，转成另一种格式。因为观众使用的客户端千差万别，要保证他们都能看到直播。

流处理完毕之后，就可以等待观众的客户端来请求这些视频流。观众的客户端请求的过程称为拉流。

如果有非常多的观众，同时看一个视频直播，那都从一个服务器上拉流，压力太大了，因而需要一个视频的分发网络，将视频预先加载到就近的边缘节点，这样大部分观众看的视频，是从边缘节点拉取的，就能降低服务器的压力。

所以整个直播流程,就可分为主播端采样编码推流,服务器接流处理分发，观众客户端拉流解码播放。

编码流程

视频序列分成三种帧。

• I帧，也称关键帧。里面是完整的图片，只需要本帧数据，就可以完成解码。
• P帧，前向预测编码帧。P帧表示的是这一帧跟之前的一个关键帧（或P帧）的差别，解码时需要用之前缓存的画面，叠加上和本帧定义的差别，生成最终画面。
• B帧，双向预测内插编码帧。B帧记录的是本帧与前后帧的差别。要解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的数据与本帧数据的叠加，取得最终的画面。

I 帧（Intra-coded picture，帧内编码帧）

• 别名：关键帧（Keyframe）。
• 特点：它是一张完整的、独立的图片，类似于一张高质量的 JPEG 照片。
• 压缩方式：只进行“帧内压缩”（只去除一张图片内部的冗余信息），不依赖任何其他画面。
• 作用：它是视频序列的“锚点”。当你在播放器里拖动进度条快进时，播放器必须先找到最近的 I 帧才能开始解码渲染。

P 帧（Predictive-coded picture，前向预测编码帧）

• 别名：差别帧。
• 特点：它不记录完整的图片，而只记录自己与前一个 I 帧（或前一个 P 帧）的“差异”和运动矢量。
• 压缩方式：帧间压缩（向前参考）。
• 作用：由于大多数视频相邻两帧的画面变化很小（比如只有人在动，背景没动），P 帧通过只存储变化的部分，数据量通常只有 I 帧的 1/2 到 1/4，大大节省了空间。

B 帧（Bidirectionally predictive-coded picture，双向预测编码帧）

• 别名：双向参考帧。
• 特点：它是压缩率最高的帧。它不仅参考前面已经出现的画面，还要参考后面即将出现的画面，通过两头对比，计算出自己的画面。
• 压缩方式：帧间压缩（双向参考）。
• 作用：B 帧只记录极少的运动变化信息，数据量极小，通常只有 I 帧的 1/10 左右。

I帧最完整，B帧压缩率最高，而压缩后帧的序列，应该是在IBBP的间隔出现的。这就是通过时序进行编码。

在一帧中，分成多个片，每个片中分成多个宏块，每个宏块分成多个子块，这样将一张大的图分解成一个个小块，可以方便进行空间上的编码。尽管时空非常立体地组成了一个序列，但是总归还是要压缩成一个二进制流。这个流是有结构的，是一个个的网络提取层单元（NALU，Network Abstraction Layer Unit）。变成这种格式就是为了传输，因为网络上的传输，默认的是一个个的包，因而这里也就分成了一个个的单元。

每一个NALU首先是一个起始标识符，用于标识NALU之间的间隔；然后是NALU的头，里面主要配置了NALU的类型；最终Payload里面是NALU承载的数据。

在NALU头里面，主要的内容是类型NAL Type。

• 0x07表示SPS，是序列参数集， 包括一个图像序列的所有信息，如图像尺寸、视频格式等。
• 0x08表示PPS，是图像参数集，包括一个图像的所有分片的所有相关信息，包括图像类型、序列号等

在传输视频流之前，必须要传输这两类参数，不然无法解码。为了保证容错性，每一个I帧前面，都会传一遍这两个参数集合。

如果NALU Header里面的表示类型是SPS或者PPS，则Payload中就是真正的参数集的内容。

如果类型是帧，则Payload中才是正的视频数据，当然也是一帧一帧存放的，前面说了，一帧的内容还是挺多的，因而每一个NALU里面保存的是一片。对于每一片，到底是I帧，还是P帧，还是B帧，在片结构里面也有个Header，这里面有个类型，然后是片的内容。

这样，整个格式就出来了，一个视频，可以拆分成一系列的帧，每一帧拆分成一系列的片，每一片都放在一个NALU里面，NALU之间都是通过特殊的起始标识符分隔，在每一个I帧的第一片前面，要插入单独保存SPS和PPS的NALU，最终形成一个长长的NALU序列。

推流流程

使用RTMP协议推送网络包。RTMP是基于TCP的，因而肯定需要双方建立一个TCP的连接。在有TCP的连接的基础上，还需要建立一个RTMP的连接，也即在程序里面，你需要调用RTMP类库的Connect函数，显示创建一个连接。

RTMP也需要先简历连接,协商本版号和时间戳等信息。

客户端发送C0、C1、 C2，服务器发送S0、 S1、 S2。

首先，客户端发送C0表示自己的版本号，不必等对方的回复，然后发送C1表示自己的时间戳。

服务器只有在收到C0的时候，才能返回S0，表明自己的版本号，如果版本不匹配，可以断开连接。

服务器发送完S0后，也不用等什么，就直接发送自己的时间戳S1。客户端收到S1的时候，发一个知道了对方时间戳的ACK C2。同理服务器收到C1的时候，发一个知道了对方时间戳的ACK S2。于是，握手完成。

握手之后，双方需要互相传递一些控制信息，例如Chunk块的大小、窗口大小等。

真正传输数据的时候，还是需要创建一个流Stream，然后通过这个Stream来推流publish。推流的过程，就是将NALU放在Message里面发送，这个也称为RTMP Packet包。Message的格式就像这样。

发送的时候，去掉NALU的起始标识符。RTMP在收发数据的时候并不是以Message为单位的，而是把Message拆分成Chunk发送，而且必须在一个Chunk发送完成之后，才能开始发送下一个Chunk。每个Chunk中都带有Message ID，表示属于哪个Message，接收端也会按照这个ID将Chunk组装成Message。

连接的时候，设置的Chunk块大小就是指这个Chunk。将大的消息变为小的块再发送，可以在低带宽的情况下，减少网络拥塞。

假设一个视频的消息长度为307，但是Chunk大小约定为128，于是会拆分为三个Chunk。

第一个Chunk的Type＝0，表示Chunk头是完整的；头里面Timestamp为1000，总长度Length 为307，类型为9，是个视频，Stream ID为12346，正文部分承担128个字节的Data。

第二个Chunk也要发送128个字节，Chunk头由于和第一个Chunk一样，因此采用Chunk Type＝3，表示头一样就不再发送了。

第三个Chunk要发送的Data的长度为307-128-128=51个字节，还是采用Type＝3。

拉流流程

看直播的观众就可以通过RTMP协议从流媒体服务器上拉取，但是这么多的用户量，都去同一个地方拉取，服务器压力会很大，而且用户分布在全国甚至全球，如果都去统一的一个地方下载，也会时延比较长，需要有分发网络。

分发网络分为中心和边缘两层。边缘层服务器部署在全国各地及横跨各大运营商里，和用户距离很近。中心层是流媒体服务集群，负责内容的转发。智能负载均衡系统，根据用户的地理位置信息，就近选择边缘服务器，为用户提供推/拉流服务。中心层也负责转码服务，例如，把RTMP协议的码流转换为HLS码流。

类似地,客户端拉流被，客户端通过RTMP协议拉取，然后组合为NALU，解码成视频格式进行播放。

P2P协议

无论是HTTP的方式，还是FTP的方式，都有一个比较大的缺点，就是难以解决单一服务器的带宽压力， 因为它们使用的都是传统的客户端服务器的方式。

后来，一种创新的、称为P2P的方式流行起来。P2P就是peer-to-peer。资源开始并不集中地存储在某些设备上，而是分散地存储在多台设备上。这些设备我们姑且称为peer。

想要下载一个文件的时候，你只要得到那些已经存在了文件的peer，并和这些peer之间，建立点对点的连接，而不需要到中心服务器上，就可以就近下载文件。一旦下载了文件，你也就成为peer中的一员，你旁边的那些机器，也可能会选择从你这里下载文件，所以当你使用P2P软件的时候，例如BitTorrent，往往能够看到，既有下载流量，也有上传的流量，也即你自己也加入了这个P2P的网络，自己从别人那里下载，同时也提供给其他人下载。可以想象，这种方式，参与的人越多，下载速度越快。

通过.torrent文件,也就是种子,知道文件信息。.torrent文件由两部分组成，分别是：announce（tracker URL）和文件信息。

文件信息里面有这些内容。

• info区：这里指定的是该种子有几个文件、文件有多长、目录结构，以及目录和文件的名字。
• Name字段：指定顶层目录名字。
• 每个段的大小：BitTorrent（简称BT）协议把一个文件分成很多个小段，然后分段下载。
• 段哈希值：将整个种子中，每个段的SHA-1哈希值拼在一起。

下载时，BT客户端首先解析.torrent文件，得到tracker地址，然后连接tracker服务器。tracker服务器回应下载者的请求，将其他下载者（包括发布者）的IP提供给下载者。下载者再连接其他下载者，根据.torrent文件，两者分别对方告知自己已经有的块，然后交换对方没有的数据。此时不需要其他服务器参与，并分散了单个线路上的数据流量，因此减轻了服务器的负担。

下载者每得到一个块，需要算出下载块的Hash验证码，并与.torrent文件中的对比。如果一样，则说明块正确，不一样则需要重新下载这个块。这种规定是为了解决下载内容的准确性问题。

这种方式特别依赖tracker。tracker需要收集下载者信息的服务器，并将此信息提供给其他下载者，使下载者们相互连接起来，传输数据。虽然下载的过程是非中心化的，但是加入这个P2P网络的时候，都需要借助tracker中心服务器，这个服务器是用来登记有哪些用户在请求哪些资源。

所以，这种工作方式有一个弊端，一旦tracker服务器出现故障或者线路遭到屏蔽，BT工具就无法正常工作了。

DHT去中心化网络

后来就有了一种叫作DHT（Distributed Hash Table）的去中心化网络。每个加入这个DHT网络的人，都要负责存储这个网络里的资源信息和其他成员的联系信息，相当于所有人一起构成了一个庞大的分布式存储数据库。

有一种著名的DHT协议，叫Kademlia协议。

任何一个BitTorrent启动之后，它都有两个角色。一个是peer，监听一个TCP端口，用来上传和下载文件，这个角色表明，我这里有某个文件。另一个角色DHT node，监听一个UDP的端口，通过这个角色，这个节点加入了一个DHT的网络。在DHT网络里面，每一个DHT node都有一个ID。这个ID是一个很长的串。每个DHT node都有责任掌握一些知识，也就是文件索引，也即它应该知道某些文件是保存在哪些节点上。它只需要有这些知识就可以了，而它自己本身不一定就是保存这个文件的节点。

数据中心

数据中心里面是服务器。服务器被放在一个个叫作机架（Rack）的架子上面。数据中心的入口和出口也是路由器，由于在数据中心的边界，就像在一个国家的边境，称为边界路由器（Border Router）。为了高可用，边界路由器会有多个。

一般家里只会连接一个运营商的网络，而为了高可用，为了当一个运营商出问题的时候，还可以通过另外一个运营商来提供服务，所以数据中心的边界路由器会连接多个运营商网络。

数据中心里面往往有非常多的机器，当塞满一机架的时候，需要有交换机将这些服务器连接起来，可以互相通信。这些交换机往往是放在机架顶端的，所以经常称为TOR（Top Of Rack）交换机。

当一个机架放不下的时候，就需要多个机架，还需要有交换机将多个机架连接在一起。这些交换机对性能的要求更高，带宽也更大。这些交换机称为汇聚层交换机（Aggregation Layer）。

数据中心里面的每一个连接都是需要考虑高可用的。这里首先要考虑的是，如果一台机器只有一个网卡，上面连着一个网线，接入到TOR交换机上。如果网卡坏了，或者不小心网线掉了，机器就上不去了。所以，需要至少两个网卡、两个网线插到TOR交换机上，但是两个网卡要工作得像一张网卡一样，这就是常说的网卡绑定（bond）。

这就需要服务器和交换机都支持一种协议LACP（Link Aggregation Control Protocol）。它们互相通信，将多个网卡聚合称为一个网卡，多个网线聚合成一个网线，在网线之间可以进行负载均衡，也可以为了高可用作准备。

网卡有了高可用保证，但交换机还有问题。如果一个机架只有一个交换机，它挂了，那整个机架都不能上网了。因而TOR交换机也需要高可用，同理接入层和汇聚层的连接也需要高可用性，也不能单线连着

最传统的方法是，部署两个接入交换机、两个汇聚交换机。服务器和两个接入交换机都连接，接入交换机和两个汇聚都连接，当然这样会形成环，所以需要启用STP协议，去除环，但是这样两个汇聚就只能一主一备了。

另一种方法是，将多个交换机形成一个逻辑的交换机，服务器通过多根线分配连到多个接入层交换机上，而接入层交换机多根线分别连接到多个交换机上，并且通过堆叠的私有协议，形成双活的连接方式。

汇聚层将大量的计算节点相互连接在一起，形成一个集群。在这个集群里面，服务器之间通过二层互通，这个区域常称为一个POD（Point Of Delivery），有时候也称为一个可用区（Available Zone）。

当节点数目再多的时候，一个可用区放不下，需要将多个可用区连在一起，连接多个可用区的交换机称为核心交换机。

VPN

有的公司有多个数据中心，需要将多个数据中心连接起来，或者需要办公室和数据中心连接起来。这该怎么办呢？

• 第一种方式是走公网，但是公网太不安全，你的隐私可能会被别人偷窥。
• 第二种方式是租用专线的方式把它们连起来，这是土豪的做法，需要花很多钱。
• 第三种方式是用VPN来连接，这种方法比较折中，安全又不贵。

VPN，全名Virtual Private Network，虚拟专用网，就是利用开放的公众网络，建立专用数据传输通道，将远程的分支机构、移动办公人员等连接起来。

VPN工作方式

VPN通过隧道技术在公众网络上仿真一条点到点的专线，是通过利用一种协议来传输另外一种协议的技术，这里面涉及三种协议：乘客协议、隧道协议和承载协议。

IPsec VPN。这是基于IP协议的安全隧道协议，为了保证在公网上面信息的安全，因而采取了一定的机制保证安全性。

• 机制一：私密性，防止信息泄露给未经授权的个人，通过加密把数据从明文变成无法读懂的密文，从而确保数据的私密性。 前面讲HTTPS的时候，说过加密可以分为对称加密和非对称加密。对称加密速度快一些。而VPN一旦建立，需要传输大量数据，因而我们采取对称加密。但是同样，对称加密还是存在加密密钥如何传输的问题，这里需要用到因特网密钥交换（IKE，Internet Key Exchange）协议。
• 机制二：完整性，数据没有被非法篡改，通过对数据进行hash运算，产生类似于指纹的数据摘要，以保证数据的完整性。
• 机制三：真实性，数据确实是由特定的对端发出，通过身份认证可以保证数据的真实性。

有了IPsec VPN之后，客户端发送的明文的IP包，都会被加上ESP头和IP头，在公网上传输，由于加密，可以保证不被窃取，到了对端后，去掉ESP的头，进行解密。

C++的一些概念复杂而且存在一些容易使用错误的地方,这里进行部分总结.

基础

const关键字

const 是一个关键字，用于表示常量。

const 可以用于修饰变量、函数、指针等：

1.修饰常量

当 const 修饰变量时，该变量将被视为只读变量，即不能被修改。

对于确定不会被修改的变量，应该加上 const，这样可以保证变量的值不会被无意中修改，也可以使编译器在代码优化时更加智能。

但理论上也可以赋给const int*再进行类型转换修改,

1
2
3
4
5
6
7
8
9
10
11

#include<iostream>
using namespace std;

int main() {
    const int num = 10;
    const int* cp = &num;
    int* p = const_cast<int*>(cp);
    *p = 20;
    cout<<num;
    return 0;
}

但编译器可能会进行优化,替换为实际值。因此应该遵循 C/C++ 语言中 const 的语义，尽量不修改只读变量的值。

2.const修饰函数参数

当 const 修饰函数参数时，表示函数内部不会修改该参数的值。这样做可以使代码更加安全，避免在函数内部无意中修改传入的参数值。

3.修饰函数返回值

当 const 修饰函数返回值时，表示函数的返回值为只读，不能被修改。这样做可以使函数返回的值更加安全，避免被误修改。

4.修饰指针或引用

const 关键字可以用来修饰指针，用于声明指针本身为只读变量或者指向只读变量的指针。

4.1指向只读变量的指针

4.2只读指针

4.3只读指针指向只读变量

const 关键字同时修饰了指针本身和指针所指向的变量，使得指针本身和所指向的变量都成为只读变量。因此，指针本身不能被修改，也不能通过指针修改所指向的变量。

4.4常量引用

常量引用是指引用一个只读变量的引用，因此不能通过常量引用修改变量的值。

5.修饰成员函数

当 const 修饰成员函数时，表示该函数不会修改对象的状态（就是不会修改成员变量）。const 的对象就可以调用这些成员方法了，因为 const 对象不允许调用非 const 的成员方法。

const 的成员函数不能调用非 const 的成员函数，原因在于 const 的成员函数保证了不修改对象状态，但是如果调用了非 const 成员函数，那么这个保证可能会被破坏。

static关键字

可以用于变量和函数

1.static修饰全局变量

static 修饰全局变量可以将变量的作用域限定在当前文件中，使得其他文件无法访问该变量。
同时，static 修饰的全局变量在程序启动时被初始化（可以简单理解为在执行 main 函数之前，会执行一个全局的初始化函数，在那里会执行全局变量的初始化），生命周期和程序一样长。

2.static修饰局部变量

static 修饰局部变量可以使得变量在函数调用结束后不会被销毁，而是一直存在于内存中，下次调用该函数时可以继续使用。

由于 static 修饰的局部变量的作用域仅限于函数内部，所以其他函数无法访问该变量

3.static修饰函数

static 修饰函数可以将函数的作用域限定在当前文件中，使得其他文件无法访问该函数。

由于 static 修饰的函数只能在当前文件中被调用，因此可以避免命名冲突和代码重复定义

4.static修饰类成员变量和函数

static 修饰类成员变量和函数可以使得它们在所有类对象中共享，且不需要创建对象就可以直接访问。

volatile关键字

volatile是 C 语言中的一个关键字，用于修饰变量，表示该变量的值可能在任何时候被外部因素更改，例如硬件设备、操作系统或其他线程。

当一个变量被声明为volatile时，编译器会禁止对该变量进行优化，以确保每次访问变量时都会从内存中读取其值，而不是从寄存器或缓存中读取，避免因为编译器优化而导致出现不符合预期的结果。

即便是volatile关键字可以确保编译器不对变量进行优化，但上面任然存在并发问题，counter++操作仍然可能导致数据不一致。

为了解决这个问题，需要使用互斥锁、原子操作或其他同步机制。

字节对齐

字节对齐是内存分配的一种策略。当分配内存时，编译器会自动调整数据结构的内存布局，使得数据成员的起始地址与其自然对齐边界（一般为自己大小的倍数）相匹配

理论上，任何类型的变量都可以从任意地址开始存放。然而实际上，访问特定类型的变量通常需要从特定对齐的内存地址开始。因为如果不对数据存储进行适当的对齐，可能会导致存取效率降低

各种数据类型需要按照一定的规则在内存中排列（起始地址），而不是顺序地一个接一个排放，这种排列就是字节对齐。例如，有些平台每次读取都是从偶数地址开始。如果一个 int 类型（假设为 32 位系统）存储在偶数地址开始的位置，那么一个读周期就可以读取这 32 位。

但如果存储在奇数地址开始的位置，则需要两个读周期，并将两次读取的结果的高低字节拼凑才能得到这 32 位数据,显然这会显著降低读取效率。

为了避免性能损耗，编译器会遵循一个基本原则：变量的内存起始地址，必须是该变量自身大小的整数倍

总结： 字节对齐有助于提高内存访问速度，因为许多处理器都优化了对齐数据的访问。但是，这可能会导致内存中的一些空间浪费。

字节对齐规则

1. 自然对齐边界

对于基本数据类型，其自然对齐边界通常为其大小。

例如，char 类型的自然对齐边界为 1 字节，short 为 2 字节，int 和 float 为 4 字节，double 和 64 位指针为 8 字节。具体数值可能因编译器和平台而异。

2. 结构体对齐

结构体内部的每个成员都根据其自然对齐边界进行对齐,也就是可能在成员之间插入填充字节。

结构体本身的总大小也会根据其最大对齐边界的成员进行对齐（比如结构体成员包含的最长类型为int类型，那么整个结构体要按照4的倍数对齐），以便在数组中正确对齐。

3.联合体对齐

联合体的对齐边界取决于其最大对齐边界的成员。联合体的大小等于其最大大小的成员，因为联合体的所有成员共享相同的内存空间。

4.编译器指令

可以使用编译器指令（如 #pragma pack）更改默认的对齐规则。这个命令是全局生效的。这可以用于减小数据结构的大小，但可能会降低访问性能。

5.对齐属性

在 C++11 及更高版本中，可以使用 alignas 关键字为数据结构或变量指定对齐要求。这个命令是对某个类型或者对象生效的。例如，alignas(16) int x; 将确保 x 的地址是 16 的倍数

6.动态内存分配

大多数内存分配函数（如 malloc 和 new）会自动分配足够对齐的内存，以满足任何数据类型的对齐要求。

字节序

字节序是指在多字节数据类型（如整数、浮点数等）中，字节在内存中的存储顺序。主要有两种字节序：大端字节序（Big-endian）和小端字节序（Little-endian）

大端字节序: 高位字节存储在低地址处，低位字节存储在高地址处。例如，一个4字节的整数0x12345678，在大端字节序的系统中，

小端字节序: 低位字节存储在低地址处，高位字节存储在高地址处。

常见大小端字节序

1. 网络传输

在网络传输过程中，通常使用大端字节序（Big-endian），也称为网络字节序，这是 TCP/IP 协议的规定，多字节数据在网络上传输时使用大端字节序。

因此，如果本地系统使用的是小端字节序，那么就需要在传输之前将其转换为大端字节序。一般通过使用htonl()、htons()、ntohl()和ntohs()等函数来完成

2. Linux

Linux 操作系统在不同的硬件平台上可能使用不同的字节序。例如，x86 和 x86_64（Intel 和 AMD 处理器）是小端字节序（Little-endian），而 PowerPC 和 SPARC 等其他架构可能使用大端字节序（Big-endian）。

所以具体的字节序取决于运行 Linux 的硬件平台。

3. Windows

Windows 操作系统主要运行在 x86 和 x86_64（Intel 和 AMD处理器）架构上，这些处理器使用小端字节序（Little-endian）。

4. Mac

一般使用 Intel 处理器或 Apple 自家的 M1 芯片（基于ARM架构），这些处理器都采用小端字节序（Little-endian）

class类和struct结构体差别

在 C++ 中，class（类）和 struct（结构体）的底层实现和核心能力几乎完全相同。

C++ 的 struct 继承自 C 语言，但进行了全面魔改——在 C++ 里，struct 同样可以拥有构造函数、析构函数、成员函数、虚函数，并且支持继承和多态。

差别:

1. 默认的访问权限（最核心区别）

• struct 的成员默认是公有的（public）。
• class 的成员默认是私有的（private）。

1. 默认的继承权限

当一个类继承自另一个类/结构体且没有显式指定继承方式时：

• struct 默认是公有继承（public）。
• class 默认是私有继承（private）

1. 模板参数中的微小差别（template）

在声明泛型模板时，你可以使用 class 或 typename，但不能使用 struct

适合用 struct 的场景：

当你需要定义一个“纯粹的数据集合”，它只包含一堆变量，没有复杂的业务逻辑和封装保护（类似 C 语言的结构体或 DTO / POJO）时，用 struct。

特征：成员全是 public，通常没有或只有简单的构造函数。

在 C++11 及之后的标准中，POD 类型需要同时满足两个独立条件：

1.平凡（Trivial）：类型具有默认的构造/拷贝/移动/析构函数（可自动生成且非虚）
2.标准布局（Standard Layout）：内存布局与 C 兼容，成员排列顺序符合特定规则

同时满足平凡性和标准布局的类型称为 POD 类型，这类数据可以安全使用 memcpy 等底层内存操作，因为它们的内存布局与 C 完全兼容且没有特殊处理需求。

适合用 class 的场景：

当你的对象具有复杂的内部状态、需要隐藏实现细节、对外提供特定接口（面向对象的核心思想）时，用 class。

特征：包含 private 内部变量，对外暴露 public 的方法（如 Getter/Setter、业务函数），有严格的封装性。

宏定义和内联函数的区别

宏定义（#define）和内联函数（inline）都是为了减少函数调用开销和提高代码运行效率而引入的机制，但是它们的实现方式和作用机制略有不同。

#define本质是文字替换,在编译之前，预处理器（Preprocessor）会扫描你的代码。看到 MAX(a, b)，它就机械地把这一行字擦掉，换成后面的三目运算符表达式。编译器在编译时，根本不知道 MAX 这个名字的存在，它看到的已经是替换后的臃肿表达式了。

写宏函数一定要注意：参数和函数体应当用括号包围，避免因运算优先级导致的错误

inline 声明的函数是一个真正的函数。

• 编译器在编译它时，会进行语法分析、类型检查、模板特化。
• 当遇到调用处时，编译器会根据当前上下文的优化策略，自主决定要不要把它“内联展开”。
• 特别注意：inline 对编译器来说只是一个建议（Suggestion），而不是强制命令。如果你的内联函数内部写了复杂的循环、递归，或者代码量巨大，编译器会理智地拒绝内联，依然把它当做普通函数来调用。

函数内联展开本质减少了函数调用压栈,跳转,出栈等成本.针对本身非常简短的函数内联减少调用成本.

内联展开遵循空间换时间的原则。每一次展开，都会让最终生成的二进制可执行文件（.exe 或 .so）体积变大。

• 如果不内联：函数在内存中只有一份拷贝。哪怕被调用 1000 次，也只是跳过去执行那同一段代码，程序体积很小。
• 如果强制内联：被调用 1000 次，这段代码就会在不同的地方被完整复制 1000 遍。

在现代 C++（C++11 及更新标准）中，为了安全和可维护性，我们应当尽量避免使用 #define 来定义常量和函数逻辑。

• 需要定义常量时：用 const 或 constexpr 代替 #define。
• 需要定义简短的高频函数时：用 inline（或者类的内联成员函数）代替 #define。
• 什么场景下还必须用 #define？：只有在需要用到条件编译（如 #ifndef _DEBUG）或者宏拼接符号（如 # 和 ## 进行动态变量名/日志打印生成）时，才是 #define 不可替代的舞台。

define和typedef区别

预处理器只进行简单的文本替换，不涉及类型检查。与宏定义不同，typedef 是在编译阶段处理的，有更严格的类型检查。

宏定义没有作用域限制，只要在宏定义之后的地方，就可以使用宏。

通常用于定义常量、简单的表达式或简单的代码片段。

typedef 遵循 C++ 的作用域规则，可以受到命名空间、类等结构的作用域限制。typedef 通常用于定义复杂类型的别名，使代码更易读和易于维护

宏定义不支持模板，因此不能用于定义模板类型别名。

typedef 可以与模板结合使用，但在 C++11 之后，推荐使用 using 关键字定义模板类型别名。

1
2
3
4
5
6
7
8
9
10
11

// 使用 typedef 定义模板类型别名
template <typename T>
struct MyContainer {
    typedef std::vector<T> Type;
};

// 使用 using 定义模板类型别名（C++11 及以后）
template <typename T>
struct MyContainer {
    using Type = std::vector<T>;
};

explicit关键字

explicit 通常用于构造函数的声明中，用于防止隐式转换

当将一个参数传递给构造函数时，如果构造函数声明中使用了 explicit 关键字，则只能使用显式转换进行转换，而不能进行隐式转换。这种机制可以防止编译器自动执行预期外的类型转换，提高代码的安全性。

隐式类型转换：当你只有一个类型T1，但是当前表达式需要类型为T2的值，如果这时候T1自动转换为了T2，那么这就是隐式类型转换。

可以使用 explicit 关键字可以防止不必要的隐式转换，提高代码的可读性和安全性。

尤其是构造函数参数只有一种类型的，强烈建议加上 explicit

extern作用

一般而言，C++全局变量的作用范围仅限于当前的文件，但同时C++也支持分离式编译，允许将程序分割为若干个文件被独立编译,于是就需要在文件间共享变量数据，这里extern就发挥了作用。

extern 用于指示变量或函数的定义在另一个源文件中，并在当前源文件中声明。
说明该符号具有外部链接(external linkage)属性。

也就是告诉编译器: 这个符号在别处定义了，你先编译，到时候链接器会去别的地方找这个符号定义的地址。

凡是没有带extern的声明同时也都是定义。
而对函数而言，带有{}是定义，否则是声明。如果想声明一个变量而非定义它，就在变量名前添加关键字extern，且不要显式的初始化变量。

链接属性

在 C++ 中，链接属性是指程序在编译、链接和执行阶段如何处理符号（变量、函数、类等)的可见性和重复定义。

外部链接: 外部链接的符号可以在不同的源文件之间共享，并且在整个程序执行期间可见。全局变量和函数都具有外部链接。

内部链接: 内部链接的符号只能在当前源文件内部使用，不能被其他源文件访问。用 static 修饰的全局变量和函数具有内部链接

无链接的符号只能在当前代码块（函数或代码块）内部使用，不能被其他函数或代码块访问。用 const 或 constexpr 修饰的常量具有无链接属性（ 通常情况下编译器是不会为const对象分配内存，也就无法链接）。

外部 C 链接的符号与外部链接类似，可以在不同的源文件之间共享，并且在整个程序执行期间可见。它们具有 C 语言的名称和调用约定，可以与 C 语言编写的代码进行交互。在 C++ 中，可以用 extern "C" 关键字来指定外部 C 链接，从而使用一些 C 的静态库。

这些链接属性可以通过关键字 extern、static、const 和 extern "C" 来显式地指定。在实际的开发中，正确地理解和处理链接属性对于编写可重用、高效、可维护的代码非常重要

编译链接过程中，extern 的作用如下：

1. 在编译期，extern 用于告诉编译器某个变量或函数的定义在其他源文件中，编译器会为它生成一个符号表项，并在当前源文件中建立一个对该符号的引用。

这个引用是一个未定义的符号，编译器在后续的链接过程中会在其他源文件中查找这个符号的定义。

1. 在链接期，链接器将多个目标文件合并成一个可执行文件，并且在当前源文件中声明的符号，会在其它源文件中找到对应的定义，并将它们链接起来

extern C

如果不用 extern C，由于 C++ 和 C 语言在编译和链接时使用的命名规则不同，这会导致 C++ 代码无法调用 C 语言编写的函数或变量（链接时找不到符号）

函数命名规则

由于需要支持重载,一个函数的链接名（Linkage Name）是由函数的名称、参数类型和返回值类型等信息组成的，用于在编译和链接时唯一标识该函数。函数的链接名的生成规则在不同的编译器和操作系统上可能有所不同，一般是由编译器自动处理，不需要手动指定，这个规则常常叫做Name Mangling

常见的规则：

• Microsoft Visual C++ 编译器（Windows）：函数的名称会被编译器修改为一个以 “?” 开头的名称，并加上参数类型和返回值类型等信息，以避免链接冲突。例如，函数 int add(int a, int b) 的链接名可能是 ?add@@YAHHH@Z。
• GCC 编译器（Linux）：也会加上参数类型和返回值类型等信息。例如，函数 int add(int a, int b) 的链接名可能是 _Z3addii。
• Clang 编译器（MacOS）：函数的链接名的生成规则与 GCC 编译器类似，但稍有不同。例如，函数 int add(int a, int b) 的链接名可能是 _Z3addii。

而 C 语言的链接函数名规则又和 上面三个 C++ 不一样，通过在 C++ 代码中使用 extern "C" 关键字，可以将 C++ 编译器的命名规则转换为 C 语言的命名规则，从而使得 C++ 代码可以调用 C 语言的函数或变量。

Name Mangling（名称修饰 / 改名机制）是编译器在编译源代码时，将变量、函数或方法的原始名称，转化为包含更多上下文信息的“独特新名称”的技术。

使用 extern "C" 声明的函数或变量会采用 C 语言的链接规则，即符号的名称和调用约定与 C 语言相同。

需要注意 extern "C" 关键字只对函数的名称和调用约定起作用，对于函数的参数类型和返回值类型没有影响。所以，在使用 extern "C" 声明函数时，需要保证函数的参数类型和返回值类型与 C 语言的定义相同，否则可能会导致编译错误或运行时错误。

mutable作用

mutable是C++中的一个关键字，用于修饰类的成员变量，表示该成员变量即使在一个const成员函数中也可以被修改。因为在C++中，如果一个成员函数被声明为const，那么它不能修改类的任何成员变量，除非这个成员变量被声明为mutable。

如果需要在const函数里面修改一些跟类状态无关的数据成员，那么这个函数中对应的成员就应该被mutable来修饰。允许在const成员函数中修改特定的成员变量，以支持内部实现所需的功能，同时仍然保持外部不变性。

四种强制类型转换

在 C++ 中，更推荐使用四个转换操作符来实现显式类型转换：

• static_cast
• dynamic_cast
• const_cast
• reinterpret_cast

static_cast

1. 静态(编译期检查),将一个基本类型转为另一个基本类型
2. 指针类型之间转换.将一个指针类型转换为另一个指针类型，尤其是在类层次结构中从基类指针转换为派生类指针。这种转换不执行运行时类型检查，可能不安全，要自己保证指针确实可以互相转换。
3. 引用类型之间的转换

static_cast在编译时执行类型转换，在进行指针或引用类型转换时，需要自己保证合法性。

如果想要运行时类型检查，可以使用dynamic_cast进行安全的向下类型转换。

dynamic_cast

dynamic_cast在C++中主要应用于父子类层次结构中的安全类型转换。它在运行时执行类型检查，因此相比于static_cast，它更加安全。

dynamic_cast在C++中主要应用于父子类层次结构中的安全类型转换。

它在运行时执行类型检查，因此相比于static_cast，它更加安全。

C++ 的 RTTI 信息是存放在虚函数表（vtable）里的。如果基类没有虚函数，它就不会生成虚函数表，dynamic_cast 也就失去了赖以生存的底层数据，编译器会直接报错。

面向对象

多态

C++中的多态是指同一个函数或者操作在不同的对象上有不同的表现形式。

C++实现多态的方法主要包括虚函数、纯虚函数和模板函数

其中虚函数、纯虚函数实现的多态叫动态多态，模板函数、重载等实现的叫静态多态。

区分静态多态和动态多态的一个方法就是看决定所调用的具体方法是在编译期还是运行时，运行时就叫动态多态。

虚函数、纯虚函数实现多态

在 C++ 中，可以使用虚函数来实现多态性。

虚函数是指在基类中声明的函数，它在派生类中可以被重写。

当我们使用基类指针或引用指向派生类对象时，通过虚函数的机制，可以调用到派生类中重写的函数，从而实现多态。

C++ 的多态必须满足两个条件：

• 必须通过基类的指针或者引用调用虚函数
• 被调用的函数是虚函数，且必须完成对基类虚函数的重写

虚函数表

虚函数是通过一张虚函数表（Virtual Table）来实现的，简称为V-Table。在这个表中，存放的是一个类的虚函数的地址表，这张表解决了继承、覆盖的问题，保证其真实反应实际的函数。

这个类的实例内存中都有一个虚函数表的指针，所以，当用父类的指针来操作一个子类的时候，这张虚函数表就显得由为重要了，它就像一个地图一样，指明了实际所应该调用的函数。

在底层，当一个类声明一个虚函数时，编译器会为该类创建一个虚函数表（Virtual Table）。
这个表存储着该类的虚函数指针，这些指针指向实际实现该虚函数的代码地址。

每个对象都包含一个指向该类的虚函数表的指针，这个指针在对象创建时被初始化，通常是作为对象的第一个成员变量。

当调用一个虚函数时，编译器会通过对象的虚函数指针查找到该对象所属的类的虚函数表，并根据函数的索引值（通常是函数在表中的位置，编译时就能确定）来找到对应的虚函数地址。

然后将控制转移到该地址，实际执行该函数的代码。对于派生类，其虚函数表通常是在基类的虚函数表的基础上扩展而来的。在派生类中，如果重写了基类的虚函数，那么该函数在派生类的虚函数表中的地址会被更新为指向派生类中实际实现该函数的代码地址。

C++的动态多态必须满足两个条件：

• 必须通过基类的指针或者引用调用虚函数
• 被调用的函数是虚函数，且必须完成对基类虚函数的重写

其中第一条很重要，当我们使用派生类的指针去访问/调用虚函数时，实际上并未发生动态多态，因为编译时就能确定对象类型为派生类型，然后直接生成调用派生类虚函数的代码即可，这种叫做静态绑定。通过基类的指针或引用调用虚函数才能构成多态，因为这种情况下运行时才能确定对象的实际类型，这种称为动态绑定

纯虚函数

纯虚函数是一种在基类中声明但没有实现的虚函数。

它的作用是定义了一种接口，这个接口需要由派生类来实现。

包含纯虚函数的类称为抽象类（Abstract Class）。抽象类仅仅提供了一些接口，但是没有实现具体的功能。作用就是制定各种接口，通过派生类来实现不同的功能，从而实现代码的复用和可扩展性。

另外，抽象类无法实例化，也就是无法创建对象。原因很简单，纯虚函数没有函数体，不是完整的函数，无法调用，也无法为其分配内存空间。

虚函数使用了一种称为虚函数表（vtable）的机制。然而，在调用构造函数时，对象还没有完全创建和初始化，所以虚函数表可能尚未设置。

这意味着在构造函数中使用虚函数表会导致未定义的行为。只有执行完了对象的构造，虚函数表才会被正确的初始化。

内存管理

RAII

资源获取即初始化（Resource Acquisition Is Initialization，简称 RAII）是一种 C++ 编程技术，它将在使用前获取（分配的堆内存、执行线程、打开的套接字、打开的文件、锁定的互斥量、磁盘空间、数据库连接等有限资源）的资源的生命周期与某个对象的生命周期绑定在一起。

确保在控制对象的生命周期结束时，按照资源获取的相反顺序释放所有资源。

同样，如果资源获取失败（构造函数退出并带有异常），则按照初始化的相反顺序释放所有已完全构造的成员和基类子对象所获取的资源。

这利用了核心语言特性（对象生命周期、作用域退出、初始化顺序和堆栈展开），以消除资源泄漏并确保异常安全。

在实际的 C/C++ 开发中，我们经常会遇到诸如 coredump、segmentfault 之类的内存问题，使用指针也会出现各种问题，比如:

• 野指针：未初始化或已经被释放的指针被称为野指针
• 空指针：指向空地址的指针被称为空指针
• 内存泄漏：如果在使用完动态分配的内存后忘记释放，就会造成内存泄漏，长时间运行的程序可能会消耗大量内存。
• 悬空指针：指向已经释放的内存的指针被称为悬空指针
• 内存泄漏和悬空指针的混合：在一些情况下，由于内存泄漏和悬空指针共同存在，程序可能会出现异常行为。

智能指针是一种可以自动管理内存的指针，它可以在不需要手动释放内存的情况下，确保对象被正确地销毁。

这种指针可以显著降低程序中的内存泄漏和悬空指针的风险。

在C++中，智能指针常用的主要是两个类实现：

• std::unique_ptr
• std::shared_ptr

智能指针是一种可以自动管理内存的指针，它可以在不需要手动释放内存的情况下，确保对象被正确地销毁。这种指针可以显著降低程序中的内存泄漏和悬空指针的风险。

std::unique_ptr是一个独占所有权的智能指针，它保证指向的内存只能由一个unique_ptr拥有，不能共享所有权。

当unique_ptr超出作用域时，它所指向的内存会自动释放。

1
2
3
4
5
6
7
8
9

#include <memory>
#include <iostream>

int main() {
    std::unique_ptr<int> ptr(new int(10));
    std::cout << *ptr << std::endl; // 输出10
    // unique_ptr在超出作用域时自动释放所拥有的内存
    return 0;
}

std::shared_ptr是一个共享所有权的智能指针，它允许多个shared_ptr指向同一个对象，当最后一个shared_ptr超出作用域时，所指向的内存才会被自动释放。

举个栗子：

1
2
3
4
5
6
7
8
9
10

#include <memory>
#include <iostream>

int main() {
    std::shared_ptr<int> ptr1(new int(10));
    std::shared_ptr<int> ptr2 = ptr1; // 通过拷贝构造函数创建一个新的shared_ptr，此时引用计数为2
    std::cout << *ptr1 << " " << *ptr2 << std::endl; // 输出10 10
    // ptr2超出作用域时，所指向的内存不会被释放，因为此时ptr1仍然持有对该内存的引用
    return 0;
}

总的来说，智能指针可以提高程序的安全性和可靠性，避免内存泄漏和悬空指针等问题。

但需要注意的是，智能指针不是万能的，也并不是一定要使用的，有些场景下手动管理内存可能更为合适

参考资料

1. 一文搞懂 C/C++ 面试重点知识和常见面试题（2025 年更新） | 编程指北-计算机学习指南

搜集到了关于现代即时通讯(IM)系统中一些设计方案，作为分布式集群应用的集大成者，这里进行总结学习。这些资料基本来自52im.net。在此感谢站长和作者们。

零基础入门

IM其实并不局限于聊天、社交这类“典型”应用中，实际上它已经广泛运用于我们身边形形色色的软件中。

聊天、直播、在线客服、物联网等所有需要实时互动、高实时性的场景等等，都需要应用到 IM 技术。

• 1）微信、qq、钉钉等主流IM应用：这是IM技术的典型应用场景；
• 2）微博、知乎等社区应用：它们利用IM技术实现了用户私信等点对点聊天；
• 3）抖音、快手等直播/短视频应用：它们利用IM技术实现了与主播的实时互动；
• 4）米家等智能家居物联网应用：利用IM技术实现实时控制、远程监控等；
• 5）滴滴、Uber等共享家通类应用：利用IM技术实现位置共享；
• 6）在线教育类应用：利用IM技术实现在线白板。

即时消息技术剖析与实战

IM技术特点

1）实时性：

对于IM系统，“实时”二字是精髓，也是这项技术存在关键意义所在。它保证的是消息的实时触达。

举个例子：如果跟你的好友微信或qq聊天，我发的消息他不能即时收到，或者他发的信息你也不知道什么时候能收到，这基本上也就没法聊下去了

2）可靠性：

保证消息的不丢失和不重复，是IM系统的另一个关键技术特点。试想，当你在用qq或微信跟女朋友聊天，好不容易鼓起勇气向“她”表白，结果这消息要是丢包了，那肯定得卸载应用了，搞不好砸手机都有可能。当然，好话不说二遍，消息重复也同样恼人。

3）一致性：

对于单聊消息而言，保证同一个设备的时间顺序、不同设备的漫游同步，也是相当重要的一环。

IM系统中的消息交互，就到底就是人跟人在“说话”，前言不搭理后言、或者胡言乱语式的消息展现，那不是人疯了就是程序疯了，总之就是没法再聊下去了。

4）安全性：

保证数据传输安全、数据存储安全、消息内容安全，也是IM系统必不可少的特性。尤其在私聊场景下，如果不能做到安全性，聊天的体验跟被人偷窥的感觉是没有区别的。

IM功能组成

一个典型的IM功能组成，无非就是以下5样：

• 1）联系人列表；
• 2）聊天界面；
• 3）消息发送通道；
• 4）消息接收通道；
• 5）消息存储；
• 6）消息未读数。

联系人列表看似简单，实际上它是一系列IM系统的社交关系确立动作的结果体现。

要想建立联系人列表，你可能需要实现以下逻辑：

• 1）怎么能找到想要聊天的人？（需要实现随机查找？精确查找？）
• 2）怎么决定要不要跟这个人聊？（需要实现对方的个人信息查看）
• 3）开始发出好友请求；
• 4）被请求的一方，还可以决定是“同意”还是“拒绝”（“同意”该怎么处理？“拒绝”又该怎么处理？）。

聊天界面看似很平常，实际它就是IM系统客户端的核心功能所在，所有主要的IM功能都是通过它展现。

它应该具备的能力有：

• 1）各种聊天功能按钮：语音留言、图片、文字、表情、文件、实时电话、实时视频等；
• 2）各种聊天消息显示：各种消息都有不同的UI显示元素和处理逻辑；
• 3）流畅的使用体验：大量不同类型的消息显示时，不能卡顿；
• 4）即时显示聊天消息：网络线程收到的消息，要马上在UI上显示出来；
• 5）历史消息的加载：上次聊过的内容也得显示出来吧。

消息发送通道

• 1）如何保证这条socket长连接时一直处于可用的状态？
• 2）当socket长连接不可用时，用户此时发送的消息该怎么处理？
• 3）怎么保证发送的消息不丢？
• 4）怎么保证发送的消息不重复？
• 5）怎么保证发送的消息乱序？
• 6）当对方不在线时，发送的消息去哪了？
• 7）发送的消息，能保证实时送到？

消息接收通道：

要实现一个可靠的消息接收通道，也并非易事：

• 1）如何保证socket长连接通道能随时处于良好的连接状态（随时接收对方write的消息）；
• 2）当socket长连接断开时，对方发送消息该怎么实现？
• 3）当socket恢复连接时，怎么恢复之前的聊天现场？
• 4）当我收到对方的消息时，对方怎么知道我已经收到了？
• 5）当重复收到对方的消息时，该怎么处理？

• 6）当收到的消息时序有错乱，该怎么处理？

  5）消息存储：\

消息存储这个功能好理解，聊天的消息如果存储，下次再聊的时候就不知道之前聊过什么，做不到这一点，这个IM系统的聊天体验好不起来。

那么，哪些情况下需要进行消息存储呢：

• 1）对方不在线时：聊天消息应该存储（这叫离线消息存储）；
• 2）对方在线时：聊天消息也要存到本地存储（这叫消息缓存）；
• 3）对方在线或不在线时：聊天消息都要存到服务端（用于实现多设备的消息漫游和同步）。

但技术落到实处，要做的事情同样少不了：

• 1）离线消息该怎么多久？
• 2）图片、短视频、大文件这类的离线消息，多媒体文件该怎么存（有可能量会很大）？
• 3）当本地的消息积累太多时，怎么能保证本地存储的性能？
• 4）当应用更新、升级或异常时，怎么能保证本地存储的完整性（不被破坏）？
• 5）怎么能保证多设备消息能不丢、不重、不乱？

消息未读数

1）未读数是客户端实现还是服务端实现？

2）会话未读和总未读怎么保持一致？

3）多终端情况下，怎么保证未读数的一致性（我在这台设备上读没读，那台设备怎么知道的？

IM聊天的实时性

短轮询技术

在“短轮询”模式下，IM客户端定时轮询服务端，以便让用户知道是否有新的聊天消息存在。

这种模式下，服务端收到请求后，即刻查询是否存在新消息，有就返回给客户端，没有则返回空并立即关闭连接。相较于前面用户需要“手动”去刷新页面的方式，这种模式只是将用户的“手动”变为“自动”而已，技术本质并没有发生任何实质性改变。

短轮询这种模式，就好比旧时代一个等待重要邮件的人，他需要每天自已跑到邮局，主动去问是否有自己的信件，有就拿回家，如果没有，则第二天继续去问。一来一去，非常低效。

长轮询技术

技术上来说，长轮询实现的IM相较于短轮询最大的改进在于：短轮询情况下，服务端不管有没有新消息，请求结束就会立即断开连接。而长轮询时，如果本次请求没有新消息发生，不会马上断开连接并返回，而是会将本次连接“挂起”一段时间，如果在这段“挂起”时间内有新的聊天消息出现，就能马上读取并立即返回给客户端，接着结束本次连接。一段时间后又会再次发起请求，如此周而复始。

长轮询这种模式，拿上节等待邮件的这个例子来说，就好比收信的人每天到邮局去问是否有信件，如果没有，他不马上回家，而是在邮局待上一段时间，如果这段时间过去了，还是没有，就先回家，接着第二天再来。

长轮询的优点是：

• 1）相较于短连询，一定程度降低了服务端请求负载；
• 2）相较于短连询，实时性有提升，因为它是主动“等”消息。

长轮询的缺点是：

• 1）长论询模式下，连接“挂起”的这段时间内，服务端需要配合开启单独的消息查询线程，仍然存在无用功；
• 2）相较于短连询模式，在一次长轮询结束、下次轮询发起前的窗口期内，仍然存在“实时性”盲区。

实际上，在Web端即时通讯技术里，长轮询有个专业的术语叫“Comet”，

在每次轮询结束和下次轮询开始的间隔期会形成“实时性盲区”。要理解纠结轮询技术的实时性缺陷，就得了解它们背后的技术——HTTP协议了。HTTP协议设计的目的，就是为了实现“请求—响应”这种模式的数据交互，也就是众所周之的“短连接”设计。而无论是短轮询还是长轮询，都跳不出HTTP的先天技术逻辑。

所以，归根到底，想要基于HTTP协议来实现IM，要达到真正的“实时性”，是相当勉强的。因为HTTP设计的目的，就是用“短连接”来简化传统TCP长连接通信带来的复杂性，而IM的实时性恰好要用到的又是TCP的长连接特性，所以这就是个悖论。

WebSocket是真正的全双式双向通信技术。

• 1）轮询技术一问一答，在下一个请求发起之前，存在“实时性”盲区；

• 2）WebSocket一旦建立连接后，数据可以随时双向通信（即客户端可以随时向服务端发消息，服务端也可以随时通知客户端有新消息）。

• 1）真正的实时性：支持客户端与服务端真正的双向实时通信；

• 2）大幅降低负载：少了轮询技术中高频率无用的请求，可大大降低服务端QPS压力；
• 3）网络开销降低：一次连接，随时使用，再也不用轮询技术中每次发起HTTP请求（随之而来的是每次HTTP的大量冗余协议头信息等）。

IM聊天系统的可靠性

M系统的消息“可靠性”，通常就是指聊天消息投递的可靠性（准确的说，这个“消息”是广义的，因为还存用户看不见的各种指令，为了通俗，统称“消息”）。

从用户行为来讲，消息“可靠性”应该分为两种类型：

• 1）在线消息的可靠性：即发送消息时，接收方当前处于“在线”状态；
• 2）离线消息的可靠性：即发送消息时，接收方当前处于“离线”状态。

从具体的技术表现来讲，消息“可靠性”包含两层含义：

• 1）消息不丢：这很直白，发出去的消息不能像进了黑洞一样；
• 2）消息不重：这是丢消息的反面，消息重复了也不能容忍。

对于“消息不丢”这个特征来说，细化下来，它又包含两重含义：

• 1）已明确被对方收到；
• 2）已明确未被对方收到。

典型的IM消息收发流程是 一条消息从客户端A发出后，需要先经过 IM 服务器来进行中转，然后再由 IM 服务器推送给客户端B，这种模式也是目前最常见的 IM 系统的消息分发架构。

P2P模式在IM系统中用的很少。

原因是以下两个很明显的弊端：

• 1）P2P模式下，IM运营者很容易被用户架空
• 2）P2P模式下，群聊这种业务形态，很难实现

TCP并不能保证在线消息的“可靠性”

这次我们从客户端角度来理解，为什么使用了可靠传输协议TCP的情况下IM聊天消息仍然不可靠的问题。

数据可靠抵达网络层之后，还需要一层层往上移交处理，可能的处理有：

• 1）安全性校验；
• 2）binary 解析；
• 3）model 创建；
• 4）写 db；
• 5）存入 cache；
• 6）UI 展示；
• 7）以及一些边界问题：比如断网、用户突然退出登陆、磁盘已满、内存溢出、app奔溃、突然关机等等。

例如，消息可靠抵达网络层之后，写 db 之前 IM APP 崩溃（不稀奇，是 App 都有崩溃的可能），虽然数据在网络层可靠抵达了，但没存进 db，下次用户打开 App 消息自然就丢失了，如果不在业务层再增加可靠性保障（比如：后面要提到的网络层面的消息重发保障），那么意味着这条消息对于接收端来说就永远丢失了，也就自然不存在“可靠性”了。

为在线消息增加可靠性保障

那么怎样在应用层增加可靠性保障呢？有一个现成的机制可供我们借鉴：TCP协议的超时、重传、确认机制。

具体来说就是：

• 1）在应用层构造一种ACK消息，当接收方正确处理完消息后，向发送方发送ACK；
• 2）假如发送方在超时时间内没有收到ACK，则认为消息发送失败，需要进行重传或其他处理。

可以把整个过程分为两个阶段。

阶段1：clientA -> server\

• 1-1：clientA向server发送消息(msg-Req)；
• 1-2：server收取消息，回复ACK(msg-Ack)给clientA；
• 1-3：一旦clientA收到ACK即可认为消息已成功投递，第一阶段结束。

无论msg-A或ack-A丢失，clientA均无法在超时时间内收到ACK，此时可以提示用户发送失败，手动进行重发。

阶段2：server -> clientB\

• 2-1：server向clientB发送消息(Notify-Req)；
• 2-2：clientB收取消息，回复ACK(Notify-ACk)给server；
• 2-3：server收到ACK之后将该消息标记为已发送，第二阶段结束。

无论msg-B或ack-B丢失，server均无法在超时时间内收到ACK，此时需要重发msg-B，直到clientB返回ACK为止

离线消息收发流程

离线消息收发流程也可划分为两个阶段：

阶段1：clientA -> server\

• 1-1：clientA向server发送消息(msg-Req) ；
• 1-2：server发现clientB离线，将消息存入offline-DB。

阶段2：server -> clientB\

• 2-1：clientB上线后向server拉取离线消息(pull-Req) ；
• 2-2：server从offline-DB检索相应的离线消息推送给clientB(pull-res)，并从offline-DB中删除。

显然：离线消息收发过程同样存在消息丢失的可能性。

举例来说：假设pull-res没有成功送达clientB，而offline-DB中已删除，这部分离线消息就彻底丢失了。

与初始的离线消息收发流程相比，上图增加了1-3、2-4、2-5步骤：

• 1-3：server将消息存入offline-DB后，回复ACK(msg-Ack)给clientA，clientA收到ACK即可认为消息投递成功；
• 2-4：clientB收到推送的离线消息，回复ACK(res-Ack)给server；
• 2-5：server收到res-ACk后确定离线消息已被clientB成功收取，此时才能从offline-DB中删除。

当离线消息的量较大时：如果对每条消息都回复ACK，无疑会大大增加客户端与服务器的通信次数。这种情况我们通常使用批量ACK的方式，对多条消息仅回复一个ACK。还可以将所有的离线消息按会话进行分组，每组回复一个ACK，假如某个ACK丢失，则只需要重传该会话的所有离线消息。

通过在应用层加入重传、确认机制后，我们确实是杜绝了消息丢失的可能性。

但由于重试机制的存在，我们会遇到一个新的问题：那就是同一条消息可能被重复发送。

举一个最简单的例子：假设client成功收到了server推送的消息，但其后续发送的ACK丢失了，那么server将会在超时后再次推送该消息，如果业务层不对重复消息进行处理，那么用户就会看到两条完全一样的消息。

消息去重的方式其实非常简单，一般是根据消息的唯一标志(id)进行过滤。

具体过程在服务端和客户端可能有所不同：

• 1）**客户端 ：可以通过构造一个map来维护已接收消息的id，当收到id重复的消息时直接丢弃；
• 2）**服务端 ：收到消息时根据id去数据库查询，若库中已存在则不进行处理，但仍然需要向客户端回复Ack（因为这条消息很可能来自用户的手动重发）。

IM聊天系统的消息时序一致性

所谓的一致性，在IM中通常指的是消息时序的一致性，那就是：

• 1）聊天消息的上下文连续性；
• 2）聊天消息的绝对时间序。

再具体一点，IM消息的一致性体现在：

• 1）单聊时：要保证发送方发出聊天消息的顺序与接收方看到的顺序一致；
• 2）群聊时：要保证所有群员看到的聊天消息，与发送者发出消息时的绝对时间序是一致的。

技术难点：没有全局时钟

一个真正堪用的生产系统，显示不可能所有服务都跑在一台服务器上，分布式环境是肯定的。

那么：在分布式环境下，客户端+服务端后台的各种后台服务，都各自分布在不同的机器上，机器之间都是使用的本地时钟，没有一个所谓的“全局时钟”（也没办法做到真正的全局时钟），那么所谓的消息时序也就没有真正意义上的时序基准点。所以消息时序问题显然不是“本地时间”可以完全决定的。

多发送方问题：服务端分布式的情况下，不能用“本地时间”来保证时序性，那么能否用接收方本地时间表示时序呢？遗憾的是，由于多个客户端的存在（比如群聊时），即使是一台服务器的本地时间，也无法表示“绝对时序”。

绝对时序上，APP1先发出msg1，APP2后发出msg2，都发往服务器web1，网络传输是不能保证msg1一定先于msg2到达的，所以即使以一台服务器web1的时间为准，也不能精准描述msg1与msg2的绝对时序。

多接收方问题，多发送方不能保证时序，假设只有一个发送方，能否用发送方的本地时间表示时序呢？遗憾的是，由于多个接收方的存在，无法用发送方的本地时间，表示“绝对时序”。绝对时序上，web1先发出msg1，后发出msg2，由于网络传输及多接收方的存在，无法保证msg1先被接收到先被处理，故也无法保证msg1与msg2的处理时序。

网络传输与多线程问题，既然多发送方与多接收方都难以保证绝对时序，那么假设只有单一的发送方与单一的接收方，能否保证消息的绝对时序一致性呢？

结论是悲观的，由于网络传输与多线程的存在，这仍然不行。

如上图所示，web1先发出msg1、后发出msg2，即使msg1先到达（网络传输其实还不能保证msg1先到达），由于多线程的存在，也不能保证msg1先被处理完。

优化思路

假设两人一对一聊天，发送方A依次发出了msg1、msg2、msg3三条消息给接收方B，这三条消息该怎么保证显示时序的一致性（发送与显示的顺序一致）？发送方A依次发出的msg1、msg2、msg3三条消息，到底服务端后，再由服务端中转发出时，这个顺序由于多线程的网络的问题，是有可能乱序的。

不过，实际上一对一聊天的两个人，并不需要全局消息时序的一致（因为聊天只在两人的同一会话在发生），只需要对于同一个发送方A，发给B的消息时序一致就行了。

常见优化方案，在A往B发出的消息中，加上发送方A本地的一个绝对时序（比如本机时间戳），来表示接收方B的展现时序。那么当接收方B收到消息后，即使极端情况下消息可能存在乱序到达，但因为这个乱序的时间差对于普通用户来说体感是很短的，在UI展现层按照消息中自带的绝对时序排个序后再显示，用户其实是没有太多感知的。

多对多群聊的消息一致性保证思路假设N个群友在一个IM群里聊天，应该怎样保证所有群员收到消息的显示时序一致性呢？不能像一对一聊天那样利用发送方的绝对时序来保证消息顺序，因为群聊发送方不单点，时间也不一致。可以利用服务器的单点做序列化。

• 1）sender1发出msg1，sender2发出msg2；
• 2）msg1和msg2经过接入集群，服务集群；
• 3）service层到底层拿一个唯一seq，来确定接收方展示时序；
• 4）service拿到msg2的seq是20，msg1的seq是30；
• 5）通过投递服务将消息发给多个群友，群友即使接收到msg1和msg2的时间不同，但可以统一按照seq来展现。

这个方法：

• 1）优点是：能实现所有群友的消息展示时序相同；
• 2）缺点是：这个生成全局递增序列号的服务很容易成为系统瓶颈

群消息其实也不用保证全局消息序列有序，而只要保证一个群内的消息有序即可，这样的话，“消息id序列化”就成了一个很好的思路。

群消息其实不用保证全局消息序列有序，而只要保证一个群内的消息有序即可，这样的话，“消息id序列化”就成了一个很好的思路。service层不再需要去一个统一的后端拿全局seq（序列号），而是在service连接池层面做细小的改造，保证一个群的消息落在同一个service上，这个service就可以用本地seq来序列化同一个群的所有消息，保证所有群友看到消息的时序是相同的。这样就需要全局消息ID生成方案，对于IM系统来说，绝对意义上的时序很难保证，但通过服务端生成的单调递增消息ID的方式，利用递增ID来保证时序性，也是一个很可性的方案。

IM聊天系统的端到端加密

一般的数据加密可以在通信的3个层次来实现：链路加密、节点加密和端到端加密。

链路加密

对于在两个网络节点间的某一次通信链路，链路加密能为网上传输的数据提供安全保证。对于链路加密(又称在线加密)，所有消息在被传输之前进行加密，在每一个节点对接收到的消息进行解密，然后先使用下一个链路的密钥对消息进行加密，再进行传输。

在到达目的地之前，一条消息可能要经过许多通信链路的传输。由于在每一个中间传输节点消息均被解密后重新进行加密，因此，包括路由信息在内的链路上的所有数据均以密文形式出现，这样，链路加密就掩盖了被传输消息的源点与终点。

节点加密

尽管节点加密能给网络数据提供较高的安全性，但它在操作方式上与链路加密是类似的：两者均在通信链路上为传输的消息提供安全性，都在中间节点先对消息进行解密，然后进行加密。因为要对所有传输的数据进行加密，所以加密过程对用户是透明的。然而，与链路加密不同，节点加密不允许消息在网络节点以明文形式存在，它先把收到的消息进行解密，然后采用另一个不同的密钥进行加密，这一过程是在节点上的一个安全模块中进行。

节点加密要求报头和路由信息以明文形式传输，以便中间节点能得到如何处理消息的信息，因此这种方法对于防止攻击者分析通信业务是脆弱的。

端到端加密

端到端加密允许数据在从源点到终点的传输过程中始终以密文形式存在。采用端到端加密(又称脱线加密或包加密)，消息在被传输时到达终点之前不进行解密，因为消息在整个传輸过程中均受到保护，所以即使有节点被损坏也不会使消息泄露。端到端加密系统的价格便宜些，并且与链路加密和节点加密相比更可靠，更容易设计、实现和维护。端到端加密还避免了其它加密系统所固有的同步问题，因为每个报文包均是独立被加密的，所以一个报文包所发生的传输错误不会影响后续的报文包。端到端加密系统通常不允许对消息的目的地址进行加密，这是因为每一个消息所经过的节点都要用此地址来确定如何传输消息。由于这种加密方法不能掩盖被传输消息的源点与终点，因此它对于防止攻击者分析通信业务是脆弱的。

在IM系统中，当用户A发送消息给用户B时，IM系统会生成一对公钥和私钥，并将公钥发送给用户B。用户A使用用户B的公钥对消息进行加密，然后将加密后的消息发送给用户B。在用户B接收到消息后，使用自己的私钥对消息进行解密，从而获取明文内容。由于私钥只有用户B拥有，因此除了用户B之外，任何人都无法解密消息。

通讯效率低：由于端对端加密需要对通讯数据进行加密和解密，因此可能会导致通信效率较低。

需双向支持：端对端加密需要发送方和接收方都需要支持该技术，否则就将无法实现端对端加密通信。

安全性问题：虽然端对端加密可以防止中间人攻击，但如果黑客能够获得了私钥或公钥，那么他们也能够轻易地获取到通信数据。

简易架构设计

IM系统设计设计方方面面，这里不作细究。从功能来说包括账号，关系链，在线状态显示，消息交互等等。

一种简单架构如下

对于上线服务由于建立的是TCP长连接，对于单台服务器往往由于硬件资源、系统资源、网络资源的限制无法做到海量用户的同时 在线，所以设计为根据服务器负载支持多服务器上线，同时由于多服务器上线造成了对整个系统交互（不同的客户端的交互，协作部门应用服务和客户的交互）的分 割，引入消息转发服务器作为粘合点。另外对于多服务器上线造成的统一账户信息（在线状态，消息）数据的分割，引入统一的数据层（内存存储 层：session、状态信息存储、消息队列存储；数据库：账号信息存储）做到业务和数据的分离，也就做到了支持分布式部署。

一种现代架构如下图

高并发上又可以从水平扩展，线程模型，多层缓存，长连接等优化。

高可用上包括心跳，稳定性以及Redis宕机高可用等。

从流程上来看主要有单聊和群聊流程。

单聊流程

假设是用户A发消息给用户B ，以下是完整的业务流程。

1）A打包数据发送给服务端，服务端接收消息后，根据接收消息的sequence_id来进行客户端发送消息的去重，并且生成递增的消息ID，将发送的信息和ID打包一块入库，入库成功后返回ACK，ACK包带上服务端生成的消息ID。

2）服务端检测接收用户B是否在线，在线直接推送给用户B。

3）如果没有本地消息ID则存入，并且返回接入层ACK信息；如果有则拿本地sequence_id和推送过来的sequence_id大小对比，并且去重，进行展现时序进行排序展示，并且记录最新一条消息ID。最后返回接入层ack。

4）服务端接收ACK后，将消息标为已送达。

5）如果用户B不在线,首先将消息存入库中，然后直接通过手机通知来告知客户新消息到来。

6）用户B上线后，拿本地最新的消息ID，去服务端拉取所有好友发送给B的消息，考虑到一次拉取所有消息数据量大，通过channel通道来进行分页拉取，将上一次拉取消息的最大的ID，作为请求参数，来请求最新一页的比ID大的数据。

群聊流程

假设是用户A发消息给群G ，以下是完整的业务流程。

1）登录，TCP连接，token校验，名词检查，sequence_id去重，生成递增的消息ID，群消息入库成功返回发送方ACK。

2）查询群G所有的成员，然后去redis中央存储中找在线状态。离线和在线成员分不同的方式处理。

3）在线成员：并行发送拉取通知，等待在线成员过来拉取，发送拉取通知包如丢失会有兜底机制。

4）在线成员过来拉取，会带上这个群标识和上一次拉取群的最小消息ID，服务端会找比这个消息ID大的所有的数据返回给客户端，等待客户端ACK。一段时间没ack继续推送。如果重试几次后没有回ack，那么关闭连接和清除ack等待队列消息。

5）客户端会更新本地的最新的消息ID，然后进行ack回包。服务端收到ack后会更新群成员的最新的消息ID。

6）离线成员：发送手机通知栏通知。离线成员上线后，拿本地最新的消息ID，去服务端拉取群G发送给A的消息，通过channel通道来进行分页拉取，每一次请求，会将上一次拉取消息的最大的ID，作为请求参数来拉取消息，这里相当于第二次拉取请求包是作为第一次拉取的ack包。

7）分页的情况下，客户端在收到上一页请求的的数据后更新本地的最新的消息ID后，再请求下一页并且带上消息ID。上一页请求的的数据可以当作为ack来返回服务端，避免网络多次交互。服务端收到ack后会更新群成员的最新的消息ID。

客户端设计

客户端的设计主要从以下几点出发：

• 1）client每个设备会在本地存每一个会话，保留有最新一条消息的顺序 ID；
• 2）为了避免client宕机，也就是退出应用，保存在内存的消息ID丢失，会存到本地的文件中；
• 3）client需要在本地维护一个等待ack队列，并配合timer超时机制，来记录哪些消息没有收到ack：N，以定时重发；
• 4）客户端本地生成一个递增序列号发送给服务器，用作保证发送顺序性。该序列号还用作ack队列收消息时候的移除

1）方案一：

设计思路：

• 1）数据传输中的大小尽量小用int，不用bigint，节省传输大小；
• 2）只保证递增即可,在用户重新登录或者重连后可以进行日期重置，只保证单次；
• 3）客户端发号器不需要像类似服务器端发号器那样集群部署，不需要考虑集群同步问题。

注：上述生成器可以用18年[(2^29-1)/3600/24/365]左右，一秒内最多产生4个消息。

优点：可以在断线重连和重装APP的情况下，18年之内是有序的。
缺点：每秒只能发4个消息，限制太大，对于群发场景不合适。
改进：使用long进行传输，年限扩展很久并且有序。