PostgreSQL笔记64：分区插件生态与扩展查询协议深度解析

Wang's Blog2026-08-25 11:19

纲要

  • 分区插件概览
    • pg_rewrite：在线转换普通表为分区表
    • pg_partman：历史插件（已停止新特性开发）
    • pg_partnerman：纯 SQL 运维自动化扩展
    • timescaledb：时序引擎与超表
  • 扩展查询协议（Extended Query Protocol）
    • 简单协议 vs 扩展协议
    • 绑定变量（Bind Variables）与执行计划缓存
    • plan_cache_mode 参数与常见报错
  • 常见问题与解决方案
    • 对象名长度限制（63 字符）
    • 绑定变量导致的执行计划错误
  • API 速览
  • Demo 完整示例（Node.js + pg）
  • 官方文档与参考链接
  • 总结

分区插件生态

PostgreSQL 原生分区功能在 10 版本引入，在 11 版本中完善了默认值分区、哈希分区等特性，至 12 版本后性能已与第三方插件持平。但在实际生产环境中，仍存在多种插件用于简化分区管理、在线迁移或提供时序增强功能。本章逐一剖析主流分区插件的设计理念、适用场景与局限性。

pg_rewrite：在线非分区表转分区表

pg_rewrite 是一个利用逻辑复制（Logical Replication）实现将普通表在线转换为分区表的插件。其核心流程如下：

  1. 在目标表上创建 REPLICA IDENTITY（通常为主键），确保逻辑复制可捕获行变更。
  2. 插件内部创建新的分区表结构（与原表定义一致），并设置分区规则。
  3. 启动逻辑复制槽，将原表的增量数据实时同步至新分区表。
  4. 在数据同步完成后，短暂获取排他锁（8 级锁）进行表名切换，将原表重命名为备份表，新分区表改为原表名。
  5. 通过 max_lock 参数控制等待锁的超时时间，避免因长时间阻塞影响业务。

该插件显著降低了从非分区表迁移到分区表的运维成本，尤其适用于无法承受长时间停机的大型生产环境。但需注意，逻辑复制要求表具有唯一标识（主键或 REPLICA IDENTITY FULL），且需确保序列（Sequence）在切换后与目标表一致。

使用示例（函数调用）：

sql 复制代码 
-- 创建测试表
CREATE TABLE t1 (id serial PRIMARY KEY, data text, created_at timestamptz);
INSERT INTO t1 SELECT generate_series(1,1000), 'test', now();

-- 创建目标分区表结构（需预先定义）
CREATE TABLE t1_part (LIKE t1 INCLUDING ALL) PARTITION BY RANGE (created_at);
CREATE TABLE t1_part_2025 PARTITION OF t1_part FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');

-- 调用 pg_rewrite 转换函数（假设插件已安装）
SELECT pg_rewrite.rewrite_table(
    source_table := 't1',
    target_table := 't1_part',
    old_table_suffix := '_old',
    max_lock_time := '5s'
);

转换完成后，t1 将指向分区表，原表被重命名为 t1_old。

pg_partman：历史遗产与原生分区的替代

pg_partman 曾是 PostgreSQL 分区管理的标准插件，支持通过内建函数自动创建、挂载、卸载分区，并提供了性能优化钩子（hooks）。然而，官方已明确表示自 PostgreSQL 12 起，原生分区性能已与 pg_partman 持平，且该插件不再进行新特性开发，仅维护严重缺陷修复。

官方立场 ：We encourage users switching to native partitioning. 当前版本（截至 PG 15）仅接受 bugfix，不再新增功能。因此，对于 12 及以上版本，强烈建议直接使用原生分区语法，避免引入外部依赖。

尽管 pg_partman 提供了自动分区管理（如按时间预建分区），但其实现依赖于 planner_hook 和 executor_hook，会拦截查询路径并加载所有分区元数据到进程内存，可能导致内存开销过大。此外，其自动创建分区逻辑存在风险：若插入一条未来数十年后的数据（例如 2100 年），插件会一次性创建大量分区（如按月分区需创建 75*12=900 个），极易耗尽系统资源或触发事务超时。

pg_partnerman：纯 SQL 运维自动化

