1. 项目概述：为什么需要定制自己的Docker镜像？

在之前的Docker入门教程里，我们学会了如何拉取和使用现成的官方镜像，比如 nginx:latest 或者 ubuntu:20.04 。这就像去超市买预制菜，方便快捷，开袋即用。但实际工作中，我们总会遇到一些特殊需求：比如，你的应用需要特定的系统库、预装某些工具、修改默认配置，或者植入公司内部的监控代理。这时候，一个“原味”的官方镜像就无法满足要求了。

“基于Commit定制镜像”就是解决这个问题的第一把钥匙，也是Docker镜像构建中最直观、最“小白友好”的方法。它的核心逻辑非常简单：你先运行一个基础容器，就像进入了一个干净的Linux虚拟机；然后，你在容器内部进行一系列操作，比如安装软件、修改文件、配置环境；最后，你把当前这个已经被你“改造”过的容器状态，打包成一个全新的、永久的镜像。这个过程，就好比你用手机拍了一张照片，照片定格了那一刻的所有画面，而 docker commit 命令就是那个快门。

这个方法特别适合初学者理解和快速验证想法，因为它完全遵循了“所见即所得”的交互式操作逻辑。你不用去学习一门新的描述语言（比如Dockerfile），也不用担心构建过程的复杂性，直接在容器里捣鼓，满意了就保存。当然，它也有其局限性，比如难以版本化管理、构建过程不透明、可重复性差，这些我们会在后面详细讨论。但无论如何，掌握 docker commit 是理解Docker镜像分层与持久化存储的绝佳起点。

2. 核心原理：理解镜像、容器与Commit的关系

要玩转 docker commit ，必须先把Docker最核心的三个概念——镜像、容器、仓库——以及它们之间的关系捋清楚。很多新手卡壳，就是因为这几个概念搅在了一起。

镜像 是一个静态的、只读的模板。它包含了一套完整的文件系统，以及运行某个软件所需的所有依赖、配置和元数据。你可以把它想象成一个 .iso 系统安装光盘，或者一个虚拟机模板。镜像是分层的，每一层代表一次文件系统的变更（比如添加一个文件、安装一个包），这种分层设计使得镜像可以高效地共享和存储。

容器 是镜像的一个运行实例。当你执行 docker run 时，Docker引擎会从镜像创建一个可写的“容器层”，然后在这个隔离的环境里启动进程。这个容器层就像是覆盖在只读镜像上的一个透明写字板，你在容器里做的所有修改（新建文件、删除数据）都只发生在这个可写层。一旦容器被删除，这个可写层也就随之消失，这就是为什么容器本身是“无状态”的。

那么， docker commit 扮演了什么角色呢？它的作用，正是将这个临时的、可写的“容器层”，连同其下的所有只读镜像层，一起打包固化，生成一个新的、永久的镜像。这个新镜像会记录下容器当前时刻的完整状态。理解这一点至关重要： commit 操作并不是只保存了你修改的部分，而是生成一个包含了基础镜像和你所有修改的完整新镜像快照。

这里有一个常见的误解需要澄清：有人认为 commit 只是保存了差异。从结果上看，新镜像确实包含了旧镜像的所有层加上新的变更层，但从存储和使用的角度， commit 后产生的是一个独立的、完整的镜像实体。当你基于这个新镜像运行容器时，它和基于原镜像运行后再手动修改，效果是完全一样的，但过程被固化了。

3. 实操准备：环境与基础镜像选择

在开始动手之前，我们需要确保环境就绪，并选择一个合适的基础镜像作为我们改造的“画布”。

3.1 环境确认

首先，打开你的终端（Linux/macOS）或命令提示符/PowerShell（Windows），确认Docker已正确安装并运行： 

docker --version
docker info

如果这两条命令能正常输出版本和系统信息，说明环境没问题。对于Windows用户，请确保你使用的是WSL2后端或Docker Desktop，并在设置中启用了WSL2集成，这样能获得更好的性能和兼容性。

3.2 选择基础镜像

基础镜像的选择是第一步，也是决定后续操作复杂度的关键。对于小白入门，我强烈建议从轻量级的Linux发行版开始：

  1. alpine ：这是Docker世界的明星，一个极简的Linux发行版，镜像体积通常只有5MB左右。它使用 apk 作为包管理器。优点是体积小，安全性相对较高。缺点是某些软件包可能版本较旧，且 musl libc 库可能与某些依赖 glibc 的二进制文件不兼容。
  2. ubuntu / debian ：最常用的通用发行版，拥有庞大的软件仓库和社区支持。使用 apt 包管理器。优点是生态丰富，资料多，几乎不会遇到兼容性问题。缺点是镜像体积较大（精简版也有80MB以上）。
  3. centos （或 rockylinux ）：在传统企业环境中常见，使用 yum 或 dnf 包管理器。如果你学习的项目或公司环境基于此，可以选择。

