【Linux网络·加餐】HTTPS协议：从密码学基础到安全机制

艾莉丝努力练剑2026-06-30 10:27

🎬 个人主页 ：艾莉丝努力练剑
❄专栏传送门 ：《C语言》《数据结构与算法》《C/C++干货分享&学习过程记录》
《Linux操作系统编程详解》《笔试/面试常见算法：从基础到进阶》《Python干货分享》

⭐️为天地立心，为生民立命，为往圣继绝学，为万世开太平

🎬 艾莉丝的简介：

文章目录

  • 框架引入
  • [1 ~> HTTPS 是什么](#1 ~> HTTPS 是什么)
    • [1.1 什么是加密](#1.1 什么是加密)
    • [1.2 为什么要加密](#1.2 为什么要加密)
    • [1.3 常见的加密方法](#1.3 常见的加密方法)
      • [1.3.1 对称加密](#1.3.1 对称加密)
      • [1.3.2 非对称加密](#1.3.2 非对称加密)
    • [1.4 数据摘要 && 数据指纹](#1.4 数据摘要 && 数据指纹)
      • [1.4.1 基本原理](#1.4.1 基本原理)
      • [1.4.2 典型应用场景](#1.4.2 典型应用场景)
      • [1.4.3 数字签名](#1.4.3 数字签名)
      • [1.4.4 方案演进思考链](#1.4.4 方案演进思考链)
  • [2 ~> HTTPS 的工作原理探究](#2 ~> HTTPS 的工作原理探究)
    • [2.1 方案一：只使用对称加密](#2.1 方案一：只使用对称加密)
    • [2.2 方案二：只使用非对称加密](#2.2 方案二：只使用非对称加密)
    • [2.3 方案三：双方都使用非对称加密](#2.3 方案三：双方都使用非对称加密)
    • [2.4 方案四：非对称加密 + 对称加密](#2.4 方案四：非对称加密 + 对称加密)
  • [3 ~> 中间人攻击](#3 ~> 中间人攻击)
    • [3.1 攻击前提](#3.1 攻击前提)
    • [3.2 攻击完整流程](#3.2 攻击完整流程)
    • [3.3 漏洞根源](#3.3 漏洞根源)
  • [4 ~> CA 证书与签名](#4 ~> CA 证书与签名)
    • [4.1 理解数据签名](#4.1 理解数据签名)
      • [4.1.1 数字签名生成流程](#4.1.1 数字签名生成流程)
      • [4.1.2 数字签名验证流程](#4.1.2 数字签名验证流程)
      • [4.1.3 核心价值](#4.1.3 核心价值)
    • [4.2 CA 证书](#4.2 CA 证书)
      • [4.2.1 证书的本质](#4.2.1 证书的本质)
      • [4.2.2 证书申请与签发流程](#4.2.2 证书申请与签发流程)
      • [4.2.3 证书验证流程](#4.2.3 证书验证流程)
      • [4.2.4 防中间人攻击的原理](#4.2.4 防中间人攻击的原理)
  • [5 ~> HTTPS 协议原理（方案五）](#5 ~> HTTPS 协议原理（方案五）)
    • [5.1 过程梳理](#5.1 过程梳理)
    • [5.2 方案五：非对称加密 + 对称加密 + 证书认证](#5.2 方案五：非对称加密 + 对称加密 + 证书认证)
    • [5.3 细节问题](#5.3 细节问题)
      • [5.3.1 为什么签名不直接加密原文，而是先 Hash 形成摘要](#5.3.1 为什么签名不直接加密原文，而是先 Hash 形成摘要)
      • [5.3.2 证书有效期机制](#5.3.2 证书有效期机制)
      • [5.3.3 常见中间人实现手段](#5.3.3 常见中间人实现手段)
    • [5.4 总结](#5.4 总结)
  • 本文总结
  • 结尾

框架引入

导入语

本文系统拆解 HTTPS 协议的底层原理与全链路工作流程，核心解决 HTTP 明文传输带来的窃听、篡改、身份伪造三大安全风险。内容从密码学基础概念出发，逐步推演加密方案的演进逻辑，深入剖析中间人攻击的原理与防御手段，最终落地到 CA 证书信任体系与 HTTPS 完整握手流程。全文覆盖加密算法特性、密钥协商机制、证书验证逻辑等核心考点，所有结论均经过技术严谨性审计，可直接用于应试冲刺与底层原理复盘。

本文知识框架

bash 复制代码 
HTTPS核心知识体系
|-- 1 ~> HTTPS是什么
|   |-- 1.1 什么是加密
|   |   |-- 分层定位与核心作用
|   |   |-- 明文、密文与密钥的关系
|   |   `-- 密码学学科背景
|   |-- 1.2 为什么要加密
|   |   |-- 明文传输风险：运营商劫持
|   |   |-- 中间人攻击的基础形态
|   |   `-- 加密的核心价值
|   |-- 1.3 常见的加密方法
|   |   |-- 对称加密：原理、特点、代表算法
|   |   `-- 非对称加密：原理、特点、代表算法
|   |-- 1.4 数据摘要 && 数据指纹
|   |   |-- 基本原理与核心特征
|   |   |-- 典型应用场景
|   |   |-- 数字签名基础定义
|   |   `-- 方案演进思考链
|-- 2 ~> HTTPS的工作原理探究
|   |-- 2.1 方案一：只使用对称加密
|   |-- 2.2 方案二：只使用非对称加密
|   |-- 2.3 方案三：双方都使用非对称加密
|   `-- 2.4 方案四：非对称加密 + 对称加密
|-- 3 ~> 中间人攻击
|   |-- 攻击前提与完整流程
|   `-- 核心漏洞根源
|-- 4 ~> CA证书与签名
|   |-- 4.1 理解数据签名
|   |   |-- 签名生成流程
|   |   |-- 签名验证流程
|   |   `-- 数字签名核心价值
|   `-- 4.2 CA证书
|       |-- 证书的本质结构
|       |-- 证书申请与签发流程
|       |-- 证书合法性验证流程
|       `-- 防中间人攻击的原理
`-- 5 ~> HTTPS协议原理（方案五）
    |-- 5.1 完整通信过程梳理
    |-- 5.2 方案五：非对称+对称+证书认证
    |-- 5.3 核心细节问题答疑
    `-- 5.4 三组密钥分工与本质总结

1 ~> HTTPS 是什么

1.1 什么是加密

HTTP 与 HTTPS 同属应用层协议。HTTPS 的本质是在 HTTP 协议与传输层（TCP/UDP）之间，新增了 TLS/SSL（传输层安全 / 安全套接字层）软件层，该层级同样归属于应用层范畴，核心能力是完成数据的加密与解密。 网络分层从上到下的完整链路为：HTTP → TLS/SSL → TCP/UDP → 网络层 → 数据链路层，数据在 TLS/SSL 层完成加解密后再进入传输层，因此整个传输过程具备安全性。

加密的核心逻辑：通过密钥参与运算，将可读的明文转换为不可读的密文；解密则是对应的反向过程，无论加密还是解密都必须依赖密钥。加解密技术发展至今已形成独立的密码学学科，该学科的奠基人之一是计算机科学先驱艾伦・麦席森・图灵。

1.2 为什么要加密

HTTP 以明文形式传输数据，传输链路中的所有中间节点均可直接读取、篡改数据内容，最典型的风险为运营商劫持。 以应用下载场景为例：用户点击下载按钮发起 HTTP 请求，服务器返回包含下载链接的 HTTP 响应；运营商作为中间节点可识别请求内容，直接篡改响应中的下载地址，导致用户下载到非目标软件。

加密的核心价值在于，数据加密后中间节点无法识别数据内容，也就无法完成篡改与窃取，这是移动支付、隐私数据传输的核心安全基础。 中间人攻击是明文传输的典型风险形态，例如手机开启热点时，热点设备可作为中间节点监听所有经过的网络数据，是最基础的中间人设备。

1.3 常见的加密方法

1.3.1 对称加密

对称加密仅使用同一把密钥完成加密与解密，通信双方必须持有完全相同的密钥。 简单实现原理可通过异或运算演示：明文与密钥进行异或运算生成密文，密文与同一密钥再次异或即可还原明文。 工业级主流算法包括 AES、DES、3DES 等。 核心特点：算法逻辑简单、加解密速度极快，适合大数据量的业务数据传输；核心缺陷是密钥分发困难，首次传输密钥时若使用明文，密钥会直接泄露，后续加密完全失效。

1.3.2 非对称加密

非对称加密需要一对配对使用的密钥：公开密钥（公钥）与私有密钥（私钥）。 主流算法包括 RSA、DSA、ECDSA 等。 核心特性：

  • 公钥可公开分发给任意主体，私钥必须由持有者严格保密，不可泄露；
  • 公钥加密生成的密文，仅能由对应的私钥解密；
  • 私钥加密生成的密文，仅能由对应的公钥解密；
  • 算法基于复杂数论原理，运算强度高，加解密速度远慢于对称加密。

生活化类比：接收方准备带锁的盒子，锁相当于公钥，可分发给所有发送方；发送方将文件放入盒子并用锁锁好，对应公钥加密；只有持有钥匙（私钥）的接收方能开锁取文件，对应私钥解密。 其中公钥加密、私钥解密的方向用于数据保密场景；私钥加密、公钥解密的方向用于身份认证与数字签名场景。

1.4 数据摘要 && 数据指纹

1.4.1 基本原理

数据摘要也叫数字指纹，核心原理是通过单向散列函数（Hash 函数）对任意长度的原始数据进行运算，生成一串固定长度的散列值。 主流算法包括 MD5、SHA1、SHA256、SHA512 等。由于是将无限的输入映射到有限的输出空间，理论上存在碰撞可能（即不同数据生成相同摘要），但高强度算法的碰撞概率极低。

核心特征：

  • 单向不可逆：无法通过摘要反推出原始数据，因此严格意义上不属于加密机制；
  • 雪崩效应：原始数据哪怕只修改 1 个比特，最终生成的摘要都会发生巨大差异；
  • 相同输入必然得到相同输出，可用于数据一致性校验。

1.4.2 典型应用场景

  1. 文件秒传功能：云盘服务端存储所有已有文件的摘要，用户上传时先在本地计算文件摘要并发送给服务端；服务端检索摘要，若已存在则直接将已有文件关联到用户账户，无需重复上传，实现秒传。
  2. 密码存储：数据库不应明文存储用户密码，而是存储密码的哈希摘要；用户登录时，将输入的密码执行相同哈希运算，与数据库中存储的摘要比对，一致则验证通过。该方案可避免数据库泄露后用户密码直接暴露。

1.4.3 数字签名

对数据摘要进行非对称私钥加密，得到的结果即为数字签名。数字签名是身份认证与防篡改的核心技术基础，是 CA 证书体系的核心组成部分。

1.4.4 方案演进思考链

三个核心问题引出后续加密方案的逐步推演：

  1. 仅对 HTTP 进行对称加密，能否解决通信安全问题？核心缺陷是什么？
  2. 为什么需要引入非对称加密？
  3. 为什么不全程使用非对称加密？

2 ~> HTTPS 的工作原理探究

2.1 方案一：只使用对称加密

方案逻辑：客户端与服务器约定同一把对称密钥 X，后续所有 HTTP 数据均使用该密钥加解密传输。 核心缺陷：密钥分发安全问题。客户端首次与服务器通信时，无法安全地将密钥 X 传递给服务器；若明文传输密钥，密钥会被中间节点截获，后续加密完全失去意义。 结论：仅使用对称加密无法解决首次密钥同步的安全问题，不具备实际可用性。

2.2 方案二：只使用非对称加密

方案逻辑：服务器持有非对称公钥 S 与私钥 S'，公钥 S 公开分发给所有客户端；客户端用公钥 S 加密请求数据后发送，服务器用私钥 S' 解密。 存在的问题：

  1. 仅能保证客户端到服务器的单向数据安全。服务器若用私钥加密响应数据，所有持有公钥的节点均可解密，无法保证响应数据的保密性；
  2. 非对称加密运算速度极慢，完全无法承载 HTTP 大数据量、高并发的传输需求。 结论：仅使用非对称加密既无法实现双向安全，也无法满足性能要求。

2.3 方案三：双方都使用非对称加密

方案逻辑：客户端与服务器各生成一对非对称密钥，双方先交换公钥；客户端用服务器公钥加密请求，服务器用客户端公钥加密响应，试图实现双向加密。 存在的问题：

  1. 依然存在安全漏洞：公钥交换过程没有身份认证，中间人可替换双方公钥，本质上和方案二一样无法抵御中间人攻击；
  2. 双向非对称加密进一步加剧了性能损耗，通信速度更慢，完全不适合实际业务场景。 结论：该方案既没有解决根本的身份信任问题，也无法满足性能要求。

2.4 方案四：非对称加密 + 对称加密

方案逻辑：结合两种加密方式的优势，用非对称加密解决密钥协商问题，用对称加密解决业务数据传输的性能问题。 完整流程：

  1. 服务器持有非对称公钥 S 与私钥 S'，公钥 S 对外公开；
  2. 客户端生成本次通信用的对称密钥 X；
  3. 客户端用服务器公钥 S 加密对称密钥 X，发送给服务器；
  4. 服务器用私钥 S' 解密数据包，得到对称密钥 X；
  5. 后续所有 HTTP 业务数据，均使用对称密钥 X 进行加解密传输。

核心优势：解决了大数据量传输的性能问题，密钥协商过程使用非对称加密保证安全性。 遗留缺陷：依然无法抵御中间人攻击，核心问题是客户端无法确认收到的公钥是否属于真实的目标服务器。

3 ~> 中间人攻击

3.1 攻击前提

中间人 M 处于客户端与服务器的通信链路之间，可截获、转发双方的所有数据包，该攻击针对方案四的公钥无认证场景成立。

3.2 攻击完整流程

  1. 服务器向客户端发送自身公钥 S，数据包被中间人 M 截获；
  2. 中间人 M 将自己的公钥 M 发送给客户端，冒充是服务器的公钥；
  3. 客户端信以为真，用公钥 M 加密自己生成的对称密钥 X，发送给服务器；
  4. 该数据包再次被中间人 M 截获，M 用自己的私钥解密，得到对称密钥 X；
  5. 中间人 M 再用服务器的真实公钥 S 加密对称密钥 X，转发给服务器；
  6. 服务器用私钥 S' 解密得到对称密钥 X，认为密钥协商正常完成。

最终结果：客户端与服务器均认为密钥协商成功，但中间人 M 同样持有对称密钥 X，可全程解密、篡改双方的所有通信数据，而通信双方完全无法感知。

3.3 漏洞根源

客户端没有能力甄别收到的公钥是否来自合法服务器，公钥与服务器身份的绑定关系无法得到验证。这也是方案一到方案四共同的核心安全缺陷，必须引入第三方信任体系才能彻底解决。

4 ~> CA 证书与签名

4.1 理解数据签名

4.1.1 数字签名生成流程

签名方持有一对非对称密钥（公钥 Q、私钥 Q'）：

  1. 对原始完整数据执行 Hash 运算，生成固定长度的数据摘要；
  2. 使用签名方的私钥 Q' 对该摘要进行加密，加密结果即为数字签名；
  3. 最终对外发布 "原始数据 + 数字签名" 的组合数据包。

4.1.2 数字签名验证流程

验证方持有签名方的公钥 Q：

  1. 对收到的原始数据执行相同的 Hash 算法，计算得到摘要 1；
  2. 使用签名方的公钥 Q 对数字签名进行解密，得到摘要 2；
  3. 对比摘要 1 与摘要 2，若完全一致，则签名有效，证明数据未被篡改，且数据确实由持有对应私钥的签名方发布。

4.1.3 核心价值

  1. 防篡改：数据被篡改后，重新计算的摘要会与签名解密后的摘要不一致，可立即识别；
  2. 身份认证：只有持有对应私钥的主体才能生成合法签名，可确认数据发布者的身份；
  3. 抗抵赖：签名方无法否认自己发布过该数据。

4.2 CA 证书

4.2.1 证书的本质

数字证书是一份携带了 CA 机构数字签名的明文数据文件，核心结构为明文信息 + CA 数字签名。 明文信息包含以下核心字段：

  • 签发机构名称
  • 证书有效起止时间
  • 证书绑定的域名
  • 证书申请者信息
  • 服务器的公钥
  • 其他扩展配置信息

4.2.2 证书申请与签发流程

  1. 服务器生成本身的公钥 pub_svr 与私钥 pri_svr；
  2. 服务器将域名、申请者信息、公钥等信息打包生成 CSR 申请文件，文件中不包含私钥；
  3. 将 CSR 文件提交给 CA 机构，CA 机构审核申请信息的真实性与合规性；
  4. 审核通过后，CA 机构使用自身的私钥，对证书明文信息的摘要进行加密，生成数字签名；
  5. CA 将携带签名的完整证书签发申请者，服务器部署证书后即可对外提供 HTTPS 服务。

4.2.3 证书验证流程

操作系统与浏览器会内置所有权威 CA 机构的公钥，客户端验证证书的完整流程：

  1. 客户端收到服务器返回的证书，分离出明文信息与数字签名；
  2. 对证书的明文信息执行相同 Hash 算法，计算得到摘要 1；
  3. 使用内置的对应 CA 公钥，解密证书中的数字签名，得到摘要 2；
  4. 对比摘要 1 与摘要 2，若一致则证明证书未被篡改；
  5. 额外校验项：证书域名与访问域名是否匹配、证书是否在有效期内、证书是否已被吊销。 所有验证项通过，则认定证书合法，证书中携带的服务器公钥可信。

4.2.4 防中间人攻击的原理

  1. 中间人无法篡改证书明文：篡改明文后，重新计算的摘要会与签名解密后的摘要不匹配，客户端可直接识别；中间人没有 CA 私钥，无法为篡改后的证书生成合法的新签名。
  2. 中间人无法整体掉包证书：若中间人使用自己申请的真实证书进行替换，证书中的域名会与用户访问的域名不一致，客户端域名校验会失败，同样可识别攻击。
  3. 申请证书需提交真实身份信息，恶意主体不会以真实身份申请证书用于攻击，存在法律风险与可溯源性。

5 ~> HTTPS 协议原理（方案五）

5.1 过程梳理

HTTPS 完整通信的前置条件：服务器已向 CA 机构申请并部署了合法的数字证书，持有自身的公私钥对。 完整通信流程：

  1. 客户端向服务器发起 HTTPS 连接请求，协商双方支持的加密套件与哈希算法；
  2. 服务器将自身的数字证书返回给客户端；
  3. 客户端执行证书合法性校验，若校验不通过则直接提示安全风险并终止连接；
  4. 校验通过后，客户端生成随机的对称密钥 R；
  5. 客户端使用证书中的服务器公钥，加密对称密钥 R 后发送给服务器；
  6. 服务器使用自身的私钥解密数据包，得到对称密钥 R；
  7. 至此密钥协商完成，后续所有 HTTP 请求与响应数据，均使用对称密钥 R 进行加解密传输。

5.2 方案五：非对称加密 + 对称加密 + 证书认证

这是 HTTPS 的最终落地方案，三层机制各司其职，形成完整安全闭环：

  • CA 证书体系：解决身份信任问题，确保客户端拿到的公钥确实属于目标服务器，从根源抵御中间人攻击；
  • 服务器非对称密钥：解决对称密钥的安全协商问题，安全传递对称密钥；
  • 对称加密：解决业务数据的高效加解密传输问题，满足高并发、大数据量的性能需求。

5.3 细节问题

5.3.1 为什么签名不直接加密原文，而是先 Hash 形成摘要

核心原因是提升运算效率。非对称加密的运算速度极慢，若直接对完整原文进行加密，耗时会随数据量线性增长；而 Hash 生成的摘要长度固定且很短，对摘要进行非对称加解密的速度远高于对全文加密，同时不影响防篡改、身份认证的能力。

5.3.2 证书有效期机制

证书均设置有效期限，核心目的是缩短密钥泄露后的风险窗口，同时推动证书定期更新，适配安全算法的迭代。除过期机制外，还存在证书吊销机制，可实时校验证书是否已被 CA 作废。

5.3.3 常见中间人实现手段

局域网场景下可通过 ARP 欺骗实现中间人攻击，公共 WiFi、恶意热点是典型的中间人攻击风险场景；广域网场景下多通过 DNS 劫持将用户引导至伪造站点。

5.4 总结

HTTPS 工作流程中共涉及三组密钥，分工明确、层层递进：

  1. 第一组：CA 机构的公私钥（非对称加密） CA 机构持有私钥用于签发证书，客户端操作系统 / 浏览器内置对应公钥用于验证证书。这是整个信任体系的根，核心作用是保证服务器公钥的合法性与权威性，解决身份认证问题。
  2. 第二组：服务器的公私钥（非对称加密） 服务器持有私钥，公钥封装在证书中对外分发。核心作用是完成对称密钥的安全协商，客户端用公钥加密对称密钥，仅服务器能通过私钥解密获取。
  3. 第三组：客户端生成的对称密钥（对称加密） 由客户端随机生成，协商完成后双方共同持有。核心作用是对后续所有 HTTP 业务数据进行加解密，兼顾安全性与传输性能。

HTTPS 本质上是在 HTTP 协议基础上引入了 TLS/SSL 加密层，通过信任链体系解决了明文传输的窃听、篡改、冒充三大核心风险，是当前互联网安全通信的基石标准。

本文总结

本文完整覆盖 HTTPS 从密码学基础到协议落地的全链路知识，核心考点与易错点梳理如下：

  1. 基础概念区分 需明确区分对称加密与非对称加密的特性、适用场景与代表算法；明确数据摘要不属于加密，核心作用是防篡改而非保密；区分数字签名与数据加密的差异：加密保证数据机密性，签名保证数据完整性与身份真实性，二者应用方向完全不同。
  2. 加密方案演进逻辑 四种方案的缺陷需精准对应：仅对称加密毁于密钥分发安全，仅非对称加密毁于性能与单向安全，双向非对称加密毁于性能与无身份认证，混合加密毁于公钥身份无法验证。演进逻辑是逐步解决前序方案的缺陷，最终通过引入第三方信任体系形成安全闭环。
  3. 中间人攻击核心 攻击成立的前提是公钥无身份认证，攻击的本质是 "两头欺骗"，同时冒充客户端与服务器；防御的核心是引入可信第三方 CA，通过证书锚定公钥与域名的绑定关系，让中间人无法伪造合法身份。
  4. 数字签名与证书验证流程 数字签名的生成与验证流程是高频考点，需牢记 "先 Hash 再私钥加密生成签名，先 Hash 再公钥解密比对验证" 的核心逻辑；证书验证需同时通过摘要比对、域名匹配、有效期校验、吊销状态校验四重验证，缺一不可。
  5. 三组密钥的分工 三组密钥层层支撑：CA 密钥作为信任根锚定身份，服务器密钥用于协商对称密钥，对称密钥用于传输业务数据。需明确每组密钥的加密类型、持有方与核心作用，不可混淆功能边界。
  6. 高频易错坑点
  • 误区：非对称加密可以实现双向保密。实际公钥是公开的，私钥加密的数据所有持有公钥的人均可解密，仅公钥加密私钥解密的方向具备保密能力，私钥加密公钥解密的方向仅用于签名认证。
  • 误区：HTTPS 完全无法被中间人攻击。实际若用户手动信任非法证书、或根 CA 机构被攻破，信任链会失效；正常合规场景下，权威 CA 体系可有效防御常规中间人攻击。
  • 误区：摘要可以解密。摘要为单向散列，不存在解密操作，仅能通过暴力碰撞尝试反推，高强度算法下碰撞概率可忽略。
  • 工程误区：密码直接用 MD5 存储即可。实际无盐哈希可被彩虹表破解，工业级方案需使用随机盐值配合慢哈希算法，保障密码存储安全。

结尾

uu们，本文的内容到这里就全部结束了，艾莉丝在这里再次感谢您的阅读！

|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ### 艾莉丝努力练剑 C/C++ & Linux 底层探索者 | 一个正在努力练剑的技术博主 *** ** * ** *** 👀 【关注】 跟随我一起深耕技术领域，见证每一次成长。 ❤️ 【点赞】 让优质内容被更多人看见，让知识传递更有力量。 ⭐ 【收藏】 把核心知识点存好，在需要时随时查、随时用。 💬 【评论】 分享你的经验或疑问，评论区一起交流避坑！ 不要忘记给博主"一键四连"哦！ "今日练剑达成！" "技术之路难免有困惑，但同行的人会让前进更有方向。" |

结语：希望对学习Linux相关内容的uu有所帮助，不要忘记给博主"一键四连"哦！

往期回顾：

【Linux网络】多路转接和反应堆模式：基于单Reactor实现的网络版本计算器

🗡博主在这里放了一只小狗，大家看完了摸摸小狗放松一下吧！🗡 ૮₍ ˶ ˊ ᴥ ˋ˶₎ა

热门推荐
012026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片02GitHub 镜像站点03如何新建文件夹？ 电脑新建文件夹的4种方法04AI科技热点日报 | 2026年07月01日05幻兽帕鲁 - 服务器管理员权限与 GM 命令完全指南06国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）072026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？08AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路092026 年 AI 大模型 & AI 编程工具实战全总结10微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新