pg_partnerman 是一个纯 SQL 实现的分区管理扩展，不涉及任何内核级钩子（hooks），完全依赖原生分区的执行路径。自 5.0 版本起，仅允许管理员角色操作，提供以下核心功能：

  • 自动创建未来分区（基于时间窗口预建）
  • 自动归档过期分区（迁移至其他表空间或删除）
  • 支持按 Range、List、Hash 三种分区策略
  • 可配置保留策略（如保留最近 6 个月数据）

其优势在于轻量级、对内核无侵入，且持续跟进 PostgreSQL 新版本。适用于重视运维自动化的场景，但需注意其不提供查询加速能力，所有查询走原生分区剪裁（Partition Pruning）。

timescaledb：时序场景的超表

timescaledb 并非单纯的分区插件，而是一个完整的时序数据库扩展。其超表（Hypertable）在底层基于 PostgreSQL 的分区表实现，但增加了时间维度的自动分片（按时间和空间双重维度），并提供面向时序分析的专用函数：

  • time_bucket()：按指定时间间隔聚合
  • gapfill()：填充缺失时间点
  • 连续聚集（Continuous Aggregates）：自动维护物化视图，实时聚合最新数据

在时序场景下，数据频繁写入且极少更新，历史数据价值递减。timescaledb 可自动按时间分区，并支持数据压缩、降采样等高级特性。若业务具有明显的时序特征，该插件是比原生分区更优的选择。

扩展查询协议与执行计划缓存

PostgreSQL 支持两种查询协议：

  • 简单查询协议（Simple Query Protocol）：客户端将完整 SQL 字符串发送至服务端，服务端立即进行解析、分析、重写、规划、执行全流程。每次执行均独立，无法复用执行计划。
  • 扩展查询协议（Extended Query Protocol） ：分为解析、绑定、执行三个阶段。客户端先发送带占位符的 SQL（如 SELECT * FROM t WHERE id = $1），服务端解析生成预备语句（Prepared Statement）；后续执行时，仅传递参数值进行绑定，服务端可复用已有执行计划。

扩展协议的优势在于减少重复解析开销，尤其适用于批量执行同类 SQL。但 PostgreSQL 并非盲目复用执行计划，而是通过 plan_cache_mode 参数控制行为：

  • auto（默认）：前 5 次执行使用通用计划（Generic Plan），之后若发现特定计划（Custom Plan）更优则切换。
  • force_custom_plan：每次执行均重新规划，不使用缓存计划。
  • force_generic_plan：强制使用通用计划，忽略参数值。

某些场景下，绑定变量可能导致执行计划不准确。例如，对于倾斜数据（Skewed Data），不同的参数值可能适合不同的索引扫描或连接策略。PostgreSQL 的通用计划基于参数化后的统计信息估算，若估算偏差较大，会导致性能骤降。此时可设置 plan_cache_mode = force_custom_plan 强制重新规划。

常见报错：

  • could not find pathkey item to sort：通常出现在计划缓存中排序键与当前绑定变量不匹配，多见于复杂查询的 ORDER BY 或分组操作。
  • variable not found in subplan target list：绑定变量在子计划中未正确映射，通常源于计划缓存的重用逻辑缺陷。

上述问题可通过设置 plan_cache_mode 规避，或在应用端使用简单查询协议（如 JDBC 的 PreparedStatement 可设置 preferQueryMode=simple）。

API 速览

pg_rewrite 插件函数

函数签名：

sql 复制代码 
pg_rewrite.rewrite_table(
    source_table text,        -- 源普通表名（含 schema）
    target_table text,        -- 目标分区表名
    old_table_suffix text,    -- 原表重命名后缀
    max_lock_time text        -- 锁超时时间（如 '5s'）
) RETURNS void

说明 ：该函数使用逻辑复制将 source_table 数据在线迁移至 target_table（必须是分区表），完成后将原表重命名为 源表名_old_table_suffix，同时将目标表重命名为源表名。max_lock_time 用于控制获取排他锁的最长等待时间，超时则抛出异常。

pg_partnerman 管理函数（典型）

sql 复制代码 
-- 创建分区管理配置
SELECT partnerman.create_partitioned_table(
    parent_table text,
    partition_type text,      -- 'range' / 'list' / 'hash'
    partition_interval interval,  -- 如 '1 month'
    retention_interval interval   -- 如 '6 months'
);