对于本次入门实操，我们选择 ubuntu:22.04 作为基础。因为它更接近大多数人的使用习惯，软件安装命令（ apt ）也更普及。

拉取镜像： 

docker pull ubuntu:22.04

注意 ：虽然我们可以直接在 docker run 时自动拉取，但先显式 pull 可以确保网络通畅，并查看镜像大小，做到心中有数。

4. 分步实操：从运行容器到提交镜像

现在，我们进入核心的实操环节。我们的目标是：创建一个包含 nginx 网页服务器和 curl 网络工具的定制化Ubuntu镜像，并修改默认的欢迎页面。

4.1 第一步：交互式运行基础容器

我们首先需要进入这个“画布”内部进行操作。 

docker run -it --name my_custom_container ubuntu:22.04 /bin/bash

逐条解释这个命令：

  • docker run ：创建并运行一个新容器。
  • -it ：这是两个参数 -i 和 -t 的组合。 -i 表示保持标准输入打开， -t 表示分配一个伪终端。合起来保证我们可以与容器进行交互式操作，就像登录了一台服务器。
  • --name my_custom_container ：给容器起一个有意义的名字，方便后续操作。如果不指定，Docker会随机生成一个名字。
  • ubuntu:22.04 ：我们使用的基础镜像。
  • /bin/bash ：容器启动后要执行的命令，这里我们启动 bash shell，以便后续输入命令。

命令执行后，你会发现终端提示符变成了类似 root@a1b2c3d4e5f6:/# 的样子，这说明你已经成功进入了容器内部。这个 a1b2c3d4e5f6 就是容器的短ID。

4.2 第二步：在容器内进行定制化操作

现在，我们就在这个全新的Ubuntu系统里进行操作了。请按顺序执行以下命令：

1. 更新软件包列表： 这是使用 apt 安装软件前的标准步骤，确保获取到最新的软件源信息。 

apt update

2. 安装nginx和curl： 

apt install -y nginx curl
  • -y 参数非常重要，它表示对所有的安装提示自动回答“yes”。因为在非交互式环境（虽然我们现在是交互式）或脚本中，如果没有这个参数，安装过程会等待用户输入而卡住。

3. 创建一个自定义的欢迎页面： 默认的nginx欢迎页位于 /var/www/html/index.nginx-debian.html 。我们备份原文件后，创建一个更简单的自定义页面。 

# 备份原文件
mv /var/www/html/index.nginx-debian.html /var/www/html/index.nginx-debian.html.bak

# 使用cat命令和EOF标记创建新的index.html文件
cat > /var/www/html/index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
    <title>My Custom Docker Image</title>
</head>
<body>
    <h1>Hello from my committed Docker image!</h1>
    <p>This page is served by Nginx inside a custom Ubuntu container.</p>
    <p>Image created on: $(date)</p>
</body>
</html>
EOF

这里使用了“Here Document”（ << 'EOF' ）的语法来向文件写入多行内容，非常方便。注意，脚本中的 $(date) 在创建文件时不会被执行，它只是普通文本。如果你想在构建时生成日期，需要更复杂的处理，这里我们先保持简单。

4. 验证安装和配置： 

# 检查nginx是否安装成功
nginx -v

# 检查curl是否安装成功
curl --version

# 查看我们创建的网页文件
cat /var/www/html/index.html

操作完成后，先不要退出容器。我们的“画布”已经绘制完毕。

4.3 第三步：提交容器，生成新镜像

现在，我们需要打开 另一个终端窗口 。因为当前的终端正在容器的 bash 会话中，我们不能在其中对自身容器执行 commit 命令。

在新的终端中，执行提交命令： 

docker commit my_custom_container my-ubuntu-nginx:v1

再次逐条解释：

  • docker commit ：提交命令。
  • my_custom_container ：我们正在运行的容器的名称。如果你之前没有指定 --name ，这里需要替换为容器的ID（可以通过 docker ps 查看）。
  • my-ubuntu-nginx:v1 ：为新镜像指定的仓库名和标签。格式为 [仓库名]:[标签] 。仓库名通常小写，可以包含路径（如 yourname/app ）。标签 v1 用于标识版本。

