线上在Docker中跑MySQL会怎样

Rain的Java大神实战圈2026-08-25 10:00

线上在Docker中跑MySQL会怎样

📌 总体结论

完全可行，但绝对不能直接裸跑默认配置！

Docker 跑 MySQL 是目前互联网大厂的主流部署方式之一，但如果忽略容器化与数据库特性的冲突，会导致数据丢失、性能暴跌、服务不可用等严重问题。

✅ 优势（为什么大厂都这么做？）

  • 🚀 环境一致性：从开发到生产环境完全一致，杜绝 "我本地能跑" 的问题
  • ⚡ 快速部署：秒级启动实例，便于扩容和灾备
  • 🔒 资源隔离：不同 MySQL 实例之间互不影响
  • 📦 标准化交付：便于 CI/CD 流水线集成，提升运维效率

⚠️ 核心问题（面试必考点，也是最大的坑）

这是面试官最想听到的部分，也是区分初级和高级工程师的关键。

1. 🔴 数据持久化问题（最致命）

  • 默认情况下，MySQL 数据存储在容器内部的/var/lib/mysql目录
  • 容器删除或重建时，所有数据会永久丢失！
  • 即使使用 bind mount，也可能因为 UID/GID 权限不匹配导致 MySQL 无法启动

2. 🚀 性能问题（最大争议点）

  • 存储 IO 性能瓶颈 ：Docker 默认的 overlay2 文件系统采用写时复制 (CoW) 机制，不适合数据库的随机 IO 场景，裸跑性能会下降 30%-50%
  • 网络性能损耗：默认 bridge 模式下，网络转发会有额外开销
  • 资源限制陷阱：如果不设置内存限制，MySQL 会占用宿主机所有可用内存；如果设置不当，会被 Linux OOM killer 直接杀掉

3. ⚙️ 配置问题

  • 官方镜像的默认配置是为开发环境设计的，完全不适合生产
  • 关键参数如innodb_buffer_pool_size、max_connections等需要根据实际情况调整
  • 时区、字符集等配置容易被忽略，导致数据乱码

4. 🛡️ 高可用与运维问题

  • 单容器 MySQL 没有高可用，容器崩溃会导致服务中断
  • 日志收集、监控、备份恢复比物理机部署更复杂
  • 容器的生命周期管理与数据库的持久化特性存在冲突

📊 物理机 vs Docker 部署 MySQL 对比

维度 物理机部署 Docker 部署（优化后）
部署速度 慢（小时级） 快（秒级）
环境一致性 差 极好
资源隔离 差 好
性能 100% 90%-95%
运维复杂度 高 低（标准化后）
扩容速度 慢（天级） 快（分钟级）
适用场景 超大规模核心数据库 绝大多数业务场景

🛠️ 生产环境最佳实践（面试官加分项）

1. 数据持久化

  • ✅ 必须使用 Docker 命名卷 (named volume)，不要使用 bind mount
  • ✅ 只挂载数据目录/var/lib/mysql，不要挂载整个 MySQL 目录
  • ✅ 定期备份卷数据，制定完整的备份恢复策略

2. 性能优化

  • ✅ 存储优化：使用本地 SSD 或高性能云存储，禁用 overlay2 的写时复制
  • ✅ 资源限制：合理设置 CPU 和内存限制，内存至少为数据量的 50% 以上
  • ✅ 网络优化：生产环境使用--network=host模式，消除网络转发开销

3. 配置优化

  • ✅ 自定义my.cnf配置文件，通过 volume 挂载
  • ✅ 关键参数调优，适配容器资源限制

4. 高可用与运维

  • ✅ 使用 Docker Compose 或 Kubernetes 部署主从复制集群
  • ✅ 配置 Prometheus+Grafana 监控 MySQL 关键指标
  • ✅ 使用官方镜像，定期更新安全补丁
  • ✅ 禁止在容器内执行docker restart命令，优先使用mysqladmin shutdown

💻 核心代码与技术亮点（面试加分项）

1. 生产级 Docker Compose 完整配置（⭐⭐⭐⭐⭐）

yaml 复制代码 
version: '3.8'