-- 手动创建下一个分区
SELECT partnerman.create_next_partition(parent_table text);

-- 归档旧分区
SELECT partnerman.archive_old_partitions(parent_table text, archive_schema text);

timescaledb 超表创建

sql 复制代码 
-- 创建超表
SELECT create_hypertable('table_name', 'time_column', chunk_time_interval => interval '1 day');

-- 创建连续聚集视图
CREATE MATERIALIZED VIEW daily_summary
WITH (timescaledb.continuous) AS
SELECT time_bucket('1 day', time_col) AS bucket, metric, avg(value)
FROM measurements GROUP BY bucket, metric;

Demo 完整示例（Node.js + pg）

本示例演示如何使用 Node.js 连接 PostgreSQL，通过扩展查询协议执行批量插入，并演示 plan_cache_mode 的调整效果。

环境准备

  • PostgreSQL 12+（已启用扩展协议）
  • Node.js 14+
  • 安装 pg 驱动：npm install pg

数据库准备

sql 复制代码 
CREATE TABLE demo_scores (
    id serial PRIMARY KEY,
    student_id int,
    score numeric(5,2),
    exam_date date
);

-- 插入测试数据（略）

Node.js 代码

ts 复制代码 
import { Client } from 'pg';

// 连接配置
const client = new Client({
    host: 'localhost',
    port: 5432,
    database: 'testdb',
    user: 'postgres',
    password: 'secret'
});

async function run() {
    await client.connect();

    // 设置 plan_cache_mode 为 force_custom_plan（演示）
    await client.query("SET plan_cache_mode = 'force_custom_plan'");

    // 预备语句（使用扩展查询协议）
    const queryText = 'SELECT * FROM demo_scores WHERE student_id = $1 AND score > $2';
    const values1 = [101, 80];
    const values2 = [102, 90];

    // 第一次执行（会生成执行计划）
    const res1 = await client.query(queryText, values1);
    console.log('Result 1 rows:', res1.rowCount);

    // 第二次执行（复用计划，但若 force_custom_plan 会重新规划）
    const res2 = await client.query(queryText, values2);
    console.log('Result 2 rows:', res2.rowCount);

    // 演示绑定变量错误（模拟 plan_cache_mode = auto 时的潜在问题）
    // 实际业务中可监控执行计划变化

    await client.end();
}

run().catch(console.error);

运行说明：

  1. 确保 PostgreSQL 运行并创建数据库 testdb。
  2. 执行 SQL 创建表并插入若干测试数据（至少两个不同 student_id）。
  3. 运行 ts-node demo.ts（或编译为 JS 后运行）。

技术点总结：

  • 使用 pg 驱动默认支持扩展查询协议（参数化查询）。
  • 通过 SET plan_cache_mode 可调整计划缓存策略，影响性能。
  • 此 Demo 未涉及分区插件，但可类比迁移场景中的批量数据操作。

多语言示例

本部分基于前述 Node.js 示例，提供 Go、Python 和 Java 三种语言的等效实现，演示如何使用参数化查询（扩展查询协议）操作 PostgreSQL，并包含 plan_cache_mode 的设置。

Go 示例

使用 lib/pq 驱动（或 pgx），以下采用 pgx/v5（支持 pgxpool 连接池），展示预备语句与参数绑定。

go 复制代码 
package main

import (
    "context"
    "fmt"
    "log"
    "os"

    "github.com/jackc/pgx/v5"
    "github.com/jackc/pgx/v5/pgxpool"
)