执行成功后，会输出新镜像的长ID，例如 sha256:7b7a... 。

4.4 第四步：验证新镜像

提交完成后，我们可以在原容器的终端里输入 exit 退出并停止容器。然后，使用新镜像来运行一个容器，验证我们的定制是否成功。

  1. 查看本地镜像列表 ，确认新镜像已存在： 

    docker images | grep my-ubuntu-nginx

    你应该能看到类似 my-ubuntu-nginx v1 7b7a... 2 minutes ago 200MB 的输出。注意看镜像大小，比原始的ubuntu大了不少，这是因为我们安装了nginx等软件。

  2. 运行新镜像的容器 ，并测试服务： 

    # 后台运行一个新容器，将容器的80端口映射到主机的8080端口
docker run -d -p 8080:80 --name test_commit my-ubuntu-nginx:v1 nginx -g "daemon off;"
    • -d ：后台运行。
    • -p 8080:80 ：端口映射，将主机（你的电脑）的8080端口映射到容器的80端口（nginx默认端口）。
    • --name test_commit ：为新容器命名。
    • nginx -g "daemon off;" ：覆盖容器默认的启动命令（原本是 bash ），直接启动nginx并以前台模式运行（ daemon off 是让nginx保持在前台，否则容器会立即退出）。

  3. 访问服务 ： 打开你的浏览器，访问 http://localhost:8080 。你应该能看到我们刚才创建的“Hello from my committed Docker image!”页面。这说明包含nginx和自定义网页的镜像已经成功运行。

  4. 验证curl工具 ： 我们还可以进入这个新容器，验证curl是否也安装成功。 

    docker exec -it test_commit /bin/bash
curl --version
exit

    docker exec 命令可以在一个运行中的容器内执行命令。

5. Commit命令的进阶参数与最佳实践

基础的 docker commit 我们已经掌握了，但这个命令还有一些有用的参数，可以帮助我们生成更规范、信息更完整的镜像。

5.1 使用 -m 和 -a 参数添加元数据

在提交时，可以像Git一样添加提交信息和作者信息，这对于镜像的维护至关重要。 

docker commit \
  -m "Initial version. Installed nginx and curl, customized homepage." \
  -a "Your Name <your.email@example.com>" \
  my_custom_container \
  my-ubuntu-nginx:v1.0
  • -m ：添加提交信息，说明本次修改的内容。 强烈建议每次提交都使用 ，否则一段时间后，你根本记不清这个镜像和原版有什么区别。
  • -a ：指定镜像的作者信息。

这些信息会被记录在镜像的元数据中，可以通过 docker inspect my-ubuntu-nginx:v1.0 命令查看，在输出的JSON中找到 Config.Labels 或 Comment 字段。

5.2 使用 --change 参数应用Dockerfile指令

这是 docker commit 一个非常强大但常被忽略的功能。它允许你在提交时，直接应用一些Dockerfile支持的指令，来修改镜像的配置。比如，我们想在提交时，就设定好容器启动时的工作目录和要执行的命令： 

docker commit \
  --change='WORKDIR /app' \
  --change='CMD ["nginx", "-g", "daemon off;"]' \
  --change='ENV MODE=production' \
  my_custom_container \
  my-ubuntu-nginx:with-changes
  • --change='WORKDIR /app' ：设置容器启动后的默认工作目录为 /app 。
  • --change='CMD ...' ：设置容器启动时默认执行的命令。这里我们覆盖了基础镜像的 bash ，设置为启动nginx。
  • --change='ENV ...' ：设置环境变量。

这样提交后的镜像，其默认行为就被改变了。运行 docker run -d --name test2 my-ubuntu-nginx:with-changes ，它会直接启动nginx，而无需在 run 命令后指定。

5.3 最佳实践与注意事项

尽管 docker commit 很方便，但在生产环境中需要谨慎使用，并遵循以下最佳实践：

  1. 仅用于临时调试和学习 ： commit 最适合快速保存一个调试好的复杂环境状态，或者用于学习理解镜像分层。对于需要持续集成/持续部署（CI/CD）的项目， 永远优先使用Dockerfile 。
  2. 提交前“清理”容器 ：提交前，尽量让容器处于一个“干净”的状态。比如，删除 apt 安装过程中产生的缓存文件，可以减小镜像体积。 
    # 在容器内执行提交前的清理