services:
  mysql:
    image: mysql:8.0.36 # 固定版本，避免latest标签带来的不确定性
    container_name: mysql-prod
    restart: always # 容器崩溃自动重启
    
    # 技术亮点1：精确资源限制+禁用swap（MySQL性能杀手）
    deploy:
      resources:
        limits:
          cpus: '4'
          memory: 8G
        reservations:
          cpus: '2'
          memory: 4G
    memswap_limit: 8G # memory-swap=memory 完全禁用swap
    
    # 技术亮点2：解决UID/GID权限不匹配问题（999是官方mysql用户的UID）
    user: "999:999"
    
    # 技术亮点3：健康检查（确保服务真正可用，而非容器启动）
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-uroot", "-p${MYSQL_ROOT_PASSWORD}"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s # 给MySQL足够的初始化时间
    
    # 技术亮点4：网络优化（生产环境建议改为network_mode: host）
    network_mode: bridge
    ports:
      - "127.0.0.1:3306:3306" # 只暴露给本地，增加安全性
    
    # 技术亮点5：数据持久化+临时目录内存挂载
    volumes:
      - mysql_data:/var/lib/mysql # 命名卷，绕过overlay2的CoW机制
      - ./conf/my.cnf:/etc/mysql/conf.d/my.cnf:ro # 只读挂载配置文件
      - ./logs:/var/log/mysql
      # 技术亮点6：临时文件挂载到tmpfs，大幅提升性能
      - type: tmpfs
        target: /tmp
        tmpfs:
          size: 1G
    
    # 环境变量（建议使用.env文件管理敏感信息）
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
      TZ: Asia/Shanghai # 统一时区，避免时间错乱

volumes:
  mysql_data:
    driver: local # 使用本地存储驱动，性能最好

2. MySQL 生产环境自定义配置my.cnf

ini 复制代码 
[mysqld]
# 基础配置
port=3306
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci
default-time_zone='+8:00'

# 技术亮点：根据容器内存动态调整（8G内存示例）
innodb_buffer_pool_size=6G # 约为容器内存的75%，最关键参数
innodb_buffer_pool_instances=4 # 每个instance 1.5G，提升并发性能

# 性能优化
innodb_flush_log_at_trx_commit=1 # 保证数据一致性
sync_binlog=1
max_connections=1000
wait_timeout=600
interactive_timeout=600

# 日志配置
slow_query_log=1
slow_query_log_file=/var/log/mysql/slow.log
long_query_time=2
log_queries_not_using_indexes=1

# 禁用DNS解析，提升连接速度
skip-name-resolve

3. 自动化全量备份脚本（生产可用）

shell 复制代码 
#!/bin/bash
# mysql_backup.sh - 生产环境MySQL自动备份脚本

# 配置信息
BACKUP_DIR="/data/backup/mysql"
CONTAINER_NAME="mysql-prod"
MYSQL_ROOT_PASSWORD="your_password"
RETENTION_DAYS=7 # 保留最近7天的备份

# 创建备份目录
mkdir -p ${BACKUP_DIR}

# 技术亮点：使用--single-transaction保证备份一致性，不锁表
BACKUP_FILE="${BACKUP_DIR}/mysql_$(date +%Y%m%d_%H%M%S).sql.gz"
docker exec ${CONTAINER_NAME} mysqldump \
  -uroot -p${MYSQL_ROOT_PASSWORD} \
  --single-transaction \
  --routines \
  --triggers \
  --all-databases | gzip > ${BACKUP_FILE}

# 检查备份是否成功
if [ $? -eq 0 ]; then
  echo "备份成功: ${BACKUP_FILE}"
else
  echo "备份失败!"
  exit 1
fi

# 自动删除过期备份
find ${BACKUP_DIR} -name "mysql_*.sql.gz" -mtime +${RETENTION_DAYS} -delete
echo "已删除${RETENTION_DAYS}天前的备份"

🎯 技术难点与解决方案对照表（面试官必问）