func main() {
    // 连接配置
    connStr := "postgres://postgres:secret@localhost:5432/testdb?sslmode=disable"
    pool, err := pgxpool.New(context.Background(), connStr)
    if err != nil {
        log.Fatal("连接池创建失败:", err)
    }
    defer pool.Close()

    ctx := context.Background()

    // 设置 plan_cache_mode = force_custom_plan
    _, err = pool.Exec(ctx, "SET plan_cache_mode = 'force_custom_plan'")
    if err != nil {
        log.Fatal("设置 plan_cache_mode 失败:", err)
    }

    // 预备语句（使用占位符 $1, $2）
    query := "SELECT id, student_id, score, exam_date FROM demo_scores WHERE student_id = $1 AND score > $2"

    // 执行第一次查询（参数 101, 80）
    rows1, err := pool.Query(ctx, query, 101, 80)
    if err != nil {
        log.Fatal("查询1失败:", err)
    }
    var count1 int
    for rows1.Next() {
        count1++
        var id int
        var studentID int
        var score float64
        var examDate string
        err = rows1.Scan(&id, &studentID, &score, &examDate)
        if err != nil {
            log.Fatal("扫描行失败:", err)
        }
    }
    rows1.Close()
    fmt.Printf("查询1 行数: %d\n", count1)

    // 执行第二次查询（参数 102, 90）
    rows2, err := pool.Query(ctx, query, 102, 90)
    if err != nil {
        log.Fatal("查询2失败:", err)
    }
    var count2 int
    for rows2.Next() {
        count2++
        var id int
        var studentID int
        var score float64
        var examDate string
        err = rows2.Scan(&id, &studentID, &score, &examDate)
        if err != nil {
            log.Fatal("扫描行失败:", err)
        }
    }
    rows2.Close()
    fmt.Printf("查询2 行数: %d\n", count2)
}

运行说明：

  1. 安装 Go 1.18+ 和 pgx 驱动：go get github.com/jackc/pgx/v5/pgxpool
  2. 确保 PostgreSQL 已启动，并已创建 testdb 数据库及 demo_scores 表（插入若干测试数据）。
  3. 修改连接字符串（主机、端口、用户名、密码、数据库名）以匹配环境。
  4. 执行 go run main.go。

代码说明：

  • 使用 pgxpool 管理连接池，提升并发效率。
  • 通过 pool.Exec 执行 SET 语句调整 plan_cache_mode。
  • 直接使用 pool.Query 传递参数，驱动内部采用扩展查询协议。
  • 遍历结果集并统计行数，未使用结构体映射以保持简洁。

技术点总结：

  • pgx/v5 默认支持扩展查询协议，参数化查询自动防止 SQL 注入。
  • 通过会话级设置 plan_cache_mode 控制计划缓存行为。
  • 连接池 pgxpool 适用于生产环境，需注意上下文超时管理。

Python 示例

使用 psycopg2（2.9+）或 asyncpg，以下使用 psycopg2 的同步方式，演示参数化查询。

python 复制代码 
import psycopg2
import psycopg2.extras

def main():
    # 连接参数
    conn = psycopg2.connect(
        host="localhost",
        port=5432,
        dbname="testdb",
        user="postgres",
        password="secret"
    )
    conn.autocommit = True  # 避免隐式事务
    cur = conn.cursor()

    # 设置 plan_cache_mode
    cur.execute("SET plan_cache_mode = 'force_custom_plan'")

    # 预备查询（使用 %s 占位符，psycopg2 自动转为 $1, $2）
    query = "SELECT id, student_id, score, exam_date FROM demo_scores WHERE student_id = %s AND score > %s"

    # 第一次查询
    cur.execute(query, (101, 80))
    rows1 = cur.fetchall()
    print(f"查询1 行数: {len(rows1)}")

    # 第二次查询
    cur.execute(query, (102, 90))
    rows2 = cur.fetchall()
    print(f"查询2 行数: {len(rows2)}")

    cur.close()
    conn.close()

if __name__ == "__main__":
    main()

运行说明：

  1. 安装 Python 3.8+ 和 psycopg2：pip install psycopg2-binary。
  2. 确保 PostgreSQL 可用并已准备测试数据。
  3. 修改连接参数（主机、端口、库名、用户、密码）。
  4. 执行 python demo.py。

代码说明：

  • psycopg2 使用 %s 占位符，内部转换为 PostgreSQL 的 $1 格式。
  • conn.autocommit = True 使每个语句自动提交，避免事务阻塞。
  • 结果通过 fetchall() 一次性获取，适合小数据量场景。

技术点总结：

  • psycopg2 默认使用扩展查询协议（参数化查询）。
  • 支持 plan_cache_mode 调整，与 PostgreSQL 会话级设置无缝集成。
  • 可通过 cursor.mogrify() 查看最终 SQL 用于调试。

Java 示例

使用 JDBC（PostgreSQL JDBC Driver 42.7+），采用 PreparedStatement 实现参数化查询，并演示 preferQueryMode 设置。

java 复制代码 
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