apt clean
rm -rf /var/lib/apt/lists/*
  3. 一个容器，一个目的 ：尽量让一个容器只运行一个主进程，并且相关的修改都围绕这个进程。不要在一个容器里安装MySQL、Redis、Nginx、Python应用等所有东西，这违背了容器“单一职责”的原则。
  4. 使用有意义的标签 ：不要总是用 latest 。使用像 v1.0 、 v1.1 、 20240418 这样的标签，便于区分版本和回滚。
  5. 记录操作历史 ：因为你无法像Dockerfile一样有清晰的构建步骤记录，所以务必在提交信息（ -m ）中详细说明所做的更改。也可以考虑在容器内创建一个 /CHANGELOG.txt 文件记录操作。

6. 深入剖析：Commit的优缺点与Dockerfile对比

理解了“如何做”之后，我们必须深入思考“何时用”以及“为什么不用”。与标准的Dockerfile构建方式对比，能让我们更清楚 commit 的定位。

6.1 Commit方式的优点

  1. 学习成本极低 ：不需要学习Dockerfile语法，对熟悉Linux命令的用户来说几乎是零门槛上手。
  2. 调试与探索利器 ：当你不确定Dockerfile的某条指令是否有效，或者想快速验证一个复杂环境的配置时，可以先用 run -it 进入容器手动配置，成功后再 commit 保存结果。这个结果可以作为编写Dockerfile的参考。
  3. 快速保存临时状态 ：在紧急问题排查或演示环境搭建时，可以快速将一个配置好的复杂环境固化为镜像，方便分发和重现。

6.2 Commit方式的致命缺点

  1. 缺乏可重复性（不可移植） ：这是最大的问题。 commit 生成镜像的过程依赖于你手动输入的命令、当时的网络状态、软件源版本等。你无法保证一个月后，另一个人（甚至你自己）能用同样的操作得到完全一致的镜像。而Dockerfile是一个文本文件，只要基础镜像不变， docker build 命令总能生成一致的镜像。
  2. 构建过程不透明（黑盒） ：镜像里到底做了什么？除了你提交时写的 -m 信息，没有其他记录。后续维护者无法了解安装了什么软件、修改了哪些配置、为什么要这么做。Dockerfile则提供了清晰的、可版本控制的构建蓝图。
  3. 镜像臃肿 ：手动操作很容易引入不必要的文件（如缓存、日志、临时文件），导致镜像体积无谓增大。Dockerfile可以通过精心设计的指令链（如 && 连接命令、最后清理缓存）来优化层，减小体积。
  4. 无法利用层缓存 ：Dockerfile构建时，如果某一层及之前的层没有变化，Docker会直接使用缓存，极大加快构建速度。 commit 是生成一个全新的完整快照，无法享受这种缓存加速。
  5. 难以自动化 ： commit 无法集成到CI/CD流水线中。现代软件开发依赖自动化构建、测试和部署， commit 的手动特性与此背道而驰。

6.3 从Commit到Dockerfile的转换

我们上面手动操作的步骤，完全可以（也应该）转化为一个Dockerfile。对比一下，你会立刻明白Dockerfile的优势： 

# Dockerfile
FROM ubuntu:22.04

RUN apt update && \
    apt install -y nginx curl && \
    apt clean && \
    rm -rf /var/lib/apt/lists/*

RUN mv /var/www/html/index.nginx-debian.html /var/www/html/index.nginx-debian.html.bak

COPY custom-index.html /var/www/html/index.html

CMD ["nginx", "-g", "daemon off;"]

然后，在同目录下准备好 custom-index.html 文件，执行 docker build -t my-nginx-dockerfile:v1 . 。

这个Dockerfile清晰、可重复、可版本控制、易于自动化。 因此，一个重要的经验法则是：一旦你通过 commit 验证了你的环境配置是可行的，下一步就应该立即着手将其转化为Dockerfile。

7. 常见问题与排查技巧实录

在实际操作 docker commit 时，你可能会遇到以下问题。这里我记录了一些踩过的坑和解决方法。

7.1 问题：提交镜像时，容器必须处于运行状态吗？

答案：不是必须的。 容器处于 Exited （停止）状态时，同样可以 commit 。Docker提交的是容器的文件系统快照，与其中进程是否运行无关。实际上，提交一个已停止的、状态稳定的容器是更常见的做法，可以避免提交时正好有数据在写入导致的不一致。

7.2 问题：Commit后，原容器的数据卷（Volume）内容会被保存吗？

答案：不会。 这是一个关键陷阱。Docker的数据卷（ -v 或 --volume 创建的）是独立于容器生命周期的持久化存储。 docker commit 操作 不会 将数据卷中的内容打包进新镜像。它只提交容器可写层（即 / 根目录下，除了挂载为Volume的路径）的变更。

例如，如果你运行容器时使用了 -v /host/path:/container/data ，那么你对 /container/data 目录做的所有修改，都实际保存在主机 /host/path ，而不会进入镜像。新镜像运行时，如果挂载了新的卷，该目录将是空的或由卷内容决定。

7.3 问题：Commit的镜像特别大，如何优化？

现象 ：一个基础的Ubuntu镜像可能只有80MB，但安装一些软件后 commit 的镜像可能达到300MB甚至更大。

原因与排查 ：

  1. 未清理包管理器缓存 ： apt 、 apk 、 yum 在安装软件后，会在本地留下下载的软件包缓存（ .deb 、 .apk 、 .rpm 文件）。这些缓存文件对于容器运行毫无用处，却会极大地增加镜像体积。
  2. 安装了不必要的推荐包或文档 ： apt install 默认会安装推荐的包。有些软件包会附带 -doc 包或大量手册页。
  3. 在容器内生成了日志、临时文件 ：操作过程中可能无意中产生了大文件。

解决方案 ：

  • 提交前手动清理 ：在容器内执行清理命令。 
    # 对于基于Debian/Ubuntu的容器：
apt clean && rm -rf /var/lib/apt/lists/*
# 对于基于Alpine的容器：
apk cache clean
# 对于基于CentOS/RHEL的容器：
yum clean all && rm -rf /var/cache/yum
  • 使用 --change 参数 ：虽然不能直接清理，但可以在提交时设置环境变量，提醒未来运行时要节约资源。
  • 根本方法 ：还是使用Dockerfile，在 RUN 指令中一条命令完成安装和清理，例如： RUN apt update && apt install -y package && apt clean && rm -rf /var/lib/apt/lists/* 。

7.4 问题：如何查看Commit镜像的构建历史？

现象 ：拿到一个用 commit 创建的镜像，想知道它到底做了什么。

排查命令 ： 虽然 commit 没有Dockerfile那样的清晰历史，但我们可以通过以下命令窥探一二：

  1. docker history my-ubuntu-nginx:v1 ：这个命令会显示镜像的层级历史。对于 commit 创建的镜像，通常只会看到一层巨大的变更，显示为 <missing> 或 /bin/sh -c #(nop) ，信息量很少。但如果你在 commit 时用了 --change ，这里可能会显示对应的指令。
  2. docker inspect my-ubuntu-nginx:v1 ：查看镜像的详细元数据，重点关注 Config.Cmd 、 Config.WorkingDir 、 Config.Env 等，这些能反映容器的默认配置。 Comment 字段可能包含 -m 提交的信息。
  3. 对比分析 ：运行新镜像和基础镜像的容器，对比文件差异是最直接的方法。 
    # 创建一个临时容器并导出其文件列表
docker run --rm my-ubuntu-nginx:v1 find / -type f | sort > new_image_files.txt
docker run --rm ubuntu:22.04 find / -type f | sort > base_image_files.txt
# 使用diff工具比较（需在主机上安装diff）
diff -u base_image_files.txt new_image_files.txt | less
    这能帮你找出所有新增和修改的文件，但工作量较大。

7.5 问题：误操作提交了，如何回退或管理镜像？

镜像管理命令 ：

  • 列出镜像 ： docker images 或 docker image ls
  • 删除镜像 ： docker rmi <image_id_or_name> 。如果镜像有容器（即使已停止）依赖它，需要先删除容器或加 -f 强制删除。
  • 给镜像打新标签 ： docker tag my-ubuntu-nginx:v1 my-ubuntu-nginx:latest 。这常用于将某个版本标记为最新。
  • 查找悬空镜像 ： commit 可能会产生一些没有标签的中间镜像（悬空镜像），占用空间。可以用 docker images -f “dangling=true” 查看，并用 docker image prune 清理。

无法真正“回退” ：Docker本身没有针对 commit 的版本回退命令。如果你发现 commit 的镜像有问题，通常的做法是：

  1. 找到之前稳定的镜像标签，基于它重新运行容器进行操作。
  2. 或者，如果你有Dockerfile，就重新构建。
  3. 因此， 为重要的 commit 镜像打上清晰的版本标签至关重要 ，这是你唯一的“快照”管理手段。

8. 实战扩展：基于Commit的简易工作流示例

尽管有诸多缺点，但在某些特定场景下，基于 commit 的简易工作流依然能发挥作用。下面分享一个我过去用于快速搭建演示环境的工作流。

场景 ：需要为一个Python Web应用（使用Flask框架）快速制作一个包含所有依赖和测试数据的演示镜像。应用依赖复杂，且有一些需要交互式配置的步骤。

工作流步骤 ：

  1. 启动一个干净的基础镜像容器 ： 

    docker run -it --name flask-demo python:3.9-slim /bin/bash

  2. 在容器内进行交互式配置 ： 

    # 进入容器后
pip install flask redis pandas  # 安装依赖
mkdir /app
cd /app
# ... 通过wget或curl从内部网络下载应用代码包 ...
tar -xzf app.tar.gz
# ... 交互式地运行数据库初始化脚本，回答一些配置问题 ...
# ... 导入一些初始数据 ...
# 配置完成后，测试应用能正常运行
python app.py &
curl http://localhost:5000/health

  3. 清理与提交 ： 

    # 停止测试进程
pkill -f app.py
# 清理pip缓存
pip cache purge
# 退出容器
exit

    在主机上提交镜像： 

    docker commit \
  -m "Flask demo app with Redis and sample data. Configured for internal demo." \
  -a "Dev Team" \
  --change='WORKDIR /app' \
  --change='CMD ["python", "app.py"]' \
  --change='EXPOSE 5000' \
  flask-demo \
  internal/flask-demo:20240418

  4. 分发与运行 ： 

    # 保存为压缩文件，方便邮件或内部网盘分发
docker save internal/flask-demo:20240418 -o flask-demo-20240418.tar
# 接收方加载镜像
docker load -i flask-demo-20240418.tar
# 运行
docker run -d -p 5000:5000 --name demo internal/flask-demo:20240418

这个工作流的关键在于： 它明确服务于“一次性”或“临时性”的演示目的 ，并且整个环境配置过程复杂、交互性强，用Dockerfile描述反而困难。在完成演示后，这个镜像的使命就结束了，不会进入正式的开发-构建-部署流水线。

最后必须再次强调 ，这个工作流是特定场景下的妥协。一旦这个演示应用需要迭代更新，或者需要部署到更多环境，第一件要做的事就是根据容器内最终的状态，反推出一个尽可能精确的Dockerfile，将构建过程标准化、自动化。 docker commit 是你探索和验证的脚手架，而不是建造房屋的永久结构。

Logo
亚马逊云科技技术品牌专区

更多推荐

open-code-review Codex 插件教程：对话式调用评审技能指南

本文是一份面向新手的 **open-code-review Codex 插件教程**，教你在 Codex 中通过对话式方式调用 open-code-review 的 AI 代码评审技能。open-code-review 是阿里巴巴开源的 AI 代码评审工具，采用"确定性流水线 + LLM Agent"混合架构，内置多语言评审规则（NPE、线程安全、XSS、SQL 注入等），可在 Codex 里用一

avatar 亚马逊云科技技术品牌专区

OBS Studio 完整指南：免费开源录屏与直播软件从零上手

想做一场像模像样的直播，或者把屏幕内容录成教程视频，但一想到商用软件的订阅费就有些犹豫？其实你不需要花一分钱。OBS Studio 是一款免费开源的直播与录屏软件，支持 Windows、macOS 和 Linux，采集、混音、编码、推流、录制，一条流水线全包了。## 先搞清楚 OBS Studio 是什么OBS Studio 是一个"场景化"的采集合成工具：你把摄像头、窗口、浏览器、图片、

avatar 亚马逊云科技技术品牌专区

如何用MediaCrawler爬取小红书抖音数据？7大平台爬虫从安装到实战完整指南

MediaCrawler 是一个支持小红书、抖音、快手、B站、微博、百度贴吧、知乎的开源自媒体数据采集工具。它能按关键词、按帖子、按创作者主页三种方式抓取笔记/视频内容、评论甚至二级评论，并把结果存成 JSON、CSV、Excel 或数据库。适合做市场调研、竞品监控、内容选题的运营人员，以及想要现成爬虫框架而不想从零写 JS 逆向的开发者。## 从一次"手动抄数据"说起想象这个场景：你负责

avatar 亚马逊云科技技术品牌专区