技术难点 根本原因 解决方案 关键注意事项
🔴 容器删除数据丢失 容器文件系统是临时的，生命周期与容器一致 使用 Docker 命名卷 (named volume) 持久化数据 ❌ 禁止使用 bind mount 挂载宿主机目录✅ 只挂载/var/lib/mysql目录
🚀 存储 IO 性能暴跌 overlay2 的写时复制 (CoW) 机制对随机写极不友好 命名卷会绕过 overlay2，直接使用宿主机文件系统 ✅ 使用本地 SSD 或高性能云盘❌ 不要使用网络存储作为数据卷
⚠️ MySQL 被 OOM Killer 杀死 Linux 内核会优先杀死内存占用高的进程 1. 合理设置内存限制2. 禁用 swap3. 调整 OOM 评分 ✅ --memory-swap=8G 完全禁用 swap✅ --oom-score-adj=-500 降低被杀死概率
🌐 网络性能损耗 默认 bridge 模式需要 NAT 转发，有额外开销 生产环境使用--network=host模式 ✅ 网络性能接近物理机❌ 注意端口冲突问题
🔑 UID/GID 权限不匹配 官方镜像使用 mysql 用户 (UID=999) 运行 1. 启动时指定user: "999:999"2. 使用命名卷自动管理权限 ❌ 不要用 root 用户运行 MySQL✅ 命名卷会自动设置正确权限
⏰ 时区和字符集乱码 官方镜像默认时区是 UTC，字符集是 latin1 1. 设置TZ=Asia/Shanghai环境变量2. 配置文件中指定 utf8mb4 ✅ 统一使用 utf8mb4，支持 emoji✅ 数据库、表、连接字符集保持一致
📝 日志管理困难 容器内日志会随容器删除丢失 1. 将日志目录挂载到宿主机2. 使用 ELK 或 Loki 收集日志 ✅ 配置日志轮转，避免磁盘占满✅ 慢查询日志单独收集分析
🛡️ 高可用难以实现 单容器没有故障转移能力 1. 部署主从复制集群2. 使用 Kubernetes StatefulSet 管理 ✅ 主从数据同步使用 GTID 模式✅ 配置自动故障转移
💾 备份恢复复杂 不能直接复制容器文件系统 1. 使用 mysqldump 逻辑备份2. 使用 xtrabackup 物理备份 ✅ 定期测试备份恢复流程✅ 关键业务每天全量 + 增量备份

真实面试模拟

真实面试模拟

面试官 💬

"我看到你简历上写了 Docker 和 MySQL，而且有线上经验。那我直接问：线上把 MySQL 跑在 Docker 里，会怎样？你先别急着说能用，凭直觉说会不会出事儿？"

求职者 🐳

"会出事儿，如果裸跑的话。但要是把该卡的点都卡死了，它也能在生产上活得好好的。我的结论是：能跑，但必须'戴镣铐跳舞'，有 4 个致命点必须处理掉。"

面试官 💬

"嗯，哪 4 个？一个一个说，不用太理论，就说你踩过的或设计时死磕过的。"

求职者 🐳

"好的，我先给您画张最精简的架构，然后对着图讲。"

"就这张图，4 个致命点全在图里了。分别是：数据持久化、性能、高可用、运维升级。"

🔥 致命点1：数据持久化 ------ "删容器跑路"不是开玩笑

"默认 MySQL 镜像的数据写在容器可写层，docker rm 一执行，整个库直接蒸发。所以生产必须挂 Volume，而且得是宿主机目录或者持久化 Volume。

我线上启动命令一定是这样的：

shell 复制代码 
docker run -d \
  --name mysql-prod \
  -v /data/mysql:/var/lib/mysql \   # 命根子挂载
  -e MYSQL_ROOT_PASSWORD=... \
  mysql:8.0 \
  --character-set-server=utf8mb4 \
  --collation-server=utf8mb4_unicode_ci

没挂 Volume 直接上线的，都是在给事故搭桥。"

🚄 致命点2：性能 ------ 网络和磁盘都有隐形税

"性能损耗分三层：

  • 网络 ：docker bridge 走宿主机虚拟网卡，小事务 OLTP 场景累积延迟明显。如果对延迟敏感，我宁可用 --network host 牺牲一点隔离性换延迟降低。
  • 存储：Overlay2 对数据库这种随机写不友好，所以我一定挂载裸盘 ext4/xfs，绕过 Storage Driver。
  • 资源争抢 ：不给容器加 --cpus=4 --memory=8g，宿主机其他容器能把 MySQL CPU 打满，慢查询瞬间堆积。