public class Demo {
    public static void main(String[] args) {
        String url = "jdbc:postgresql://localhost:5432/testdb";
        String user = "postgres";
        String password = "secret";

        // 设置连接参数，强制使用简单查询协议（演示）
        // 也可通过 preferQueryMode=simple 或 extended 控制
        // 此处默认为 extended（支持扩展协议）
        String urlWithParams = url + "?preferQueryMode=extended";

        try (Connection conn = DriverManager.getConnection(urlWithParams, user, password)) {
            // 设置 plan_cache_mode
            try (java.sql.Statement stmt = conn.createStatement()) {
                stmt.execute("SET plan_cache_mode = 'force_custom_plan'");
            }

            // 预备语句
            String sql = "SELECT id, student_id, score, exam_date FROM demo_scores WHERE student_id = ? AND score > ?";
            try (PreparedStatement pstmt = conn.prepareStatement(sql)) {
                // 第一次查询
                pstmt.setInt(1, 101);
                pstmt.setDouble(2, 80.0);
                try (ResultSet rs = pstmt.executeQuery()) {
                    int count1 = 0;
                    while (rs.next()) {
                        count1++;
                    }
                    System.out.println("查询1 行数: " + count1);
                }

                // 第二次查询（复用 PreparedStatement，但会重新绑定参数）
                pstmt.setInt(1, 102);
                pstmt.setDouble(2, 90.0);
                try (ResultSet rs = pstmt.executeQuery()) {
                    int count2 = 0;
                    while (rs.next()) {
                        count2++;
                    }
                    System.out.println("查询2 行数: " + count2);
                }
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }
}

运行说明：

  1. 安装 Java 11+ 和 PostgreSQL JDBC 驱动（如 postgresql-42.7.3.jar），将其添加到 classpath。
  2. 确保数据库及测试数据已准备。
  3. 修改连接 URL 中的主机、端口、库名、用户名、密码。
  4. 编译：javac Demo.java，运行：java -cp .:postgresql-42.7.3.jar Demo（Windows 用 ; 分隔）。

代码说明：

  • 使用 PreparedStatement 占位符 ?，由驱动映射为 $1, $2。
  • 连接 URL 参数 preferQueryMode=extended 明确使用扩展协议（默认即为 extended），也可设为 simple 切换为简单协议。
  • 每次执行 executeQuery() 前重新绑定参数值，驱动内部会发送 Bind 消息复用解析计划。
  • 通过 Statement 执行 SET 调整 plan_cache_mode。

技术点总结：

  • JDBC 驱动支持扩展查询协议，PreparedStatement 的 executeQuery() 对应扩展协议的 Execute 阶段。
  • preferQueryMode 可控制协议选择：extended（默认）、extendedForPrepared（仅预备语句用扩展）、simple（全部简单协议）。
  • 通过 plan_cache_mode 可进一步控制服务端计划缓存策略，两者结合可灵活调整性能。

多语言对比表格

特性 Go (pgx/v5) Python (psycopg2) Java (JDBC) Node.js (pg)
驱动/库 github.com/jackc/pgx/v5 psycopg2 org.postgresql:postgresql pg
连接池支持 内置 pgxpool 需第三方（如 psycopg2.pool） 内置 HikariCP 等 内置 pg.Pool
占位符 $1, $2 %s（自动转 $1） ?（自动转 $1） $1, $2
扩展查询协议 默认启用 默认启用 默认启用（preferQueryMode=extended） 默认启用
设置 plan_cache_mode pool.Exec(ctx, "SET ...") cur.execute("SET ...") stmt.execute("SET ...") client.query("SET ...")
参数绑定方式 直接作为 Query 参数 元组传入 execute setInt, setDouble 等方法 数组传入 query
结果集遍历 rows.Next() + Scan fetchall() / 迭代 rs.next() + getXXX rows 事件或异步迭代
事务支持 显式 Begin / Commit 默认自动提交（可关闭 autocommit） 默认自动提交（可设置 setAutoCommit(false)） 显式 begin / commit
上下文/超时 支持 context.Context 可通过 statement_timeout 或 socket 超时 通过 setQueryTimeout 通过 timeout 选项或 statement_timeout
典型应用场景 微服务、高并发 数据科学、脚本运维 企业级应用、Spring Boot 全栈、轻量级 API

对比说明：

  • 所有语言驱动均支持扩展查询协议，参数化查询可防止 SQL 注入。
  • 调整 plan_cache_mode 的语法一致，均通过执行 SET 语句实现。
  • 占位符风格因驱动而异，但底层均映射为 PostgreSQL 的 $n 格式。
  • 连接池和事务管理因生态不同，但核心数据库交互逻辑高度相似。

以上示例可直接运行，验证扩展查询协议下 plan_cache_mode 对执行计划的影响（需在数据库端启用 auto_explain 或查看 pg_stat_statements 观察实际计划）。

项目难点与解决方案

核心难点

  • 在线迁移非分区表：在不中断业务的前提下将大表转换为分区表，需解决数据一致性、锁时长和增量同步问题。
  • 分区插件选择：原生分区已成熟，但历史遗留系统仍使用 pg_partman，需评估迁移风险。
  • 扩展查询协议带来的计划缓存缺陷：绑定变量可能导致次优执行计划，尤其在数据分布不均时。

解决方案

  • 采用 pg_rewrite 结合逻辑复制，通过短暂的排他锁完成切换，可控制在秒级。
  • 升级至 PostgreSQL 12+ 后，逐步停用 pg_partman，改用原生 DDL 或 pg_partnerman 做纯 SQL 管理。
  • 监控 pg_stat_statements 和 auto_explain，识别计划缓存导致的性能问题，必要时设置 plan_cache_mode = force_custom_plan 或应用层强制简单查询。

广度

涉及逻辑复制、分区管理、查询优化、时序数据库等多个领域。

深度

深入剖析了 pg_partman 废弃原因、扩展协议的执行计划缓存机制及常见报错根因。

复杂度

涵盖了多个插件的比较、版本兼容性、内存开销、事务并发控制等复杂因素。

官方文档

参考链接

总结

本文全面梳理了 PostgreSQL 分区相关的第三方插件生态，明确了各插件的定位、适用版本及维护状态，并重点剖析了扩展查询协议的工作原理、计划缓存策略及常见问题。技术要点包括：

  • pg_rewrite 利用逻辑复制实现在线非分区表迁移，适合升级场景。
  • pg_partman 已过时，12+ 建议转向原生分区。
  • pg_partnerman 提供纯 SQL 运维自动化，适合轻量级管理。
  • timescaledb 是时序场景的强力扩展，底层仍依赖分区。
  • 扩展查询协议可提升批量执行性能，但需警惕计划缓存导致的次优计划，可通过 plan_cache_mode 调控。
  • 对象名长度不得超过 63 字符，否则会截断导致约束查找失败。

合理选用插件并理解内部机制，可有效提升分区场景下的运维效率和查询性能。

相关推荐
小蒜学长1 小时前
基于Django的社区团购购物平台的设计与实现（代码+数据库+LW）
数据库·后端·python·django
刘婉晴1 小时前
【AI提效】利用 qwenwork 智能体平台（免费）实现 webgoat 靶场 SQL 注入速通
数据库·sql
影寂ldy1 小时前
Modbus-ASCII 协议 + LRC校验
笔记·网络协议·c#
__zRainy__1 小时前
Node系列 · 数据库：MySQL 安装
数据库·后端·mysql·node.js
金立基包装胶水1 小时前
纸袋封口热封胶不粘是什么原因？
大数据·笔记·其他
sibylyue1 小时前
MariaDB / H2
数据库·mariadb
chnyi6_ya1 小时前
论文阅读笔记 | From Priors to Perception: Grounding Video-LLMs in Physical Reality
论文阅读·笔记
zone_z2 小时前
07 · 等待事件与 OWI 方法：从 OSW 到 BUG 的完整破案实录
linux·数据库·oracle·ffmpeg·bug·troubleshooting
A.说学逗唱的Coke2 小时前
【数据库专题】ClickHouse 深度实战：从列式存储原理到 PB 级海量日志与可观测性分析
数据库·clickhouse·硬件架构
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02GitHub 镜像站点032026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？04微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新05历年考研数学一、数学二、数学三真题试卷及答案PDF06Agnes AI 免费 API 接入指南：文本、生图、生视频，一套接口全免费07AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路082026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片09VSCode+CodeX扩展，无法启动10如何新建文件夹？ 电脑新建文件夹的4种方法