下面这张对比表，您一看就清楚 Docker MySQL 的代价在哪。

维度 Docker MySQL 物理机/虚拟机 MySQL 云数据库 RDS
数据持久性 ⚠️ 必须手动挂载 Volume，否则删库跑路 ✅ 直接写盘 ✅ 自动多副本
性能开销 🔸 网络+存储驱动约 5-15% 损耗 ✅ 几乎无额外开销 ✅ 底层优化，但走网络
高可用 ❌ 单点，需自建主从/Operator 🔸 手工搭建 MHA/MGR ✅ 开箱即用自动切换
备份恢复 🔸 自备 xtrabackup+定时任务 🔸 同上 ✅ 自动物理备份+时间点恢复
运维成本 🔸 升级镜像、改配置要注意数据卷 🔸 yum/apt 升级 ✅ 控制台点点，或全托管
隔离性 🐳 cgroup 隔离，但宿主机高负载会互相影响 ✅ 独立硬件 ✅ 独立实例

🔁 致命点3：高可用 ------ 容器挂了不会自己活

"docker run --restart=unless-stopped 只是进程拉起，不是高可用。真正故障转移必须上编排。我目前觉得靠谱的两种方案：

  • 有 K8s 的：MySQL Operator（如 Bitpoke/Percona）+ StatefulSet，自动主从、自动故障转移。
  • 没 K8s 的折中：Docker Compose + 自建主从 + Orchestrator 做拓扑发现，至少做到故障秒级发现。

另外 Java 侧 JDBC 必须配上超时，防止容器 IP 漂移导致线程卡死：

yaml 复制代码 
spring:
  datasource:
    url: jdbc:mysql://mysql-master:3306/db?connectTimeout=3000&socketTimeout=60000
    hikari:
      connection-timeout: 3000
      validation-timeout: 1000

否则一挂数据库，连接池耗尽，整个服务雪崩。

🛠️ 致命点4：运维升级 ------ 改配置、升版本都是技术活

升级大版本（8.0.30→8.0.35）的步骤：停容器 → 备份数据卷 → 跑新镜像 → 执行 mysql_upgrade。配置修改我坚持挂载自定义 my.cnf 到宿主机，改完 docker restart 就行，不会进容器用 vi。

日志和备份呢？慢日志挂到 Volume 再用 Filebeat 进 ELK，备份用 xtrabackup 定时推到 NAS。这步不做，出了事没法查，也没法恢复。

面试官 💬

"讲得挺细。那你觉得，什么场景能这么用，什么场景打死也不能用？"

求职者 🐳

✅ 可以上线的情况：

  • 非核心业务、内部管理系统，允许分钟级恢复。
  • 已经有 K8s Operator，并且做过故障演练、备份校验。
  • 给客户做私有化交付，用 docker-compose 快速部署，SLA 要求不高。

❌ 坚决不能用的：

  • 核心交易库、金融类、每秒万级写入。
  • 团队只会 docker run，没有容器化运维能力。
  • 多实例强一致性写入（分布式事务）。这种趁早用云 RDS 或者专门的存储团队扛。"

面试官 💬

"最后，如果让你画一个生产可用的最小 Docker MySQL 架构，怎么画？"

求职者 🐳

"这样，一张图收尾："

"应用和 MySQL 同宿主机 bridge 通信，数据、日志全挂载到宿主机，备份推到 NAS。混合云场景还能把 RDS 当异步灾备。这就是我在生产上验证过的最小闭环。"

面试官 🦦

"行，总结一下？"

求职者 🐳

"> 容器是无状态的，数据库是一生要强的状态。你要做的就是用 Volume、备份、高可用这三条锁链，把状态牢牢拴在地上，让 MySQL 在容器里也能体面地活着。"

面试官 💬

"你刚才说的架构挺完整，那我再抠深一点：能贴出几段你实际会用到的核心代码吗？别拿伪代码糊弄我，要能看出技术亮点的。另外，你把这个场景的技术难点和你的解决方案，用一张表给我理清楚。"

求职者 🐳

"没问题，我直接贴几段平时生产会用到的精华，然后给一张表收尾。"

🧩 核心代码片段（有技术亮点）

1. 生产级 Docker 启动脚本（含资源限制、自定义配置、网络优化）

shell 复制代码 
#!/bin/bash
# 创建数据目录并启动 MySQL 容器，适配宿主机 numa、cpu 和内存
DATA_DIR="/data/mysql"
mkdir -p $DATA_DIR /var/log/mysql /etc/mysql/conf.d

# 自定义 my.cnf 核心参数（高性能）
cat > /etc/mysql/conf.d/my.cnf <<EOF
[mysqld]
innodb_buffer_pool_size = 6G
innodb_log_file_size = 2G
innodb_flush_log_at_trx_commit = 2
innodb_io_capacity = 2000
innodb_flush_method = O_DIRECT
slow_query_log = ON
long_query_time = 0.5
EOF

docker run -d \
  --name mysql-prod \
  --network host \                          # 🔥 网络亮点：绕过 bridge 降低延迟
  --cpus=4 \
  --memory=8g \
  --restart=unless-stopped \
  -v $DATA_DIR:/var/lib/mysql \             # 数据持久化
  -v /var/log/mysql:/var/log/mysql \        # 日志外挂
  -v /etc/mysql/conf.d:/etc/mysql/conf.d \  # 配置外挂
  -e MYSQL_ROOT_PASSWORD=MySecret123 \
  mysql:8.0.35 \
  --character-set-server=utf8mb4 \
  --collation-server=utf8mb4_unicode_ci

🐳 亮点 ：--network host 在高并发 OLTP 下减少一层网络转发，innodb_flush_log_at_trx_commit=2 结合备机写入策略平衡性能与安全。

2. Java 端连接池配置（防雪崩 + 容器漂移感知）

yaml 复制代码 
spring:
  datasource:
    url: jdbc:mysql://mysql-master:3306/prod_db?useSSL=true&connectTimeout=3000&socketTimeout=60000&autoReconnect=true&failOverReadOnly=false
    hikari:
      connection-timeout: 3000
      validation-timeout: 1000
      maximum-pool-size: 20
      minimum-idle: 5
      idle-timeout: 600000
      max-lifetime: 1800000
      leak-detection-threshold: 10000

⚡ 亮点 ：socketTimeout=60000 避免网络分区时连接僵死，leak-detection-threshold 在容器环境快速发现连接泄漏。

3. 定时备份脚本（xtrabackup + 保留策略 + 故障通知）

shell 复制代码 
#!/bin/bash
BACKUP_DIR="/backup/mysql/$(date +%Y%m%d_%H%M%S)"
RETENTION_DAYS=7

xtrabackup --backup \
  --target-dir=$BACKUP_DIR \
  --user=root --password=MySecret123 \
  --host=127.0.0.1 \
  --compress --parallel=4         # 压缩 + 多线程

# 保留最近7天备份
find /backup/mysql/ -maxdepth 1 -type d -mtime +$RETENTION_DAYS -exec rm -rf {} \;

# 钉钉/企业微信告警
if [ $? -ne 0 ]; then
  curl -实战项目与面试模拟 POST -H 'Content-Type: application/json' \
    -d '{"msgtype":"text","text":{"content":"MySQL 备份失败，请检查！"}}' \
    https://oapi.dingtalk.com/robot/send?access_token=xxx
fi

📦 亮点：xtrabackup 热备份不锁表 + 压缩节省 NAS 空间 + 失败即时告警，适合 Docker 数据卷备份。

4. K8s StatefulSet + MySQL Operator 声明式高可用（核心片段）

yaml 复制代码 
apiVersion: mysql.presslabs.org/v1alpha1
kind: MysqlCluster
metadata:
  name: mysql-prod
spec:
  replicas: 3
  secretName: mysql-secret
  volumeSpec:
    persistentVolumeClaim:
      storageClassName: fast-ssd
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 200Gi
  podSpec:
    resources:
      requests:
        memory: 8Gi
        cpu: 4
      limits:
        memory: 16Gi
        cpu: 8
  mysqlVersion: "8.0"

🚀 亮点 ：通过 Operator 自动化主从复制、故障转移、备份调度，无需手工 docker exec，直接声明式管理。

📋 技术难点 & 解决方案全表

技术难点 为何是难点 我的解决方案 涉及关键代码/工具
数据丢失风险 容器删除数据层消失 挂载宿主机或持久卷，定期热备份 -v /data/mysql:/var/lib/mysql + xtrabackup 定时任务
网络延迟增高 bridge 模式多一层 NAT 使用 --network host 或 macvlan 降低延迟 --network host，应用 JDBC 超时精细配置
存储性能损耗 Overlay2 写时复制不适用数据库 直接挂载裸块设备或宿主机 ext4/xfs Volume 挂载裸盘，innodb_flush_method=O_DIRECT
资源争抢 宿主机多容器竞争 CPU/内存，导致 MySQL 响应变慢甚至 OOM cgroup 硬限制 + NUMA 绑定 --cpus=4 --memory=8g，CPU pinning
单点故障无自动恢复 Docker 重启只拉进程，不解决节点宕机 采用 K8s StatefulSet+Operator 或 Orchestrator+主从 K8s MysqlCluster CRD 或 Docker Compose + Orchestrator
备份恢复时间点难保障 只全量备份，可能丢失大段时间数据 开启 binlog + 全量+增量结合，定期恢复演练 log-bin，PITR 脚本
配置与镜像升级风险 升级大版本可能导致数据格式不兼容或启动失败 先备份数据，再用新镜像启动并运行 mysql_upgrade 脚本化滚动升级
监控与日志收集割裂 容器内日志易丢失，监控指标需要额外采集 外挂日志目录 + Filebeat 推 ELK，MySQL Exporter 暴露指标 -v /var/log/mysql:/var/log/mysql + Prometheus Exporter
Java 应用连接池雪崩 MySQL 容器漂移或卡顿，连接池无保护导致线程占满 设置合理的连接/读/写超时，启用断路器 HikariCP 超时配置 + Resilience4j
多实例写一致性 容器化多主写入难以保证强一致 不用容器化多主写，改用 MGR 或直接上云 RDS Group Replication 或 云厂商托管

面试官 🦦

"代码能看出你确实在生产环境趟过坑。那最后用一句话总结，你怎么让 MySQL 在容器里体面活着？"

求职者 🐳

"> 容器无状态，数据库有脾气。给足资源、拴紧数据、备好退路、配好监控，四个锚点缺一不可，才能让 MySQL 在容器里既浪又稳。"

公众号"Rain的Java大神之路"

个人博客"www.javadashen.com"

相关推荐
Rain的Java大神实战圈11 小时前
高并发下的抽奖系统：不只是扣库存，还要防作弊与风控
场景设计题
Rain的Java大神实战圈3 天前
高并发下的秒杀系统架构全景：从单体到云原生的演进之路
场景设计题
Rain的Java大神实战圈4 天前
Spring事务失效的场景有哪些
场景设计题
Rain的Java大神实战圈6 天前
高并发下的排行榜系统：如何用Redis快速实现千万用户实时排名
场景设计题
Rain的Java大神实战圈6 天前
手写一个Spring容器
场景设计题
Rain的Java大神实战圈10 天前
JavaWeb开发如何解决跨域问题
场景设计题
Rain的Java大神实战圈11 天前
高并发下的热点账户余额扣减：Redis+Lua脚本实现无锁记账
场景设计题
Rain的Java大神实战圈12 天前
介绍一下常用的Token鉴权方案
场景设计题
Rain的Java大神实战圈13 天前
高并发下的抢红包设计：微信红包背后的算法与温情
场景设计题
Rain的Java大神实战圈14 天前
如何设计对外API接口
场景设计题
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接03微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新04历年考研数学一、数学二、数学三真题试卷及答案PDF05GitHub 镜像站点06人工智能（AI）发展史：详细里程碑072026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？08【一等奖版】2026 国赛 A题 药材的烘干问题09Agnes AI 免费 API 接入指南：文本、生图、生视频，一套接口全免费10ZCode 周末送额度活动开启：3 亿 Token 免费领取